BGP conditional advertisement with non-exist-map - can we modify logic

[owaisberg]

Hi,

I need to implement BGP conditional advertisement with non-exist-map, but in a different logic.

As by the book, BGP will advertise prefixes listed in advertise-map only if the routes matched in

non-exist-map do not exist, but if at least one of them exists - advertisement will be withdrawn.

Now, I am trying to find a way to initiate advertisement through BGP if  ANY of the routes in the 

non-exist-map doesn't exist. Other words, if at least one of the prefixes within the non-exist-map

doesn't exist, BGP will start advertisement.

Tried to play with a non-exist-map route-map using multiple seq. entries for different routes - no

success. Tried to use multiple "neighbor x.x.x.x addvertise-map" lines with same advertise-map

and different non-exist-map route-maps to reflect multiple routes looks like no success either,

as soon as one of the conditions matches to be withdrawn, next one even if matches to be as

advertised, has no effect and BGP sends no advertisements. Hope there is a trick to go around

this limitation.

Thanks in advance

[Philip D'Ath]

This hurts my head.  I'm thinking if the non-exist route-map returns a match then nothing happens.  If a match fails then the non-exist prefix list is injected.

I'm thinking using multiple match criteria might do this, where each prefix list contains one route to be monitored.  So for below, if all match criteria are met (and this is a logical "and") then a match will be returned.  If any of them are missing, then a failure will be returned.

route-map NON-EXIST permit 10 
 match ip address 10
 match ip address 20
 match ip address 30

[owaisberg]

Thank you Philip,

Let me test it and come back to you if it works. Thanks

[owaisberg]

It doesn't work. Multiple "match" statements to get logical AND get collapsed into one line "match ip address ACL1 ACL2" making it logical OR which will result in "combined route does exist" so do not Advertise ...not even sure IOS will allow that to be set to an AND logic ...

[Philip D'Ath]

Another approach you could try.  No idea if it will work.  What I am doing here is setting the metric to 0, and then bumping the metric by 10 for each match, and then in the final match I'm see if if the metric came to 30 (for 3 tests), meaning all prior matches were also true.

If even one route doesn't match, then the metric would be smaller.

route-map NON-EXIST permit 1 
 set metric 0
 continue
route-map NON-EXIST permit 10
 match ip address 10
 set metric +10
 continue
route-map NON-EXIST permit 20
 match ip address 20
 set metric +10
 continue
route-map NON-EXIST permit 30
 match ip address 30
 set metric +10
 continue
route-map NON-EXIST permit 100
 match metric 30

[owaisberg]

Doesn't work....more precisely not supported by IOS:

RTR-WAN-2(config-route-map)#continue
% "NON-EXIST" used as BGP condition route-map, continue match not supported

If you try first to create a route map and then apply it to BGP process, will get

the same message. Looks like a complete no go for initial scenario I wanted to

implement.

[Philip D'Ath]

I can't think of any other creative answers sorry. Perhaps re-examine the topology and see if you can solve it that way.  Maybe a "backdoor" GRE tunnel could be used as a backup interface to cause routes to be injected.

[owaisberg]

Well, original issue, why I wanted to employ this feature is a design for a backup WAN connection running over L2 MPLS with iBGP, and the main connection running over L3 MPLS. Branch and hub LANs running EIGRP. L3 MPLS provider running eBGP on PE-CE links and that brinngs lots of pain when you try and design fully automatic fail over and reconverging back. Idea was to monitor multiple PE-CE links on their presense within BGP tables and if they absent to start advertising prefixes via backup WAN iBGP sessions to reach the hub site. Otherwise if I advertise all the time - I can failover from EIGRP to iBGP but when EIGRP comes back it doesn't get into effect due to the fact that CEs see earlier learned prefixes via eBGP from MPLS cloud since it's simply has better AD. I'm attaching a small diagram for you to look. If I run EIGRP on PE-CE link everything works like a charm - fully automated failover and reconvergance back after service restored

[Philip D'Ath]

Have you considered using EIGRP OTP?

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/ire-xe-3s-book/ire-eigrp-over-the-top.html

I think this would be a great use for it.  Use OTP between the branch and hub directly.

[owaisberg]

Hi Philip, Looks like a great feature. However it looks like it can run only on Cisco IOS XE Release 3.10S/15S and my routers in here are pretty ancient.

There is another option is running GRE from CE to CE to make all EIGRP prefixes of type internal and then run EIGRP on the backup WAN which will be internal as well as it is L2, however it will require ISP involvement as CEs are owned by them. As well may be to force ISP to carry EIGRP via MPLS core like type internal or even simply ask them to switch to EIGRP on PE-CE link....all these solutions will require ISP to step in and that's what I'm trying to avoid.

Thanks again

[Jon Marshall]

I'm not following why it doesn't go back to the L3 MPLS link.

If you advertise the routes via both links the presumably you are redistributing EBGP into EIGRP and these are AD 170 which is better than IBGP.

If the L3 MPLS link fails then IBGP is used but if the link comes back up it then redistribute EBGP back into EIGRP ?

Are you redistributing EIGRP into BGP as well for the L3 MPLS connection ?

Can you clarify what is redistributing where and what the actual issue is ?

Jon

[owaisberg]

Hi Jon,

Here are couple clarifications: Within the branch office, the only redistribution configured is on the CE router, where eBGP  from PE-CE link is redistributed into EIGRP that facing a couple office routers. On these two routers there is no redistribution between EIGRP and iBGP (of the Backup L2 MPLS). What happens is, let's say I have CE LAN facing interface goes down, branch fails over to iBGP, and MPLS as well learns about the branch site prefixes via its cloud and via the Hub (which is good so far). However, when we bring this CE interface back up, the CE sees branch LAN routes from two sources: LAN (EIGRP AD90) and MPLS (AD20 eBGP), so it chooses MPLS and never converge back pointing for the branch prefixes to the local EIGRP routers (instead points back to MPLS)....hope it clarifies the issue.  

[Jon Marshall]

Sorry to keep asking questions but are you saying at the hub site you are advertising out the branch subnets to the rest of the L3 MPLS network.

So if the branch CE LAN interface fails it gets routes from the L3 MPLS network for it's own branch subnets and then when the interface comes back up it still sees it's own branch routes via the L3 MPLS network.

Is that what you are saying ?

Jon 

[owaisberg]

It's fine. Branch subnets are advertised from the branch: both via iBGP (via backup WAN) and via EIGRP (towards MPLS), no redistribution at the branch routers  [only CE does that to inject prefixes into MPLS at the branch]. These prefixes make to the hub and then redistributed from iBGP into EIGRP (that's how MPLS sees them after the branch CE interface goes down).

Yes, your second statement is correct. That's what happens after CE's LAN interface comes back up, CE still chooses MPLS connection to get to the its own LAN prefixes since eBGP just more preferrable than restored LAN EIGRP

[Jon Marshall]

So if there is no redistribution at the branch (other than CE) then the branch routers use the backup link if the L3 MPLS link goes down so no routes from EBGP are redistributed into EIGRP ?

I am just wondering why you cannot change the AD of BGP on your CE device to be higher than EIGRP so your CE device chooses the EIGRP routes when the LAN interface comes back up.

Perhaps I am not understanding the full picture.

Jon