Selective BGP announcements based on EIGRP redistribution.

[Henry Pugsley]

This is a diagram of what I am dealing with (IP addresses changed to protect the innocent). It is a multi-homed network with Internet links at R1 and R5. R1 and R5 have a public AS to connect to the Internet, and a private AS to connect to internal routers. Don't ask why they did BGP -> BGP -> EIGRP when BGP -> EIGRP would have been sufficient All devices are Cisco ASR or 7206 routers with one Cisco 6509-E. The firewalls don't participate in routing so I left them out of the diagram.  There are actually more than 2 sites off the WAN (which is Layer2) but I left them out for brevity

In order to balance traffic, some networks hanging off R8 are routed to the Internet through R5. This is accomplished by manipulating the metric for 0.0.0.0/0 through R6 to look better than 0.0.0.0/0 through R2 for some sites -- this takes care of the outbound traffic. Inbound traffic is pulled in through R5 by advertising those R8 networks to the provider (shorter prefix). Unfortunately this is a static config which leads to problems in certain failure cases.

If R6 or R7 go offline, R5 currently has no way of knowing that the path is dead. Outbound traffic from R8 goes through R3-R2-R1 to reach the Internet, but R5 is still announcing so return traffic comes back in the wrong way and firewalls drop the traffic. The firewalls are between R1-R2 and R5-R6. Someone needs to manually kill the R5 announcement then put it back when R6/R7 are back online which leads to multiple outages.

Possible solution: on R7, tag routes from R8 networks before they are passed to R6. Configure R6 to redistribute these tagged routes to R5, which will in turn advertise them to the Internet. If R7 fails, the routes are never tagged and if R6 fails then the routes can't be passed to R5 anyway. It feels like a kludge but it should work.

Horrible solutions: someone proposed using EEM and TCL scripts to track network state to remove the announcements; I don't even want to think about writing this. Could also use ip tracking objects to do the same, but I'd rather stick to what the routing protocols can do natively.

Am I on the right track? Any potentially better solutions?

[Jon Marshall]

Couple of questions -

Inbound traffic is pulled in through R5 by advertising those R8 networks to the provider (shorter prefix). Unfortunately this is a static config which leads to problems in certain failure cases.

How is this done. Even if you used "network ..." statements under the BGP config on R5 the router still needs to find the corresponding network in the IP routing table.  So you are not actually receving the routes on R5 via the IBGP connection to R6 ?

The firewall between R5 and R6 it is passing an IBGP connection between R5 and R6 ?

Edit - they may be using BGP twice because with IBGP the neighbors do not need to be on the same subnet. If you used EIGRP all the way up to the R1 and R5 routers then you could not have adjacencies between R1 and R2 and R5 and R6 because the firewalls are another L3 hop between them (assuming the firewalls are in routed mode and not transparent mode) so the firewalls would either have to participate in the routing protocol or you have to track the state of the link to know when there is a failure.

If the firewalls were in transparent mode then you could peer with EIGRP between R1 and R2 and between R5 and R6.

Jon

[Henry Pugsley]

The firewalls are in routed mode, so there are static routes pointing from R1 and R5 to the outside interface of the firewalls.  This satisfies the requirement for BGP to have the route in the routing table before it will advertise it to a neighbor.  eBGP is configured between R1-R2 and R5-R6 (different AS) but they are currently setup so that R1/R2 *only* pass 0.0.0.0/0 down toe R5/R6, and R5/R6 are configured to pass no routes up to R1/R2 -- they pretty much took all of the intelligence out of the routing protocol and only use it pass a default route.

I've tossed around the idea of enabling EIGRP on the firewalls (ASAs) and moving the BGP/EIGRP redistribution point up to the Internet router.  It should be doable, I just don't have time to plan that sort of migration right now.

[Jon Marshall]

eBGP is configured between R1-R2 and R5-R6

Can you just confirm it is EBGP because your diagram suggests it is IBGP ie. R1/R2 and R5/R6 seem to be in AS 65000 ?

Jon

[Jon Marshall]

Sorry for the questions but need to understand the setup -

R1/R2 *only* pass 0.0.0.0/0 down toe R5/R6, and R5/R6 are configured to pass no routes up to R1/R2 -- they pretty much took all of the intelligence out of the routing protocol and only use it pass a default route.

Your diagram doesn't show this. It shows R5 receiving a default from AS 12345 or am i reading it wrong ?

Jon

[Henry Pugsley]

Guess I made the diagram too brief .. sorry.

