Configuring IP Routing Protocols

In the previous section, we explored establishing the routing environment and creating the routing table via static routes. Although entire networks could be run using static routes, they would be tedious to manage and would not be very responsive to outages and topology changes that could occur on a frequent basis.

To address these concerns, dynamic routing protocols were developed. Dynamic routing protocols a re algorithms that enable routers to advertise the existence of the IP network path information required to build the routing table. These algorithms also determine the selection criteria of the route that a packet follows when it is presented to the router for a switching decision. The goals of the routing protocol are to provide the user with the ability to select the optimum path through the network, to react rapidly to changes in the network, and to do these tasks in the simplest manner with the least overhead on the router.

Routing protocols fall into two major classes: Interior Gateway Protocols (IGP) and Exterior Gateway Protocols (EGP). IGPs are designed to exchange network and subnetwork information among routers within the same autonomous system ”that is, among routers running a common routing protocol under one administrative domain. EGPs are designed to exchange only network information between routers in different autonomous systems.

The most common EGP used today is the Border Gateway Protocol version 4 (BGP-4). It is the predominant routing protocol used to exchange network path information between companies, ISPs, and NSPs on the Internet. A basic BGP-4 configuration is described in the section "Configuring the Border Gateway Protocol," later in this chapter.

Among the IGPs, the two major attributes that distinguish one protocol from another are the propagation methodology and whether the protocol is classful or classless. The two common propagation methodologies are the distance vector and the link-state methodologies. In the distance vector method, each router sends all or a portion of its routing table in update messages at regular intervals to neighboring routers. As routing information is spread through the network, routers can calculate distances to all networks and subnetworks within the intranetwork.

With the link-state method, each router sends complete local connection information to all other routers in the intranetwork. Because each router receives all the local connection information, it can build a complete view of the entire intranetwork by running a complex algorithm called Shortest Path First (SPF) against the connection information.

The IGPs are also distinguished by whether they are classful or classless. Classful routing protocols do not have the capability to exchange network mask information between routers. For this reason, these protocols must assume that a uniform network or subnetwork mask is applied throughout a common network address space. This limitation prohibits the use of variable-length subnet masking (VLSM) and so usually results in suboptimal network address space utilization. Furthermore, network mask information cannot be passed from router to router, so network address information must be summarized at the classful network address boundaries. For example, subnet information from network 131.108.0.0 could not be shared with network 172.16.0.0. Only the classful network route 131.108.0.0 could be propagated through the 172.16.0.0 network address space. The routing protocols that are considered classful include Routing Information Protocol (RIP) version 1 and Cisco Systems Interior Gateway Routing Protocol (IGRP).

Classless routing protocols are distinguished from the classful protocols by their capability to carry network mask information along with the network route information. For this reason, the classless protocols can support multiple subnet masks within a network address space and can therefore implement VLSM. By carrying network mask information, classless protocols can also implement supernet or CIDR block addressing.

Furthermore, classless protocols do not require the summarization of subnets at major network boundaries, as do the classful protocols (although the default behavior is to summarize). More detailed subnet information from one major network address space can be propagated into another major network address space because network masks give specific information about which subnetworks are available. The capability of classless routing to propagate subnet information from one major network address space to another facilitates the use of discontiguous networks. A discontiguous network occurs when a major network address space is broken into two or more pieces by a second major network address space, as depicted in Figure 4-6. The routing protocols that are considered classless include RIP version 2, Cisco Systems Enhanced IGRP (EIGRP), the IETF Open Shortest Path First (OSPF), and the ISO Intermediate System-to-Intermediate System Intradomain Routing Exchange Protocol (IS-IS).

Figure 4-6. Classless Routing Protocols Allow for Discontiguous Network Address Space

The selection of which dynamic routing protocol to use in a network is influenced by many variables . Although an entire book could be devoted to the design of the network and the selection of a routing protocol, the following are some of the key points that influence the network administrator's decision:

• Network topology ”Some routing protocols rely on a logical hierarchy to properly scale and distribute network path information. Protocols such as OSPF and IS-IS require the establishment of a backbone and logical areas, as depicted in Figure 4-7. These protocols may require you to redesign your physical network topology or to engineer initial network design to operate optimally.

  Figure 4-7. A Hierarchical Network Topology

  

• Address and route summarization ”In a large intranetwork, the benefits of reducing the number of routing table entries maintained by routing nodes include the reduction of the relative complexity of the network as well as a reduction in the routers' loads. Summarization requires that a routing protocol support VLSM and that it have the capability to propagate network mask information with the network routes. Classless protocols, such as OSPF and EIGRP, are well-suited to summarization.

• Convergence speed ”The speed with which a routing protocol identifies that a path is not available, selects a new path, and propagates the new path information can be one of the most important criteria. If the network supports mission-critical applications, the network administrator likely desires a fast converging routing protocol. Distance vector protocols typically require more time to converge than link-state protocols because new path information must be passed hop by hop to each successive router in the intranetwork. RIP version 1 and IGRP are typically slower to converge than EIGRP and OSPF.

• Route selection criteria ”The individual route attributes that a routing protocol uses to create its route metric play a key role in determining the proper dynamic routing protocol to implement. A protocol that relies strictly on the number of router hops to determine the route selection ”such as RIP ”may not be ideal when multiple paths in the intranetwork are composed of different types of LAN or WAN media. RIP views the router hop across a Fast Ethernet segment as being the same relative cost as a router hop across a 56-kbps WAN link. Some of the network path attributes used by various protocols to compute their metric include path length, reliability, delay, bandwidth, and load.

