topic Doesn't work....more in Routing and SD-WAN

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

owaisberg — Tue, 05 Mar 2019 11:28:15 GMT

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

This hurts my head. I'm

Philip D'Ath — Wed, 02 Mar 2016 03:27:12 GMT

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

Thank you Philip,

owaisberg — Wed, 02 Mar 2016 04:00:45 GMT

Thank you Philip,

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

It doesn't work. Multiple

owaisberg — Wed, 02 Mar 2016 04:47:08 GMT

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 ...

Another approach you could

Philip D'Ath — Wed, 02 Mar 2016 06:31:01 GMT

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

Doesn't work....more

owaisberg — Wed, 02 Mar 2016 15:20:23 GMT

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.

I can't think of any other

Philip D'Ath — Wed, 02 Mar 2016 19:09:09 GMT

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.

Well, original issue, why I

owaisberg — Wed, 02 Mar 2016 19:58:34 GMT

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

Have you considered using

Philip D'Ath — Wed, 02 Mar 2016 19:58:35 GMT

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.

I'm not following why it

Jon Marshall — Wed, 02 Mar 2016 20:20:16 GMT

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

Hi Jon,

owaisberg — Wed, 02 Mar 2016 20:54:28 GMT

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.

Hi Philip, Looks like a great

owaisberg — Wed, 02 Mar 2016 21:03:29 GMT

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

Sorry to keep asking

Jon Marshall — Wed, 02 Mar 2016 21:06:27 GMT

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

It's fine. Branch subnets are

owaisberg — Wed, 02 Mar 2016 21:14:14 GMT

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

So if there is no

Jon Marshall — Wed, 02 Mar 2016 21:31:08 GMT

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

Yes, first statement is

owaisberg — Wed, 02 Mar 2016 21:36:26 GMT

Yes, first statement is correct, if MPLS goes down, then no prefixes are to be redistributed into the branch LAN on CE and all the prefix exchange shifts to iBGP backup (I've just updated the diagram, marking where is what for clarity).

Your second statement: it could be a potential work around, however the CEs are owned by the SP so it requires their involvement plus they may simply refuse. As well that will have to be done on all the CEs and we are talking multiple sites, pretty painfull thing.

Thanks again.

No problem I understand.

Jon Marshall — Wed, 02 Mar 2016 21:43:07 GMT

No problem I understand.

So again, just thinking out loud, is there any chance within the branch you can advertise a summary route for the branch subnets via IBGP across the backup link ?

That way when the CE interface came back up it would have a summary for it's own branch subnets from EBGP but more specific EIGRP routes from within the branch itself.

Jon

Unfortunately this is not an

owaisberg — Wed, 02 Mar 2016 22:02:10 GMT

Unfortunately this is not an option, as each branch router has a bunch of networks and subnets that cannot be summarized as they are all over the map 😞

Just out of interest you

Jon Marshall — Wed, 02 Mar 2016 22:19:52 GMT

Just out of interest you mentioned GRE tunnels and running EIGRP everywhere, can you not run the tunnel from the branch router itself to the hub router ie. why does it need to be between the CE devices ?

That aside one final idea for the day before logging off.

Use EEM on the branch router and if the CE EIGRP neighbor goes down then configure a "redistribute eigrp <AS no>" under your BGP configuration on the branch router.

If it comes back up then remove that command.

There would be a delay for the routes to propagate but there would be anyway with your original idea.

If I think of anything else tomorrow I'll post back 🙂

Jon

Little late to the party on

Tyler Conrad — Wed, 05 Oct 2016 18:18:16 GMT

Little late to the party on this one, but found it while searching for something similar and decided to take a shot.

Try this - doing it from memory, so cli syntax may be a little off.

neighbor x.x.x.x advertise-map ADVERTISEDROUTES non-exist-map TRACKEDROUTE

track 5 ip route 192.0.2.50/32 reachability

track 6 ip route 192.0.2.51/32 reachability

track 10 list boolean AND

object 5

object 6

ip route 192.0.2.1/32 track 10

route-map ADVERTISEDROUTES permit 10

match ip address prefix-list YOURADVERTISEDROUTES

route-map TRACKEDROUTE permit 10

match ip address prefix-list TRACKED

ip prefix-list TRACKED permit 192.0.2.1/32

Redistribute that static /32 route using a route-map to BGP, and then if either of the tracked objects go down, the /32 will be withdrawn, and your conditional advertisement will be advertised.