|
|
This chapter describes routing protocol options for the Internet Protocol (IP) suite. The chapter "Routing IP" contains all the information you need for configuring IP. This chapter focuses on IP routing protocols. Other protocol stacks--DECnet, Novell, Apollo, and so on--are described in their own chapters. Topics in this chapter include:
Routing is the process of determining where to send data packets destined for addresses outside the local network. Routers gather and maintain routing information to enable the transmission and receipt of such data packets. Conceptually, routing information takes the form of entries in a routing table, with one entry for each identified route. The router can create and maintain the routing table dynamically to accommodate network changes whenever they occur.
The routing protocols are broadly divided into two classes: interior gateway protocols (IGPs) and exterior gateway protocols (EGPs). The interior routing protocols supported by Cisco include the Routing Information Protocol (RIP), Hello, the Interior Gateway Routing Protocol (IGRP), and the Open Shortest Path First (OSPF) protocol. Interior protocols are used for routing networks that are under a common network administration. The exterior routing protocols include the Exterior Gateway Protocol (EGP) and the Border Gateway Protocol (BGP). Exterior protocols are used to exchange routing information between networks that do not share a common administration.
Cisco routers offer many protocol-independent routing features. For example, subnetting lets you divide a network into logical subparts. Load balancing lets you split network traffic over parallel paths, which provides greater overall throughput and reliability. Because the router can avoid routing loops, you can implement general network topologies. Notification of disabled interfaces eliminates network black holes. Static routing table entries can provide routing information when dynamically obtained entries are not available.
An autonomous system (AS) is a collection of networks under a common administration sharing a common routing strategy (see Figure 1-1). An autonomous system may comprise one or many networks, and each network may or may not have an internal structure (subnetting). The autonomous system number, which is assigned by the Network Information Center (NIC), is a 16-bit decimal number that uniquely identifies the autonomous system. An assigned AS number is required when running EGP or BGP. All routers that belong to an autonomous system must be configured with the same autonomous system number.
The multiple routing protocol support in the Cisco routers was designed for connecting networks that might use different routing protocols. It is possible, for example, to run RIP on one subnetted network, IGRP on another subnetted network, and to exchange the routing information in a controlled fashion. The routing protocols available today were not designed to interoperate with one another, so each protocol collects different types of information and reacts to topology changes in its own way. For example, RIP uses a hop count metric and IGRP uses a five-valued vector of metric information. In the case where routing information is being exchanged between different networks that use different routing protocols, there are many configuration options to enable and to filter the exchange of routing information. See the section "Redistributing Routing Information," later in this chapter.
Cisco routers can handle the simultaneous operation of up to 30 dynamic IP routing processes.
The combination of routing processes on a router can consist of the following protocols (with the limits noted):
Each routing protocol must be configured separately. So, most of the configuration information is in protocol-specific subsections. The interior routing protocols are listed first, followed by the exterior protocols. With any routing protocol, follow these basic steps:
Step 1: Create the routing process with one of the router commands.
Step 2: Configure one or more network router subcommands.
Step 3: Configure the protocol specifics.
The next sections provide a review of the two protocol classes and how they are configured, followed by sections that explain how to configure each of the routing protocols. EXEC-level commands for monitoring the IP routing operations are also provided, and these are explained at the end of this chapter, along with alphabetical summaries of the configuration commands.
All IP routing protocols must have a list of networks specified by the network router subcommand before routing activities can begin. The routing process will listen to updates from other routers on these networks and will broadcast its own routing information on those same networks. In addition, the routing process only advertises the (sub)nets listed in the network command. The IGRP routing protocol also has an autonomous system number, usually assigned by the NIC.
The exterior routing protocols require three sets of information before routing can begin:
Cisco Systems designed the Interior Gateway Routing Protocol (IGRP) for routing in an autonomous system having arbitrarily complex topology and consisting of media with diverse bandwidth and delay characteristics. The IGRP protocol can advertise all connected and IGRP-derived networks for a particular autonomous system.
IGRP advertises three types of routes: interior, system, and exterior, as shown in Figure 1-2. Interior routes are routes between subnets in the network attached to a router interface. If the network attached to a router is not subnetted, IGRP does not advertise interior routes.
System routes are routes to networks within the autonomous system. The router derives system routes from directly connected network interfaces and system-route information provided by other IGRP-speaking routers. System routes do not include subnetting information. Exterior routes are routes to networks outside the autonomous system that are considered when identifying a gateway of last resort.
To create the routing process, use the router global configuration command. The full syntax of this command follows:
router igrp autonomous-systemThe argument autonomous-system identifies the routes to other IGRP routers, and is used to tag the routing information.
Use the no router igrp command to shut down the routing process on the AS specified by the autonomous-system argument.
Next, specify the list of networks with the network router configuration subcommand.
The full syntax of this command is listed below.
network network-numberThe argument network-number is a network number in dotted IP notation (of directly connected networks). Note that this number must not contain subnet information. You may specify multiple network subcommands.
The network router subcommand is a mandatory configuration command and must be included in the configuration of each IP routing process.
Use the no network command with the network number to remove a network from the list.
In this example, a router is configured for IGRP and assigned to AS 109. In the next two lines, two network commands indicate the networks directly connected to the router.
router igrp 109 network 131.108.0.0 network 192.31.7.0
IGRP has been enhanced to simultaneously use an asymmetric set of paths for a given destination. This feature is known as unequal-cost load balancing. The following general rules apply to IGRP unequal-cost load balancing:
IGRP can balance traffic across multiple routes that have different metrics. The amount of load balancing that is performed can be controlled with the variance router subcommand. The command syntax is:
variance multiplierThe argument multiplier defines the range of metric values that will be accepted for load balancing. Acceptable values are nonzero, positive integers. By default, the amount of variance is set to one (equal-cost load balancing). The no version resets variance to one.
This value is used in the procedure for determining the feasibility of a potential route. A route is feasible if the next router in the path is closer to the destination than the current router and if the metric for the entire path is within the variance. Only paths that are feasible can be used for load balancing and included in the routing table. The two feasibility conditions are:
If both these conditions are met, the route is deemed feasible and can be added to the routing table.
Figure 1-3 illustrates the process of determining IGRP path feasibility.
The feasibility test would work as follows:
Assume that C1 already has a route to Network A with metric m and has just received an update about Network A from C2. The best metric at C2 is p. The metric that C1 would use through C2 is n.
If both conditions are met, the route will be included in C1's routing table. A maximum of four paths can be in the routing table for a single destination. If there are more than four feasible paths, the four best feasible paths are used.
These conditions limit the number of cases in which load balancing can occur, but ensure that the dynamics of the network will remain stable.
The router chooses a gateway of last resort from the list of exterior routes that IGRP provides. The router uses the gateway (router) of last resort if it does not have a better route for a packet and the destination is not a connected network. If the autonomous system has more than one connection to an external network, different routers may choose different exterior routers as the gateway of last resort.
IGRP uses several types of metric information. For each path through an autonomous system, IGRP records the segment with the lowest bandwidth, the accumulated delay, the smallest MTU (Maximum Transmission Unit), and the reliability and load.
The IGRP metric is a 32-bit quantity that is a sum of the segment delays and the lowest segment bandwidth (scaled and inverted) for a given route. For a network of homogeneous media, this metric reduces to a hop count. For a network of mixed media (FDDI, Ethernet, and serial lines running from 9,600 bps to T1 rates), the route with the lowest metric reflects the most desirable path to a destination.
A router running IGRP sends an update broadcast every 90 seconds. It declares a route inaccessible if it does not receive an update from the first router in the route within three update periods (270 seconds). After seven update periods (630 seconds), the router removes the route from the routing table. IGRP uses flash update and poison reverse to speed up the convergence of the routing algorithm.
This section describes the Open Shortest Path First (OSPF) routing protocol and provides the following specific discussions:
The OSPF show command descriptions, debug command definitions, and OSPF configuration examples are provided in subsequent sections of this chapter along with similar descriptions and examples for other IP routing protocols.
OSPF is an Interior Gateway Protocol (IGP). As such, OSPF distributes routing information between routers belonging to a single AS. For the purposes of OSPF, an autonomous system is essentially a group of routers exchanging routing information via a common routing protocol. The OSPF protocol is based on shortest-path-first, or link-state, technology. This is a departure from the Bellman-Ford base, distance vector technology, used by traditional IP routing protocols such as IGRP.
The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force (IETF). It has been designed expressly for the Internet environment, including explicit support for IP subnetting, Type of Service (TOS) based routing and the tagging of externally derived routing information. OSPF also provides for the authentication of packets, and uses IP multicast when sending/receiving packets. The OSPF (Version 2) protocol is documented in the Internet RFC 1247.
OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group, together with the routers having interfaces to any one of the included networks, is called an area. Each area runs a separate copy of the basic shortest-path-first routing algorithm. This means that each area has its own topological database.
The topology of an area is invisible from the outside of the area. Conversely, routers internal to a given area know nothing of the detailed topology external to the area. This isolation of knowledge enables the protocol to effect a marked reduction in routing traffic as compared to treating the entire Autonomous System as a single SPF domain.
With the introduction of areas, it is no longer true that all routers in the AS have an identical topological database. A router actually has a separate topological database for each area to which it is connected. Routers connected to multiple areas are called area border routers. Two routers belonging to the same area have, for that area, identical area topological databases.
Routing in the autonomous system takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intraarea routing is used) or different areas (interarea routing is used). In intraarea routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intraarea routing from the injection of bad routing information.
Every OSPF routing domain AS must have a backbone. The backbone is a special OSPF area that must have an area id of 0.0.0.0 (or simply 0). It consists of those networks not contained in any specific area, their attached routers, and those routers that belong to multiple areas. The backbone must be contiguous. Each router's interface that is configured in Area 0 must be reachable via other routers where each interface in the path is configured as being in
Area 0.
However, it is possible to define areas in such a way that the backbone is no longer contiguous--where the continuity between routers is broken. In this case, you must establish backbone continuity by configuring virtual links. Virtual links are useful when the backbone area is either purposefully partitioned or when restoring inadvertent breaks in backbone continuity.
When the AS is split into OSPF areas, the routers are further divided according to function into the following four overlapping categories:
Figure 1-4 illustrates the various OSPF router types and their relationships to each other and to the overall OSPF environment.
All OSPF routing implementations adhere to an essentially common set of rules and conventions. The following descriptions outline these conventions and, where applicable, specific characteristics of Cisco's implementation.
OSPF routing implementations support the following types of physical networks:
OSPF attaches an IP address mask to each advertised route. The mask indicates the range of addresses being described by the particular route. For example, a summary advertisement for the destination 128.185.0.0 with a mask of 255.255.0.0 actually is describing a single route to the collection of destinations 128.185.0.0 to 128.185.255.255. Including the mask with each advertised destination enables the implementation of variable-length subnet masks.
The OSPF area concept is modeled after an IP subnetted network. OSPF areas have been loosely defined to be a collection of networks. Instead, an OSPF area is specified to be a list of address ranges. Each address range is defined as an address/mask pair. Many separate networks may then be contained in a single address range, just as a subnetted network is composed of many separate subnets. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of the route is the minimum cost to any of the networks falling in the specified range.
When a source and destination reside within the same area, routing is said to be intraarea. The router sends Hello packets to its neighbors, and in turn receives their Hello packets.
The router will attempt to form adjacencies with some of its newly acquired neighbors. Topological databases are synchronized between pairs of adjacent routers. On multiaccess networks, the designated router determines which routers should become adjacent.
Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies. In particular, distribution of topological database updates proceeds along adjacencies.
When a packet's source and destination reside in different areas, routing is interarea. For interarea routing, area border routers use the same basic routing strategy as with intraarea routing, but also inject additional routing information into an area. This additional information is a distillation of the rest of the AS's topology.
Routers that have information regarding other ASes can flood this information throughout an AS. This external routing information is distributed verbatim to every participating router. There is one exception: external routing information is not flooded into stub areas (described in the next section).
To use external routing information, the path to all routers advertising external information must be known throughout the AS (not including stub areas). For that reason, the locations of AS boundary routers are summarized by nonstub area border routers.
OSPF allows certain areas to be configured as stub areas. A stub area can be defined as any area that does not allow the advertisement of external routes. In other words, external advertisements are not flooded into or throughout stub areas; routing to AS external destinations in these areas is based on a per-area default only. This reduces the topological database size and the memory requirements associated with a stub area's internal routers.
In order to take advantage of the OSPF stub area support, default routing must be used in the stub area.
OSPF creates adjacencies between neighboring routers to facilitate exchange of routing information. Neighboring routers are two routers that have interfaces to a common network. On multiaccess networks, neighbors are dynamically discovered by OSPF's Hello Protocol. An adjacency is a relationship formed between selected neighboring routers for the purpose of exchanging routing information.
Not every pair of neighboring routers becomes adjacent. Instead, adjacencies are established with some subset of the router's neighbors. Routers connected by point-to-point networks and virtual links always become adjacent. On multiaccess networks, all routers become adjacent to both the designated router and the backup designated router (defined later in this section).
The Hello Protocol is responsible for establishing and maintaining neighbor relationships. It also ensures that communication between neighbors is bidirectional. Hello packets are sent periodically out all router interfaces. Bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet.
On multiaccess networks, the Hello Protocol elects a designated router for the network. Among other things, the designated router controls what adjacencies will be formed over the network (see below).
Every multiaccess network has a designated router. The designated router performs two main functions for the routing protocol:
The backbone area (area id = 0) cannot be disconnected from any area, or some areas of the AS will become unreachable. To establish or maintain connectivity of the backbone, virtual links can be configured through nonbackbone areas. Virtual links connect separate components of the backbone (for example, two areas of the same AS). The two endpoints of a virtual link are area border routers. The virtual link must be configured in both routers. The configuration information in each router consists of the other virtual endpoint (the other area border router), and the nonbackbone area the two routers have in common (called the transit area).
The sections that follow detail the specific router and interface subcommands used to enable and configure the OSPF IP routing protocol on Cisco routers. Cisco's implementation conforms to the OSPF Version 2 specifications detailed in Internet RFC 1247. The following list outlines key features supported in Cisco's OSPF implementation:
Configuration of an OSPF routing process for a Cisco router involves the following general steps. Step 1 is mandatory; the other steps are optional, but may be required for your specific application.
Step 1: Enable OSPF using the router ospf global command and network router subcommand.
Step 2: Specify route redistribution, as needed (addressed separately with redistribution discussion for all IP routing protocols).
Step 3: Set any OSPF area parameters, as needed.
Step 4: Set interface parameters, as needed.
Step 5: For nonbroadcast networks, specify appropriate neighbor parameters and the router's polling interval, as required.
The commands for each of these steps are detailed in the sections that follow.
To start an OSPF routing process, you must enable OSPF in the router, specify the range of IP addresses to be associated with the routing process, and assign area ids to be associated with that range of IP addresses. Two commands are associated with this initial step: router ospf (a global configuration command) and network (a router subcommand).
The first step in setting up OSPF support on a router is to enable OSPF using the router ospf global configuration command. The syntax for this command is:
router ospf ospf-process-idThe argument ospf-process-id is an internally used identification parameter. It is locally assigned and can be any positive integer. A unique value is assigned for each OSPF routing process. You can specify multiple OSPF routing processes in each router.
The no router ospf command must be specified with the ospf-process-id and terminates individual OSPF routing processes in the router.
Use the network router subcommand to define the interfaces on which OSPF run and the define the area id for those interfaces. The general syntax for this command is:
network address wildcard-mask area area-idThe network router subcommand is a mandatory configuration command and must be included in the configuration of each IP routing process.
The address and wildcard-mask arguments together allow you to define one or multiple interfaces to be associated with a specific OSPF area using a single command. The argument address is formed as an IP address. The argument wildcard-mask is an IP-address-type mask that includes "don't care" bits.
The keyword/variable argument pair area area-id specifies an area to be associated with the OSPF address range as defined in the same network command. The argument area-id can be specified as either a decimal value or as an IP address. If you intend to associate areas with IP subnets, you can specify a subnet address as the area-id.
The no network router subcommand must be specified with the complete address range and area id; it disables OSPF routing for interfaces defined with the address wildcard-mask pair.
The router ospf and network commands defined in this section control the assignment of area ids to specific address ranges. The following example illustrates the assignment of four area ids to four IP address ranges.
In the following example, OSPF routing process 109 is initialized, and four OSPF areas are defined: 10.9.50.0, 2, 3, and 0. Areas 10.9.50.0, 2, and 3 mask specific address ranges, while Area 0 enables OSPF for all other networks.
router ospf 109 network 131.108.20.0 0.0.0.255 area 10.9.50.0 network 131.108.0.0 0.0.255.255 area 2 network 131.109.10.0 0.0.0.255 area 3 network 0.0.0.0 255.255.255.255 area 0 ! ! Interface Ethernet0 is in area 10.9.50.0: interface Ethernet 0 ip address 131.108.20.5 255.255.255.0 ! ! Interface Ethernet1 is in area 2: interface Ethernet 1 ip address 131.108.1.5 255.255.255.0 ! ! Interface Ethernet2 is in area 2: interface Ethernet 2 ip address 131.108.2.5 255.255.255.0 ! ! Interface Ethernet3 is in area 3: interface Ethernet 3 ip address 131.109.10.5 255.255.255.0 ! ! Interface Ethernet4 is in area 0: interface Ethernet 4 ip address 131.109.1.1 255.255.255.0 ! ! Interface Ethernet5 is in area 0: interface Ethernet 5 ip address 10.1.0.1 255.255.0.0
Each network subcommand is evaluated sequentially, so the specific order of these commands in the configuration is important. The router sequentially evaluates the address/wildcard-mask pair for each interface as follows:
Step 1: The wildcard-mask is logically ORed with the interface IP address.
Step 2: The wildcard-mask is logically ORed with address in network command.
Step 3: The router compares the two resulting values.
Step 4: If they match, OSPF is enabled on the associated interface and this interface is attached to the OSPF area specified.
Consider the first network subcommand. area id 10.9.50.0 is configured for the interface on which subnet 131.108.20.0 is located. Assume that a match is determined for interface Ethernet 0. Interface Ethernet 0 is attached to Area 10.9.50.0 only.
The second network subcommand is evaluated next. For Area 2, the same process is then applied to all interfaces (except interface Ethernet 0). Assume that a match is determined for interface Ethernet 1. OSPF is then enabled for that interface and Ethernet 1 is attached to Area 2.
This process of attaching interfaces to OSPF areas continues for all network subcommands. Note that the last network subcommand in this example is a special case. With this command all available interfaces (not explicitly attached to another area) are attached to Area 0.
When you configure secondary addresses with OSPF, make certain that the primary and secondary addresses of an interface fall into the same area. If they are in different areas, secondary addresses will be ignored. The following example illustrates the correct way to configure secondary addresses.
interface ethernet 0 ip address 131.108.10.10 255.255.255.0 ip address 10.0.0.10 255.0.0.0 secondary router ospf 109 network 131.108.0.0 0.0.255.255 area 0 network 10.0.0.0. 0.255.255.255 area 0
The area router subcommand allows control of various area parameters as defined by RFC 1247. This router subcommand also allows you to control certain special capabilities. (such as stub areas and virtual links). The discussions that follow outline the various options for the area subcommand and summarize their applications.
In general, authentication is configured on a per-area basis. It is enabled for an area using the authentication option of the area router subcommand. The syntax for this command is:
area area-id authenticationThe argument area-id is the specific area id of the area for which authentication is to be enabled. The argument area-id can be specified as either a decimal value or as an IP address. Specifying authentication for an area sets the authentication to Type 1 (simple password). If this command is not included in the configuration for a router, authentication is of Type 0 (no authentication).
The authentication type must be the same for all routers in an area. The authentication key (password) for all OSPF routers on a network must be the same if they are to communicate with each other via OSPF. Use the ip ospf authentication-key interface subcommand to specify this password.
The no area area-id authentication option removes the area's authentication specification.
There are two stub area router subcommands: the stub and default-cost options of the area router subcommand. In all routers attached to the stub area, the area should be configured as a stub area using the stub option of the area command. Use the default-cost only on an area border router attached to the stub area. This command provides the metric for the summary default route generated by the area border router into the stub area. The syntax for the area area-id stub router subcommand is as follows:
area area-id stubThe argument area-id is the specific area id for the stub area. The argument area-id can be specified as either a decimal value or as an IP address.
The stub option is used to enable the stub area.
The no area area-id stub option removes the specified area as a stub area.
The syntax for the area area-id default-cost cost router subcommand is as follows:
area area-id default-cost costThe argument area-id is the specific area id for the stub area. The argument area-id can be specified as either a decimal value or as an IP address.
The default-cost cost keyword/argument pair assigns a specific cost for the default summary route used for the stub area. The accepted value is a 24-bit number.
The no area area-id default-cost cost removes the assigned default route cost.
Routing information is condensed at area boundaries. External to the area, a single route is advertised for each address range. To consolidate or summarize routes, you can use the range option of the area router subcommand. The result is that a single summary route is advertized to other areas by the area border router. This command is only used with area border routers. The syntax for this router subcommand is as follows:
area area-id range address maskThe argument area-id is the specific area id for the area about which routes are to be summarized. The argument area-id can be specified as either a decimal value or as an IP address.
The address argument is a standard IP address. The mask argument is a standard IP mask.
The interface subcommands described in this section define how you can configure each OSPF router interface parameter. In general, you do not need to configure any of these parameters. However, some interface parameters must be consistent across all routers in an attached network; be sure that if you do configure any of these parameters, that the configurations for all routers on the network have compatible values.
To explicitly specify the cost of sending a packet on an interface, use the ip ospf cost interface subcommand. The syntax for this command is:
ip ospf cost costThe argument cost is expressed as the link state metric. It is a dimensionless integer value that is always greater than zero. This value is advertized as the link cost in the router's router links advertisement. Cisco does not support Type of Service (TOS), so you can assign only one cost per interface.
Using the following formula, the default path costs were calculated as noted in the list that follows the formula. If these values do not suit your network, you can use your own method of calculating path costs.
In general, the path cost is calculated as follows:
The no ip ospf cost interface subcommand resets the path cost for an interface to the default value.
The number of seconds between link state advertisement retransmissions, for adjacencies belonging to the interface, is specified with the ip ospf retransmit-interval interface subcommand. The syntax for this command is:
ip ospf retransmit-interval number-of-secondsThe value for the number-of-seconds argument is an integer number, that should be greater than the expected round-trip delay between any two routers on the attached network. The setting of this parameter should be conservative, or needless retransmission will result. The value should be larger for serial lines and virtual links. The retransmit interval is the number of seconds a router should wait before retransmitting a link state advertisement (LSA) in the absence of an acknowledgment. If a change in the link occurs, an LSA is immediately transmitted.
The default value is five seconds.
The no ip ospf retransmit-interval subcommand resets the link state advertisement
retransmission interval to the default value.
To set the estimated number of seconds it takes to transmit a link state update packet on the interface, use the ip ospf transmit-delay interface subcommand. The syntax for this command is:
ip ospf transmit-delay number-of-secondsLink state advertisements in the update packet must have their age incremented by this amount before transmission. The value assigned should take into account the transmission and propagation delays for the interface.
The argument number-of-seconds is an integer value that must be greater than zero. The default value is 10 seconds.
If the delay is not added before transmission over a link, the time in which the LSA propagates over the link is not considered. This setting has more significance on very low-speed links.
The no ip ospf transmit-delay subcommand resets the estimated transmission time for the link state update packet the default value.
The router priority is used to help determine the designated router for a network. To set the router priority, use the ip ospf priority interface subcommand. The syntax for this command is:
ip ospf priority 8-bit-numberThe argument 8-bit-number is an 8-bit unsigned integer.
When two routers attached to a network both attempt to become the designated router, the one with the highest router priority takes precedence. If there is a tie, the router with the highest router id takes precedence. A router with a router priority set to zero is ineligible to become the designated router or backup designated router. Router priority is only configured for interfaces to multiaccess networks (in other words, not point-to-point networks).
The default router priority is 1.
The no ip ospf priority subcommand resets the router priority to the default value.
Use the ip ospf hello-interval interface subcommand to specify the length of time, in seconds, between the Hello packets that the router sends on the interface. The syntax for this command is:
ip ospf hello-interval number-of-secondsThe argument number-of-seconds is an unsigned integer value. This value is advertised in the router's Hello packets. It must be the same for all routers attached to a common network. The smaller the Hello interval, the faster topological changes will be detected, but more routing traffic will ensue.
The default differs for broadcast and nonbroadcast networks. The default for broadcast networks is 10 seconds. The default for nonbroadcast networks (for example, X.25, Frame Relay, and SMDS) is 30 seconds (determined automatically when any of the serial encapsulations are specified).
The no ip ospf hello-interval subcommand resets the length of time between Hello packet transmissions on an interface to the default value.
Use the ip ospf dead-interval interface subcommand to set the number of seconds that a router's Hello packets have not been seen before its neighbors declare the router down. The command syntax is:
ip ospf dead-interval number-of-secondsThe argument number of-seconds is an unsigned integer value.
The default is four times the ip ospf hello-interval value. As with the Hello interval, this value must be the same for all routers attached to a common network.
The no ip ospf dead-interval subcommand resets the length of time that a router's Hello packets have not been seen before its neighbors declare the router down to the default value.
The number-of-seconds specified must be the same for all nodes on a network.
Use the ip ospf authentication-key interface subcommand to assign a specific password to be used by neighboring routers on a wire that are using OSPF's simple password authentication. The command syntax is:
ip ospf authentication-key 8-bytes-of-passwordThe argument 8-bytes-of-password is any continuous string of characters that you can enter from the keyboard up to eight bytes in length.
This key is inserted directly into the OSPF header when originating routing protocol packets. A separate password can be assigned to each network on a per-interface basis. All neighboring routers on the same network must have the same password to be able to route OSPF traffic.
The default is null. The no ospf authentication-key interface subcommand removes any OSPF password that was previously assigned.
OSPF treats a nonbroadcast, multiaccess network (X.25, Frame Relay, or SMDS) much like it treats a broadcast network. Since there may be many routers attached to the network, a designated router is selected for the network. This designated router then originates a networks links advertisement, which lists all routers attached to the nonbroadcast network.
However, due to the lack of broadcast capabilities, it is necessary to use special configuration parameters in the designated router selection. These parameters need only be configured in those routers that are themselves eligible to become the designated router or backup designated router (in other words, routers with a positive, nonzero router priority value).
Use the neighbor router subcommand to configure routers interconnecting to nonbroadcast networks. The syntax for this command is:
neighbor address interface type unit-number [priority 8-bit-number]One neighbor entry must be included in the router's configuration for each known nonbroadcast network neighbor.
The argument address is the specific interface IP address of the neighbor.
The keyword/argument sequence interface type unit-number identifies the specific router interface for this neighbor command. The interface must be connected to a nonbroadcast, multiaccess type network. In addition, the neighbor specified must be eligible to be a designated router or backup designated router.
The keyword/argument pair priority 8-bit number is the router priority value of the nonbroadcast neighbor associated with the IP address specified.
If a neighboring router has become inactive (Hello packets have not been seen for Router DeadInterval period), it may still be necessary to send Hello packets to the dead neighbor. These Hello packets will be sent at a reduced rate called the Poll Interval.
Specify the poll interval with the keyword/argument pair poll-interval number-of-seconds. The argument number-of-seconds is an unsigned integer value. RFC 1247 recommends that this value should be much larger than the Hello interval. The default is 2 minutes (120 seconds).
The no neighbor router subcommand requires specification of the neighbor's IP address; this command removes the specific neighbor from the list.
In OSPF, all areas must be connected to a backbone area. If the connection to the backbone is lost, it can be repaired by establishing a virtual link. With Cisco routers, virtual links are defined using the virtual link option of the area router subcommand. The general syntax for this subcommand is as follows:
area area-id virtual-link router-id [hello-interval number-of-seconds]The argument area-id is the area id assigned to the transit area for the virtual link.This can be either a decimal value or a valid IP address.
The argument router-id is the router id associated with the virtual link neighbor. The router id appears in the show ip ospf display. It is internally derived by each router from the router's interface IP addresses. This value must be entered in the format of an IP address.
The default is null.
Specify the length of time, in seconds, between the Hello packets that the router sends on the interface with the hello-interval option of the area area-id virtual-link router subcommand. The argument number-of-seconds is an unsigned integer value. This value is advertised in the router's Hello packets. It must be the same for all routers attached to a common network. The smaller the Hello interval, the faster topological changes will be detected, but more routing traffic will ensue. The default is ten seconds.
Specify the number of seconds between link state advertisement retransmissions for adjacencies belonging to the interface, with the retransmit-interval option of the area area-id virtual-link router subcommand. The value for the number-of-seconds argument is an integer that should be greater than the expected round-trip delay between any two routers on the attached network. The setting of this parameter should be conservative, or needless retransmission will result. The value should be larger for serial lines and virtual links. The default value is five seconds.
Specify the estimated number of seconds it takes to transmit a link state update packet on the interface with the transmit-delay option of the area area-id virtual-link router subcommand. Link state advertisements in the update packet must have their age incremented by this amount before transmission. The value assigned should take into account the transmission and propagation delays for the interface. The argument number-of-seconds is an integer value that must be greater than zero. The default value is one second.
Set the number of seconds that a router's Hello packets have not been seen before its neighbors declare the router down with the dead-interval option of the area area-id virtual-link router subcommand. The argument number-of-seconds is an unsigned integer value. The default is four times the Hello interval. As with the Hello interval, this value must be the same for all routers attached to a common network.
Assign a specific password to be used by neighboring routers with the authentication-key option of the area area-id virtual-link router subcommand. The argument 8-bytes-of-password is any continuous string of characters that you can enter from the keyboard up to eight bytes in length. This configured data allows the authentication procedure to generate and/or verify the authentication field in the OSPF header. This key is inserted directly into the OSPF header when originating routing protocol packets. A separate password can be assigned to each network on a per-interface basis. All neighboring routers on the same network must have the same password to be able to route OSPF traffic. There is no default value.
The no area area-id virtual-link router-id command removes a virtual link.
The Routing Information Protocol (RIP) uses broadcast User Datagram Protocol (UDP) data packets to exchange routing information. Each router sends routing information updates every 30 seconds; this process is termed advertising. If a router does not receive an update from another router for 180 seconds or more, it marks the routes served by the nonupdating router as being unusable. If there is still no update after 240 seconds, the router removes all routing table entries for the nonupdating router.
The measure, or metric, that RIP uses to rate the value of different routes is the hop count. The hop count is the number of routers that may be traversed in a route. A directly connected network has a metric of zero (see Figure 1-5); an unreachable network has a metric of 16. This small range of metrics makes RIP unsuitable as a routing protocol for large networks. If the router has a default network path, RIP advertises a route that links the router to the pseudo-network 0.0.0.0. The network 0.0.0.0 does not exist; RIP treats 0.0.0.0 as a network to implement the default routing feature.
To create a routing process for RIP, use the router rip global configuration command:
router ripUse the no router rip command to shut down the routing process.
Next, specify the list of networks with the network router configuration subcommand. The full syntax of this command follows.
network network-numberThe argument network-number is a network number in dotted IP notation (of directly connected networks). Note that this number must not contain subnet information. You may specify multiple network subcommands. RIP routing updates will be sent and received only through interfaces on this network.
The network router subcommand is a mandatory configuration command and must be included in the configuration of each IP routing process.
The following example configuration defines RIP as the routing protocol to be used on all interfaces connected to networks 128.99.0.0 and 192.31.7.0.
router rip network 128.99.0.0 network 192.31.7.0
To remove a network from the list, use the no network router subcommand followed by the network address.
The Hello protocol, described in RFC 891, was developed for the Fuzzball gateways of the Distributed Computer Network project and was used extensively in the early NSFnet backbone network. Hello is an interior routing protocol.
The Cisco Systems implementation of Hello does not implement the extensive time-keeping and delay measurement features. Specifically, the router sets the invalid bit in the Hello date field and clears the time and timestamp fields.
The metric used in Hello is a delay value measured in milliseconds (see Figure 1-6). This metric can range from 0 to 30,000 milliseconds, making Hello a good candidate for routing larger networks. A network with a 30,000-millisecond delay is considered unreachable. The Cisco Systems implementation uses a delay of 100 milliseconds for all routes, regardless of their actual delay characteristics.
Create the routing process with the router global configuration command:
router helloUse the no router hello command to shut down the routing process.
After you have created the routing process, specify the list of networks. This list is specified with the network router configuration subcommand:
network network-numberThe network router subcommand is a mandatory configuration command and must be included in the configuration of each IP routing process.
The argument network-number is a network number in dotted IP notation (of directly connected networks). Note that this number must not contain subnet information. You can specify multiple network subcommands.
In the following example, the network 160.1.0.0 is being set up for Hello.
router hello network 160.1.0.0
BGP, as defined in RFC 1267, allows you to set up a distributed routing core that automatically guarantees the loop-free exchange of routing information on an autonomous system (AS) basis.
To configure BGP, use the router bgp global configuration command:
router bgp autonomous-systemThe autonomous-system number is used to identify the router to other BGP routers, and to tag the routing information passed along.
In the following example, a router is assigned to AS 120.
router bgp 120
Use the network router subcommand to specify networks that are to be advertised as originating within the current AS. These networks can be learned from connected, dynamic routing, and static route sources. The command syntax follows:
network network-numberThe argument network-number is the dotted IP address of the network that will be included in the router's BGP updates. The no version removes the specified network-number.
The network router subcommand is a mandatory configuration command and must be included in the configuration of each IP routing process. The maximum number of network subcommands allowed under a router BGP process is 200.
In the following command, the network 131.108.0.0 is set up to be included in the routers BGP updates.
network 131.108.0.0
BGP supports two different kinds of neighbors: internal and external. Internal neighbors are in the same autonomous system. External neighbors are in other autonomous systems.
BGP routing includes several related router subcommands that specify neighbor routers and manage your router's relationship with its neighbors. Use the neighbor router subcommands to:
In the simplest case, you want to specify that another router is a neighbor. Use the neighbor command, as shown below:
neighbor address remote-as numberThe argument address is the IP address of the neighbor. The argument number is the AS to which the neighbor belongs. Specifying a neighbor with a number that matches the AS number specified in the router bgp command identifies the neighbor as internal to the same AS to which the router belongs.
Using the no keyword removes the router as a neighbor.The arguments address and autonomous-system are the neighbor's address and AS number.
This example specifies that the router at the address 131.108.1.2 is a neighbor in AS number 109.
neighbor 131.108.1.2 remote-as 109
In the following example, a BGP router is assigned to AS 109, and two networks are listed as originating in the AS. Then the addresses of three remote routers (and their ASes) are listed. The router being configured will share information about networks 131.108.0.0 and 192.31.7.0 with the neighbor routers. The first router listed is in the same Class B networkaddress space, but in a different AS; the second neighbor command illustrates specification of an internal neighbor (with the same AS number) at address 131.108.234.2; and the last neighbor command specifies a neighbor on a different network.
router bgp 109 network 131.108.0.0 network 192.31.7.0 neighbor 131.108.200.1 remote-as 167 neighbor 131.108.234.2 remote-as 109 neighbor 150.136.64.19 remote-as 99
The neighbor weight router subcommand specifies a weight to assign to a specific neighbor connection. Its full syntax is as follows:
neighbor address weight weightThe argument address is the address of the neighbor. The argument weight is the weight to assign. All routes learned from this neighbor will have this initial weight. The route with the highest weight will be chosen as the preferred route when multiple routes are available to a particular network. Negative values for the weight argument are not allowed.
Use the no neighbor command with the appropriate arguments and keywords to remove this function.
In the example below, the neighbor at address 151.23.12.1 is assigned a weight of 50.
neighbor 151.23.12.1 weight 50
You can filter BGP advertisements in two ways: by using access lists, and by using AS-path filters. Access lists in IP are discussed in the chapter "Routing IP."
You can apply access lists to BGP updates with the neighbor distribute-list router subcommand. Its full syntax follows.
neighbor address distribute-list list {in|out}The argument address is the address of the neighbor. The argument list is a predefined access list number. The keywords in and out specify whether you are applying the access list to incoming or outgoing advertisements to that neighbor. Only standard access lists can be used with this command.
Use the no neighbor command with the appropriate arguments and keywords to remove this function.
In the example below, list 41 is applied to outgoing advertisements to neighbor 120.23.4.1.
neighbor 120.23.4.1 distribute-list 41 out
You can specify an access list filter on both incoming and outbound BGP routes. In addition, you can assign weights based on a set of filters. Each filter is an access list based on regular expressions. Use the ip as-path access-list global configuration command to define an BGP access list, and the neighbor router subcommand to apply a specific access list.
To define a BGP-related access list, use the ip as-path access-list global configuration command. The command syntax is:
ip as-path access-list list [permit|deny] as-regular-expressionThe list argument is an integer from 1 to 99.
Regular expressions are defined in the appendix "Pattern Matching." If the regular expression matches the representation of the autonomous system path of the route as an ASCII string, then the permit or deny condition applies.
Filters are established with the neighbor router subcommand, using access lists defined with the ip as-path access-list command. Several variations are allowed. The command syntax is:
neighbor address filter-list list {in|out|weight weight}The argument address is the address of the neighbor.
The argument list is a predefined BGP access list number.
One of three alternative keywords must also be used:
In the following example, the BGP-neighbor with IP address 128.125.1.1 is not sent advertisements about any path through or from the adjacent AS 123.
ip as-path access-list 1 deny ^123$ ip as-path access-list 1 deny ^123 .* ! The space in the above expression (^123.*)is required. router bgp 109 network 131.108.0.0 neighbor 129.140.6.6 remote-as 123 neighbor 128.125.1.1 remote-as 47 neighbor 128.125.1.1 filter-list 1 out
Cisco's implementation of BGP now supports Versions 2 and 3 of the protocol and permits dynamic version negotiation with neighbors. Cisco routers can be configured to handle only Version 2 of the protocol using the neighbor version router subcommand. The command syntax is:
neighbor ip-address version valueThe argument ip-address is the address of the BGP-speaking neighbor; the version value can be set to 2 to force the router to only use Version 2 with the specified neighbor. The default is to use Version 3 of BGP and dynamically negotiate down to Version 2 if requested. The no neighbor ip-address version value command returns the version to the default state for that neighbor.
Cisco's implementation of BGP allows the use of three possible administrative distances, assigned with the distance bgp router subcommand. The command syntax is:
distance bgp external-distance internal-distance local-distanceUse this command if another protocol is known to be able to provide a better route to a node that was actually learned via external BGP, or if some local routes should really be preferred by BGP.
The argument external-distance specifies the value for BGP external routes. External routes are routes for which the best path is learned from a neighbor external to the autonomous system. Acceptable values are positive, nonzero integers.
The argument internal-distance specifies the value for BGP internal routes. Internal routes are those routes that are learned from another BGP entity within the same autonomous system. Acceptable values are positive, nonzero integers.
The argument local-distance specifies the value for BGP local routes. Local routes are those networks listed with a network command--possibly as back doors (discussed in the next section)--for that router or for networks that are being redistributed from another process.
By default, the administrative distances are as follows
The no distance bgp command resets these values to the defaults.
To adjust the default BGP timers, use the timers bgp router subcommand. The full syntax of this command follows.
timers bgp keepalive holdtimeThe argument keepalive is the frequency in seconds with which the router sends keepalive messages to its peer (default 60 seconds) and holdtime is the interval in seconds after not receiving a keepalive message that the router declares a peer dead (default 180 seconds). The no timers bgp command restores the default.
In the example below, the keepalive timer is changed to 70 seconds, and the holdtime is changed to 210 seconds.
timers bgp 70 210
Use the EXEC command clear ip bgp to reset BGP connections. The command syntax is:
clear ip bgp *This command resets the BGP connection with the specified BGP neighbor (identified with the address argument). If you specify an asterisk (*), all current BGP sessions are reset.
In general, use this command whenever a policy changes. Changes that might prompt you to use this command are as follows:
To control how a BGP process determines which neighbors will be treated as peers, use the neighbor any router subcommand with the router bgp 0 global subcommand. The syntax for this command is as follows:
neighbor any [list]If the list argument is specified, the neighbor must be accepted by the access list number specified to be allowed to peer with the BGP process.
Continuing with the preceding sample configuration, the configuration would look like the following:
router bgp 109 network 131.108.0.0 network 192.31.7.0 neighbor 131.108.200.1 remote-as 167 neighbor 131.108.234.2 remote-as 109 neighbor 150.136.64.19 remote-as 99 neighbor any 1 access-list 1 permit 192.31.7.0 0.0.0.255
Use the no synchronization subcommand of the router bgp global command when you want to disable the synchronization between BGP and your IGP.
Usually, a BGP speaker does not advertise a route to an external neighbor unless that route is local or exists in the IGP. The no synchronization command will allow a router to advertise a network route without waiting for the IGP. This feature allows routers within an AS to have the route before BGP makes it available to other ASs. Use the synchronization command if there are routers in the AS that do not speak BGP. The default is synchronization.
no synchronizationIn Figure 1-7, with synchronization on, Router B will not advertise network 10.0.0.0 to Router A until an IGRP route for network 10.0.0.0 exists. If you specify the no synchronization command, Router B will advertise network 10.0.0.0 as soon as possible.
Use the show ip bgp EXEC command to display a particular network in the BGP routing table. Enter this command at the EXEC prompt:
show ip bgp [network]The optional argument network is a network number and is entered to display a particular network in the BGP routing table.
Following is sample output of the command without specifying a network number:
puck> show ip bgp
BGP table version is 22855, local router ID is 192.54.222.5
Status codes: * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric Weight Path
*> 128.128.0.0 131.192.115.3 0 ?
*> 192.132.70.0 192.54.222.9 20 702 701 ?
*> 152.155.0.0 131.192.77.1 0 ?
*> 192.74.137.0 192.54.222.9 20 702 701 i
*> 192.52.247.0 131.192.2.1 0 ?
*> 146.150.0.0 131.192.77.1 0 ?
*> 192.139.79.0 192.54.222.9 20 702 701 ?
*> 192.75.142.0 192.54.222.9 20 702 701 ?
*> 192.75.141.0 192.54.222.9 20 702 701 ?
*> 142.136.0.0 192.54.222.9 20 702 701 ?
*> 192.139.77.0 192.54.222.9 20 702 701 ?
*> 129.135.0.0 192.54.222.9 20 702 701 ?
*> 192.160.103.0 192.54.222.9 20 702 701 ?
*> 7.0.0.0 192.54.222.9 20 702 701 35 e
*> 139.140.0.0 131.192.34.2 0 ?
*> 8.0.0.0 131.192.2.1 0 ?
*> 192.58.242.0 131.192.2.1 0 ?
In the display:
Following is sample output of the command when used with a network number:
puck> show ip bgp 7.0.0.0
BGP routing table entry for 7.0.0.0, version 20760
Paths: (1 available, best #0)
702 701 35
192.54.222.9 from 192.54.222.9, metric 0, weight 20
Origin EGP, valid, external, best
In the display:
Use the show ip bgp neighbors network routes command to show the routes learned from that particular neighbor. Enter this command at the EXEC prompt:
show ip bgp neighbors network routesThe optional argument network is the network number for the neighbor whose routes you have learned from.
The display is the same as the display for the show ip bgp command.
Use the show ip bgp paths command to display all the BGP paths in the database. Enter this command at the EXEC prompt:
show ip bgp pathsFollowing is sample output:
Address Hash Refcount Metric Path 0x297A9C 0 2 0 i 0x30BF84 1 0 0 702 701 ? 0x2F7BC8 2 235 0 ? 0x2FA1D8 3 0 0 702 701 i
In the display:
Address--Internal address where the path is stored
Hash--Hash bucket where path is stored
Refcount--Number of routes using that path
Metric--INTER_AS metric for the path
Path--AS_PATH for that route, followed by the origin code for that route
Use the show ip bgp summary command to display the status of all BGP connections. Enter the command that follows at the EXEC prompt.
show ip bgp summaryFollowing is sample output:
BGP table version is 3937, main routing table version 3937 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Uptime/State 192.54.222.6 2 690 7655 268 3937 0 0 2:39:51 192.54.222.9 3 702 682 364 3937 0 0 2:39:54
In the display:
Use the following EXEC commands to debug BGP. For each debug command, there is a corresponding undebug command that runs the messages off.
debug ip-bgp-updatesThe debug ip-bgp-updates command generates per-update messages.
This section discusses the issues of BGP interacting with the various interior gateway protocols (referred to generically as IGPs), such as IGRP, RIP, and Hello. BGP maintains its own routing table, separate from the main IP routing table used to make datagram switching decisions. The BGP routing table is organized by network, and contains information referred to as attributes, such as the list of ASes that a datagram must transit to reach a particular network. Information from the BGP routing table is entered into the main IP routing table (see Figure 1-8). In most cases, the BGP information should override IGP information.
Networks that originate in the local AS are indicated with the network router subcommand for the BGP process. Such networks, referred to as local networks, will have a BGP origin attribute of IGP. They appear in the main IP routing table and may have any source, for example, directly connected, static route, learned from an IGP, and so forth. The BGP routing process periodically scans the main IP routing table to detect the presence or absence of local networks, updating the BGP routing table as appropriate.
It is possible to indicate which networks are reachable using a back-door route that the border router should use. A back door network is treated as a local network, except that it is not advertised.
Use this variation of the network router subcommand to specify a backdoor route:
network address backdoorThe network router subcommand is a mandatory configuration command and must be included in the configuration of each IP routing process.
The argument address is the network that you wish a backdoor route to.
In the example below, network 131.108.0.0 is a local network and network 192.31.7.0 is a backdoor network.
router bgp 109 network 131.108.0.0 network 192.31.7.0 backdoor
Using the redistribute router subcommand, you can inject BGP routing information into the IGP. This creates a situation where BGP is potentially deriving information about local networks from the IGP, and then sending such information back into the IGP. This is another reason to suppress nonlocal networks from the IP routing table--you do not want to hear echoes of your routing updates.
It is also possible to inject IP routing table information into the BGP routing table using the redistribute router subcommand. EGP-derived information will have a BGP origin attribute of EGP; all other nonlocal routes will have a BGP origin attribute of incomplete. All IGP and EGP information will now override BGP-derived IP routing table entries. If you are also redistributing information from BGP into an IGP, you must set up appropriate filtering to ensure that routing information does not loop. A configuration such as this is fairly risky, requiring careful attention to filtering. Filtering is described in more detail earlier in this chapter and in subsequent discussions.
The BGP process selects a single AS path to pass along to other BGP-speaking routers. It is important for routing stability that each BGP-speaking router in an AS use the same set of rules so that all BGP-speaking routers arrive at a consistent view of the AS topology. To this end, the Cisco BGP implementation has a reasonable set of factory defaults that may be overridden by administrative configuration, as follows:
You can also create routing loops if a BGP speaker injects a route into the IGP and then forwards packets back into the AS. For this reason, routes learned via internal BGP cannot be redistributed into other routing protocols.
The Cisco BGP implementation supports all path attributes defined in RFC 1163 and 1267. This section describes some details of that implementation.
The default-metric router subcommand may be used to configure the value for the INTER_AS metric attribute. The same metric value will be sent with all BGP updates originating from the router. The default is to not include an INTER_AS metric in BGP updates.
The Cisco implementation will use a third-party next hop router address in NEXT_HOP attribute regardless of the AS of that third-party router.
Transitive, optional, path attributes are passed along to other BGP-speaking routers. The Cisco BGP implementation does not currently generate such attributes.
The Exterior Gateway Protocol (EGP), specified in RFC 904, is used for communicating with certain routers in the Defense Data Network (DDN) that the U.S. Department of Defense designates as core routers. EGP is also extensively used when attaching to the NSFnet (National Science Foundation Network) and other large backbone networks as shown in Figure 1-9. An exterior router uses EGP to advertise its knowledge of routes to networks within its autonomous system. It sends these advertisements to the core routers, which then re-advertise their collected routing information to the exterior router. A neighbor or peer router is any router with which the router communicates using EGP.
Before you can set up EGP routing, you must specify an autonomous system number using the autonomous-system global configuration command. The syntax for this command follows:
autonomous-system local-ASThe argument local-AS is the local autonomous system (AS) number to which the router belongs. The local AS number will be included in EGP messages sent by the router. To remove the AS number, use the no autonomous-system global configuration command.
After the local AS number has been specified, start the EGP routing process with a router egp global configuration command:
router egp remote-ASThe argument remote-AS is the AS number the router expects its peers to be advertising in their EGP messages. The Cisco software does not insist that the actual remote AS number match the configured remote AS numbers. (The output from debug ip-egp EXEC command will advise of any discrepancies, however. See the section "Debugging IP Routing" for more information.) Turn off your EGP routing process with the no router egp subcommand.
A router using EGP cannot dynamically determine its neighbor or peer routers. You must provide a list of neighbor routers using the neighbor router subcommand:
neighbor ip-addressThe argument ip-address is the IP address of a peer router with which routing information will be exchanged. Multiple neighbor subcommands may be used to specify additional neighbors or peers. The no neighbor subcommand followed by an IP address removes a peer from the list.
Use the network router subcommand to specify the network to be advertised to the EGP peers of an EGP routing process.
network network-numberThe argument network-number is the IP address of the network. Such networks are advertised with a distance of zero. There is no restriction on the network number other than that the network must appear in the routing table. The network may be connected, may be statically configured, or may be redistributed into EGP from other routing protocols.
Multiple network subcommands may be used to specify additional networks. The no network subcommand followed by the network number removes a network from the list.
The network router subcommand is a mandatory configuration command and must be included in the configuration of each IP routing process.
The following is an example configuration for an EGP router process. The router is in autonomous system 109 and is peering with routers in AS 164, as shown in Figure 1-10. It will advertise the networks 131.108.0.0 and 192.31.7.0 to the router in AS 164, 10.2.0.2. The information sent and received from peer routers may be filtered in various ways, including blocking information from certain routers and suppressing the advertisement of specific routes.
autonomous-system 109 router egp 164 network 131.108.0.0 network 192.31.7.0 neighbor 10.2.0.2
The Hello and polltime timers for EGP are adjustable. To adjust the EGP timers, use the subcommand:
timers egp hello polltimeThe argument hello is the frequency in seconds with which the router sends Hello messages to its peer. The default is 60 seconds.
The argument polltime is the interval in seconds after not receiving a Hello message that the router declares a peer dead. The default is 180 seconds, and the no timers egp restores this default.
This command changes the EGP timers to two minutes and five minutes respectively.
timers egp 120 300
To change the invalid time or flush time for EGP routes, use the timers basic command as explained in the section "Special Routing Configuration Techniques" later in this chapter.
EGP supports what is termed a third-party mechanism. In this circumstance, EGP tells its peer that another router (the third party) on the shared network is the appropriate router for some set of destinations. If updates mentioning third-party routers are desired, they may be configured using a variation of the neighbor router subcommand:
neighbor address third-party third-party-ip-address [internal|external]The argument third-party-ip-address is the address of another router (the third party) on the network shared by the Cisco router and the EGP peer specified by the address argument. All networks reachable through that third-party router will be listed in the Cisco EGP updates as reachable via that router. Any other networks will be listed as reachable via the Cisco router. The optional keyword internal or external indicates whether the third-party router should be listed in the internal or external section of the EGP update. Normally, all networks are mentioned in the internal section. You may use the neighbor address third-party router subcommand multiple times to specify additional third party routers.
In the following example, routes learned from router 131.108.6.99 will be advertised to 131.108.6.5 as third-party internal routes.
neighbor 131.108.6.5 third-party 131.108.6.99 internal
In the following example, routes learned from 131.108.6.100 will be advertised to 131.108.6.5 as third-party external routes.
neighbor 131.108.6.5 third-party 131.108.6.100 external
It may be desirable to have a second router belonging to a different AS act as a backup to the EGP router for your AS. To differentiate between the primary and secondary EGP routers, the two routers will advertise network routes with differing EGP distances or metrics. A network with a low metric is generally favored over a network with a high metric.
Networks flagged with the network router subcommand are always announced with a metric of zero. Networks that are redistributed will be announced with