John Albritton, CCIE
$55.00 0-07-134743-7
|
Cisco IOS Essentials
John Albritton, CCIE $55.00 0-07-134743-7 |
|
| Reserve your copy at a Bet@ Bookstore near you! |
Contact Bet@ Books © 1999 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use. |
The Internet Protocol (IP) is the only routed protocol that is turned on by default on a Cisco router running IOS. The acronym IP is actually an abbreviated way of writing TCP/IP (Transmission Control Protocol/Internet Protocol), which is the suite of protocols and applications used on the Internet and many private internetworks.
We are going to begin the coverage of IP configuration with a brief overview of IP and how IOS processes its traffic. Then we will delve into the configuration itself and make some modifications to the internetwork that we built in Chapter 3. The only version of IP covered in this book is IP version 4.
All hosts that run IP must have a unique IP address. An IP address is a logical address that is independent of a host’s hardware. IP addressing is perhaps the most mystifying part of IP for people who are new to the networking world; however, it really is very simple. To understand, you just need to use a little bit of binary (base 2) arithmetic and decimal (base 10) arithmetic.
IP addresses are 32 bits long, and the normal way of writing them is called dotted-decimal notation. To write an address in dotted-decimal notation, we divide the 32 bits of the address into four 8-bit chunks. Each 8-bit chunk is called an octet or a byte. We then convert the octets from binary to decimal and put dots (.) between them. Figure 7-1 shows four forms of the same IP host address.
<<<J115 – Figure 7-1 IP Address Notations>>>
The first form in Figure 7-1 is normal binary, just a string of 32 ones and zeros; each one and zero is a bit. This form is difficult for people to read, but it is what a computer, like a router, sees. The decimal representation of the binary address has a rather large value; 32 bits can represent decimal numbers between 0 and 4,294,967,295. The second line is the decimal equivalent of the first line. How would you like to read a number like that every time you wanted to communicate a host address to someone?
The third line of Figure 7-1 is just an intermediate step toward the last line, with the 32 bits divided into four octets. The last form, dotted-decimal notation, is the one that we use, and it is the easiest to read and write.
Since each of the four quarters (octets) of an IP address is eight bits and the decimal values that can be represented with eight bits range from 0 to 255, the value of any one of the numbers in a dotted-decimal IP address cannot exceed 255.
IP addresses have two main parts – a network part that identifies the network where a host resides and a node part that identifies a specific host on the network (sort of like a street name and a house number). The network and node parts together make up the full IP address of a host. The network part is used by routing software to determine for which network a packet is destined. The node part is used by routing software to send a packet to an individual host once the packet has reached the host’s network. Just to make this a little more exciting, the line between network and node moves.
There are three things that can be used to tell which part of an address is network and which part of an address is node. These are as follows:
The network mask explicitly specifies which part of an IP address represents a network. The network mask is 32 bits long and is normally written in dotted-decimal notation just like an address. An IP address and mask are usually written together, with the mask immediately after the address.
A network mask has binary ones in the bit positions that represent the network part of an address and binary zeros in the bit positions that represent the node part of an address. The binary ones must start from the left (most-significant) side of the mask and extend contiguously (They must be side by side.) until the network part ends; the rest of the mask must be all zeros. For example, the mask
255.255.255.0
when paired with an IP address, would tell us that the first 24 bits of the address is considered network and the last eight bits are node. This becomes clear when the binary equivalent of this mask is examined as shown below:
11111111 11111111 11111111 00000000 (Binary)
255 . 255 . 255 . 0 (Dotted-Decimal)
We see that the mask has 24 ones, starting from the left, and eight zeros. Let us apply this mask to the IP address in Figure 7-1.
11000000 10101000 10000001 01100011 (Address)
11111111 11111111 11111111 00000000 (Mask)
Since the mask indicates that the first 24 bits of the address are the network, the network address must be
11000000 10101000 10000001 01100011
192 . 168 . 129 . 0
An IP address that has binary zeros in all of the node bits represents a network, not a host. An IP address that has binary ones in all of the node bits represents all of the hosts on a network; this is called a broadcast address. The broadcast address of the 192.168.129.0 network in the above example is:
10101100 00010000 10000001 11111111
192 . 168 . 129 . 255
The node values between all zeros and all ones identify individual hosts on a network. Therefore, the 192.168.129.0 255.255.255.0 network can have hosts with addresses between 192.168.129.1 and 192.168.129.254. That is 254 valid host addresses on this particular network. Figure 7-2 shows the simple formula for calculating the number of valid host addresses on a network.
<<<J117 – Figure 7-2 Network Hosts Formula>>>
Applying this formula to our running example with eight node bits has the following results:
2
8 – 2 = 256 – 2 = 254 HostsThe answer is the same, 254 hosts on the network 192.168.129.0 255.255.255.0.
Some publications refer to an address’ network part, the part that is significant for routing, as a prefix; therefore, all we really have to do is specify the length of the prefix to communicate the same information as the network mask.
A prefix length is written immediately after an IP address as a decimal number preceded by a forward slash (/). In our example above, the host address with prefix length would be written as
192.168.129.99/24
Notice that 24 is the length of the network part (prefix) of the address; this leaves eight (32 minus 24) node bits. Notice also that the prefix length is the number of binary ones in the network mask.
IOS can use either a network mask or a prefix length when it displays IP addressing information to us. As of version 11.2, prefix length is the default.
In the absence of an explicitly stated network mask, the class of an address identifies the network part of an address. There are five classes of IP addresses: A, B, C, D, and E; these are summarized in Figure 7-3. Only class A, B, and C addresses are used for host addressing. Class D addresses are used for multicast addresses, and class E addresses are reserved. We will be concentrating on class A, B, and C addresses.
<<<J116 – Figure 7-3 IP Address Classes>>>
Each of the host-address classes has a default-length network part and node part; therefore, each has a default network mask and prefix length. These are shown in Figure 7-3.
The easiest way to tell the class of an address is to look at its first octet in decimal. Again, the first octet refers to the most significant one, the one on the left. Figure 7-3 shows the range of decimal numbers for each class’ first octet. Based on these ranges, the address, 192.168.129.99, used in Figure 7-1 and the network mask examples is a class C address. The network mask and prefix length we used in the examples is the default for a class C address.
There is a limited number of IP network addresses, and, since each network must have its own address, we sometimes need to artificially increase the number of networks we can address at the cost of reducing the number of hosts on each network.
Suppose, for example, that we have been assigned a class B address to address our network. A class B address has 16 node bits so we can address a single network that has 65,534 hosts. Our internetwork is likely to have many networks, and none of them is likely to have that many hosts. Therefore, to efficiently utilize the assigned address space, we can take some of the node bits and use them to address networks (subnets) instead of hosts. A subnet is still a network, but it has an address that has been derived from a classful network address such as a class B network address.
Subnetting is the act of taking some of the node bits and using them as network bits. This is accomplished by extending the binary ones of the network mask to the right to include some of the node bits. The length of the mask must still be 32; therefore, to increase the number of network bits, we must decrease the number of node bits.
The extent of the increase in network bits depends on the number of subnets we need and the number of hosts we need on each subnet. Figure 7-4 shows some possible ways of subnetting class B networks and Figure 7-5 shows some possible ways to subnet class C networks.
|
Network Mask |
Prefix Length |
Subnet Bits |
Node Bits |
Subnets |
Hosts |
|
255.255.0.0 |
/16 |
0 |
16 |
0 (1 Net) |
65534 |
|
255.255.192.0 |
/18 |
2 |
14 |
2 |
16382 |
|
255.255.224.0 |
/19 |
3 |
13 |
6 |
8190 |
|
255.255.240.0 |
/20 |
4 |
12 |
14 |
4094 |
|
255.255.248.0 |
/21 |
5 |
11 |
30 |
2046 |
|
255.255.252.0 |
/22 |
6 |
10 |
62 |
1022 |
|
255.255.254.0 |
/23 |
7 |
9 |
126 |
510 |
|
255.255.255.0 |
/24 |
8 |
8 |
254 |
254 |
|
255.255.255.128 |
/25 |
9 |
7 |
510 |
126 |
|
255.255.255.192 |
/26 |
10 |
6 |
1022 |
62 |
|
255.255.255.224 |
/27 |
11 |
5 |
2046 |
30 |
|
255.255.255.240 |
/28 |
12 |
4 |
4094 |
14 |
|
255.255.255.248 |
/29 |
13 |
3 |
8190 |
6 |
|
255.255.255.252 |
/30 |
14 |
2 |
16382 |
2 |
<<<Figure 7-4 Class B Network Subnetting>>>
|
Network Mask |
Prefix Length |
Subnet Bits |
Node Bits |
Subnets |
Hosts |
|
255.255.255.0 |
/24 |
0 |
8 |
0 (1 Net) |
254 |
|
255.255.255.192 |
/26 |
2 |
6 |
2 |
62 |
|
255.255.255.224 |
/27 |
3 |
5 |
6 |
30 |
|
255.255.255.240 |
/28 |
4 |
4 |
14 |
14 |
|
255.255.255.248 |
/29 |
5 |
3 |
30 |
6 |
|
255.255.255.252 |
/30 |
6 |
2 |
62 |
2 |
<<<Figure 7-5 Class C Network Subnetting>>>
The number of hosts per subnet shown in Figure 7-4 and Figure 7-5 was calculated using the formula from Figure 7-2. The number of subnets uses the same formula except subnet bits have been substituted for node bits. The same formulas can be applied to class A addresses, even though they are not shown. The number of subnet bits in the Figures 7-4 and 7-5 is the number of bits that the mask has been extended to the right from the default according to the address class.
Once we determine what type of subnetting will be used, addresses for each of the networks (or subnets) should be calculated. We can use decimal arithmetic to do this easily. Let us again take the IP address used in Figure 7-1, 192.168.129.99. Using the default mask for a class C address, we determined that this is the address of a host on the 192.168.129.0 network. Now suppose that we need to use this same network to address six networks that will have no more than 30 hosts each. Based on Figure 7-5, we can use a network mask of 255.255.255.224 (three subnet bits) to accomplish this.
Following these steps to calculate the network addresses of the subnets.
For example, in our mask, the last non-zero octet is the fourth octet and its value is 224. Subtracting 224 from 256 yields 32. The subnet seed is 32, and all of the subnet addresses are multiples of 32 in the fourth octet. The network addresses of our six subnets are as follows:
That is six subnets just like Figure 7-5 indicated. The first and last combinations of the three subnets are not normally used, even though they can be used. These combinations yield subnet addresses 192.168.129.0 and 192.168.129.224. We will call these the zero subnet and the all-ones subnet, respectively. IOS will support the use of these special subnets, but not all other hosts will; therefore, to be safe, we are not including them here.
The broadcast address of each subnet is the address one less that the next higher subnet. For example, the broadcast address of the 192.168.129.96 subnet is 192.168.129.127. Remember that the valid host addresses for a network or subnet are those addresses between the network’s address and its broadcast address; therefore, the valid host addresses for the 192.168.129.96 255.255.255.224 network range from 192.168.129.97 through 192.168.129.126. That is 30 hosts just like we calculated.
Our example IP host address, 192.168.129.99, is in this range; therefore, it is a host on the 192.168.129.96/27 subnet. We could have just calculated this by using a calculation similar to the one we used to calculate the subnet addresses. The last non-zero value in the network mask is 224 is in the fourth octet. Dividing the fourth octet of the host address (99) by the subnet seed (32) gives a result of 3 (never mind the remainder). Multiplying the result (3) by the seed (32) yields the subnet address’ fourth octet value (96).
Network traffic that traverses a public network like the Internet must use public addresses. When we connect one of our networks directly to the Internet, we usually have public addresses assigned to us by an Internet Service Provider (ISP). ISP’s get their public addresses from American Registry for Internet Numbers (ARIN).
IP packets with public addresses can be routed on the Internet because the addresses are unique; however, because of a shortage of public addresses, private addresses has been defined for use on networks that are not going to connect directly to the Internet. RFC 1918 defines one class A network address, 16 class B network addresses, and 256 class C network addresses to be private. These addresses are as follows:
The IP address, 192.168129.99, that we have been using in our examples is taken from a private class C network address.
Many companies are using these network addresses to address their internal internetworks (intranetworks), which connect to the Internet through a firewall or some other system that performs Network Address Translation (NAT). In these cases, NAT is used to translate the private addresses found in the internal IP packets to public addresses to allow the packets to be routed on the external Internet.
The TCP/IP protocol suite has been around since the late 1970’s; this is long before the OSI Reference Model (see Section 2.1.1) was developed. However, since the OSI Reference Model is a "reference model", we will refer to it when discussing the layers of the IP stack. The OSI Reference Model and the IP stack are shown side by side in Figure 7-6. The functionality of the OSI Reference Model layers is present even though the IP stack is represented as only four layers instead of seven.
<<<J114 – Figure 7-6 IP Stack Compared to OSI Reference Model>>>
We are going to cover just enough about the basics of IP to allow us to understand what we are doing when we configure it. We will start at the bottom of the stack and work our way up describing each layer and the individual blocks shown in them in Figure 7-6.
Layers 1 and 2 deal with the connection of a host to a network. IP running on a host is independent of the type of network connection.
Layer 1 defines the physical medium where a host is attached. A host running IP can be attached to just about any kind of network.
Layer 2 defines the format of the frame header and trailer that a host builds and wraps around a packet before transmitting the packet. The frame header contains a field that indicates the protocol encapsulated between the frame header and the frame trailer. The field is called either protocol type or Service Access Point (SAP) depending on the encapsulation type configured on the host’s interface. For example, with ARPA encapsulation on Ethernet, a protocol type field value of 0x0800 (hexadecimal 0800) indicates that an IP packet is encapsulated within the frame and an IP header immediately follows the frame header. With SAP encapsulation, a SAP field value of 0x06 means the same thing.
The layer-2 header of a frame traveling a LAN contains the addresses that are used to identify the network host that transmitted the frame and the host, or hosts, to whom the frame is destined. These addresses are called MAC addresses. The MAC address of each host on a network must be unique. The layer-2 header gets removed and rebuilt each time that frame is forwarded by a router; therefore, the layer-2 addresses change in the header from one network to the next.
At layer 3, there can be either an IP header or Address Resolution Protocol (ARP) data.
IP is used for the exchange of data between hosts. At layer 3 of an IP packet is the IP header. The IP header does not contain real data, but it does many items that are used by the protocol. Some of these are shown below:
The source IP address is the 32-bit IP address of the host that originated the packet. The destination IP address is the 32-bit IP address that routers examine to determine where to route a packet. The destination IP address can be a unicast host address, a broadcast address, or a multicast address. Neither the source IP address nor the destination IP address normally changes from the time a packet leaves a host to the time the packet arrives at its destination.
The time to live (TTL) field in a packet’s IP header is decremented each time the packet is routed by a router. The use of TTL keeps a packet from being routed endlessly on an internetwork when its destination cannot be found. When a router decrements a packet’s TTL to zero (0), the router must drop the packet. The router can then send an ICMP message to the packet’s source indicating the reason the packet was dropped (TTL exceeded). The TTL field has a maximum value of 255; therefore, in theory, if the source host sent a packet with a beginning TTL of 255, the packet could get routed 255 times before it got dropped.
The protocol number identifies the next level protocol, that is, what is after the IP header in the packet. Following are some examples of items that could follow the IP header and their associated protocol numbers:
TCP Header – Protocol Number 6
UDP Header – Protocol Number 17
ICMP Message – Protocol Number 1
IGRP Message – Protocol Number 9
Upper-layer applications usually use TCP or UDP, but before a host gets to the application data, it must read a TCP or UDP header. TCP and UDP are probably the most used protocol numbers.
Hosts use ARP to acquire the MAC address of another host to which a frame is being transmitted. This is done during the frame encapsulation process. A source host presumably would already know the IP address of a destination host and would be able to build the layer-3 (IP) header containing both source and destination IP addresses. However, the source host also must build a frame header for encapsulation of the packet on a LAN. The frame header contains the source and destination MAC addresses. The source host knows its own MAC address, but it needs to know the destination host’s MAC address to complete the frame header.
The source host locates a destination host’s MAC address by sending a layer-2 broadcast frame onto the LAN asking for the MAC address associated with a given IP address; this frame is called an ARP request. Every host on a network examines a layer-2 broadcast frame. If the destination host is on the network, it will recognize the IP address in the ARP request frame and send an ARP reply to the source host. The ARP reply contains the destination host’s MAC address that the source host uses to complete the frame header. The source host also puts the destination host’s MAC address and IP address into a table, called the ARP cache. The next time the source host wants to send a frame to the destination host, it can just look up the destination host’s MAC address in the ARP cache and not send the ARP request.
If a router receives an ARP request for a destination host on a network other than the one on which the request was received, the router can reply on behalf of the destination host. The source host receives an ARP reply containing the router interface’s MAC address, thus instructing the source host to send its frame to the router to be routed. The feature, called proxy ARP, is enabled by default in IOS, but we can disable it if we desire.
ARP is extremely important in IP-based networks. Some textbooks call ARP a layer-2 protocol because its messages are never routed at layer 3. ARP is included at layer 3 here only because the ARP messages follow the layer-2 header.
A router is not normally concerned with information above layer 3 in a packet unless the router is generating its own traffic, receiving traffic destined for it, or performing packet filtering.
IP traffic generated by a router can include ICMP messages and routing protocol updates. A router both receives and generates traffic when a telnet connection is established to it or from it.
TCP is a connection-oriented protocol. This means that applications can use TCP at layer 4 to establish a connection with each other, and the applications can depend on TCP to perform sequencing, acknowledging, and windowing of their data. TCP is considered to be a reliable transport for application data.
Port numbers in the TCP header identify the upper layer applications, source and destination, that are using the connection.
UDP is a connectionless protocol. Applications that use UDP at layer 4 must do connection establishment themselves if a connection is required. UDP does no data sequencing, acknowledging, or windowing. UDP is used when applications want to handle these tasks themselves or applications want to just send data to other applications without the overhead and delay of connection establishment.
Similar to TCP, port numbers in the UDP header identify the upper layer application that a message came from and the upper layer application for which a message is destined.
Hosts (especially routers) use ICMP to communicate network conditions or errors to other hosts. For example, ICMP is used to communicate a packet’s exceeded time to live to the host that sent the packet (see Section 7.2.2.1).
ICMP messages are also used to communicate broken routing or nonexistent networks to transmitting hosts. ICMP Destination Unreachable messages are used for this purpose.
Probably the most recognizable use of ICMP is found within the ping application. The IP implementation of ping uses ICMP echo messages to test connectivity. When we want to find out if a host is accessible, we can "ping" the host with an ICMP echo request containing data. If the host receives the request, it should respond by returning an ICMP echo response containing the same data.
Other possible protocols that appear at layer 4 of IP include Interior Gateway Router Protocol (IGRP), Enhanced IGRP (EIGRP), and Open Shortest Path First (OSPF). All of these examples are IP routing protocols.
Layers 5, 6, and 7 are loosely bundled for all IP-based applications. Most of the applications we use everyday, run over TCP or UDP. IOS can run many of these applications.
TCP applications that can run on IOS include:
Telnet is a remote session application that is used to when configuring a remote router. rcp is a file copy application that can be used to copy files to and from a Cisco router. HTTP is the application used to transfer World Wide Web (WWW) pages from web servers to web clients (browsers).
UDP applications that can run on IOS include:
TFTP is a file copy application that is used to copy files to and from a Cisco router. SNMP is a network management application used to monitor and manage network devices, and DNS is the application used to translate host names to IP addresses and vice versa.
When a router receives a frame that contains an IP packet, the router removes the frame header and trailer; it then sends the packet to the IP routing process. The IP routing process looks for an entry in the IP routing table that matches the destination IP address in the packet’s IP header.
The IP routing table contains a list of the best paths to the networks that IOS knows about. Each network entry includes its address and its prefix length (or network mask). The prefix length tells the router how much of an address is significant for routing, or how much of a destination address to use when a routing decision is being made. If the router finds multiple matches for a destination in the routing table, the router uses the most specific entry, that is the one with the longest prefix length.
The routing table also contains the name of the interface out which IOS should transmit a packet to reach the network and, potentially, the address of another router (a next-hop gateway) to which IOS can forward the packet for further routing. Figure 7-7 shows the display of the IP routing table resulting from the entry of the show ip route command on our test router Dallas.
<<<Figure 7-7 IP Routing Table on Dallas>>>
We will see many versions of IP routing tables throughout this chapter as we make modifications to our test network, but let us start with this very simple one. The display of the IP routing table begins with a legend describing the character notations that appear at the beginning of each network entry. On Line 12 or Figure 7-7, the entry begins with an R indicating that the network was learned through RIP. Lines 13 and 14 begin with a C indicating networks that are directly connected to this router.
Line 11 shows that we have three subnets, each with a prefix length of /24; that is a network mask of 255.255.255.0 (24 ones, remember). The two entries for directly-connected networks are almost self explanatory. All we are shown is the interface that is used to reach the network.
The RIP entry on Line 12 contains a little more information. We can interpret this the following way. When IOS receives a packet with a destination address matching 172.16.20.0/24, IOS should forward the packet out Serial1 to the router with address 172.16.11.2; network 172.16.20.0/24 is one hop away, and IOS last received an update for it five seconds ago. The next hop router, the time, and the interface are easily spotted in the displayed entry. The hop count is not so obvious.
Immediately after the network address itself, are two numbers in brackets, [120/1]. The second number within the brackets (after the slash) is a metric, 1 in this case. Since RIP’s metric is hop count, this must be a number of hops. The first number within the brackets is called the administrative distance.
IOS has three primary ways of learning about network routes to put into its routing table. Two of these are displayed in Figure 7-7: a direct network connection and a routing protocol. The third is a static route, which is our manual entry of a route into the routing table.
IOS can run many routing protocols simultaneously; only RIP is being run so far on our test network. Each routing protocol uses a different metric, which is used to gauge the length of the paths to the networks it is advertising. When IOS learns about multiple paths to a network from a routing protocol, IOS puts the best path, the one with the lowest metric, into the routing table. However, when IOS is running multiple routing protocols and it learns about multiple paths to a network from different routing protocols, how does it compare the different metrics of the protocols? The answer is, "It doesn’t."
Each routing protocol and each other way that IOS can get potential routing table entries has an associated administrative distance. We can think of administrative distance as a measure of believability for something heard. The lower the administrative distance for a potential routing table entry, the more believable the entry and, thus, the more likely the learned route will be placed into the routing table as the best route to a network.
A directly-connected network has an administrative distance of zero (0). This is the lowest possible distance and the most believable route. A route cannot be any better than directly-connected. The next most believable route is a static route; if we manually enter a route into the routing table, IOS assumes that we know what we are doing. A static route has a default administrative distance of one (1). We will cover static routes and routing protocols in more detail as we implement them.
When IOS learns about several routes to a network and must select the best one for placement in the routing table, the first measurement IOS uses is administrative distance. The route with the lowest administrative distance is the best one and is placed in the routing table. If IOS has multiple routes with the same administrative distance, the one with the lowest metric is the best one. If multiple routes to a network have the same administrative distance and the same metric, all of the routes, up to six, are placed into the routing table; IOS then load shares traffic across all of the routes.
The command to tell IOS to route IP packets on an interface is:
ip address
address maskwhere address is the IP address, in dotted-decimal notation, that should be assigned to the interface, and mask is the address’ network mask in dotted-decimal notation. The ip address command is an interface configuration mode and subinterface configuration mode command. This makes sense because we must specify the interface that will get the address before we assign the address.
The address specified with this command becomes the primary IP address for an interface. To change an interface’s IP address, we can just type this command again in interface configuration mode with the new IP address and mask.
The ip address command will be used in the next section when we add a router to our test internetwork.
We already have an internetwork configured to route IP traffic. We configured this internetwork of two routers, Dallas and FortWorth, in Chapter 3 using the System Configuration Dialog. Figure 7-8 shows the existing internetwork’s IP configuration.
<<<J112 – Figure 7-8 Two-Router IP Internetwork>>>
The current routing table for Dallas is shown in Figure 7-7. The two routers are using the RIP routing protocol to exchange information about their networks.
To illustrate the configuration of IP, we are going to add a router to the internetwork and do its configuration from scratch using the IOS command line interface. The new internetwork of three routers is shown in Figure 7-9. We are going to add a router named Austin, and this three-router internetwork will be used for most of the examples throughout the rest of this book.
<<<J110 – Figure 7-9 Three-Router IP Internetwork with Interface Addresses>>>
Austin has a 256 kbps leased line to Dallas and a 56 kbps leased line to FortWorth. Figure 7-9 has the IP addresses of each of the new interfaces that we will be using to connect Austin into the internetwork. Notice that abbreviations for the interfaces are being used to conserve space; Ethernet is E, and Serial is S.
The implementation of Austin will be done using the following steps:
Dallas and FortWorth already have working configurations; therefore, they each need only one interface configured. Austin will be booted with no startup configuration, and we will answer No to the initial configuration dialog question (see Section 3.5.1) to avoid entering the System Configuration Dialog.
We need to give interface Serial0 on Dallas the IP address 192.168.2.1 with a network mask of 255.255.255.0 (prefix length /24), according to Figure 7-9. Since the leased line to which Serial0 connects has a bandwidth of 256 kbps, we should also set the bandwidth for future reference. Figure 7-10 shows the commands for configuring Serial0 on Dallas for connection to Austin.
<<<Figure 7-10 IP Configuration on Dallas Serial0>>>
IOS configuration changes must be made from a configuration mode. The configure terminal command (Line 1) is used to get to global configuration mode, and the interface serial0 command (Line 3) is used to get to interface configuration mode where commands affecting Serial0 can be entered. The ip address command is used to assign the IP address to the interface (Line 4), and the bandwidth is set to 256 (Line 5). The bandwidth parameter was described in Section 6.2.4; it does not affect the operation of the WAN; we are just putting it here for future informational purposes. The description (Line 6) is just our way of documenting the reason for the link. Since Serial0 was administratively down when we started, we start it with the no shutdown command (Line 7). Serial0 will not come up until Austin’s Serial1 interface is configured and keepalives are exchanged across the link.
According to Figure 7-9, interface Serial1 on FortWorth should be assigned the IP address 192.168.3.1 with a network mask of 255.255.255.0 (prefix length /24). Figure 7-11 shows the commands for configuring Serial1 on FortWorth for connection to Austin.
<<<Figure 7-11 IP Configuration on FortWorth Serial1>>>
The commands for FortWorth are very similar to those we just entered for Serial0 of Dallas in Section 7.5.1. The configure terminal command (Line 1) is used to get to global configuration mode where we can make changes. Since we are changing the configuration of an interface, we use the interface serial1 command (Line 3) to get to interface configuration mode for Serial1. The ip address command is used to assign the IP address to the interface (Line 4), and the bandwidth is set to 56 (Line 5). The description (Line 6) is just documentation for the link. Serial1 was administratively down when we started; we start it with the no shutdown command (Line 7). Serial1 will not actually come up (up/up state) until Austin’s Serial0 interface is activated and keepalives are exchanged.
When we turned on the new router that is to become Austin, it had no startup configuration; therefore, IOS asked us to enter the initial configuration dialog. We answered No to the question. It looked like this:
Notice: NVRAM invalid, possibly due to write erase.
--- System Configuration Dialog ---
At any point you may enter a question mark '?' for help.
Use ctrl-c to abort configuration dialog at any prompt.
Default settings are in square brackets '[]'.
Would you like to enter the initial configuration dialog? [yes]: no
Press RETURN to get started!
When we do not run the System Configuration Dialog on a new router, the result is a running configuration that essentially does nothing useful. The router has the default name Router; all of the interfaces are shut down (administratively down state), and there are no passwords. We will start from the user mode prompt and configure the host name, the passwords, and the interfaces. All of the commands for accomplishing this are shown in Figure 7-12.
<<<Figure 7-12 Initial Configuration of Austin with IP>>>
The commands used in Figure 7-12 have been previously covered in this book; we will use this context to review them. We cannot make any changes to IOS from user mode; therefore, we must use the enable command (Line 1) to get to privileged mode. Notice that the prompt changed (Line 2) and IOS did not ask for a password before allowing us to access privileged mode. At this point there is no enable password and the router’s name is Router (as indicated by command prompt on Line 1, 2, and 4). To enter configuration commands, we must enter configuration mode; the configure terminal command (Line 2) puts us there.
We use the hostname command to name the router Austin (Line 4). The configuration change is immediate; the new host name is entered into the running configuration, and the next command prompt has the new name in it (Line 5).
Every router needs passwords; therefore, we will take the opportunity to define them. The two types of enable passwords are configured first. The enable secret password is set with the enable secret command (Line 5), and the regular enable password is set with the enable password command (Line 6). The passwords for the five VTY terminal lines, 0 through 4, must be defined in line configuration mode, so we issue the line vty 0 4 command (Line 7) indicating to IOS that the next commands are to be applied to all of the VTY’s. Once in line configuration mode, we assign the VTY passwords with the password command (Line 8) and allow logins with the login command (Line 9). If the VTY’s do not have passwords, no one will be able to establish a telnet connection to Austin. The last password is the one for the console. The console is another terminal line device so we type the line con 0 command (Line 10) to go to line configuration mode for the console. The line command is a global configuration command; therefore, it can be typed in any configuration mode. We used the line command in line configuration mode, and IOS just changed the line we were configuring. The command prompt did not change; it is very important to realize that IOS did not tell us that we are configuring a different line; we must be aware of what we are doing. Console password authentication is enabled with the password command (Line 11) and the login command (Line 12).
To configure an interface, we must be in interface configuration mode; the interface command is used to put us there. Just like the line command, interface is a global configuration command and can be used in any configuration mode. The interface ethernet0 command (Line 13) informs IOS that we wish to enter interface configuration mode and type commands that affect Ethernet0. From there, we assign the IP address (Line 14) and description (Line 15) for Ethernet0. The no shutdown command (Line 16) activates the interface.
The configurations of Serial0 (Lines 17 through 21) and Serial1 (Lines 22 through 26) are similar to that of Ethernet0 except for the bandwidth commands that set the informational bandwidth parameter to an appropriate value for each interface. The IP addresses for the three interfaces were taken directly from Figure 7-9.
We could have done most of this configuration with the System Configuration Dialog. Typing the commands on the command line is usually faster than answering questions even though the command line may not be quite as intuitive. The command line does not limit what we can do. The System Configuration Dialog cannot be used to set a console password, define an interface’s bandwidth, or define an interface’s description. Since we wanted to perform those functions, we had to use the command line anyway. So why not just do it all from the command line?
We are going to check connectivity by examining the routing tables. Routing tables are not always a good indication of connectivity in a production network, but we are going to use them for illustration. Figure 7-13 shows our three-router internetwork with the addresses of each of the networks. Figure 7-9 shows the individual interface addresses.
<<<J113 – Figure 7-13 Three-Router IP Internetwork with Network Addresses>>>
The new IP routing tables for Dallas, FortWorth, and Austin are shown in Figure 7-14, Figure 7-15, and Figure 7-16, respectively.
<<<Figure 7-14 Dallas IP Routing Table After Austin Installation>>>
Much of the specific information displayed was described in Section 7.3. The only difference in the current Dallas routing table and the original one in Figure 7-7 is the addition of the directly-connected network 192.168.2.0/24 (Figure 7-14, Line 9). IOS added this to the routing table because we assigned an IP address to Serial0 and Serial0 has an up/up status.
The new Dallas routing table does not show the Austin Ethernet LAN or the serial link between FortWorth and Austin; therefore, Dallas cannot route a packet to those destinations.
<<<Figure 7-15 FortWorth IP Routing Table After Austin Installation>>>
The FortWorth IP routing table now contains network 192.168.3.0/24 (Figure 7-15, Line 9) because we assigned an IP address to Serial1 and Seria11 is in an up/up state. The FortWorth routing table does not contain a path to the Austin Ethernet LAN or the serial link between Dallas and Austin; therefore FortWorth cannot route packets destined for either of those networks.
<<<Figure 7-16 Austin Initial IP Routing Table>>>
The Austin routing table after the initial configuration shows only the directly-connected networks.
Dallas and FortWorth do not have a route to the Austin Ethernet LAN, and Austin does not have a route to either the Dallas Ethernet LAN or the FortWorth Ethernet LAN. All of the routers should have routing table entries that allow IOS to route packets to any network. The reason the routing tables are incomplete is that IOS has not been told of the existence of the additional networks, yet. We need to solve that problem. We are going to partially solve the problem with the brute force method (static routes) and then move on to something a little more elegant (dynamic routing protocols) for complete resolution.
We need to tell Austin and Dallas of the existence of their Ethernet LAN’s. We are going to start by manually adding an entry to the Austin IP routing table; this entry is called a static route. Adding a static route is done with the global configuration command ip route. Figure 7-17 shows the configuration on Austin of a static route to the Dallas Ethernet LAN.
<<<Figure 7-17 Austin Static Route to Dallas Ethernet>>>
The command to add the static route is on Line 3. The network address of the Dallas Ethernet LAN is 172.16.10.0/24; therefore, the network entry we want to add to the routing table has the address 172.16.10.0 and the network mask 255.255.255.0. The ip route command requires the network mask; the prefix length cannot be used. The last address on the command is the address of the next hop gateway. The gateway is the address of the router to which Austin should send packets destined for the indicated network. The gateway address should be on a network that is already in the Austin routing table. In this case, the gateway address is the Dallas Serial0 interface, which is directly connected to Austin. Austin’s new routing table is shown in Figure 7-18.
<<<Figure 7-18 Austin IP Routing Table After Static Route Configuration>>>
The static route (Line 6) is displayed with the letter S in the left column; the static route’s administrative distance is 1, and its metric is 0. We can change the administrative distance of a static route by entering the new value of the distance at the end of the ip route command. Now when Austin gets a packet destined for the Dallas Ethernet LAN, Austin will forward the packet to 192.168.2.1 out its Serial1 interface.
The ping application is one that used ICMP echo packets to verify connectivity between two hosts. There are two forms of ping implemented in IOS: simple ping and extended ping. Let us start with simple ping.
A simple ping can be done in either user mode or privileged mode. The simple ping is invoked with the ping command. Either an IP address or a host name follows the word ping. If a host name is used, some form of address resolution must be used to resolve the name to an IP address. Figure 7-19 shows a simple ping from Austin to Dallas.
<<<Figure 7-19 Simple Ping from Austin to Dallas>>>
On Line 1, we have issued a ping to the address 172.16.10.1, which is the Dallas Ethernet0 interface. The simple ping will send five ICMP echo request packets, with 100 bytes of data, to the address, and it will expect to receive an ICMP echo reply packet within two seconds of each of the requests (Line 4). For each reply received within the timeout period, IOS displays an exclamation point (!). Austin received a reply for all five of the requests (Line 5); this made the success rate 100 percent (Line 6). Each of the replies arrived within 12 milliseconds (ms) of the request.
But what have we really tested here? Any traffic generated by IOS uses the address of the outbound interface as its source address; therefore, what we just tested was connectivity between the Dallas Ethernet0 interface and the Austin Serial1 interface. We would rather test LAN-to-LAN connectivity since our users’ host systems are going to be attached to LAN’s. We can use an extended ping to override the source address of the ping packets to check routing between LAN’s. Figure 7-20 shows an extended ping from Austin’s Ethernet0 interface to Dallas’s Ethernet0 interface.
<<<Figure 7-20 Extended Ping from Austin to Dallas>>>
To perform an extended ping, just type ping in privileged mode. The extended ping application prompts us to change the default ping parameters. The first thing we are prompted for is the protocol (Line 2); the default is IP, which is what we want. Then we are prompted for the destination IP address (Line 3), the number of echo requests to send (Line 4), the size of the requests (Line 5), and the reply timeout (Line 6). Default answers to the questions are shown in brackets; pressing <Enter> accepts the default. The default answers are those that the simple ping uses.
Changing the source address of the ping echoes is an extended command; therefore, we answer yes the Line 7 questions indicating that we want to use extended commands. On Line 8, we set the source address to 192.168.1.1. For this test, we took the default answers to all of the rest of the questions.
The extended ping fails as indicated by the five periods (.) on Line 17. Using the simple ping, Dallas sends the echo replies to the address of the Austin Serial1 interface, which is on one of Dallas’ directly-connected networks. However, using the extended ping allows us to change the source address of the echo requests (Line 8) and require that Dallas send the echo replies to the address of the Austin Ethernet0 interface, 192.168.1.1. The Dallas IP routing table (Figure 7-14) does not contain an entry that matches the 192.168.1.0/24 network; therefore, Dallas cannot send the echo replies. LAN-to-LAN connectivity has not been established.
Dallas needs a static route to Austin’s Ethernet LAN; therefore, we will add one. Figure 7-21 shows the configuration of a static route on Dallas.
<<<Figure 7-21 Dallas Static Route to Austin Ethernet>>>
The Ethernet LAN on Austin has the address 192.168.1.0/24; therefore, the entry for network 192.168.1.0 with the mask 255.255.255.0 is placed into Dallas’ routing table. The gateway that Dallas should use to get to the network is 192.168.2.2, Austin’s Serial1 interface.
Now if we were to repeat the extended ping from Figure 7-20, it would be successful because Dallas has a route to Austin’s Ethernet LAN. But what happens when the serial link between Dallas and Austin goes down? Figure 7-22 shows the broken internetwork, and Figure 7-23 shows Austin’s routing table during the outage.
<<<J118 – Figure 7-22 Broken Serial Link Between Dallas and Austin>>>
<<<Figure 7-23 Austin IP Routing Table With Serial Link Down>>>
Since our connectivity between the Dallas and Austin Ethernet LAN’s was established with a static route on each router, we would lose connectivity if the serial link between the routers went down, even though there is another potential path through FortWorth. The IP routing table on Austin (Figure 7-23) no longer contains the static route to network 172.16.10.0/24 because the directly-connected network where the next hop gateway was located went down.
If we wanted to get full internetwork connectivity, we would have to put several static routes are each router. That is why I called this the brute force method of updating the routing tables. Adding static routes and maintaining them during network changes is a major administrative task that can cause problem in large internetworks. Each time that new routers or new networks are added, static routes would have to be added or changed.
Dynamic routing protocols allow our routers to share information about the networks that they know about. We are going to configure those next, but we are going to remove the static routes on Dallas and Austin first.
Remember "Just say no." Use the no ip route command to remove a static route. Figure 7-24 shows the removal of Austin’s static route, and Figure 7-25 shows the removal of Dallas’s static route.
<<<Figure 7-24 Removal of Static Route on Austin>>>
<<<Figure 7-25 Removal of Static Route on Dallas>>>
To remove a static route, just put the keyword no in front of the exact command that was used to create the static route. If you do no remember the exact command that created the static route, just display the running configuration and find it.
Running a dynamic routing protocol will allow our routers to share their network information with each other and recover from a network outage automatically. If an alternate path exists and all of the routers are running properly configured routing protocols, they will eventually locate the alternate path and use it if the primary path goes down. We are going to cover the basic configuration of the following routing protocols, shown in order from simplest to most complex:
These routing protocols are called interior routing protocols. They are meant to be run on routers under a common administration.
The first thing that we must do before configuring a routing protocol is to determine which one best suits our needs. If we want a routing protocol that is very simple and supported by just about every IP router on the market, then RIP may be the choice. If we need a routing protocol that will work well in a large internetwork of several hundred routers, then EIGRP or OSPF may be the choice unless some of those routers are not Cisco routers; then OSPF may be the choice.
Regardless of which one is chosen, we should be consistent with its configuration on our routers. IOS can run more than one IP routing protocol, but that usually requires extra configuration and extra maintenance.
The two steps for configuring an IP routing protocol are as follows:
The forms of the router and network commands differ slightly from one routing protocol to another. We will see those differences in the coming sections as we start with RIP and migrate through each of the routing protocols.
There are two versions of RIP: 1 and 2. The default version of RIP is version 1. Unless we explicitly state that we are referring to RIP version 2 (RIPv2), we are referring to RIP version 1 (RIPv1).
RIP is a distance vector routing protocol that sends updates every 30 seconds. See Section 2.2.2.1 for a summary of distance vector routing protocols. Cisco’s implementation of RIP allows the transmission of an update immediately upon the detection of a change in a network’s state without waiting for the current 30-second period to expire; this is called a triggered, or flash, update.
RIP uses a single metric in determining the best path, hop count. The maximum number of hops is 15; anything over that is invalid and indicates an unreachable network. The metric for a network address is carried in the RIP update packets.
RIP updates are sent to the IP broadcast address that is configured on an interface; the default IP broadcast address is 255.255.255.255. RIP does not include in its updates the network mask or prefix length for a network address being advertised; this makes RIP a classful routing protocol. When RIP advertises a subnet of a network out an interface that is not another subnet of the same network, RIP summarizes the subnets of the network as the classful network address. This feature is called auto-summarization, and we cannot turn it off. Because of these features, one should adhere to the following subnetting rules when addressing networks in an internetwork running RIP.
Major, classful network address refers to a class A address, a class B address, or a class C address.
Two of our routers, Dallas and FortWorth, are already running RIP. We will look at their RIP configurations to explain the command, and then we will complete the configuration to include Austin. Figure 7-26 shows the RIP configuration on Dallas, and Figure 7-27 shows the RIP configuration on FortWorth.
<<<Figure 7-26 Original Dallas RIP Configuration>>>
<<<Figure 7-27 Original FortWorth RIP Configuration>>>
The current RIP configuration of both routers consists of two commands (Lines 4 and 5). The router rip command informs IOS that the next commands are to be used on the RIP process. The network 172.16.0.0 command tells IOS that all of the router’s interfaces that have addresses in the 172.16.0.0 network are to send RIP updates and receive RIP updates; this command also tell IOS to include the network addresses of those same interfaces in the RIP updates. The address placed after the network command must be a major, classful network address to which the router has a direct connection. Since Dallas has two interfaces that are part of the 172.16.0.0 network, RIP is started on both of them, Ethernet0 and Serial1. FortWorth also has two interfaces that are part of the 172.16.0.0 network; therefore, RIP is started on both of them, Ethernet0 and Serial0.
We still need to start RIP on Dallas’ Serial1 interface, FortWorth’s Serial1 interface, and all of Austin’s interfaces. Figure 7-28 shows the completion of the RIP configuration on Dallas; Figure 7-29 shows the completion of the RIP configuration on FortWorth; Figure 7-30 shows the configuration of RIP on Austin.
<<<Figure 7-28 Completion of Dallas RIP Configuration>>>
<<<Figure 7-29 Completion of FortWorth RIP Configuration>>>
<<<Figure 7-30 Austin RIP Configuration>>>
To verify which routing protocols that IOS is running, we use the user mode command show ip protocols. Figure 7-31 shows the output on Dallas.
<<<Figure 7-31 Show IP Protocols Output on Dallas After RIP Configuration>>>
Dallas is running RIP (Line 2). RIP updates are transmitted every 30 seconds, and the next updates are scheduled for transmission in 9 seconds (Line 3). RIP routes that have not been heard in 180 seconds (3 minutes) are marked as invalid and flushed from the routing table after 240 seconds (4 minutes). When IOS is informed by RIP that a route has gone down, IOS places the route in holddown state for 180 seconds. While the route is in holddown, IOS will accept no other route as a replacement until the timer expires unless the replacement route has a better metric than the original. Because of the holddown timer, RIP’s convergence time tends to be rather long; however, the holddown timer helps reduce the possibility of routing loops.
RIP is running on interfaces Ethernet0, Serial0, and Serial1 (Lines 10, 11, and 12). On the same lines, we see that IOS is send RIPv1 updates and is capable of receiving RIPv1 and RIPv2 updates. Lines 14 and 15 show the networks that have been configured for RIP on Dallas. Lines 18 and 19 show the sources of RIP updates received by Dallas. These are Austin (Line 18) and FortWorth (Line 19). Since RIP updates are sent to the broadcast address, the sources should always be directly-connected neighbor routers. These lines also show a distance of 120, which is the default administrative distance for RIP. The time since an update was received from each source is also given.
Now that RIP is running, we should take a look at the routing tables on our three routers. Figure 7-32 has the IP routing table for Dallas; Figure 7-33 has the IP routing table for FortWorth, and Figure 7-34 shows the IP routing table for Austin.
<<<Figure 7-32 Dallas IP Routing Table After RIP Configuration>>>
The Dallas IP routing table prior to the complete RIP configuration is shown in Figure 7-14. Two more RIP routes have been added (Line 15 and Line 17). Dallas has heard a RIP update from Austin about the Austin Ethernet LAN, 192.168.1.0. Since RIP does not put network mask information into its updates, Dallas is using the default network mask for a class C address, 255.255.255.0 for the routing table entry. The serial link between FortWorth and Austin, 192.168.3.0, has been heard from both of the other routers. The metric (second number within the brackets) for both routes is the same, one hop; therefore, IOS places both of them into the routing table. IOS will distribute the traffic destined for the 192.168.3.0 network across the two equal-cost paths. The traffic distribution will most likely not be equal, or balanced; this is called load sharing. The first number within the brackets is the administrative distance. The default for RIP routes is 120. This can be changed with the router configuration command distance.
<<<Figure 7-33 FortWorth IP Routing Table After RIP Configuration>>>
The FortWorth IP routing table now shows routes to all of the networks also. Austin’s Ethernet LAN is shown as being one hop away (Line 7), and the serial link between Dallas and Austin has two equal-cost paths (Lines 8 and 9). The time shown on each RIP entry indicates how long ago each entry was updated, or how long it has been since a RIP update was received with each entry’s information.
<<<Figure 7-34 Austin IP Routing Table After RIP Configuration>>>
The IP routing tables of Dallas and FortWorth each contained six routes; however, Austin’s routing table has only four. In this first paragraph of this section, we mentioned auto-summarization. Here is an example. There are really three subnets of the 172.16.0.0 network in our internetwork; however, neither Dallas nor FortWorth advertises them. Instead, they advertise the class B network address 172.16.0.0. Since their links to Austin are not subnets of the 172.16.0.0 subnet, the subnets themselves are not sent. Since RIP does not include network mask information in its updates, Austin would understand them anyway. So Austin gets an update from Dallas containing the summary route 172.16.0.0 and an update from FortWorth with the same summary route. Both updates have the same hop count, 1; therefore, they both go into the routing table. The prefix length used is the default for a class B address, /16. This means that Austin will distribute the traffic for all of the subnets of the 172.16.0.0 subnets across both of its serial interfaces. Traffic may not be sent along the most efficient path. Traffic for Dallas’ Ethernet LAN, 172.16.10.0/24, may get routed through FortWorth because Austin has no knowledge of the subnetting.
RIP version 2 (RIPv2) is just a slight modification of RIPv1. RIPv2 is a distance vector routing protocol with the same timers as those of RIPv1; RIPv1 and RIPv2 also use the same metric, hop count; however, RIPv2 is classless and is capable of doing authentication. RIPv2 updates are sent to the multicast address 224.0.0.9, which is processed only by other routers running RIPv2; therefore, RIPv2 updates do not interrupt the processing of non-router hosts.
Being classless, RIPv2 includes the network mask of network addresses in its updates. RIPv2 also does auto-summarization by default, but we can turn off auto-summarization if we desire. The classless characteristic means that all of the subnets of a major network address do not need to share the same network mask, and they do not have to be contiguous. Using multiple network masks for a single network address is called variable-length subnet masking (VLSM). VLSM is essentially the subnetting of subnets – taking a subnet and increasing the number of ones in the network mask for that subnet to get multiple smaller subnets. This can allow us to more efficiently use our network address space, especially in internetworks with many two-host networks such as WAN’s.
IOS can run both RIPv1 and RIPv2 simultaneously, but both cannot be enabled on the same interface. RIPv1 and RIPv2 can work together within an internetwork; however, there are a few rules we need to remember.
The conversion from RIPv1 to RIPv2 can be done one interface at a time or all interfaces at the same time on a router. To completely convert our internetwork from RIPv1 to RIPv2, we need to add just one command to the RIP configuration on each router. The command is the router configuration command version 2. We will type this command on each router; since the command sequence is identical on all of the routers, only one is shown. Figure 7-35 shows the configuration of RIPv2 on Dallas.
<<<Figure 7-35 RIP Version 2 Configuration on Dallas>>>
Typing the sequence of commands on each of our test routers converts them from running RIPv1 to RIPv2. Since we are configuring the RIP process, we must identify it with the router rip command (Line 3). The version 2 command (Line 4) tells IOS that it is to use version 2 on all of the interfaces that currently have RIP enabled unless we explicitly change the version on the interface itself. This command is added to the network commands that we entered when we configured RIPv1 in the preceding section. The RIP configuration on Dallas now looks like this:
router rip
version 2
network 172.16.0.0
network 192.168.2.0
The RIP configurations on FortWorth and Austin are similar, and the routing tables on the routers appear to be identical to the ones created with RIPv1 shown in Figure 7-32, Figure 7-33, and Figure 7-34.
In Figure 7-34, we saw that Austin has a summary route to 172.16.0.0/16. This means that if Austin gets a packet destined for a subnet of the 172.16.0.0 network that does not really exist, such as 172.16.33.0, Austin will route it toward Dallas or FortWorth. This causes some minor overhead because the packet will cross the WAN just to be dropped at the other side. A side effect of this is the router that drops the packet will probably send an ICMP destination unreachable message back across the WAN to packet’s source thus causing more WAN overhead.
Suppose that the WAN between Dallas and FortWorth were down. Figure 7-36 shows this occurrence. Since Dallas and FortWorth are both summarizing the 172.16.0.0 network to Austin, Austin will maintain the two equal-cost paths to the network, 172.16.0.0/16. When Austin receives a packet with a destination address that exists on the 172.16.10.0 subnet, such as 172.16.10.1, Austin cannot accurately tell which path is valid, and only one path will reach the address. The packet has a 50/50 chance of reaching its destination.
<<<J119 – Figure 7-36 Broken Serial Link Between Dallas and FortWorth With Auto-Summarization>>>
With RIPv2 we can turn off the auto-summarization feature that causes the summary route. We use the router configuration command no auto-summary to accomplish this. Figure 7-37 shows the disabling of auto-summarization on Dallas.
<<<Figure 7-37 Disabling of RIPv2 Auto-Summarization on Dallas>>>
All of the networks are now operational. After a few minutes, an examination of the IP routing tables on FortWorth and Austin reveals something interesting. Figure 7-38 shows the new IP routing table on FortWorth after RIPv2, and Figure 7-39 shows the new IP routing table on Austin.
<<<Figure 7-38 FortWorth IP Routing Table After Auto-Summarization Disabled on Dallas>>>
<<<Figure 7-39 Austin IP Routing Table After Auto-Summarization Disabled on Dallas>>>
Dallas is now sending the individual subnets of the 172.16.0.0 network instead of the summary route of 172.16.0.0/16; therefore, Austin has learned about the individual subnets with the /24 prefix length (Figure 7-39, Lines 4 through 6). Austin is summarizing these subnets to FortWorth so now FortWorth’s routing table has the summary route (Figure 7-38, Line 7). FortWorth is still sending a summary route for the three subnets to Austin so Austin still has the summary route (Figure 7-39, Line 7).
We need to disable auto-summarization on all three routers to completely get rid of the summary route. After issuing the no auto-summary command under the RIP configurations of FortWorth and Austin and allowing a few minutes for the summary routes to get flushed, the contents of the FortWorth IP routing table return to that displayed in Figure 7-33. Figure 7-40 shows the new Austin routing table.
<<<Figure 7-40 Austin IP Routing Table After Auto-Summarization Disabled on All Routers>>>
Austin now knows about just the subnets that exist. If Austin receives a packet destined for a nonexistent subnet such as 172.16.33.0, Austin will drop the packet since it has no route that matches the destination address. If the serial link between Dallas and FortWorth goes down as was shown in Figure 7-36 and auto-summarization is turned off, Austin would have an accurate, specific path to the 172.16.10.0 subnet even though the subnets of the 172.16.0.0 network would no longer be contiguous.
In most large networks, summarization is a good thing since it reduces the size of the routing table; however, in our small network, we turned it off just to illustrate its effect.
Two important interface customizations that we can make to RIP are making an interface passive and setting the RIP version.
IOS will not send RIP updates out an interface that we have configured to be passive for RIP. The passive characteristic is routing-protocol specific; it works for the other routing protocols, also. When we make an interface passive, we are telling IOS that no updates are to be transmitted out the interface, but updates are allowed to enter the interface. In other words, the interface will listen but not speak. Why would we want to turn off the updates on an interface?
When we configured RIP, we used the network command to indicate which interfaces were to have RIP enabled. The network address that we have to use with the network command is a major, classful address, not a subnet address. When we enable RIP on one interface that is connected to a subnet of a network, all of the router’s other interfaces in the same network are also enabled for RIP. If there were no other routers on the network to which updates were being sent, the updates would be a waste of network bandwidth. If there were other routers on a network and we did not want them to learn about our networks, we could turn off the updates on the interface that connected our router to the other routers.
We use the router configuration command passive-interface to turn off updates on a specific interface. Figure 7-41 shows the command being used to turn off RIP updates to FortWorth’s Ethernet LAN.
<<<Figure 7-41 Passive-Interface Command on FortWorth>>>
The passive-interface command must be entered in router configuration mode for the routing protocol to which it applies, RIP in this example (Figure 7-41, Line 3). The interface to be passive is specified immediately after the command (Line 4). Because there are no other routers on FortWorth’s Ethernet LAN, we tell IOS to stop sending RIP updates out the Ethernet0 interface. This will stop both RIPv1 and RIPv2 updates from being transmitted.
On the Austin Ethernet LAN, there is a host that our users insist should maintain a routing table similar to our routers. For example, this could be a Unix-based host running routed. The host expects to receive RIP updates from Austin, but the host’s implementation of routed supports only RIPv1. To maintain connectivity to Dallas and FortWorth, Austin should run RIPv2 on its WAN’s, but we can configure Austin to send RIPv1 updates out its Ethernet0 interface with the interface configuration command ip rip. Figure 7-42 shows the configuration of RIPv1 updates on Austin’s Ethernet0 interface.
<<<Figure 7-42 Setting RIP Version on an Interface>>>
Austin is currently running RIPv2, but with the ip rip send version 1 command (Line 4) issued in interface configuration mode for Ethernet0, we have overridden that to get Austin to send RIPv1 updates onto its Ethernet LAN. Austin will still receive only RIPv2 updates; therefore, it will ignore any RIPv1 updates that it receives from the Ethernet LAN. We could override that also by entering the ip rip receive version 1 command in interface configuration mode for Ethernet0.
We configure RIP by entering the router rip command in global configuration mode and then the appropriate network commands for enabling RIP on the router’s interfaces. RIPv1 is the default version; if we want to run RIPv2 on all, or most, of the interfaces, we enter the version 2 command while we are in router configuration mode for RIP. To change the RIP version on an individual interface that has been included in one of the network commands, use the ip rip send version or the ip rip receive version command, with the appropriate RIP version number (1 or 2), in interface configuration mode for the desired interface. To stop updates on an interface, issue the passive-interface command, with the interface name, in router configuration mode for RIP.
The RIP-specific configuration commands entered in this chapter for Dallas, FortWorth, and Austin are shown in Figure 7-43, Figure 7-44, and Figure 7-45, respectively.
<<<Figure 7-43 Dallas RIP-Specific Configuration Commands>>>
<<<Figure 7-44 FortWorth RIP-Specific Configuration Commands>>>
<<<Figure 7-45 Austin RIP-Specific Configuration Commands>>>
In Figure 7-45 (Line 4), the interface Ethernet0 command is shown only to provide context for the ip rip send version 1 command (Line 5) in context. The interface command is not specific to RIP.
Even though the configuration of RIP required quite a few commands, the removal of RIP requires a single global configuration command on each router. Figure 7-46 shows the removal of RIP on Dallas.
<<<Figure 7-46 Removal of RIP>>>
The no router rip command (Line 3) removes all of the RIP-specific commands from the running configuration. After issuing the command on all three of our test routers, our internetwork is left without an IP routing protocol.
IGRP is a classful, distance vector routing protocol similar to RIP. IGRP does not include network mask information in its periodic updates, and its periodic updates occur every 90 seconds by default. IGRP updates have a destination address of the IP broadcast address configured on the interface out which the updates are being transmitted; the default IP broadcast address is 255.255.255.255.
The metric used by IGRP is a composite (calculated value) of four parameters that are carried in the update packets. The four parameters are as follows:
All of these parameters are tracked by IOS for each interface in a router. Bandwidth and delay are static; they have default values, and the values are configurable. Bandwidth is specified in kbps and is configured with the interface configuration command bandwidth as described in Section 6.2.4. Delay is specified in microseconds (usec) and is configured with the interface configuration command delay. The delay is supposed to be the amount of time a bit takes to cross a network. Reliability and load are dynamic. They are each given as a fraction of 255. For example, an interface load of 25 means that interface utilization is at about 10 percent. Figure 7-47 shows that these parameters for an interface are available using the show interfaces command. The parameters appear on Line 5 of Figure 7-47.
<<<Figure 7-47 Five IGRP Composite Metric Parameters in Show IP Interfaces Output>>>
MTU (Maximum Transmission Unit) is shown for an interface (Line 5, Figure 7-47) and carried in an IGRP update, but it is not part of the composite metric calculation. MTU is given in bytes and is configured with the interface configuration command mtu. MTU is the maximum size of a packet, the payload of a frame. A sixth value, hop count, is also carried in the IGRP updates, but, just like MTU, hop count is not included in the composite metric. The default maximum number of hops for an IGRP route is 100; this maximum can be increased or decreased.
IGRP was developed by Cisco. Not many other router vendors have implemented IGRP so it is generally useful only in networks that consist of mostly Cisco routers.
The configuration of IGRP is very similar to the configuration of RIP. We just need to specify the IGRP process with the router igrp command and then enable IGRP on a router’s interfaces with network commands. IGRP, however, requires that its process be identified with an autonomous system number (ASN). There are several definitions of an autonomous system. The one that we will use here is a group of routers that are using the same interior routing protocol to share routing information. Our three routers are part of the same autonomous system. All of the routers must have the same ASN in their IGRP configuration for them to be able share routing information with IGRP. IOS can support multiple IGRP autonomous systems by running multiple IGRP processes, each with a different ASN.
Let us put IGRP on the three routers. Figure 7-48 shows the configuration of IGRP on Dallas; Figure 7-49 shows the configuration of IGRP on FortWorth; Figure 7-50 shows the configuration of IGRP on Austin.
<<<Figure 7-48 IGRP Configuration on Dallas>>>
<<<Figure 7-49 IGRP Configuration on FortWorth>>>
<<<Figure 7-50 IGRP Configuration on Austin>>>
The ASN that we have chosen is 100 (Line 3 of Figures 7-48, 7-49, and 7-50). All of the routers must use the same ASN if we expect them to be able to exchange route information. The ASN is a 16-bit variable; therefore, its maximum value is 65,535. The network commands that we used to enable IGRP for ASN 100 are identical to the ones we used when we configured RIP in Section 7.7.1.1.
If we have a need to stop the transmission of IGRP updates on an individual interface, we can use the passive-interface command, with the interface name, in router configuration mode for the IGRP process. The function and use of the command is the same as was explained for RIP in Section 7.7.1.3.
Now that we have IGRP running, we need to examine its status. Figure 7-51 shows the output of the show ip protocols command on Dallas.
<<<Figure 7-51 Show IP Protocols Output After IGRP Configuration>>>
We see that IGRP for ASN 100 is running (Line 2); IOS always includes the ASN when referencing an IGRP process because there can be multiple IGRP processes. The values of the main IGRP timers are given on Lines 3 and 4; these values are much greater than those for RIP. (See Figure 7-31 for the RIP timer values.) Notice that IGRP’s flush timer value is over 10 minutes. Convergence time for an internetwork running IGRP can be much longer then that for one running RIP; however, IGRP uses a little less bandwidth than RIP because the periodic interval for the IGRP update broadcasts is three times longer (90 seconds as opposed to 30 seconds). Dallas is receiving IGRP updates from Austin (Line 18) and FortWorth (Line 19). The default administrative distance for IGRP is 100 (Line 20). If we were running both RIP and IGRP in our internetwork, IOS would prefer the routes learned from IGRP because IGRP’s administrative distance is lower than RIP’s (120).
The IP routing tables created by IGRP have the exact same routes as the tables created by RIPv1. The only differences are the values of the administrative distance and the metric given for each route. Figure 7-52 shows the IP routing table on Dallas; Figure 7-53 shows the IP routing table on FortWorth, and Figure 7-54 has Austin’s IP routing table.
<<<Figure 7-52 Dallas IP Routing Table After IGRP Configuration>>>
<<<Figure 7-53 FortWorth IP Routing Table After IGRP Configuration>>>
<<<Figure 7-54 Austin IP Routing Table After IGRP Configuration>>>
Just in all the other displays of the IP routing table, the numbers in brackets are the administrative distance followed by the metric. For the IGRP-learned routes indicated by the letter I in the left column, the distance is 100, and the metric is the composite metric. We cannot get a real perspective on how far away a network is from a router except that a very large metric generally indicates the presence of a low-bandwidth WAN.
In Figure 7-54 (Line 3), the summary route of 172.16.0.0/16 is evidence that IGRP does auto-summarization just like RIP does. We cannot turn off auto-summarization for IGRP; therefore, we have the same issues with noncontiguous subnets and static network masking as we did with RIPv1. When the routers were running RIP, the IP routing table showed two equal-cost paths to the summary network address; however, with IGRP, there is only one path. The metric is the reason for this. IGRP’s composite metric takes in account the bandwidth of a network in determining best path. The link from Austin to Dallas has a bandwidth of 256 kbps, and the link from Austin to FortWorth has a bandwidth of 56 kbps. The higher bandwidth link is preferred, but we had to configure the bandwidth of each interface with the bandwidth command (Figure 7-12, Lines 19 and 24).
Trace is a utility that we use to check connectivity to a destination by finding the route that packets take to get to the destination. We saw in Figure 7-54 that Austin’s path to the 172.16.0.0 network is via Dallas. The Ethernet LAN on FortWorth is part of the 172.16.0.0 network, and we can use trace to verify that packets to FortWorth actually go through Dallas. Figure 7-55 shows the output of a trace to FortWorth’s Ethernet0 interface from Austin.
<<<Figure 7-55 Trace from Austin to FortWorth>>>
We can specify either an IP address or a host name in the trace command. We have issued a trace to the IP address 172.16.20.1 (Line 1), which is the address of FortWorth’s Ethernet0. The trace output tells us the routers (hops) that our traffic to the IP address is going through. The first router in the path to the address has the IP address 192.168.2.1 (Line 6), which is Dallas. Trace tries each router in the path three times and returns a round-trip time in milliseconds for each try. The second, and last, router in the path has the IP address 172.16.11.2 (Line 7), which is FortWorth.
If Austin had a host table with entries for the IP addresses returned by the trace, IOS would return the name of the router after it resolved the address to a host name. The same would be true if we were using DNS, and the IP addresses had reverse lookup entries in the DNS database.
IGRP is configured by entering the router igrp command with an ASN in global configuration mode and then the appropriate network commands for enabling IGRP on the router’s interfaces. All of the routers that are to share information with IGRP must use the same ASN. To stop updates on an interface, issue the passive-interface command, with the interface name, in router configuration mode for the IGRP process.
The IGRP-specific configuration commands entered in this chapter for Dallas, FortWorth, and Austin are shown in Figure 7-56, Figure 7-57, and Figure 7-58, respectively.
<<<Figure 7-56 Dallas IGRP-Specific Configuration Commands>>>
<<<Figure 7-57 FortWorth IGRP-Specific Configuration Commands>>>
<<<Figure 7-58 Austin IGRP-Specific Configuration Commands>>>
With the exception of specifying IGRP and an ASN with the router command, the configuration of IGRP is practically identical to the configuration of RIPv1.
The removal of IGRP requires a single global configuration command on each router. Figure 7-59 shows the removal of IGRP on Dallas.
<<<Figure 7-59 Removal of IGRP>>>
The no router igrp 100 command (Line 3) removes all of the IGRP-specific commands from the running configuration. After issuing the command on all three of our test routers, our internetwork is left without an IP routing protocol.
Remember that whenever IGRP is referenced in configuration mode, we must include the ASN with it.
EIGRP is a classless routing protocol that is neither distance vector nor link state. EIGRP does include prefix length of network addresses in its update packets. We can use VLSM in an internetwork that is using EIGRP; however, since EIGRP does auto-summarization by default, we could run into the same issues with noncontiguous subnets that we saw with RIPv2 in Figure 7-36. EIGRP also supports password authentication like RIPv2 does.
EIGRP was developed by Cisco, and its internal workings are proprietary to Cisco; therefore, EIGRP has been implemented only in Cisco IOS. EIGRP is rather complicated so we will briefly summarize how it works before we get into its basic configuration. IOS can use EIGRP to exchange information for IPX and AppleTalk, also; the configuration of IPX EIGRP and AppleTalk EIGRP is covered in Chapters 8 and 9, respectively.
EIGRP requires the use of an ASN just like IGRP. All routers that are to share route information with EIGRP must have the same ASN. If IGRP and EIGRP are running on the same router with the same ASN, routes are automatically redistributed between them. Redistribution means that the routing processes will advertise routes learned from each other. Routes learned through EIGRP will also be advertised in IGRP updates, and routes learned through IGRP will also be advertised in EIGRP updates. IOS includes this handy feature to make the transition from IGRP to EIGRP a little easier.
EIGRP uses the same composite metric parameters as IGRP – bandwidth, delay, reliability, and load. (MTU and hop count are also carried in the updates.) However, the metric calculated for EIGRP is 8 bits longer so the EIGRP metric is 256 times bigger than the one for IGRP.
A special algorithm called Diffusing Update Algorithm (DUAL) is used by EIGRP to perform its major functions.
Before any updates are exchanged, a router must discover any other routers that are its neighbors. A neighbor router is one that is attached to a directly-connected network and is running EIGRP with the same ASN. Neighbors are discovered using Hello packets that are sent to the multicast address 224.0.0.10 about every five seconds by default (60 seconds by default on non-broadcast networks such as X.25). Routers running EIGRP listen for Hello packets. Upon hearing a Hello packet from a neighbor router, a router will place the neighbor router’s address into a neighbor table. The neighbor routers then form an adjacency with each other. The adjacency formation requires that the routers exchange routing information with each other.
EIGRP Hello packets are sent out every interface that is enabled for EIGRP at periodic intervals. If a router does not hear a Hello packet from a neighbor router within a hold time, the neighbor router will be removed from the neighbor table. The default value of the hold time is three times the Hello interval. On a LAN, the default Hello interval is five seconds; therefore, the default hold time is 15 seconds. Because of the fast discovery of down routers, EIGRP convergence after a network change can be very fast.
EIGRP does not send periodic updates, rather updates are sent only during the establishment of an adjacency and after a network change. Updates sent after a network change contain partial information about routes, that is, they contain only what is necessary to be communicated, not the entire routing table.
Information about networks learned from neighbor routers is placed into a topology table. The topology table contains all of the routes learned from each neighbor and two metrics for each route. The first metric is the composite metric as advertised by a neighbor router. The composite metric as advertised by a neighbor router is actually the neighbor router’s metric to the destination network address. This is called the advertised distance of a route. The second metric is the local router’s composite metric of the route through the neighbor router that advertised the network address. This is called the feasible distance of a route. The feasible distance is just the normal metric that is calculated when a route is learned.
All of the routes to a destination network address are compared and the one with the best feasible distance is placed into the routing table. If there is a tie for the best feasible distance, up to six routes to the same destination can be maintained in the routing table. The neighbor router through which the best path flows is called the successor. The neighbor router through which the second to the best path flows is called the feasible successor for a route if its advertised distance to the destination network address is less than the successor’s feasible distance to the destination network address. Once all of the routes to a destination have been placed into the topology table and the successor and feasible successor, if any, have been selected, the route is said to be in passive state.
When the successor goes down, and there is a feasible successor, the feasible successor immediately becomes the successor and is installed as the preferred path; the route stays in passive state. If there is no feasible successor when the successor goes down, a new successor must be located. The route changes to active state, and the router sends a query to its neighbors requesting new information about the route. The neighbors send replies with the information, which the router acknowledges. Once all neighbors have responded and an alternate path is available, a new successor and feasible successor, if any, are selected, and the route is changed back to passive state. While the route is active, no traffic will be routed to it. If there is no alternate path, the route is removed from the topology table.
Turning on EIGRP on IOS is practically identical to turning on IGRP, as we did in Section 7.7.2.1, with the exception of the addition of the letter e. We configure the EIGRP process by referencing EIGRP with an ASN after the router command. Then we need to enable EIGRP on the appropriate interfaces with the network command. The network commands used to configure EIGRP on our test network are the exact same ones that we used to configure RIP and IGRP. For consistency, we will show the entering of the commands. Figure 7-60 shows the configuration of EIGRP on Dallas; Figure 7-61 shows the configuration of EIGRP on FortWorth, and Figure 7-62 shows the EIGRP configuration on Austin.
<<<Figure 7-60 EIGRP Configuration on Dallas>>>
<<<Figure 7-61 EIGRP Configuration on FortWorth>>>
<<<Figure 7-62 EIGRP Configuration on Austin>>>
We chose the ASN 100 to use on all of the routers (Line 3). The network commands enable EIGRP on all of the active interfaces of the routers. For example, the network 172.16.0.0 command (Line 4, Figure 7-61) tells IOS on FortWorth that EIGRP should be enabled on all of the interfaces that have addresses in the 172.16.0.0 network address space; these are Ethernet0 and Serial0.
As soon as EIGRP is enabled on an interface, the EIGRP process starts sending Hello packets and listening for Hello packets to determine the neighbor routers. Once the neighbor routers are discovered, their addresses are placed into a neighbor table and adjacencies are formed.
To turn off EIGRP on a single interface that is included in one of the network statements, we can use the router configuration command passive-interface. Since there are no other routers running EIGRP on the Ethernet LAN’s, we can make the Ethernet interfaces passive to stop the Hello packets from being transmitted every five seconds out of them. Figure 7-63 shows the passive-interface command being issued on FortWorth.
<<<Figure 7-63 Passive-Interface Command for EIGRP>>>
Whenever the EIGRP process is referenced on the command line, the ASN must be included since there may be multiple EIGRP processes. The latest version of IOS supports up to 30 EIGRP processes. With Ethernet0 on FortWorth now passive, EIGRP will send no Hello packets or updates to the Ethernet LAN.
Auto-summarization is on by default for EIGRP. It can be turned off with the router configuration command no auto-summary. This command will perform the same function as it did for RIPv2 as described in Section 7.7.1.2.
Now that EIGRP has been started, there are a few commands that we can use to check its operation. The commands are as follows:
We will display the output for these just to see the type of information available from each. The show ip protocols command is extremely useful for getting general information about which IP routing protocols IOS is running and how they are configured. Figure 7-64 shows the output of the show ip protocols command on Dallas.
<<<Figure 7-64 Show IP Protocols Output After EIGRP Configuration>>>
The output shows that process EIGRP 100 is running (Line 2); that is EIGRP with ASN 100. EIGRP has the same default maximum hop count as IGRP, 100 (Line 8). As has already been mentioned, auto-summarization is in effect by default; this is reported on Line 11, and the summary routes being advertised by Dallas are shown on Lines 13 and 14.
The sources of EIGRP 100 routing information are shown near the bottom of the output. We see that Dallas is one of its own sources (Line 21). This occurs because of the auto-summarization of the 172.16.0.0 network address. As we will see in the routing table (Figure 7-67), Dallas installs a local summary route for the 172.16.0.0/16 address that leads to the Null0 interface. The administrative distance for an EIGRP summary is 5 (Line 21). The other two sources are Austin (Line 22) and FortWorth (Line 23). The administrative distance for routes learned via EIGRP from those sources is 90. Routes that originate within the EIGRP autonomous system are called internal routes, and those that come from outside the EIGRP autonomous system but are included in EIGRP updates are called external routes. The default administrative distance for EIGRP internal routes is 90 (Line 24); this is lower than IGRP’s thus EIGRP-learned internal routes are preferred over IGRP-learned routes. The default administrative distance for EIGRP external routes is 170 (Line 24).
Dallas is receiving route information from FortWorth and Austin; therefore, they must be neighbor routers. We can check that by issuing the show ip eigrp neighbors command on Dallas to check the contents of Dallas’ EIGRP neighbor table. Figure 7-65 shows the result of this command.
<<<Figure 7-65 Show IP EIGRP Neighbors Output>>>
The two neighbor routers are shown on Line 5 (FortWorth) and Line 6 (Austin). The H column shows a sequence number indicating the order in which the neighbors were discovered; Austin was discovered first. The Interface column shows the local interface out which the neighbor can be reached. The Hold column shows the value of the hold timer, in seconds, which by default started counting down at 15 seconds (the Hold Time). This timer for a neighbor router gets set to its maximum value each time that a Hello packet is received from the neighbor. Remember that Hello packets should be received every five seconds. If the hold timer every reaches the zero, the neighbor is assumed to be down. The Uptime column contains the elapsed time since a router became a neighbor. SRTT is smooth round-trip time; this is the average time that a query response sequence takes to a neighbor router. RTO is the retransmission timeout after which a query or update will be retransmitted when a response or acknowledgment has not been received from a neighbor. In the Figure 7-65 example, the RTO is six times the SRTT. The number of packets queued for transmission to a neighbor router is given in the Q Cnt column. All of the information packets between neighbor routers have sequence numbers, and the Seq Num column shows the sequence number of the last packet received from each neighbor.
We have established that EIGRP is running, and Dallas has discovered that FortWorth and Austin are neighbors. Now we should look at what information has been exchanged between the neighbors. The EIGRP topology table shows the information in a raw format. Figure 7-66 shows Dallas’ EIGRP topology table.
<<<Figure 7-66 Show IP EIGRP Topology Output>>>
The show ip eigrp topology command displays a summary of the EIGRP topology table. The topology table on Dallas shows that all of the routes are in passive state, as indicated by the letter P in the left column of each route. The successor, or successors, is shown for each route along with the feasible distance (FD) for the route. Remember the feasible distance is the composite metric as calculated from the local router’s (Dallas) perspective through a neighbor router. Those routes that are learned from a neighbor show two numbers separated by a slash (/) in parentheses (Line 8, for example). The first number is the feasible distance through the neighbor, and the second number is the advertised distance of the route from the neighbor.
The successor for each route is placed into the IP routing table. We will look at the IP routing tables for each of our routers. Figure 7-67 shows the IP routing table for Dallas; Figure 7-68 shows the IP routing table for FortWorth, and Figure 7-69 shows the IP routing table for Austin.
<<<Figure 7-67 IP Routing Table on Dallas After EIGRP Configuration>>>
When EIGRP is running, the EIGRP-learned routes have a D displayed in the left column of their routing table entries (for example, Line 4). The first number within the brackets, on the entries for routes that are not directly connected, shows that the EIGRP-learned routes have an administrative distance of 90. Whenever a router is running EIGRP and summarization is being done, IOS creates a local summary route for the route being summarized (Line 7). The local summary route points to the Null0 interface. The Null0 interface is a logical interface that goes nowhere; some people may refer to this as the bit bucket. If Dallas were to get a packet destined for a non-existent subnet of the 172.16.0.0 network, for example, 172.16.33.0, the packet would be routed to the Null0 interface and dropped, even if a default route existed. Dallas would also send an ICMP destination (host) unreachable message back to the source of the original packet. If we were to turn off auto-summarization, the local summary route would be removed.
<<<Figure 7-68 IP Routing Table on FortWorth After EIGRP Configuration>>>
FortWorth’s new IP routing table also contains the local summary route to the Null0 interface (Line 7). With exception of the summary route, the network addresses in the routing table are the same as the ones we saw when the routers were running IGRP (Figure 7-53). In Figure 7-53, the metric for the IGRP-learned route to the 172.16.10.0/24 network is 8576. The metric for the EIGRP-learned route is 2195456 (Line 5). When we multiply the value 8576 by 256, the result is 2195456. Remember the EIGRP composite metric uses the same parameters as the IGRP metric multiplied by 256.
<<<Figure 7-69 IP Routing Table on Austin After EIGRP Configuration>>>
Austin’s IP routing table contains the summary route, 172.16.0.0/16, that is being advertised by Dallas (Figure 7-69, Line 3). FortWorth is also advertising the summary route, but the path to Dallas has a lower metric and is, thus, preferred. Austin has no local summary route to the Null0 interface because Austin is not directly connected to any subnets of major network addresses and is not actively summarizing its routes to Dallas and FortWorth.
We use the show ip eigrp traffic command to check the number of packets being processed by EIGRP. Figure 7-70 shows the output of the show ip eigrp traffic command on Dallas.
<<<Figure 7-70 Show IP EIGRP Traffic Output>>>
The number of times each type of EIGRP packet was transmitted and received is given in the output. The packet types were covered in Section 7.7.3.2. In a stable network, the number of Hello packets (Line 3) should steadily increase since they are transmitted and received periodically. The other counters should not change very much unless a network is in transition.
EIGRP configuration, at least getting it started, is very similar to that of RIP and IGRP. EIGRP is configured by entering the router eigrp command with an ASN in global configuration mode and then the appropriate network commands for enabling EIGRP on the interfaces. Just as with IGRP, all of the routers that use EIGRP to share information must have the same ASN. To stop updates on an interface, issue the passive-interface command, with the interface name, in router configuration mode for the EIGRP process. The router configuration command no auto-summary can be used to turn off auto-summarization for an EIGRP process.
The EIGRP-specific configuration commands, from the running configurations, entered for Dallas, FortWorth, and Austin are shown in Figure 7-71, Figure 7-72, and Figure 7-73, respectively.
<<<Figure 7-71 Dallas EIGRP-Specific Configuration Commands>>>
<<<Figure 7-72 FortWorth EIGRP-Specific Configuration Commands>>>
<<<Figure 7-73 Austin EIGRP-Specific Configuration Commands>>>
EIGRP is very easy to turn on. IOS hides most of its complexity from us.
The removal of an IP routing protocol is almost too easy. It requires a single global configuration command on each router. Figure 7-74 shows the removal of EIGRP on Dallas.
<<<Figure 7-74 Removal of EIGRP>>>
The no router eigrp 100 command (Line 3) removes all of the EIGRP-specific commands from the running configuration. After issuing the command on all three of our test routers, our internetwork is once again left without an IP routing protocol and is awaiting the configuration of another.
Remember that whenever EIGRP is referenced in configuration mode, the ASN must be included with it to uniquely identify the EIGRP process.
OSPF is an open standard, link state routing protocol. (See Section 2.2.2.2 for an overview of link state routing protocols.) OSPF was developed by the Internet Engineering Task Force (IETF), and its latest version, 2, is defined in RFC 2328.
Similar to EIGRP, OSPF is classless, has a very fast convergence time and is complicated, both in operation and in configuration, just as one would expect from something developed by a committee. The following coverage provides just a glimpse into its complexity.
The nature of OSPF practically requires that some type of hierarchy be designed into an internetwork. The hierarchy can be either physical or logical.
We build a hierarchy of an internetwork running OSPF by defining areas. An area is a logical group of routers and networks. Each area has its own numeric identifier (ID). An area ID is a 32-bit value that can be written as either a decimal number or a dotted-decimal value, like an IP address. A router can be attached to multiple areas, but a network should be a part of only one area. If an OSPF network has multiple areas, one of the areas must be area 0 (or 0.0.0.0). Area 0 is the backbone area, and inter-area traffic (traffic between areas) flows through the backbone area. The backbone area should consist of stable networks. The areas of an OSPF internetwork are collectively referred to as an autonomous system.
A router with connections to multiple areas is called an Area Border Router (ABR). A router with connections to a single area is called an internal router, and a router that connects to another autonomous system is called an Autonomous System Boundary Router (ASBR).
Each router running OSPF gets a dynamically assigned router ID (RID); the router ID is derived from the IP address of one of a router’s active interfaces and is assigned when OSPF is started. If a router has a loopback interface with an IP address configured, the router ID is the IP address of loopback interface, or the highest loopback interface IP address if there are multiple loopback interfaces. If there are no loopback interfaces, the router ID is the highest IP address that is assigned to one of the other router’s active interfaces. An active interface is one that is in an up/up state. Loopback interfaces are logical interfaces that we create; they do not go down unless we manually shut them down. A router’s OSPF RID will change if the interface from which it was derived goes down.
All routers running OSPF transmit and save Link State Advertisements (LSA) in a link state database. There are many types of LSA’s; the most basic ones are described in the next few paragraphs. All of the routers within an area must contain identical LSA’s in their databases for the area, or areas, to which they are connected. Routers transmit LSA’s when a network changes state and periodically at 30 minute intervals. The retransmission every 30 minutes happens because each LSA in the link state database must be refreshed every 90 minutes. Routers must acknowledge all valid LSA’s that they receive.
A router LSA is one that is generated by each router in an OSPF autonomous system; it contains information about an individual router such as its RID and the links (for example, networks) to which it is attached. Router LSA’s are propagated, or flooded, to every router that is connected to the area in which the LSA originated.
Routes to networks within an area are called intra-area routes, and routes to networks in another area of the same OSPF autonomous system are called inter-area routes. Inter-area routes are propagated by ABR’s by using summary LSA’s. Summary LSA’s propagate within area borders. Routes to networks in another autonomous system are called external routes; external routes are injected into the OSPF autonomous system by ASBR’s by using external LSA’s. External LSA’s propagate throughout an entire OSPF autonomous system except as indicated below.
Several types of OSPF areas are defined; we will be covering the following types:
A normal area is an area that can contain internal routers, ABR’s, and ASBR’s. Area 0 must be a normal area.
A stub area is one that does not allow the propagation of external routes. The ABR that connects a stub area to the backbone area blocks the propagation of external LSA’s and transmits a default route along with the normal inter-area routes (by summary LSA’s) into the stub area. The default route is used by all of the stub area’s internal routers to get to networks that are not a part of the OSPF autonomous system. The inter-area routes are used to get to networks that are a part of the autonomous system. A stub area cannot contain an ASBR. Stub areas are defined in the OSPF standard.
A totally stubby area is a Cisco-proprietary area type that extends the definition of a stub area. A totally stubby area does not allow the propagation of external routes (external LSA’s) or inter-area routes (normal summary LSA’s); instead, the ABR that connects a totally stubby area to the backbone area transmits only a default route into the totally stubby area. The default route is used by all of the totally stubby area’s internal routers to get to networks that are not a part of the local totally stubby area. Internal routers in totally stubby areas tend to have very small routing tables relative to the routers in normal areas.
Similarly to EIGRP, OSPF discovers neighbor routers by transmitting Hello packets and listening for Hello packets. OSPF routers transmit Hello packets to the multicast address designated for all OSPF routers, 224.0.0.5. Once neighbors are discovered, their information is placed into a neighbor table. In order for two routers to become OSPF neighbors, they must agree on five OSPF parameters that are contained in the Hello packets:
The hello interval is the length of time between hello packets. The default hello interval is 10 seconds. The dead interval is the amount of time that must elapse without a router hearing a Hello from a neighbor before the router will remove the neighbor’s information from its table. This is similar to the Hold Time that was covered for EIGRP. The default dead interval is four times the hello interval, 40 seconds.
The stub area flag is set in the hello packets transmitted by a router into an area when we define the area to be a stub area or a totally stubby area. The flag is actually just a single bit within the packet. All of the routers that connect to any kind of stub area must know that the area is a stub area.
OSPF provides password authentication just like RIPv2 and EIGRP so it is reasonable that two routers cannot be neighbors and share information if they do not know each other’s password.
On multi-access networks such as LAN’s and frame relay multipoint WAN’s, a Designated Router (DR) and a Backup Designated Router (BDR) are elected based on OSPF priority and router ID. The router with the highest OSPF priority on a multi-access network is selected to be DR; the router with the second highest OSPF priority is selected to be the BDR. The default OSPF priority of an IOS-based router is 1 (one). If multiple routers have the same priority, the RID is used as the tie-breaker. The router with the highest RID wins. Once a router has been elected DR for a network, the router continues to be DR until its connection to the network goes down. When a network loses its DR, the BDR immediately becomes the DR, and there is an election for a new BDR.
The DR is responsible for advertising the network to the rest of the OSPF routers using a network LSA. The network LSA contains the network’s address and mask along with the RID’s of all of the routers attached to the network. The propagation of network LSA’s is bounded by an area’s border, just as that of router LSA’s and summary LSA’s are.
Each multi-access network gets its own DR and BDR. All routers on the multi-access network build adjacencies only with the DR and the BDR; this usually reduces the number of adjacencies that must be maintained by all of the routers except the DR and BDR. When routers transmit LSA’s meant for the DR and BDR, the routers send the LSA’s to the multicast address designated for all DR’s and BDR’s, 224.0.0.6. An adjacency is the synchronization of the routers’ link state databases so that they have identical LSA’s for the area in which the network exists.
There is no DR and BDR election on point-to-point networks; the routers on each end do, however, establish an adjacency with each other.
OSPF uses a single metric called cost. The cost is calculated from the bandwidth assigned to an interface; this bandwidth is defined the same way as the bandwidth used in the composite metric for IGRP and EIGRP. The cost of a link is included in the LSA that is being used to advertise the link. OSPF costs are additive. To get the total metric from one network to another, routers simply add the costs of the individual networks that must be crossed to get to a destination. The default formula for calculating the outbound cost of an interface is as follows:
10
8 / bandwidth (in bps) = costFor example, the default cost of a 10 Mbps Ethernet interface is 10 as shown below.
10
8 / bandwidth = 108 / 10,000,000 = 108 / 107 = 10So now there are all of these types of LSA’s being transmitted and collected by different types of routers within different types of areas. We still have not reached the point where a router running OSPF can route packets using the information it has gathered in its link state database.
The OSPF process runs a special algorithm called the Shortest Path First (SPF) algorithm against the link state database. The algorithm is also called the Dijkstra algorithm. The running of the SPF algorithm produces a map of an internetwork in the form of a tree with the local router as the root. From the network tree, the router takes the shortest path to each network and places that path into the IP routing table.
When the link state database is updated, a router must run the SPF algorithm, produce another network tree, and then update the routing table. Because of this three-step process, routers running OSPF use more CPU time than those running the other routing protocols we have covered. The existence of the neighbor table, the link state database, and the network tree requires a little more RAM, also.
The configuration of OSPF requires the designation of an OSPF process with the router ospf command along with a process ID (PID). The PID identifies the local OSPF process only, and does not have to be the same on all of the routers running OSPF. OSPF is enabled on a router’s interfaces by using the network area command. The network area command associates a wildcard mask with an address, and it specifies the area to which interfaces that match the address and wildcard mask pair are connected. This gives us control over exactly which interfaces have OSPF enabled and which area each interface is in. The command syntax looks like this.
network
address wildcard-mask area area-IDThe address is the dotted-decimal address of a network, a subnet, or an interface. The wildcard-mask is a 32-bit, dotted-decimal value sometimes called an inverse mask because the meanings of its bits are inverted from their meanings in a network mask. We covered network masks when we did IP address subnetting. In a network mask, a binary one in a bit position means that the bit position is important in routing, and a binary zero in a bit position means that the bit position has no significance in routing. The opposite is true for a wildcard mask. In a wildcard mask, a binary zero means that the bit position should be checked in matching an address, and a binary one means that the bit position should be ignored during the matching process. A wildcard mask of 255.255.255.255 is used to match any address, and a wildcard mask of 0.0.0.0 is used to match only the specific address with which is paired. Those are the two extremes of the wildcard mask; the configuration examples will provide more insight. The area-ID is the number that we have assigned to the area to which all interfaces with addresses matching the address/wildcard-mask pair are connected.
The OSPF internetwork that we are going to configure is shown in Figure 7-75. There are two areas, 0 and 1. The area boundaries are highlighted. Area 0 will contain Dallas’s Ethernet0 and Serial1 interfaces and FortWorth’s Ethernet0 and Serial0 interfaces. Area 1 will contain Dallas’s Serial0 interface, FortWorth’s Serial1 interface, and all of Austin’s interfaces. Dallas and FortWorth will be ABR’s, and Austin will be an internal router.
<<<J120 – Figure 7-75 OSPF Area Diagram>>>
Figure 7-76 shows the configuration of our OSPF design on Dallas. Figure 7-77 shows the OSPF configuration on FortWorth, and Figure 7-78 has the configuration of OSPF on Austin.
<<<Figure 7-76 OSPF Configuration on Dallas>>>
The configuration of OSPF is initiated on Dallas with the router ospf 100 command (Line 3). The PID is 100; this identifies the OSPF process on Dallas. This number does not have to be the same on the other routers. As a matter of fact, we purposely used a different PID on each router to illustrate this. Under normal circumstances, we would have used the same PID on all the routers just to be consistent and to avoid having to figure out which PID we used each time that we wanted to configure OSPF on a router. On the Line 4 network area command, we have an address of 172.16.10.1 with a wildcard mask of 0.0.0.0. The interfaces with addresses matching this address/mask pair are to run OSPF for area 0. Since the wildcard mask is all zeros, there can be only one matching address. This particular command enables OSPF on Dallas’ Ethernet0 interface and places the Ethernet LAN in area 0 because the Ethernet0 interface has the exact address 172.16.10.1. The next network area command (Line 5) enables OSPF on the Serial1 interface for area 0. The last network area command (Line 6) enables OSPF on the Serial0 interface for area 1.
The network area commands are processed from top to bottom so the order in which they are typed is important when an interface’s address matches multiple statements. When using the 0.0.0.0 wildcard mask, the order does not really matter since each statement can possibly match only one address.
<<<Figure 7-77 OSPF Configuration on FortWorth>>>
We used the PID 200 on FortWorth (Line 3, Figure 7-77). The first network area command (Line 4) enables OSPF on both the Ethernet0 and the Serial0 interfaces and places them both in area 0. The address of 172.16.0.0 paired with the wildcard mask of 0.0.255.255 means that the interfaces with addresses beginning with 172.16 match the statement; those are Ethernet0 and Serial0. The Line 5 command puts Serial1 into area 1 because the address of Serial1 starts with 192.168.3.
<<<Figure 7-78 OSPF Configuration on Austin>>>
Austin gets another different PID, 300 (Line 3, Figure 7-78). We used a single network area command (Line 4) to put all of Austin’s interfaces into OSPF area 1. With the wildcard mask of 0.255.255.255, only the first octet of an interface’s address is checked in the statement. All of Austin’s addresses begin with 192; therefore, all of them get placed into area 1.
The commands we will use to verify the operation of OSPF are as follows:
Since we started the verification of all the other routing protocols with the show ip protocols command, we will do the same thing here. Figure 7-79 shows the output of the show ip protocols command on Dallas.
<<<Figure 7-79 Show IP Protocols Output After OSPF Configuration>>>
As shown on Line 2, OSPF with the PID of 100 is running. OSPF updates are triggered, not periodic; that is why the timers are all 0 (Lines 3 and 4). The addresses that match our address/wildcard mask pairs on the network area commands are specified on Lines 9, 10, and 11. Dallas is receiving routing from both FortWorth (Line 15) and Austin (Line 14). The addresses shown are the RID’s for the routers. OSPF’s default administrative distance of 110 (Line 16) is lower than that of RIP but higher than that of IGRP and EIGRP.
The IP routing tables are an indication of the type of connectivity our internetwork has. Figure 7-80 shows the IP routing table for Dallas. Figure 7-81 has FortWorth’s IP routing table, and Figure 7-82 has Austin’s IP routing table.
<<<Figure 7-80 Dallas IP Routing Table After OSPF Configuration>>>
Dallas’s routing shows the usual routes. The routes learned via OSPF have the letter O in the left column of their entries. The administrative distance of 110 is shown in the brackets for the OSPF-learned routes. As usual, the second number within the brackets is the metric. The metric for these routes is the OSPF cost. Let us do a quick calculation of a route’s metric. The route to network address 172.16.20.0 has a cost of 74 (Line 4). This is a route to FortWorth’s Ethernet LAN across the T1. The cost for the T1 is 64, and the cost for FortWorth’s Ethernet0 interface is 10; the total cost is 74.
<<<Figure 7-81 FortWorth IP Routing Table After OSPF Configuration>>>
The IP routing table on FortWorth shows the same basic routes as the one on Dallas.
<<<Figure 7-82 Austin IP Routing Table After OSPF Configuration>>>
The IP routing table of Austin shows some differences from what we saw with the other routing protocols. Austin knows about each of the 172.16.0.0 subnets (Lines 4, 5, and 6). OSPF does not do auto-summarization; OSPF summarization must be manually configured. The subnets have the additional letters IA after the O in the left column. The IA indicates that these are inter-area routes; the networks are in another area to which Austin is not connected. According to Figure 7-75 and our configuration, they are in area 0 while Austin is entirely within area 1.
General information about OSPF operation can be obtained with the show ip ospf command. Figure 7-83 shows the output of the show ip ospf command on Dallas.
<<<Figure 7-83 Show IP OSPF Output>>>
The only OSPF process running has PID 100, and the RID selected for that process is 192.168.2.1 (Line 2). The address 192.168.2.1 is the highest IP address assigned to an active interface on Dallas. Dallas is connected to two areas – 0 (Line 10) and 1 (Line 20). Being connected to two areas makes Dallas an ABR (Line 4). Dallas has two interfaces in area 0 (Line 11) and one interface in area 1 (Line 21). We also see the number of times that the SPF algorithm has been run for each of the areas (Lines 13 and 23). This is good statistic to monitor. If it starts increasing rapidly, we probably have an unstable network somewhere.
The OSPF neighbor table contains the RID’s for all of the routers that the local router has discovered as neighbors. Figure 7-84 shows the neighbor table displayed on Dallas after issuing the show ip ospf neighbor command.
<<<Figure 7-84 Show IP OSPF Neighbor Output>>>
Dallas’ two neighbor routers are Austin (Line 4) and FortWorth (Line 5). The Neighbor ID column shows the RID’s for the routers, not the addresses of their directly-connected interfaces. The neighbors’ directly-connected interface addresses are given in the Address column, and the interface to which the neighbor is connected is shown in the Interface column. The State column shows the status of the neighbor relationship. A full state indicates that an adjacency has been established with a neighbor. The Dead Time column indicates the amount of time left in the dead interval either to receive a Hello packet from a neighbor or to remove the neighbor from the table.
<<<Figure 7-85 Show IP OSPF Interface Output>>>
Figure 7-85 shows the output of the show ip ospf interface command on Dallas. The show ip ospf interface command shows the status of OSPF on a router’s interfaces. Figure 7-85 shows that Dallas has OSPF enabled on interfaces Ethernet0, Serial0, and Serial1 (Lines 9, 19, and 28). We will look at some of the information given for the Serial1 interface (starting on Line 27). The Serial1 interface is connected to area 0 (Line 28) for Dallas’s OSPF PID 100 (Line 29). Dallas’ RID is 192.168.2.1 (Line 29). The network to which Serial1 is connected is a point-to-point network with a cost of 64. The cost of 64 is based on the bandwidth of the Serial1 interface being set to the fast-serial interface default value of 1544. That is 1544 kbps, or 1,544,000 bps, to plug into the formula for calculating OSPF cost. The OSPF timers are given on Line 31. Dallas has one neighbor out its Serial1 interface (Line 33), and an adjacency has been established with that neighbor (Line33). The neighbor’s RID (192.168.3.1) is given on Line 34; the neighbor is Austin.
The link state database is another useful item to examine when verifying the operation of OSPF. Figure 7-86 shows the output of the show ip ospf database command on Dallas.
<<<Figure 7-86 Show IP OSPF Database Output>>>
Since Dallas is an ABR with connections to both area 0 and area 1, there are two sets of link state information in the database. There are two routers with connections to area 0; therefore, there must be two router link states for area 0: one for Dallas (Line 9) and one for FortWorth (Line 10). There are two ABR’s between area 0 and area 1; therefore, each of them generated summary LSA’s into area 0 indicating the routes in area 1 (Lines 15 through 20). There are three routers with connections to area 1 so there must be three router link states for area 1: one for Dallas (Line 25), one for FortWorth (Line 26), and one for Austin (Line 27). The two ABR’s each generated summary LSA’s into area 1 indicating the routes in area 0 (Lines 32 through 37).
Stub areas were covered in Section 7.7.4.1. We use the router configuration command area stub to convert an area into a stub area. The area stub command must be entered under the OSPF process for every router that has a connection to the area that is to be a stub area. Figure 7-87 shows the conversion of area 1 from a normal area to a stub area.
<<<Figure 7-87 Conversion of a Normal Area to a Stub Area>>>
The configurations of our three test routers were grouped together to show that the same command must by typed for the OSPF process on each router. The ID of the area being made a stub area must be referenced in the area stub command. The area ID goes between the area keyword and the stub keyword in the command (Lines 4, 11, and 18).
After converting area 1 to a stub area, the IP routing tables of Dallas and FortWorth are unchanged since they are ABR’s for area 1. However, the Austin routing table now contains a default route as shown in Figure 7-88.
<<<Figure 7-88 IP Routing Table of Austin After Stub Area Conversion>>>
The default route is shown on Line 18 as a network 0.0.0.0 with a prefix length of /0. The prefix length of /0 will cause any destination address to match this route. Austin will route all IP packets with this route unless there is another routing table match with a longer prefix length. As a general rule, the default route is used if no other match for a destination address can be found in the routing table. The default route also appears as the gateway of last resort (Line 9). The OSPF inter-area routes to the 172.16.0.0 subnets are still in the routing table. We can get rid of those by making area 1 a totally stubby area.
To convert an area from a stub area to a totally stubby area, we need to reissue the area stub command, on the ABR’s, with the keyword no-summary at the end of it. Figure 7-89 shows the conversion of area 1 from a stub area to a totally stubby area.
<<<Figure 7-89 Conversion of a Stub Area to a Totally Stubby Area>>>
Since Austin is not an ABR for area 1, the configuration of Austin remains as it is with the original area 1 stub command. The no-summary keyword (Lines 4 and 11) indicates that the usual summary LSA’s containing inter-area routes are not to be injected into the area. Instead only a default route is injected. Figure 7-90 shows Austin’s routing table after area 1 becomes a totally stubby area.
<<<Figure 7-90 IP Routing Table of Austin After Totally Stubby Area Conversion>>>
Austin’s IP routing table no longer contains any inter-area routes. Instead there is a default route, which will be used to route packets to any network that not in area 1.
We start OSPF by entering the router ospf command, with a process id, in global configuration mode and then the appropriate network area commands for enabling OSPF on the interfaces. The network area command, through the use of a wildcard mask, allows us to accurately control which interfaces get OSPF enabled and which area an interface is connected to.
To convert a normal area to a stub area, we use the area stub command, in router configuration mode for the OSPF process, on every router that has a connection to the area. We create a totally stubby area by using the area stub command on every router that has a connection to the area, but, on the area’s ABR’s, we include the no-summary keyword on the area stub command
The current, OSPF-specific configuration commands, from the running configurations of Dallas, FortWorth, and Austin are shown in Figure 7-91, Figure 7-92, and Figure 7-93, respectively.
<<<Figure 7-91 Dallas OSPF-Specific Configuration Commands>>>
<<<Figure 7-92 FortWorth OSPF-Specific Configuration Commands>>>
<<<Figure 7-93 Austin OSPF-Specific Configuration Commands>>>
Since OSPF is the last IP routing protocol we will be covering, we will be leaving the configuration in this state.
Removing an OSPF process on a Cisco router requires a single global configuration command. Just put the keyword no in front of the command that was used to configure OSPF. For example, the command to remove the current OSPF process from Dallas would be as follows:
no router ospf 100
When OSPF is referenced in configuration mode, the PID must be included with it to uniquely identify the OSPF process since there could be multiple OSPF processes running on the router.
| Chapter: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| Reserve your copy at a Bet@ Bookstore near you! |
Contact Bet@ Books © 1999 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use. |
