IBGP as an IGP

By stretch | Monday, March 14, 2011 at 12:33 a.m. UTC

A BGP adjacency can be described as either internal (between two routers in the same autonomous system) or external (between two routers in different autonomous systems). The same protocol is run in either case, with just a few tweaks to the way route advertisement is handled. The term "internal" leads many newbie networkers to consider the potential deployment of IBGP as an interior routing protocol. Although this is typically and appropriately dismissed as a bad idea, few people take the time to examine the reasoning behind the conclusion. This article discusses five major weaknesses of IBGP as interior routing protocol. It is important to understand that this article does not assert that IBGP cannot function as an interior routing protocol. Rather, it explains why IBGP is a poor choice for the role given the availability of alternative protocols.

No Dynamic Neighbor Discovery

One of the major features of all modern interior routing protocols is the ability to automatically discover and form adjacencies with neighboring routers on links with broadcast capability. BGP, by contrast, requires the explicit configuration of all neighbors. While it may be desirable to always statically configure neighbors in any routing protocol for security reasons, dynamic neighbor discovery is a valuable feature for less hands-on network deployments.

Complex Path Selection Process

IGPs determine the best path for a destination based on relatively simple metrics. EIGRP uses a combination of overall delay and minimum available bandwidth, whereas OSPF and IS-IS use link cost. All of these are easily tuned to meet the needs of the network operators. In all cases, the route with the lowest metric wins. BGP, on the other hand, employs a rather complex path selection process to determine the best route for a destination. By default, no meaningful metric is carried by IBGP advertisements within an autonomous system (AS).

The Full Mesh Requirement and Route Recursion

By default, a BGP router will not advertise a network learned from one IBGP peer to another. If IBGP is used as an IGP, this presents severe scaling problems; every router would have to peer with every other router on the network. The full-mesh requirement can be overcome by carefully designating intermediate routers as route reflectors, but we're still left with the issue of excessive route recursion. Consider the topology below, where R2 and R3 are reflecting IBGP routes between their neighbors.

Although end-to-end connectivity is achieved, the routing tables on R1 and R4 are needlessly complex. R1's table looks like this: R1# show ipv6 route IPv6 Routing Table - 10 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 http://packetlife.net/blog/2011/mar/14/ibgp-igp/ Page 1

C L B B B C L B B L

I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external 2001:DB8:0:1::/64 [0/0] via ::, Loopback0 2001:DB8:0:1::1/128 [0/0] via ::, Loopback0 2001:DB8:0:2::/64 [200/0] via 2001:DB8:0:12::2 2001:DB8:0:3::/64 [200/0] via 2001:DB8:0:23::3 2001:DB8:0:4::/64 [200/0] via 2001:DB8:0:34::4 2001:DB8:0:12::/64 [0/0] via ::, FastEthernet0/0 2001:DB8:0:12::1/128 [0/0] via ::, FastEthernet0/0 2001:DB8:0:23::/64 [200/0] via 2001:DB8:0:12::2 2001:DB8:0:34::/64 [200/0] via 2001:DB8:0:23::3 FF00::/8 [0/0] via ::, Null0

In order for CEF to resolve the next hop address of, for example, 2001:db8:0:4::1, it must perform a recursive lookup for every hop in the BGP path. In this case, this requires three lookups: 2001:DB8:0:4::/64 via 2001:DB8:0:34::4 2001:DB8:0:34::/64 via 2001:DB8:0:23::3 2001:DB8:0:23::/64 via 2001:DB8:0:12::2 (which is directly connected)

This recursive resolution is performed only in response to routing updates, not per packet, but it does introduce significant convergence delays. The following output from debug ip cef table shows that routes with next hops which cannot be immediately resolved are queued for later processing. (The example below is from a similar IPv4 topology, as the IPv6 version of the command produced no output.) CEF-Table(Default-table): Event up 10.0.4.0/24 (rdbs:1, flags:1A00000) CEF-Table: attempting to resolve 10.0.4.0/24 CEF-IP: can't resolve 10.0.4.0/24 via 10.0.34.4 CEF-IP: Failed to instantly resolve recursive entry 10.0.4.0/24, queued for background resolution Compare the routing table above to the one produced by OSPFv3 running on the same topology. Every route is advertised with a directly connected next hop address, removing the burden of route recursion. R1# show ipv6 route IPv6 Routing Table - 10 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external C 2001:DB8:0:1::/64 [0/0] via ::, Loopback0 http://packetlife.net/blog/2011/mar/14/ibgp-igp/ Page 2

L O O O C L O O L

2001:DB8:0:1::1/128 [0/0] via ::, Loopback0 2001:DB8:0:2::/64 [110/11] via FE80::C002:18FF:FEE5:0, 2001:DB8:0:3::/64 [110/21] via FE80::C002:18FF:FEE5:0, 2001:DB8:0:4::/64 [110/31] via FE80::C002:18FF:FEE5:0, 2001:DB8:0:12::/64 [0/0] via ::, FastEthernet0/0 2001:DB8:0:12::1/128 [0/0] via ::, FastEthernet0/0 2001:DB8:0:23::/64 [110/20] via FE80::C002:18FF:FEE5:0, 2001:DB8:0:34::/64 [110/30] via FE80::C002:18FF:FEE5:0, FF00::/8 [0/0] via ::, Null0

FastEthernet0/0 FastEthernet0/0 FastEthernet0/0

FastEthernet0/0 FastEthernet0/0

Convergence Delays
Configured with its default 10-second hello timer and 40-second dead timer, OSPF will take between 30 and 40 seconds to react to an indirect adjacency failure (that is, a failure which does not transition the interface status). BGP's default hello and hold timers are 60 and 180 seconds, respectively; BGP can take up to three minutes to respond to an indirect failure. The two log messages below were generated by the OSPF and BGP processes in response to the same failure; the BGP notification occures more than two minutes after the OSPF notification.

00:19:37: %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down 00:21:42: %BGP-5-ADJCHANGE: neighbor 2001:DB8::2 Down BGP Notification sent Although the timers of both protocols may be tuned to much lower values, these default values provide an idea of how quickly either protocol is intended to react. Configuring BGP's hold time to less than 20 seconds on IOS invokes the following warning: Router(config-router)# timers bgp 5 15 % Warning: A hold time of less than 20 seconds increases the chances of peer flapping It is also worth noting that in Cisco IOS, BGP adjacencies are not tied to the state of an interface as is an IGP like OSPF; whereas an OSPF adjacency over an interface is deleted immediately upon shutting the interface down, a BGP adjacency will be maintained until it times out. BGP was intended to function so long as any path to an adjacent router is available; it is not bound to any particular interface.

Licensing
Finally, the right-to-use licensing for router software which supports BGP often costs more than a basic license with only IGP support. This is an especially important decision when implementing a routed access edge. Posted in Routing

http://packetlife.net/blog/2011/mar/14/ibgp-igp/

Page 3