• Scalability ”Depending on the types of routers in the intranetwork and the size of the network, the relative scalability of the routing protocol is very important. Distance vector protocols consume fewer CPU cycles than link-state protocols, with their complex SPF algorithms. Link-state protocols consume less LAN and WAN bandwidth than distance vector protocols because only change information is propagated instead of the complete routing table.

• Ease of implementation ”If the network is not overly complex, protocols that do not require network re-engineering or well-structured and organized topologies are easier to implement. For example, RIP, IGRP, and EIGRP do not require much planning or organization within the topology to be run effectively. OSPF and IS-IS require that the network topology and addressing schemes be well thought-out before deployment.

• Security ”If your network might exchange IGP information with a partner company or with divisions within a corporation, you might want to be able to authenticate the source of the routing information. Protocols such as OSPF and EIGRP support strong authentication methods , such as MD5 key authentication.

Note

A complete evaluation of the operation and features of the various protocols is available in Technology Overview Briefs , which is located on CCO at http://www.cisco. com/univercd/cc/td/doc/cisintwk/ito_doc/index.htm.

The selection of a routing protocol for any one network greatly depends on the following factors:

• Whether a router is being added to an existing network topology

• The design of the network

• The presence of existing routers and routing protocols

• The administrator's relative comfort and experience with TCP/IP routing

• The necessity to exchange routing information with end system devices, such as a server

If you are unsure about what routing protocol is appropriate for your network environment, we recommend that you discuss different options with technical sales engineers , outside network consultants , or other individuals who have experience in deploying IP networks. Additionally, Cisco Systems has documented in detail the design and selection criteria for deploying dynamic routing protocols in a design guide called Designing Large-Scale IP Internetworks . This guide is available on CCO at http://www.cisco. com/univercd/cc/td/doc/cisintwk/idg4/nd2003.htm.

For the ZIP network, the EIGRP routing protocol was selected because of its effective balance of the distance vector and link-state protocols' features. It is relatively easy to configure, does not require a specific physical topology, supports summarization and VLSM, and offers fast convergence. The basic configuration of EIGRP is discussed in the section "Configuring the Cisco IP Enhanced Interior Gateway Routing Protocol," later in this chapter. Although other popular IGPs are not implemented in the ZIP network, their basic configuration is covered in the following sections. Throughout the following discussions, we stick to basic configuration steps for each protocol. Additional commands for controlling dynamic routing protocol information are covered later, in the section "Managing Dynamic Routing Protocol Information."

Configuring the Routing Information Protocol

The Routing Information Protocol (RIP) is one of the oldest routing protocols used by IP-based devices. Its original implementation was for the Xerox PUP protocol in the early 1980s. RIP gained popularity when it was distributed with the Berkeley Systems Distribution (BSD) version of UNIX as the routing protocol for that TCP/IP implementation. Formal specification of RIP as a TCP/IP routing protocol can be found in RFC 1058.

RIP is a distance vector protocol that uses a router hop count as its metric. The maximum hop count in RIP is 15. Any route farther than 15 is tagged as unreachable by setting the hop count to 16. Routing information in RIP is propagated from a router to its neighbor routers via an IP broadcast using the UDP protocol and port 520.

RIP version 1 is a classful routing protocol that did not support the advertisement of network mask information. RIP version 2 is a classless protocol that can support CIDR, VLSM, route summarization, and security via plain text and MD5 authentication.

Although RIP is not implemented in the ZIP network, let's examine how it would be configured on a router that we'll call RIProuter. Configuring the RIP routing protocol consists of three basic steps: enabling the router to run the RIP protocol, deciding which RIP version to run, and configuring which network addresses and interfaces are included in routing updates. To enable the router to run RIP, the IOS major configuration command router rip is used. To select the RIP version to run, the IOS routing configuration subcommand version is used. The version command takes a parameter of either 1 or 2 to specify which RIP version to use. If no version is specified, the IOS software defaults to sending RIP version 1 but receives both version 1 and version 2 updates. In this example, we enable the RIP routing protocol and select RIP version 2:

 RIProuter#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. RIProuter(config)#  router rip  RIProuter(config-router)#  version 2  RIProuter(config-router)#  ^Z  

Specifying which interfaces and network addresses to include in RIP routing advertisements is accomplished with the IOS routing configuration subcommand network . This command takes as a parameter the classful network address that should be included in routing updates. The network command should be used to identify only those IP network addresses that are directly connected to the router being configured and that are meant to be included in the RIP routing process. Only interfaces having IP addresses in the identified network are included in routing updates.

For example, suppose that a router has two interfaces with IP addresses 131.108.4.5 and 131.108.6.9, respectively, and a third interface with the IP address 172.16.3.6. The subcommand network 131.108.0.0 causes routing advertisements to be sent only about the subnets of network 131.108.0.0 and only to the interfaces that are addressed in the 131.108.0.0 network. To include routing updates for the interface in the 172.16.0.0 address space, an additional command network 172.16.0.0 must be configured.

The following is an example of configuring the network command to include the subnets and interfaces of the 131.108.0.0 network:

 RIProuter#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. RIProuter(config)#  router rip  RIProuter(config-router)#  network 131.108.0.0  RIProuter(config-router)#  ^Z  

Note

It is possible to mix RIP version 1 and RIP version 2 in the same network, even though version 1 cannot support many of the features of version 2. Mixing the versions can result in interoperability problems. Overriding the globally configured version and specifying the version on a per-interface basis is accomplished with the IOS interface configuration subcommands ip rip send version and ip rip receive version .

