| Previous | Table of Contents | Next |
Convergence time factors may be negated somewhat by load balancing. OSPF supports up to four equal-cost paths per destination, which can maintain connectivity in the event of a single link failure. As with other routing protocols, designers should use the bandwidth command to accurately reflect the capacity of their links and optimize traffic flows.
|
Network Design in the Real World: OSPF OSPF configuration, done properly, can be more difficult than other protocols, as noted in the main text. However, many of the design concepts mandated by OSPF are well suited for other routing protocols. This is especially true for route summarization. There are two common issues with OSPF implementations. The first is the over-simplified model. The placement of all routers in area zero is affectionately called the over-simplified model. A surprising number of fairly large networks have deployed this model in the past, and many designers unfamiliar with OSPF may be tempted to do the same. The problem with this deployment is that it does not scale, and ultimately many of the benefits integrated into OSPF will be lost. It is better to complicate a small network design slightly by anticipating its growth than to take this shortcut. The second common problem in OSPF design is redundancy and, more importantly, diversity. One large ATM network we were deploying was originally slated for OSPF; however, backup links frequently crossed local access and transport area (LATA) boundaries. Crossing a LATA typically increases the cost for a circuit—in our design this almost tripled the recurrent costs. As a result, to provide the needed redundancy, we had to consider virtual links or abandon the structure of OSPF in favor of a less-demanding protocol. Clearly this was an unacceptable solution, and so our original design with symmetric distribution layers in different geographic locations was too difficult to implement with the area constraints mandated by OSPF. There were alternatives, including the use of virtual links; however, each was deemed suboptimal. The network was ultimately deployed with EIGRP, which still permitted summarization at the access layer, and many of the other features required by the project, including fast-convergence and VLSM support. |
On-demand routing, or ODR, is perhaps one of the most interesting routing protocols available on the Cisco platform—perhaps because it is not a routing protocol at all.
| At present, ODR is not incorporated into the CID exam or its objectives. However, the protocol is very useful in simplifying small hub-and-spoke network routing, as it adds virtually no overhead. |
It would be most accurate to describe ODR as a routing process. However, the process relies on the Cisco Discovery Protocol (CDP). The CDP packets are a proprietary method for exchanging information between two Cisco devices. The majority of this information is used in troubleshooting and administration. For example, CiscoWorks and other SNMP/RMON (remote monitoring) tools now use the CDP information to assist in the discovery and map-building processes.
ODR adds another function to CDP. By listening to CDP packets in a simple hub-and-spoke design, a master router (located at the hub) is able to learn about all the other routers in the network. The remote routers are configured with a single default route to the hub. This design does not provide many of the benefits of a formal routing protocol, but it will provide connectivity and status regarding the remote router interfaces without consuming additional bandwidth. Of course, CDP can be disabled—it is on by default. Figure 4.9 illustrates a typical ODR installation.
 | As of this writing, Cisco does not support CDP on ATM links. However, this feature and support for secondary interfaces are documented as available in IOS 12.0. |
)
FIGURE 4.9 On-demand routing
The Border Gateway Protocol (BGP) could accurately be called the routing protocol of the Internet. It is virtually impossible to have an advanced (ISP or multi-homed, multi-ISP) connection within the Internet without having at least a few external BGP (eBGP) routes.
 | This section provides greater detail regarding the BGP protocol and process than required for the Cisco objectives. The extra information is provided because of the limited amount of information available on the protocol and the likely migration by Cisco toward greater use of BGP in enterprise deployments. |
However, Cisco has recently advocated the use of BGP in the internal network when the network gets particularly large. Consider for a moment how you might design a network with 10,000 routers. Even OSPF with multiple areas will have difficulty handling that many devices, to say nothing about the introduction of new networks and, in some cases, acquired companies.
BGP is best described as a path-vector routing protocol. The protocol, in this context, is less concerned with the internal routes and more concerned with the relationships between autonomous systems. For this presentation, consider an AS to be synonymous with individual companies, although in actuality the term defines the administrative domain. BGP is also called an inter-autonomous system routing protocol.
Overall, BGP is a very powerful protocol—primarily due to two specific characteristics. First, the protocol removes the concept of network class and supports address summarization and supernetting like OSPF does. Second, BGP operates over TCP, which provides it with a more robust transport architecture than other routing protocols. Part of this function includes a graceful shutdown—errors and other messages are sent before the protocol shuts down whenever possible. BGP uses TCP port 179.
Another useful function in eBGP is the characteristic that governs its advertised routes. BGP will advertise to its peers only the routes that the BGP speaker uses, rather than routes only known from other announcements. Routes are further defined on a hop-by-hop basis.
There are three autonomous system types that designers considering BGP should understand:
BGP works by maintaining a direct transport layer connection between two systems and providing updates whenever changes occur. A full routing table is sent upon session establishment. Keepalive messages are sent periodically to validate the integrity of the connection. These are sent, by default, at one-third the hold-time interval.
As of this writing, there are over 65,000 networks in the Internet routing table. This information is shown in the ip bgp summary that follows:
){kind=link}
Inet_Rtr#show ip bgp summary
BGP table version is 17453706, main routing table version
17453706
65353 network entries and 101590 paths using 9735069 bytes
of memory
14801 BGP path attribute entries using 1187400 bytes of
memory
3143 BGP filter-list cache entries using 50288 bytes of
memory
Dampening enabled. 57 history paths, 93 dampened paths
BGP activity 690913/625560 prefixes, 4454740/4353150 paths
4327988 prefixes revised.
 | Administrators are advised to use the loopback address on the router for all BGP traffic. Doing so can work to stabilize the routing process and maintain connectivity in the event of an interface failure. This stability is the result of the TCP session being established via the loopback interface—a link failure, given other paths, will not require re-establishment of the TCP session between BGP pairs. |
| Previous | Table of Contents | Next |