This chapter is from the book
This chapter is from the book
This chapter is from the book
8.4 Overloading
The previous section dealt with the issue of adjusting the size of LSAs and LSPs to existing link bandwidth—the assumption being that in large networks OSPF Updates and IS-IS can become very large. There is a "flip side" to this issue: What happens when a router’s memory is not large enough to store all of the LSA/LSPs being flooded in an area? We know that all link state databases in an area must be identical. If the memory allocated to storing the link state database becomes full so that not all information can be recorded, the SPF calculation at that router will likely be incorrect. The router then cannot be trusted to route correctly on the shortest-path tree and should not be included as a transit node.
IS-IS has a facility for coping with this situation. If the database memory fills up—that is, if the memory becomes overloaded—the router notifies the other routers in the area by setting the Overload (OL) bit in its LSAs (Figure 8.43). The other routers in the area treat an overloaded router as a leaf router on the shortest-path tree: It is included for reachability of its directly connected links, but not as a transit path to other routers.
)
Figure 8.43 The Overload (OL) bit, when set, signals to other routers in the area that the originator’s database memory is overloaded.
Like several other features of OSPF and IS-IS, both of which were created in the days when routers were sharply limited in CPU power, memory capacity, and throughput time, the original intention of the overload mechanism is now mostly irrelevant. Modern core routers have enormous memory capacity that will not be overloaded by IS-IS in any intelligently designed network.13
However, unlike other now-obsolete features of OSPF and IS-IS, the OL bit is tremendously useful in modern networks for a reason that has nothing to do with memory depletion: helping to prevent unintentional blackholing of packets in BGP transit networks. To understand this function, you must understand some basics of BGP. Figure 8.44 shows a very simple BGP transit network, AS 65502. BGP is used for routing through the AS between AS 65501 and AS 65503. BGP is a point-to-point protocol, running over TCP sessions. The sessions running between the autonomous systems are External BGP (EBGP), and the sessions running internal to an autonomous system are Internal BGP (IBGP). Whereas EBGP sessions are usually14 between directly connected neighbors, IBGP sessions often pass through several routers internal to the AS. In Figure 8.44, the IBGP session between RTR A and RTR E passes through three internal routers. When RTR A and RTR E exchange routes learned from their EBGP neighbors, they show their RIDs (normally loopback addresses) as the next-hop address of the routes.15 IBGP depends on the AS’s IGP for two things:
Finding the route through the AS to its IBGP peers for establishing its point-to-point TCP sessions
Finding the routes to the next-hop addresses of the external routes advertised by its IBGP peers
)
Figure 8.44 IBGP relies on the autonomous system’s IGP to find its IBGP peers and the next-hop addresses of the external routes advertised by its IGP peers.
If RTR A in Figure 8.44 needs to route a packet to a destination in AS 65503, it performs a route lookup and finds that the next hop for the route is RTR E, at 10.1.1.5. It then performs a second lookup for 10.1.1.5 and finds that the next hop for that destination is RTR B. The packet is then forwarded to RTR B. If the IBGP session shown in Figure 8.44 were the only IBGP session in the AS, there would now be a problem. Because RTR B has no IBGP session with RTR E, it cannot learn the external routes RTR E is advertising. So when RTR B receives the packet, it has no route entry for the destination in AS 65503 and drops the packet.
Therefore, in a transit AS, it is necessary to create a full mesh of IBGP sessions as shown in Figure 8.45.16 Each internal router learns the external routes via IBGP. Now, when the packet in our example is forwarded from RTR A to RTR B, RTR B and subsequent routers along the path to RTR E can perform the correct lookups to get the packet to RTR E.
)
Figure 8.45 A full mesh of IBGP sessions is necessary for the non-EBGP routers to know how to forward packets transiting the AS.
But a potential problem lurks in the network, stemming from the nature of IGPs and BGP: OSPF and IS-IS converge very quickly, whereas BGP, which must first establish TCP sessions and then exchange tens or hundreds of thousands of routes, converges quite slowly. A BGP session carrying a full Internet routing table can take several minutes to converge. Suppose RTR C in Figure 8.45 is restarted intentionally or otherwise. The IGP routes will become known quickly, so that RTR A and RTR B again learn the route to RTR E through RTR C. If a packet to an AS 65503 destination is forwarded on the route after the IGP has converged but before IBGP has finished converging at RTR C, RTR C will not recognize the destination and will drop the packet.
This is where the OL bit comes in handy. When a new IBGP router is added to the network, or a router is restarted, the IS-IS OL bit can be manually set. Because directly connected addresses on an overloaded router—including the loopback address that serves as an endpoint for IBGP sessions—are considered reachable by the other routers in the AS, IBGP can be brought up and can begin exchanging routes. However, the other routers will not include the overloaded router for transit traffic, and so will route packets transiting the AS on an alternate path. (In a correctly designed transit AS, unlike the simple example AS of Figure 8.45, there is always at least one alternate path.) When BGP has converged, the OL bit can be cleared and the router can then begin forwarding AS-transit packets.
In some special cases, you might want to leave the OL bit permanently set, so that the router has full network knowledge and other routers know its stub links, but the router is never used for transit traffic. Examples include routers that are connected for analysis purposes but should not be considered part of the production network, such as lab or network management routers, and IBGP route reflectors that you want to perform only as BGP route servers and not as transit nodes.
The OL bit is manually set in IOS with the command set-overload-bit and in JUNOS with the command overload. Removing the command from the configuration clears the OL bit. But remembering to set and then clear the OL bit whenever you add or restart a router is a hassle, and unplanned restarts give you no chance to use the OL bit. Both IOS and JUNOS have a very useful option—set-overload-bit on-startup in IOS and overload timeout in JUNOS—that allows you to specify a number of seconds that the OL bit is set automatically during startup. When the specified seconds expire—200 to 400 seconds is usually a reasonable period for allowing BGP to converge—the OL bit is automatically cleared. The option is highly recommended in any IBGP network.
OSPF has no comparable feature to the OL bit in its LSAs. However, some vendor implementations include a mechanism by which you can create the same kind of behavior in an OSPF area by setting the metric of all transit links on an "overloaded" router to 0xFFFF in its type 1 LSAs. This metric indicates that the links are unreachable, so that the router is not included as a transit node on the SPF tree. Stub links connected to the router are advertised with their normal metrics, so that they are still reachable when the router is in overload. OSPF overloading is supported in JUNOS, for example, using the same overload command, and allowing the same optional automatic overload timeout at startup, as with IS-IS.