Configuring the Cisco Interior Gateway Routing Protocol

The Cisco Interior Gateway Routing Protocol (IGRP) is an enhanced distance vector protocol that was developed by Cisco Systems in the mid-1980s. It was designed to address some of the shortcomings of RIP and to provide better support for larger networks with multiple bandwidth link characteristics.

IGRP calculates its metric based on several user-configurable network path attributes, which include the internetwork delay, bandwidth, reliability, and load. Each WAN and LAN interface has preconfigured values for bandwidth and delay based on the relative speed and capabilities of the interface. The reliability and load attributes are calculated based on the performance of the interface in handling actual network traffic, although they are not enabled by default for routing decisions in the Cisco IOS.

Like RIP, IGRP uses IP broadcasts to communicate routing information to neighbor routers. However, IGRP is designated as its own transport layer protocol. It does not rely on UDP or TCP to communicate network route information. (Because IGRP has no feedback mechanisms, it operates in a manner similar to UDP.)

IGRP offers three major enhancements over the RIP protocol. First, the metric for IGRP can support a network with up to 255 router hops. Second, the metric for IGRP can distinguish between different types of connection media and their associated costs. Third, IGRP offers faster convergence through the use of flash updates. Flash updates send network change information as it becomes available instead of waiting for the regularly scheduled update time.

Let's examine the configuration of IGRP on a router that we'll call IGRProuter. Configuring the IGRP routing process consists of two steps: enabling the router to run IGRP, and identifying which network addresses and interfaces are included in routing updates. To enable the router to run IGRP, use the IOS major configuration command router igrp . This command requires a parameter known as a process-id. The process-id can be an integer in the range from 1 to 65535. Because multiple IGRP processes can run on the same router, process-id numbers are needed to distinguish them. Multiple IGRP processes might be run on a router that interconnects two divisions of a company, both of which want to separate the network administration between them. All routers in one division would share the same IGRP process-id with the other routers within that division.

As with RIP, specifying which interfaces and network addresses to include in IGRP routing advertisements is accomplished with the IOS routing configuration subcommand network . This command takes as a parameter the classful network address, which should be included in routing updates. The network command should be used to identify only those IP network addresses that are directly connected to the router being configured and that are meant to be included in the IGRP routing process. Only interfaces having IP addresses in the identified network are included in routing updates.

For example, if two interfaces have IP addresses 131.108.4.5 and 131.108.6.9, respectively, and a third interface has the IP address 172.16.3.6, the command network 131.108.0.0 results in routing advertisements being sent only about the subnets of network 131.108.0.0 and only to the interfaces that are addressed in the 131.108.0.0 network. To include routing updates for the interface in the 172.16.0.0 address space, the additional command network 172.16.0.0 must be configured.

The following is an example of configuring the IGRP routing process for network 131.108.0.0:

 IGRProuter#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. IGRProuter(config)#  router igrp 25000  IGRProuter(config-router)#  network 131.108.0.0  IGRProuter(config-router)#  ^Z  

Configuring the Open Shortest Path First Protocol

Open Shortest Path First (OSPF) was designed in the late 1980s by the OSPF Working Group of the IETF. It was designed to address the needs of IP-based networks, including VLSM, route source authentication, fast convergence, tagging of routes learned via external routing protocols, and multicast route advertisements. OSPF version 2, the most current implementation, is specified in RFC 1583.

OSPF operates by dividing a large intranet or an autonomous system into smaller hierarchical units. Each of these areas is attached to a backbone area via an Area Border Router, as shown previously in Figure 4.7. All packets addressed from a workstation address in one area to a workstation address in another area traverse the backbone area, regardless of whether there is a direct connection from one area to another. Although it is possible to operate an OSPF network with only the backbone area, OSPF scales well only when the network is subdivided into a number of smaller areas.

As described previously, OSPF is a link-state routing protocol. Unlike RIP and IGRP, which advertise their routes only to neighboring routers, OSPF routers send link-state advertisements (LSAs) to all other routers within the same hierarchical area via an IP multicast. The LSA contains information on attached interfaces, metrics used, and other information needed to compute network path and topology databases. OSPF routers accumulate link-state information and run the SPF algorithm (also known as the Dijkstra algorithm, after the person credited with its creation) to calculate the shortest path to each node.

To determine which interfaces receive link-state advertisements, routers run the OSPF Hello protocol. Neighboring routers exchange hello messages to determine which other routers exist on a given interface and to serve as keepalives to indicate that those routers are still accessible.

When a neighbor router is detected , OSPF topology information is exchanged. After the routers are in sync, they are said to have formed an adjacency . LSAs are sent and received only on adjacencies.

LSA information is carried in packets via the OSPF transport layer. The OSPF transport layer defines a reliable advertisement, acknowledgment, and request process to ensure that LSA information is properly flooded to all routers within an area. LSAs are divided into four types. The most common types are those that advertise information about a router's connected network links and those that advertise networks available outside the OSPF areas.

OSPF's routing metric is calculated as the sum of the OSPF costs across the path to reach a network. The OSPF cost for a link is calculated based on the bandwidth of the interface and is user-configurable.

We consider the basic configuration of OSPF on a router called OSPFrouter. Configuring the OSPF routing process consists of two steps: enabling the router to run OSPF, and identifying which network addresses and interfaces are included in routing updates and to which areas the interfaces belong.

