Chapter 7. Configuring IP
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
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:
28 - 2 = 256 - 2 = 254 Hosts
The 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
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.
<<<Figure 7-4 Class B Network Subnetting>>>
<<<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 18.104.22.168).
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 addressaddress mask
where 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 22.214.171.124 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 126.96.36.199, 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:
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 188.8.131.52.
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 184.108.40.206.
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 220.127.116.11 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 18.104.22.168, 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 22.214.171.124.
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