Recently I was working for a client that had resilient Internet connections. As is commonplace these days, the customer used BGP peering with their ISP. They did not, however, run iBGP between their internal ISP peer points. Instead, they redistributed their routing into EIGRP and then allowed each data centre to make local decisions based on EIGRP metrics to their local Internet connections – and relied on RIB failures to sort out which was preferred.
- Network Diagram
(click for full size diagram)
The issue with this is, in order to get RIB failure to work like this, the admin distance of eBGP routes have to be increased, or EIGRP decreased, at the backup site.
This is how the default route appeared within the EIGRP network before tweaking the admin distance:
D*EX 0.0.0.0/0 [170/2562816] via 192.168.1.5, 00:00:06, GigabitEthernet2/0
[170/2562816] via 192.168.1.1, 00:00:06, GigabitEthernet1/0
and on the backup router peering with the Internet after changing the admin distance:
show ip bgp Network Next Hop Metric LocPrf Weight Path r> 0.0.0.0 10.1.1.5 0 0 1 i show ip route | i 0.0.0.0 D*EX 0.0.0.0/0 [170/2563072] via 192.168.1.6, 00:01:52, GigabitEthernet2/0
If the only route accepted was a default route from the Internet, this would not have represented as much of an issue. However, they also made use of extranet partners. To complicate the matters even further, the “backup” site was sometimes primary for these extranets and complex route-maps were required to get around these issues. I felt while working on this network that we were only one misconfiguration away from the entire thing falling in a limp heap of routing loops and / or lost connectivity.
What would have been a far more scalable and standard approach was to use iBGP between the peering points and allowing BGP to resolve its BGP database before redistribution. Then RIB failure would work the way it was designed; only on iBGP routes and without the requirement for BGP admin distance changes. In addition, the standard BGP control mechanisms of Local Preference / AS Prepending / MED can then be used to control routing.
In the case below, the default route has been marked with a local preference of 200 in the primary site. The output shows that both the iBGP and the eBGP learnt prefixes are RIB failed.
show ip bgp Network Next Hop Metric LocPrf Weight Path r>i0.0.0.0 10.1.1.1 0 200 0 1 i r 10.1.1.5 0 0 1 i show ip route | i 0.0.0.0 D*EX 0.0.0.0/0 [170/2563072] via 192.168.1.6, 00:01:15, GigabitEthernet2/0
From the output above we can see that External EIGRP is the preferred route – even though there is an eBGP prefix, which is itself suppressed due to the iBGP prefix having a higher Local Preference. The moral of this story is that there is a right and wrong way to design networks, and “working” is not good enough.