To enable the router to run OSPF, use the IOS major configuration command router ospf . This command requires as a parameter a process-id integer in case multiple OSPF processes are run on the same router. As with other routing protocols, you need to configure which interfaces and network addresses are included in OSPF routing advertisements. Additionally, you must identify which OSPF area an interface resides within.

Use the IOS routing configuration subcommand network area to identify the network addresses and interfaces to include in OSPF and to identify the areas to which they belong. This command takes two parameters. The first parameter is the network address and the wildcard mask used to compare against IP addresses assigned to interfaces. The wildcard mask is a method for matching IP addresses or ranges of IP addresses. It is described in the section "Configuring IP Filtering via Access Lists," later in this chapter. When the wildcard mask is applied to the IP address of an interface and the resulting network address matches the network address in the network area command, the interface is included in the OSPF routing process for the specified area. The second parameter, which is referred to as the area id, is used to identify the area to which the interface belongs. The area id can be an integer or a dotted -decimal number, such as an IP address.

Let's assume that our example router, called OSPFrouter, has three interfaces. The interfaces are assigned IP addresses 131.108.200.1, 131.108.201.1, and 131.108.202.1, respectively. The first two interfaces are assigned to Area 1, and the third is assigned either to Area 0 or to the backbone area. Based on these assumptions, the following is an example of configuring OSPF:

 OSPFrouter#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. OSPFrouter(config)#  router ospf 25000  OSPFrouter(config-router)#  network 131.108.200.0 0.0.1.255 area 1  OSPFrouter(config-router)#  network 131.108.202.0 0.0.0.255 area 0  OSPFrouter(config-router)#  ^Z  

As with the previously discussed routing protocols, only those network addresses and interfaces that match the addresses in the network area commands are included in OSPF routing updates.

OSPF operates on the principle that LSAs can be multicast to all routers within an autonomous system. However, many WAN media ”such as point-to-point serial lines, point-to-point Frame Relay, and multipoint Frame Relay ”are non-broadcast media and do not support multicasting. Without the capability to multicast the LSA routing information, the network administrator is forced to manually configure the neighbor relationships between routers on the point-to-point and multipoint network interfaces. However, one solution eliminates this manual configuration of neighbors. OSPF can be instructed to treat a point-to-point interface as a broadcast medium and a multipoint interface as a partial broadcast network. The IOS interface configuration subcommand ip ospf network controls the network type that OSPF believes is connected to the interface. The command takes as a parameter one of the following options:

• broadcast ”Treat this medium as a broadcast medium, assuming that multicasts can be transmitted and received.

• non-broadcast ”Treat this medium as a non-broadcast medium. This option requires the administrator to manually configure neighbor relationships via the IOS routing configuration subcommand neighbor .

• point-to-multipoint ”Treat this medium as a partial broadcast medium. The router at the hub of a point-to-multipoint topology has virtual circuits to the multiple remote routers, and it serves as the relay for LSAs and routing between the routers that are not directly connected.

The following is an example of configuring a point-to-point Frame Relay subinterface as an OSPF broadcast type and a multipoint Frame Relay interface as an OSPF point-to-multipoint type:

 OSPFrouter#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. OSPFrouter(config)#  interface serial 0.1 point-to-point  OSPFrouter(config-int)#  ip ospf network broadcast  OSPFrouter(config-int)#  interface serial 1  OSPFrouter(config-int)#  ip ospf network point-to-multipoint  OSPFrouter(config-int)#  ^Z  

Unlike other IGP routing protocols, OSPF does not generate a default route when configured with the ip default-network command. For OSPF, the autonomous system boundary router must be configured manually to force it to generate the default route into the rest of the OSPF domain. The IOS routing configuration subcommand ip default-information originate causes OSPF to generate the default route. The following is an example of configuring the ip default-information originate command in conjunction with the ip default-network command to force an autonomous system boundary router to generate a default route:

 OSPFrouter#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. OSPFrouter(config)#  ip default-network  140.222.0.0  OSPFrouter(config-router)#  router ospf  25000  OSPFrouter(config-router)#  ip default-information originate  OSPFrouter(config-router)#  ^Z  

Configuring the Cisco IP Enhanced Interior Gateway Routing Protocol

The Enhanced Interior Gateway Routing Protocol (EIGRP) is an improved version of the original IGRP developed by Cisco Systems. EIGRP retains the same distance vector algorithm and metric information as the original IGRP; however, the convergence time and other scalability aspects have been significantly improved. EIGRP offers features not found in its predecessor, IGRP, such as support for VLSM and arbitrary route summarization. Additionally, EIGRP offers features found in protocols such as OSPF, including partial incremental updates and decreased convergence time. EIGRP combines the advantages of link-state protocols with the advantages of distance vector protocols.

As with IGRP, EIGRP advertises routing table information only to neighbor routers. However, unlike IGRP, these neighbors are discovered via a simple Hello protocol exchanged by routers on the same physical network. After neighbors are discovered , EIGRP uses a reliable transport protocol to ensure the accurate and ordered delivery of routing table information and updates. A router keeps track not only of its own connected routes, but also of all routes advertised by its neighbors. Based on this information, EIGRP can quickly and efficiently select the least-cost path to a destination and guarantee that the path is not part of a routing loop. By storing the routing information of its neighbors, the algorithm can more quickly determine a replacement route or feasible successor in case of a link failure or other topology change event.

EIGRP hello and routing information are carried in the EIGRP transport protocol. The EIGRP transport defines a reliable advertisement, acknowledgment, and request process to ensure that hello and routing information is properly transmitted to all neighbor routers.