Definitely eBGP.  R1 and R5 are configured with AS 12345, R2 and R6 are configured with AS 65000.  Here is a config snippet from R6 (R2 is configured the same way)"

router bgp 65000

bgp log-neighbor-changes

bgp redistribute-internal

neighbor xx.xx.xx.xx remote-as 12345

neighbor xx.xx.xx.xx description Internet

neighbor xx.xx.xx.xx ebgp-multihop 2

neighbor xx.xx.xx.xx soft-reconfiguration inbound

neighbor xx.xx.xx.xx prefix-list default-in in

neighbor xx.xx.xx.xx prefix-list none-out out

!

ip prefix-list default-in seq 5 permit 0.0.0.0/0

ip prefix-list none-out seq 5 deny 0.0.0.0/0

[Jon Marshall]

Okay, so the AS used for peering to your ISP is not AS 12345 ?

From the config posted -

neighbor xx.xx.xx.xx description Internet

but it's not the internet it's another of your routers. Like i say apologies for the questions but i don't want to suggest something without making sure i fully understand the topology.

Based on the diagram and your description (but not with the question above) if you are not redistributing EIGRP into BGP anywhere at the moment which it sounds like you aren't then yes the easiest thing is to redistribute EIGRP on R6 into EBGP and then remove the static routes on R5 pointing to the outside interface of the firewall.  You don't need to tag them on R7 you can simply specify which EIGRP routes to redistribute on R6 under the BGP config. 

Note, this assumes there is no EIGRP to BGP redistribution on any of the other routers. If there is then can you let me know because there could be further complications.

Jon

[Henry Pugsley]

Yes, 12345 is the public AS that peers with the upstream provider.

The problem with using the EIGRP/BGP redistribution point to advertise those routes without something to differentiate them is the fact that R6 learns those routes over two different links: R7 and R2.  Of course the R2 path has a horrible metric and won't be used unless R7 is down.  If R7 fails then R6 will learn the route via the WAN - R3 - R2 path and redistribute into BGP anyway ... unless I'm missing something?

[Jon Marshall · Accepted solution]

Yes, 12345 is the public AS that peers with the upstream provider.

There is something i am not understanding here.  You say the R6 peers with 12345 but it can't because R2 is in the way. Your diagram shows R6 using 65000 as the EBGP peering to R2 and R2 using 12345 to peer with the ISP and this makes sense. But your description doesn't. What does R2s config look like ?

The problem with using the EIGRP/BGP redistribution point to advertise those routes without something to differentiate them is the fact that R6 learns those routes over two different links: R7 and R2.  Of course the R2 path has a horrible metric and won't be used unless R7 is down.  If R7 fails then R6 will learn the route via the WAN - R3 - R2 path and redistribute into BGP anyway ... unless I'm missing something?

So whether R6 or R7 fail you want traffic to go out via R1 and come back on R1 (because of the firewall) so R5 needs to stop advertising 128.100.10.0/24 and 128.100.20.0/24 if either fails. Yes you do  need to to differentiate in that case because if you didn't when R7 fails R6 still gets those routes from R2 and so redsitributes and so R5 is still advertising those routes. So traffic would go from R8 -

R8 -> R3 -> R2 - R1 -> internet

internet -> R5 -> R6 -> R2 -> R3 -> R8

and this would present problems on your firewalls. 

So i think it was me overlooking the default route used down the R1 -> R2 -> R3 side.

So yes, you would need to tag the routes on R7 or you could do it on R6 with a "match ip route-source" specifying R7 as the route source depending on whether you are doing EIGRP to BGP redistribution anywhere else or not.

Jon

[Jon Marshall]

One other point. If you are using a static on R5 for 128.100.0.0/16 pointing to the firewall interface then i assume you are not actually going to get that as a route via R7  ie. it is a summary address. So you shouldn't remove that static, just the one for the EIGRP routes advertised from R8 to R7.

Do you prefer R2 for the 128.100.0.0/16 prefix ie. only traffic for 128.100.10.0/24 and 128.100.20.0/24 comes in via R5 and any traffic for other subnets comes in via R2 ?   I ask because If R6 fails then you need to stop advertising 128.100.0.0/16 via R5 to the internet.

Jon

[Henry Pugsley]

Good call on the static routes, I really need to clean those up.

R1 is the preferred path for the /16, there is actually a route-map on R5 that does an AS path prepend to dirty up the annoucements.  Both Internet links go through the same provider so they actually honor the path prepend and send traffic to R1 unless it is offline or there is a more specific annoucement from R5.

I did most of the config in GNS3 and it seems to be working properly, time to schedule a maintenance window.  Thanks for your help!