EIGRP is the dynamic routing protocol of the example ZIP network, so let's examine its configuration in that context. Configuring the EIGRP routing process consists of two steps: enabling the router to run EIGRP, and identifying which network addresses and interfaces are included in routing updates.

To enable the router to run EIGRP, use the IOS major configuration command router eigrp . This command requires as a parameter a process-id integer in case multiple EIGRP processes are run on the same router. As with IGRP, specifying which interfaces and network addresses are included in EIGRP routing advertisements is accomplished with the IOS routing configuration subcommand network . This command takes as a parameter the classful network address, which should be included in routing updates. The network command should be used to identify only those IP network addresses that are directly connected to the router being configured and that are meant to be included in the EIGRP routing process. Only interfaces having IP addresses in the identified network are included in routing updates.

For example, on the ZIP SF-Core-1 router, there are interfaces in the 131.108.0.0 network and in the 192.7.2.0 network. The command network 131.108.0.0 stipulates that routing advertisements are sent about the subnets of network 131.108.0.0 and to the interfaces that are addressed in the 131.108.0.0 network. To include routing updates for the interface in the 192.7.2.0 address space, an additional command, network 192.7.2.0 , would need to be configured. In this case, the 192.7.2.0 network is the connection to the ISP. It is not included in the EIGRP routing process because the ISP does not use EIGRP.

The following is an example of configuring EIGRP on the ZIP SF-Core-1 router for the 131.108.0.0 network:

 SF-Core-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-Core-1(config)#  router eigrp 25000  SF-Core-1(config-router)#  network 131.108.0.0  SF-Core-1(config-router)#  ^Z  

Configuring the Border Gateway Protocol

The Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP). Unlike IGPs, which exchange information about networks and subnetworks within the same routing domain or autonomous system, EGPs are designed to exchange routing information between routing domains or autonomous systems. BGP is the primary method for exchanging network information between companies, ISPs, and NSPs for the global Internet. BGP offers advantages over its predecessor, the Exterior Gateway Protocol (EGP). The most notable advantage is that it guarantees the loop-free exchange of routing information between autonomous systems. BGP version 4 is the most current revision of BGP. It offers advantages over previous versions, such as handling CIDR blocks. BGP, which has been adopted by the IETF, is specified in RFCs 1163, 1267, and 1771. These RFCs define BGP versions 2, 3, and 4, respectively.

BGP routers are configured with neighbor information so that routers may form a reliable TCP connection over which to transport network route and autonomous system path information. Unlike some of the IGPs, BGP uses TCP as its transport protocol instead of defining its own. After a neighbor BGP session is established, it remains open unless it is specifically closed or unless there is a link failure. When two neighbor routers are exchanging BGP session and route information, they are said to be BGP peers. The route information exchanged between peers includes the network number/autonomous system path pair and other route attributes. The autonomous system path is a string of autonomous system numbers through which the advertised route can be reached.

Initially, BGP peers exchange the entire contents of their BGP routing tables. Subsequently, only incremental updates are sent between the peers to advise them of new or deleted routes. Unlike IGP route tables, the BGP route table does not require periodic refreshing. Instead, each BGP router retains the latest version number of the table that it has advertised to its peers, as well as its own internal table version. When a change is received from a peer, the internal table version is incremented and compared to the advertised table versions of the peers. This process ensures that each of the router's peers is kept in sync with all changes that are processed . BGP also keeps a separate BGP route table that contains all possible paths to the advertised networks. Only the optimal path is stored in the primary route selection table of the router, and only the optimal path is advertised to other BGP peers.

BGP peers are divided into two categories, external BGP peers (EBGP) and internal BGP peers (IBGP). BGP peers that are in different administrative domains or autonomous systems and that exchange routing information are said to be EBGP peers. EBGP peers are typically other organizations, ISPs, or NSPs with whom an autonomous system wants to share information regarding routes within the autonomous system or that were learned from other external sources.

BGP peers that are in the same administrative domain or autonomous system and that exchange routing information are said to be IBGP peers. IBGP peers are routers within the same autonomous system that need to share the externally learned BGP routes to have a complete picture of all possible routes to external destinations and for readvertisement to other EBGP peers. IBGP peering is typical when an autonomous system has more than one external BGP peering relationship, such as two ISP or NSP connections to the global Internet. IBGP peering is a simpler and more flexible method to share routes derived from EBGP peers.

The alternative to IBGP peering is to redistribute the EBGP learned routes into an IGP (such as EIGRP or OSPF) to be transported through the autonomous system and then to redistribute the routes from the IGP back into BGP to be advertised via EBGP to other external BGP peers. As described in the following section, "Managing Dynamic Routing Protocol Information," route redistribution can result in loss of routing metric information and potential routing loops . In addition to protection from the hazards of route redistribution, IBGP peering offers all the administrative controls, weights, and filtering capabilities associated with the BGP protocol, and it maintains a consistent view of routing information advertised to the external world via BGP.

Figure 4-8 demonstrates the difference between IBGP and EBGP peers as seen in the ZIP network. EBGP peers exist between the router pairs Seoul-1 and ISP-A, and SF-Core-1 and ISP-B. IBGP peers exist between the router pair Seoul-1 and SF-Core-1. As IBGP peers, Seoul-1 and SF-Core-1 will share routing information learned from ISP-A and ISP-B to determine the best route to destinations outside the ZIP network.

Figure 4-8. EBGP and IBGP Peers in the ZIP Network

Without applying administrative controls and weights, BGP optimal route selection is based on the length of the autonomous system path for a network route. The length is defined as the number of distinct autonomous systems required to reach the network. The shorter the length, the more desirable the path. Through its use of administrative controls, BGP is one of the most flexible and highly configurable routing protocols available. It gives the network administrator the ability to implement a wide variety of routing policies through route attributes such as the Multi-Exit Discriminator (MED) metric and the Local Preference attribute and filtering features such as distribution lists.

Tip

Before implementing BGP routing policies through the use of MEDs, Local Preference, and other attributes, make sure that you have a complete understanding of the effects of these modifiers. We recommend reviewing the text Internet Routing Architectures, Second Edition, and the Cisco Systems case study Using the Border Gateway Protocol for Interdomain Routing . The case study can be found on CCO at http://www.cisco. com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm.

When a network has multiple ISP connections, BGP normally is run to allow the selection of the best path to external networks. Running BGP when there is only one ISP connection generally is not required, because all external network paths are reached through only the one provider. However, some providers like to exchange BGP to learn the path to their customer networks and to provide network routes for default routing.

Let's examine the configuration of BGP on the ZIP SF-Core-1 and the Seoul-1 router, each of which has a connection to the Internet through an ISP. Configuring the BGP routing process consists of three steps: enabling the router to run BGP, identifying the peer routers, and identifying what network addresses to advertise to the peer routers.

To enable the router to run BGP, use the IOS global configuration command router bgp . This command takes as a parameter an integer, which is the autonomous system number (ASN) assigned to this network by one of the network address registries (RIPE, APNIC, or ARIN). Each independent autonomous system that is connected to the Internet must be assigned a unique ASN by one of the registries to prevent accidental duplication. Duplication of ASN could result in a network not being advertised because of an erroneous loop detection. If BGP is run on a completely private network that is not connected to the Internet, selection of an ASN should be from the block of private ASNs in the range from 32768 through 64511.

Note

Many network administrators use the ASN as the process-id for other dynamic routing protocols such as EIGRP. The ZIP network follows this convention.

Identifying peer routers is accomplished through the use of the IOS routing configuration subcommand neighbor remote-as . This command takes two parameters, the IP address of the neighbor router and an ASN. When the ASN specified as the remote-as is different from the ASN specified in the router bgp global configuration command, that neighbor is considered an external BGP (EBGP) peer. The IP address of a neighbor router that is an EBGP peer is usually an address on a directly connected network interface.

When the ASN specified as the remote-as is the same as the ASN specified in the router bgp global configuration command, that neighbor is considered an internal BGP (IBGP) peer. The IP address of a neighbor router that is an IBGP peer is any valid and reachable IP address for that peer. IBGP peers can be located on a directly connected network interface (as with multiple ISP connections in one location) or a nonconnected network attached to a distant router within the autonomous system (as with multiple ISP connections at different locations).

Because IBGP peer IP addresses need not be found on a directly connected network interface, it is often desirable to use the loopback interface address as the source and destination address for IBGP peering. Because the loopback interface is not associated with any physical interface, it is always up and reachable as long as there is a path to its associated IP address through IGP routing or static routes. To configure a loopback interface as the source IP address for IBGP peering, use the IOS routing configuration subcommand neighbor with the update-source keyword. The update-source keyword should be followed by the name and number of a properly addressed and configured loopback interface of the router being configured.

When a router has many BGP peering neighbors, it is often difficult to remember which IP addresses and ASNs belong to which peers. Using the description keyword parameter of the IOS routing configuration subcommand neighbor , comments can be added that can help provide information to the network administrator.

Identifying which networks within the autonomous system to advertise to the EBGP peers is accomplished through the use of the IOS routing configuration subcommand network . This command takes as a parameter the network address to be advertised to the peer routers and the optional keyword mask , followed by a network mask for that address. If no network mask is supplied, the classful network address is assumed. Through the use of the network mask, BGP can advertise both subnets and CIDR blocks to peer routers. Networks learned from other autonomous systems via EBGP will be exchanged between the IBGP peers within the autonomous system.

Note

Keep in mind that a BGP router advertises routes learned from a BGP peer to all its other BGP peers. For example, routes learned via EBGP with one ISP will be readvertised to IBGP peers, which in turn will readvertise to other ISPs via EBGP. By readvertising routes, your network may become a transit network between the providers to which you connect. This result could upset the providers as well as cause massive network congestion. If creation of such transit networks is not desired, use the route filtering capabilities of distribute-lists and route-maps to control the readvertising of learned routes. Distribute lists are discussed in more detail in the next section.

Finally, because the ZIP network will not be transmitting traffic between ISP-A and ISP-B, and because BGP routes will not be redistributed into the IGP routing process, BGP synchronization will be disabled via the IOS route configuration subcommand no synchronization . With synchronization enabled, a route will not be advertised to an EBGP peer unless that route appears in the primary route selection table for the peer and is learned via the IGP routing process. Because the ZIP network wants to advertise only routes for its own autonomous system, disabling synchronization will result in faster BGP convergence times.

The following is an example of configuring BGP routing on the ZIP SF-Core-1 router to advertise the network 131.108.0.0 to its ISP via EBGP. The ZIP SF-Core-1 router has an ASN of 25000. The ISP has an ASN of 1, with a peer IP address of 192.7.2.1. Additionally, the Seoul-1 router is configured as an IBGP peer to the SF-Core-1 router with a peer IP address of 131.108.254.6, using the IP address of interface loopback 0 as the source address for the peering connection:

 SF-Core-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-Core-1(config)#  router bgp 25000  SF-Core-1(config-router)#  no synchronization  SF-Core-1(config-router)#  network 131.108.0.0  SF-Core-1(config-router)#  neighbor 192.7.2.1 remote-as 1  SF-Core-1(config-router)#  neighbor 192.7.2.1 description Internet Connection to ISP-B  SF-Core-1(config-router)#  neighbor 131.108.254.6 remote-as 25000  SF-Core-1(config-router)#  neighbor 131.108.254.6 description IBGP to Seoul-1  SF-Core-1(config-router)#  neighbor 131.108.254.6 update-source loopback 0  SF-Core-1(config-router)#  ^Z  

The following is an example of configuring BGP routing on the ZIP Seoul-1 router to advertise the network 131.108.0.0 to its ISP via EBGP. The ZIP Seoul-1 router has an ASN of 25000. The ISP has an ASN of 701, with a peer IP address of 211.21.2.1. Additionally, the SF-Core-1 router is configured as an IBGP peer to the Seoul-1 router with a peer IP address of 131.108.254.3, using the IP address of interface loopback 0 as the source address for the peering connection:

 Seoul-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. Seoul-1(config)#  router bgp 25000  Seoul-1(config-router)#  no synchronization  Seoul-1(config-router)#  network 131.108.0.0  Seoul-1(config-router)#  neighbor 211.21.2.1 remote-as 701  Seoul-1(config-router)#  neighbor 211.21.2.1 description Internet Connection to ISP-A  Seoul-1(config-router)#  neighbor 131.108.254.3 remote-as 25000  Seoul-1(config-router)#  neighbor 131.108.254.3 description IBGP to SF-Core-1  Seoul-1(config-router)#  neighbor 131.108.254.3 update-source loopback 0  Seoul-1(config-router)#  ^Z  

When both routers are configured for BGP and the peers are established, the route for network 131.108.0.0 will be advertised to ISP A and ISP B by Seoul-1 and SF-Core-1, respectively. Using IOS EXEC commands described in the later section "Viewing Dynamic Routing Protocol Information," the network administrator can verify the establishment of the peers and the proper advertisement and receipt of network routes.

When IBGP peers exchange routing information learned from EBGP peers, it is important to note that the IBGP peer must have a route to the next-hop address for the route being learned from the EBGP peer. For example, if SF-Core-1 learns about the route 140.222.0.0/16 from ISP B, the next-hop address for that route will be 192.7.2.1. When the route is readvertised to the IBGP peer Seoul-1, the route cannot be installed in Seoul-1's BGP route table unless Seoul-1 has a route to the next-hop address of 192.7.2.1. If the route is not installed in Seoul-1's BGP table, it cannot be selected as the best route to be included in the primary route selection table, nor can it be evaluated against the same route that might be learned from ISP A. If the next-hop addresses are not part of the network address range for which your IGP provides routing information (for example, ISP assigned addressing), use the redistribute command, described in the next section, to advertise the directly connected or static routes for those addresses into your IGP routing process.

Managing Dynamic Routing Protocol Information

Network administrators often want to apply administrative policy to control the flow of network routing information both within and outside their networks. These policies include determining which routers participate in the routing process, whether subnet information is propagated between different major network address spaces, and what routes should be shared between routers. By implementing these policies, you can control network access traffic patterns and security. In this section, we examine five popular IOS commands that are used to manage dynamic routing protocols and to implement routing policy.

One of the most important attributes of managing dynamic routing protocols is the ability to permit and deny network routes from being propagated from one router to the network. This ability to filter routing information enables you to restrict one part of a network from being reached by another part of that network. In the case of BGP, restricting routes from being propagated and readvertised to peer routes prevents an autonomous system from inadvertently transiting packets between two or more ISPs.

The primary tool for filtering routing information is the IOS routing configuration subcommand distribute-list . The filtering capabilities of the distribute-list command are enabled through the use of standard IP access lists. Access lists are general tools for defining filtering criteria. When applied in conjunction with routing protocol subcommands, access lists can define which routes are permitted or denied . They are discussed in detail in the later section "Configuring IP Filtering via Access Lists." The distribute-list command applies an access list to the particular situation of controlling route propagation.

The distribute-list command takes several parameters, including the name or number of an IP access list, the keyword in or out , which controls the direction in which the filtering occurs, and an optional interface identifier. This identifier indicates that the filtering should occur only on routing updates for that specific interface. If this identifier is omitted, the distribute list applies to all routing updates that match the access list.

The following is an example of applying the distribute-list command on the SF-Core-1 router to prevent the reserved network address 10.0.0.0 from being learned by the BGP routing process and to permit every other address to be learned:

 SF-Core-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-Core-1(config)#  router bgp 25000  SF-Core-1(config-router)#  distribute-list 1 in  SF-Core-1(config-router)#  access-list 1 deny 10.0.0.0 0.0.0.0  SF-Core-1(config)#  access-list 1 permit any  SF-Core-1(config)#  ^Z  

Note

Because of the flooding nature of the LSA packets in link-state protocols such as OSPF and IS-IS, filtering of inbound routing information is not possible. Filtering of outbound routing information applies only to external routes.

When the distribute-list command is applied as a subcommand of a routing process, the filtering defined in the distribute-list applies to all sources of the routing updates. In many situations, it may be desirable to apply the filtering to only one source of routing information, such as a particular BGP peer. Filtering updates to and from particular BGP peers can be accomplished by applying the distribute-list to a particular BGP neighbor as an optional keyword of the BGP neighbor subcommand.

The following is the previous example rewritten to apply the distribute-list command on SF-Core-1 as an option to the neighbor subcommand so that only the EBGP peer is prevented from learning the reserved network address 10.0.0.0:

 SF-Core-1(config)#  router bgp 25000  SF-Core-1(config-router)#  neighbor 192.7.2.1 distribute-list 1 in  SF-Core-1(config-router)#  access-list 1 deny 10.0.0.0 0.0.0.0  SF-Core-1(config)#  access-list 1 permit any  SF-Core-1(config)#  ^Z  

Occasionally, you may want to have a router listen to routing updates on a specific interface, but to not advertise routing information to other routers on the interface. When this configuration is desired, an interface is said to be operating in passive mode. The IOS routing configuration subcommand passive-interface sets up passive mode. This command takes as a parameter the interface identifier on which outgoing routing updates are suppressed. The following is an example of configuring the ZIP San-Jose router with the passive-interface command to prevent routing updates from being sent on the router's Token Ring interface:

 San-Jose#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. San-Jose(config)#  router eigrp 125000  San-Jose(config-router)#  passive-interface tokenring 1/0  San-Jose(config-router)#  ^Z  

You may want to configure a router with a list of specific neighbor routers with which it can exchange dynamic routing information. For example, to implement OSPF on non-broadcast media, specific neighbor routers must be specified for proper protocol operation. As another example, you can implement a more secure environment in which only specified neighbor routers are permitted to exchange routing information in a point-to-point fashion.

The IOS routing configuration subcommand neighbor is used to specify the IP address of a neighbor router with which to exchange routing information. When used with the passive-interface command, routing information is exchanged with only the specified neighbors through point-to-point (non-broadcast) exchanges. The neighbor command takes as a parameter an IP address for the neighbor router. The following is an example of configuring the ZIP Seoul-2 router to exchange point-to-point routing information with a UNIX server running RIP on the Ethernet segment. The passive-interface command is used to prevent RIP from being advertised on the serial interface.

 Seoul-2#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. Seoul-2(config)#  router rip  Seoul-2(config-router)#  passive-interface serial 0  Seoul-2(config-router)#  passive-interface ethernet 0  Seoul-2(config-router)#  neighbor 131.108.3.40  Seoul-2(config-router)#  ^Z  

Occasionally, your Cisco IOS-based routers may need to communicate routing information with other devices that do not support the routing protocol selected for your network. For example, the ZIP network runs EIGRP. A UNIX platform cannot receive EIGRP routing updates because it has the capability to run only the RIP protocol. To accommodate such situations, the IOS software has the capability to pass routing information from one dynamic routing protocol to another. This process is called route redistribution.

The IOS routing configuration subcommand redistribute is used to enable route redistribution. This command takes as an argument the name of the routing process from which to redistribute routes. The keywords static or connected may also be specified in place of a routing process name. Using the static keyword allows manually configured static routes to be advertised into the routing process. The keyword connected allows the routes for directly connected interfaces not matching the address specified in the routing subcommand network to be advertised by the routing process. Because each dynamic routing protocol uses a different method to calculate its metric, automatic metric conversion may not be possible. The following is a list of the IOS-supported automatic metric conversions:

• RIP can automatically redistribute static routes. It assigns static routes a metric of 1 (directly connected).

• IGRP can automatically redistribute static routes and information from other IGRP-routed autonomous systems. IGRP assigns static routes a metric that identifies them as directly connected. IGRP does not change the metrics of routes derived from IGRP updates from other autonomous systems.

• Any protocol can redistribute other routing protocols if a default metric is in effect.

A default metric is defined with the IOS routing configuration subcommand default-metric . The command takes as an argument one or more routing protocol metric attributes, based on the particular routing protocol being configured. The following is an example of redistributing EIGRP into RIP on the ZIP Singapore router. Note that the passive-interface command is used to prevent RIP from being advertised on the serial interface and that the default metric is set to 3.

 Singapore#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. Singapore(config)#  router rip  Singapore(config-router)#  default-metric 3  Singapore(config-router)#  redistribute eigrp 25000  Singapore(config-router)#  passive-interface serial 0  Singapore(config-router)#  ^Z  

Tip

Redistributing routing information from one protocol to another can be a tricky business. Mutual redistribution ”in which routes are passed from one protocol to another, and vice versa ”can cause routing loops because there are no sanity checks on the routes being redistributed. Mutual redistribution should be avoided, if possible. If mutual redistribution is absolutely required, the passive-interface and distribute-list commands should be used to restrict the advertisement of specific routes to specific routing protocols.

As discussed earlier, the IGP routing protocols that support VLSM automatically summarize all subnets to a single classful network route when passing routing information from one major network address to another. For example, subnets of the ZIP network 131.108.0.0 are not advertised into the 172.16.0.0 address space of another router running EIGRP. If there are subnets of the 131.108.0.0 address space that are connected beyond 172.16.0.0 ”a discontiguous network ”it may be necessary to propagate subnet information from one part of the 131.108.0.0 network, through the 172.16.0.0 network, and then to the other portion of the 131.108.0.0 network. Clearly, route summarization is undesirable in this situation. The IOS routing configuration subcommand no auto- summary prevents automatic address summarization at classful network boundaries and allows propagation of subnet information.

The following is an example of deconfiguring autosummarization on the ZIP SF-Core-1 router:

 SF-Core-1#  configure  Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line.  End with CNTL/Z. SF-Core-1(config)#  router eigrp 25000  SF-Core-1(config-router)#  no auto-summary  SF-Core-1(config-router)#  ^Z