### 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:

• Prefix Length
• Class

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.

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

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.

### Subnetting

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.

• Locate the last non-zero octet of the network mask.
• Note the octet number and its value.
• Subtract the value from 256 to get the subnet seed.
• Calculate multiples of the seed to get the subnet addresses.

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:

• 192.168.129.32
• 192.168.129.64
• 192.168.129.96
• 192.168.129.128
• 192.168.129.160
• 192.168.129.192

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.

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).

### Public and Private IP Addresses

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:

• 10.0.0.0
• 172.16.0.0 through 172.31.0.0
• 192.168.0.0 through 192.168.255.0

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.

## IP Overview

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

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.

### Layer 3

At layer 3, there can be either an IP header or Address Resolution Protocol (ARP) data.

### Internet Protocol (IP)

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:

• Time to Live
• Protocol Number

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.

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.

### Layer 4

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.

### Transmission Control Protocol (TCP)

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.

### User Datagram Protocol (UDP)

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.

### Internet Control and Messaging Protocol (ICMP

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.

### Others

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

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

TCP applications that can run on IOS include:

• Telnet (client and server)
• rcp (client)
• HTTP (server)

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

UDP applications that can run on IOS include:

• TFTP (client)
• SNMP (client)
• DNS (client)

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.

## IP Routing

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.

1. Dallas>show ip route
2. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
3. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
4. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
5. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
6. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
7. U - per-user static route, o - ODR
8. Gateway of last resort is not set
9. 172.16.0.0/24 is subnetted, 3 subnets
10. R 172.16.20.0 [120/1] via 172.16.11.2, 00:00:05, Serial1
11. C 172.16.10.0 is directly connected, Ethernet0
12. C 172.16.11.0 is directly connected, Serial1
13. 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.

## Configuring IP on an Interface

The command to tell IOS to route IP packets on an interface is:

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:

• Configure Serial0 on Dallas.
• Configure Serial1 on FortWorth.
• Configure miscellaneous items (see Chapter 6) and all active interfaces on Austin.

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.

### Configuring IP on Dallas Serial0

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.

1. Dallas#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Dallas(config)#interface serial0
5. Dallas(config-if)#bandwidth 256
6. Dallas(config-if)#description 256k Line to Austin
7. Dallas(config-if)#no shutdown
8. Dallas(config-if)#<Ctrl-Z>
9. Dallas#

<<<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.

### Configuring IP on FortWorth Serial1

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.

1. FortWorth#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. FortWorth(config)#interface serial1
5. FortWorth(config-if)#bandwidth 56
6. FortWorth(config-if)#description 56k Line to Austin
7. FortWorth(config-if)#no shutdown
8. FortWorth(config-if)#<Ctrl-Z>
9. FortWorth#

<<<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.

### Configuring Austin

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

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.

1. Router>enable
2. Router#configure terminal
3. Enter configuration commands, one per line. End with CNTL/Z.
4. Router(config)#hostname Austin
5. Austin(config)#enable secret itsasecret
7. Austin(config)#line vty 0 4
10. Austin(config-line)#line con 0
13. Austin(config-line)#interface ethernet0
15. Austin(config-if)#description Austin Ethernet LAN
16. Austin(config-if)#no shutdown
17. Austin(config-if)#interface serial0
19. Austin(config-if)#bandwidth 56
20. Austin(config-if)#description 56k Line to FortWorth
21. Austin(config-if)#no shutdown
22. Austin(config-if)#interface serial1
24. Austin(config-if)#bandwidth 256
25. Austin(config-if)#description 256k Line to Dallas
26. Austin(config-if)#no shutdown
27. Austin(config-if)#<Ctrl-Z>
28. Austin#

<<<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).

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?

### Examining IP Routing Tables

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.

1. Dallas#show ip route
2. [text omitted]
3. Gateway of last resort is not set
4. 172.16.0.0/24 is subnetted, 3 subnets
5. R 172.16.20.0 [120/1] via 172.16.11.2, 00:00:14, Serial1
6. C 172.16.10.0 is directly connected, Ethernet0
7. C 172.16.11.0 is directly connected, Serial1
8. C 192.168.2.0/24 is directly connected, Serial0
9. Dallas#
10. <<<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.

11. FortWorth#show ip route
12. [text omitted]
13. Gateway of last resort is not set
14. 172.16.0.0/24 is subnetted, 3 subnets
15. C 172.16.20.0 is directly connected, Ethernet0
16. R 172.16.10.0 [120/1] via 172.16.11.1, 00:00:08, Serial0
17. C 172.16.11.0 is directly connected, Serial0
18. C 192.168.3.0/24 is directly connected, Serial1
19. FortWorth#
20. <<<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.

21. Austin#show ip route
22. [text omitted]
23. Gateway of last resort is not set
24. C 192.168.1.0/24 is directly connected, Ethernet0
25. C 192.168.2.0/24 is directly connected, Serial1
26. C 192.168.3.0/24 is directly connected, Serial0
27. Austin#

<<<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.

## Static Routes

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.

1. Austin#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Austin(config)#ip route 172.16.10.0 255.255.255.0 192.168.2.1
4. Austin(config)#<Ctrl-Z>
5. Austin#
6. <<<Figure 7-17 Austin Static Route to Dallas Ethernet>>>

7. Austin#show ip route
8. [text omitted]
9. Gateway of last resort is not set
10. 172.16.0.0/24 is subnetted, 1 subnets
11. S 172.16.10.0 [1/0] via 192.168.2.1
12. C 192.168.1.0/24 is directly connected, Ethernet0
13. C 192.168.2.0/24 is directly connected, Serial1
14. C 192.168.3.0/24 is directly connected, Serial0
15. Austin#

<<<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.

### Testing Connectivity With Ping

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.

1. Austin#ping 172.16.10.1
2. Type escape sequence to abort.
3. Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
4. !!!!!
5. Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/12 ms
6. Austin#
7. <<<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.

8. Austin#ping
9. Protocol [ip]: <Enter>
11. Repeat count [5]: <Enter>
12. Datagram size [100]: <Enter>
13. Timeout in seconds [2]: <Enter>
14. Extended commands [n]: y
15. Source address or interface: 192.168.1.1
16. Type of service [0]: <Enter>
17. Set DF bit in IP header? [no]: <Enter>
18. Validate reply data? [no]: <Enter>
19. Data pattern [0xABCD]: <Enter>
20. Loose, Strict, Record, Timestamp, Verbose[none]: <Enter>
21. Sweep range of sizes [n]: <Enter>
22. Type escape sequence to abort.
23. Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
24. .....
25. Success rate is 0 percent (0/5)
26. Austin#

<<<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.

1. Dallas#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Dallas(config)#ip route 192.168.1.0 255.255.255.0 192.168.2.2
4. Dallas(config)#<Ctrl-Z>
5. Dallas#
6. <<<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>>>

7. Austin#show ip route
8. [text omitted]
9. C 192.168.1.0/24 is directly connected, Ethernet0
10. C 192.168.3.0/24 is directly connected, Serial0
11. 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.

### Removing Static Routes

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.

1. Austin#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Austin(config)#no ip route 172.16.10.0 255.255.255.0 192.168.2.1
4. Austin(config)#<Ctrl-Z>
5. Austin#
6. <<<Figure 7-24 Removal of Static Route on Austin>>>

7. Dallas#configure terminal
8. Enter configuration commands, one per line. End with CNTL/Z.
9. Dallas(config)#no ip route 192.168.1.0 255.255.255.0 192.168.2.2
10. Dallas(config)#<Ctrl-Z>
11. Dallas#

<<<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.

## Dynamic Routing Protocols

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:

• RIP
• IGRP
• EIGRP
• OSPF

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:

• Indicate which routing protocol is being configured with the global configuration command router.
• Start the routing protocol on the appropriate interfaces with the router configuration command network.

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.

### RIP (Routing Information Protocol)

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 Version 1

• All subnets of a major, classful network address should use the same network mask.
• All subnets of a major, classful network address should be contiguous; they should touch each other.

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.

1. Dallas#show running-config
2. [text omitted]
3. !
4. router rip
5. network 172.16.0.0
6. !
7. [text omitted]
8. Dallas#
9. <<<Figure 7-26 Original Dallas RIP Configuration>>>

10. FortWorth#show running-config
11. [text omitted]
12. !
13. router rip
14. network 172.16.0.0
15. !
16. [text omitted]
17. FortWorth#
18. <<<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.

19. Dallas#configure terminal
20. Enter configuration commands, one per line. End with CNTL/Z.
21. Dallas(config)#router rip
22. Dallas(config-router)#network 192.168.2.0
23. Dallas(config-router)#<Ctrl-Z>
24. Dallas#
25. <<<Figure 7-28 Completion of Dallas RIP Configuration>>>

26. FortWorth#configure terminal
27. Enter configuration commands, one per line. End with CNTL/Z.
28. FortWorth(config)#router rip
29. FortWorth(config-router)#network 192.168.3.0
30. FortWorth(config-router)#<Ctrl-Z>
31. FortWorth#
32. <<<Figure 7-29 Completion of FortWorth RIP Configuration>>>

33. Austin#configure terminal
34. Enter configuration commands, one per line. End with CNTL/Z.
35. Austin(config)#router rip
36. Austin(config-router)#network 192.168.1.0
37. Austin(config-router)#network 192.168.2.0
38. Austin(config-router)#network 192.168.3.0
39. Austin(config-router)#<Ctrl-Z>
40. Austin#
41. <<<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.

42. Dallas#show ip protocols
43. Routing Protocol is "rip"
44. Sending updates every 30 seconds, next due in 9 seconds
45. Invalid after 180 seconds, hold down 180, flushed after 240
46. Outgoing update filter list for all interfaces is
47. Incoming update filter list for all interfaces is
48. Redistributing: rip
49. Default version control: send version 1, receive any version
50. Interface Send Recv Key-chain
51. Ethernet0 1 1 2
52. Serial0 1 1 2
53. Serial1 1 1 2
54. Routing for Networks:
55. 172.16.0.0
56. 192.168.2.0
57. Routing Information Sources:
58. Gateway Distance Last Update
59. 192.168.2.2 120 00:00:23
60. 172.16.11.2 120 00:00:21
61. Distance: (default is 120)
62. Dallas#
63. <<<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.

64. Dallas#show ip route
65. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
66. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
67. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
68. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
69. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
70. U - per-user static route, o - ODR
71. Gateway of last resort is not set
72. 172.16.0.0/24 is subnetted, 3 subnets
73. R 172.16.20.0 [120/1] via 172.16.11.2, 00:00:02, Serial1
74. C 172.16.10.0 is directly connected, Ethernet0
75. C 172.16.11.0 is directly connected, Serial1
76. R 192.168.1.0/24 [120/1] via 192.168.2.2, 00:00:00, Serial0
77. C 192.168.2.0/24 is directly connected, Serial0
78. R 192.168.3.0/24 [120/1] via 192.168.2.2, 00:00:00, Serial0
79. [120/1] via 172.16.11.2, 00:00:02, Serial1
80. Dallas#
81. <<<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.

82. FortWorth#show ip route
83. [text omitted]
84. 172.16.0.0/24 is subnetted, 3 subnets
85. C 172.16.20.0 is directly connected, Ethernet0
86. R 172.16.10.0 [120/1] via 172.16.11.1, 00:00:00, Serial0
87. C 172.16.11.0 is directly connected, Serial0
88. R 192.168.1.0/24 [120/1] via 192.168.3.2, 00:00:05, Serial1
89. R 192.168.2.0/24 [120/1] via 172.16.11.1, 00:00:00, Serial0
90. [120/1] via 192.168.3.2, 00:00:05, Serial1
91. C 192.168.3.0/24 is directly connected, Serial1
92. FortWorth#
93. <<<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.

94. Austin#show ip route
95. [text omitted]
96. R 172.16.0.0/16 [120/1] via 192.168.2.1, 00:00:06, Serial1
97. [120/1] via 192.168.3.1, 00:00:10, Serial0
98. C 192.168.1.0/24 is directly connected, Ethernet0
99. C 192.168.2.0/24 is directly connected, Serial1
100. C 192.168.3.0/24 is directly connected, Serial0
101. Austin#

<<<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

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.

• Interfaces with RIPv1 enabled send RIPv1 updates.
• Interfaces with RIPv1 enabled will receive both RIPv1 and RIPv2 updates by default, but RIPv1 will ignore the network mask and authentication in the RIPv2 updates.
• Interfaces with RIPv2 enabled send RIPv2 updates.
• Interfaces with RIPv2 enabled will receive only RIPv2 updates by default.

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.

1. Dallas#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Dallas(config)#router rip
4. Dallas(config-router)#version 2
5. Dallas(config-router)#<Ctrl-Z>
6. Dallas#
7. <<<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.

8. Dallas#configure terminal
9. Enter configuration commands, one per line. End with CNTL/Z.
10. Dallas(config)#router rip
11. Dallas(config-router)#no auto-summary
12. Dallas(config-router)#<Ctrl-Z>
13. Dallas#
14. <<<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.

15. FortWorth#show ip route
16. [text omitted]
17. 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
18. C 172.16.20.0/24 is directly connected, Ethernet0
19. R 172.16.10.0/24 [120/1] via 172.16.11.1, 00:00:17, Serial0
20. C 172.16.11.0/24 is directly connected, Serial0
21. R 172.16.0.0/16 [120/2] via 192.168.3.2, 00:00:23, Serial1
22. R 192.168.1.0/24 [120/1] via 192.168.3.2, 00:00:23, Serial1
23. R 192.168.2.0/24 [120/1] via 172.16.11.1, 00:00:17, Serial0
24. [120/1] via 192.168.3.2, 00:00:23, Serial1
25. C 192.168.3.0/24 is directly connected, Serial1
26. FortWorth#
27. <<<Figure 7-38 FortWorth IP Routing Table After Auto-Summarization Disabled on Dallas>>>

28. Austin#show ip route
29. [text omitted]
30. 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
31. R 172.16.20.0/24 [120/2] via 192.168.2.1, 00:00:01, Serial1
32. R 172.16.10.0/24 [120/1] via 192.168.2.1, 00:00:01, Serial1
33. R 172.16.11.0/24 [120/1] via 192.168.2.1, 00:00:01, Serial1
34. R 172.16.0.0/16 [120/1] via 192.168.3.1, 00:00:15, Serial0
35. C 192.168.1.0/24 is directly connected, Ethernet0
36. C 192.168.2.0/24 is directly connected, Serial1
37. C 192.168.3.0/24 is directly connected, Serial0
38. Austin#
39. <<<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.

40. Austin#show ip route
41. [text omitted]
42. 172.16.0.0/24 is subnetted, 3 subnets
43. R 172.16.20.0 [120/1] via 192.168.3.1, 00:00:07, Serial0
44. R 172.16.10.0 [120/1] via 192.168.2.1, 00:00:00, Serial1
45. R 172.16.11.0 [120/1] via 192.168.2.1, 00:00:00, Serial1
46. [120/1] via 192.168.3.1, 00:00:07, Serial0
47. C 192.168.1.0/24 is directly connected, Ethernet0
48. C 192.168.2.0/24 is directly connected, Serial1
49. C 192.168.3.0/24 is directly connected, Serial0
50. Austin#

<<<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.

### RIP Interface Customization

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.

1. FortWorth#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. FortWorth(config)#router rip
4. FortWorth(config-router)#passive-interface ethernet0
5. FortWorth(config-router)#<Ctrl-Z>
6. FortWorth#
7. <<<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.

8. Austin#configure terminal
9. Enter configuration commands, one per line. End with CNTL/Z.
10. Austin(config)#interface ethernet0
11. Austin(config-if)#ip rip send version 1
12. Austin(config-if)#<Ctrl-Z>
13. Austin#

<<<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.

### RIP Configuration Summary

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.

1. Dallas#show running-config
2. [text omitted]
3. !
4. router rip
5. version 2
6. network 172.16.0.0
7. network 192.168.2.0
8. no auto-summary
9. !
10. [text omitted]
11. Dallas#
12. <<<Figure 7-43 Dallas RIP-Specific Configuration Commands>>>

13. FortWorth#show running-config
14. [text omitted]
15. !
16. router rip
17. passive-interface Ethernet0
18. network 172.16.0.0
19. network 192.168.3.0
20. !
21. [text omitted]
22. FortWorth#
23. <<<Figure 7-44 FortWorth RIP-Specific Configuration Commands>>>

24. Austin#show running-config
25. [text omitted]
26. !
27. interface Ethernet0
28. ip rip send version 1
29. [text omitted]
30. !
31. router rip
32. version 2
33. network 192.168.1.0
34. network 192.168.2.0
35. network 192.168.3.0
36. no auto-summary
37. !
38. [text omitted]
39. Austin#

<<<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.

### RIP Removal

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.

1. Dallas#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Dallas(config)#no router rip
4. Dallas(config)#<Ctrl-Z>
5. 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 (Interior Gateway 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:

• Bandwidth
• Delay
• Reliability

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.

1. FortWorth#show interfaces ethernet0
2. Ethernet0 is up, line protocol is up
3. Hardware is Lance, address is 0010.7b3a.d4af (bia 0010.7b3a.d4af)
5. MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
6. [text omitted]
7. FortWorth#

<<<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.

### IGRP Configuration

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.

1. Dallas#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Dallas(config)#router igrp 100
4. Dallas(config-router)#network 172.16.0.0
5. Dallas(config-router)#network 192.168.2.0
6. Dallas(config-router)#<Ctrl-Z>
7. Dallas#
8. <<<Figure 7-48 IGRP Configuration on Dallas>>>

9. FortWorth#configure terminal
10. Enter configuration commands, one per line. End with CNTL/Z.
11. FortWorth(config)#router igrp 100
12. FortWorth(config-router)#network 172.16.0.0
13. FortWorth(config-router)#network 192.168.3.0
14. FortWorth(config-router)#<Ctrl-Z>
15. FortWorth#
16. <<<Figure 7-49 IGRP Configuration on FortWorth>>>

17. Austin#configure terminal
18. Enter configuration commands, one per line. End with CNTL/Z.
19. Austin(config)#router igrp 100
20. Austin(config-router)#network 192.168.1.0
21. Austin(config-router)#network 192.168.2.0
22. Austin(config-router)#network 192.168.3.0
23. Austin(config-router)#<Ctrl-Z>
24. Austin#

<<<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.

### IGRP Verification

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.

1. Dallas#show ip protocols
2. Routing Protocol is "igrp 100"
3. Sending updates every 90 seconds, next due in 32 seconds
4. Invalid after 270 seconds, hold down 280, flushed after 630
5. Outgoing update filter list for all interfaces is
6. Incoming update filter list for all interfaces is
7. Default networks flagged in outgoing updates
8. Default networks accepted from incoming updates
9. IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
10. IGRP maximum hopcount 100
11. IGRP maximum metric variance 1
12. Redistributing: igrp 100
13. Routing for Networks:
14. 172.16.0.0
15. 192.168.2.0
16. Routing Information Sources:
17. Gateway Distance Last Update
18. 192.168.2.2 100 00:00:24
19. 172.16.11.2 100 00:00:24
20. Distance: (default is 100)
21. Dallas#
22. <<<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.

23. Dallas#show ip route
24. [text omitted]
25. 172.16.0.0/24 is subnetted, 3 subnets
26. I 172.16.20.0 [100/8576] via 172.16.11.2, 00:00:30, Serial1
27. C 172.16.10.0 is directly connected, Ethernet0
28. C 172.16.11.0 is directly connected, Serial1
29. I 192.168.1.0/24 [100/41162] via 192.168.2.2, 00:00:09, Serial0
30. C 192.168.2.0/24 is directly connected, Serial0
31. I 192.168.3.0/24 [100/182571] via 172.16.11.2, 00:00:30, Serial1
32. [100/182571] via 192.168.2.2, 00:00:09, Serial0
33. Dallas#
34. <<<Figure 7-52 Dallas IP Routing Table After IGRP Configuration>>>

35. FortWorth#show ip route
36. [text omitted]
37. 172.16.0.0/24 is subnetted, 3 subnets
38. C 172.16.20.0 is directly connected, Ethernet0
39. I 172.16.10.0 [100/8576] via 172.16.11.1, 00:00:53, Serial0
40. C 172.16.11.0 is directly connected, Serial0
41. I 192.168.1.0/24 [100/43162] via 172.16.11.1, 00:00:53, Serial0
42. I 192.168.2.0/24 [100/43062] via 172.16.11.1, 00:00:53, Serial0
43. C 192.168.3.0/24 is directly connected, Serial1
44. FortWorth#
45. <<<Figure 7-53 FortWorth IP Routing Table After IGRP Configuration>>>

46. Austin#show ip route
47. [text omitted]
48. I 172.16.0.0/16 [100/41162] via 192.168.2.1, 00:00:27, Serial1
49. C 192.168.1.0/24 is directly connected, Ethernet0
50. C 192.168.2.0/24 is directly connected, Serial1
51. C 192.168.3.0/24 is directly connected, Serial0
52. Austin#

<<<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).

### Verifying Connectivity With Trace

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.

1. Austin#trace 172.16.20.1
2. Type escape sequence to abort.
3. Tracing the route to 172.16.20.1
4. 1 192.168.2.1 4 msec 4 msec 8 msec
5. 2 172.16.11.2 12 msec * 8 msec
6. 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 Configuration Summary

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.

1. Dallas#show running-config
2. [text omitted]
3. !
4. router igrp 100
5. network 172.16.0.0
6. network 192.168.2.0
7. !
8. [text omitted]
9. Dallas#
10. <<<Figure 7-56 Dallas IGRP-Specific Configuration Commands>>>

11. FortWorth#show running-config
12. [text omitted]
13. !
14. router igrp 100
15. network 172.16.0.0
16. network 192.168.3.0
17. !
18. [text omitted]
19. FortWorth#
20. <<<Figure 7-57 FortWorth IGRP-Specific Configuration Commands>>>

21. Austin#show running-config
22. [text omitted]
23. !
24. router igrp 100
25. network 192.168.1.0
26. network 192.168.2.0
27. network 192.168.3.0
28. !
29. [text omitted]
30. Austin#

<<<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.

### IGRP Removal

The removal of IGRP requires a single global configuration command on each router. Figure 7-59 shows the removal of IGRP on Dallas.

1. Dallas#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Dallas(config)#no router igrp 100
4. Dallas(config)#<Ctrl-Z>
5. 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 (Enhanced IGRP)

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.

### Comparison with IGRP

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.

### EIGRP Terminology and Operation

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.

### EIGRP Configuration

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.

1. Dallas#configure terminal
2. Enter configuration commands, one per line. End with CNTL/Z.
3. Dallas(config)#router eigrp 100
4. Dallas(config-router)#network 172.16.0.0
5. Dallas(config-router)#network 192.168.2.0
6. Dallas(config-router)#<Ctrl-Z>
7. Dallas#
8. <<<Figure 7-60 EIGRP Configuration on Dallas>>>

9. FortWorth#configure terminal
10. Enter configuration commands, one per line. End with CNTL/Z.
11. FortWorth(config)#router eigrp 100
12. FortWorth(config-router)#network 172.16.0.0
13. FortWorth(config-router)#network 192.168.3.0
14. FortWorth(config-router)#<Ctrl-Z>
15. FortWorth#
16. <<<Figure 7-61 EIGRP Configuration on FortWorth>>>

17. Austin#configure terminal
18. Enter configuration commands, one per line. End with CNTL/Z.
19. Austin(config)#router eigrp 100
20. Austin(config-router)#network 192.168.1.0
21. Austin(config-router)#network 192.168.2.0
22. Austin(config-router)#network 192.168.3.0
23. Austin(config-router)#<Ctrl-Z>
24. Austin#
25. <<<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.

26. FortWorth#configure terminal
27. Enter configuration commands, one per line. End with CNTL/Z.
28. FortWorth(config)#router eigrp 100
29. FortWorth(config-router)#passive-interface ethernet0
30. FortWorth(config-router)#<Ctrl-Z>
31. 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.

### EIGRP Verification

Now that EIGRP has been started, there are a few commands that we can use to check its operation. The commands are as follows:

• show ip protocols
• show ip eigrp neighbors
• show ip eigrp topology
• show ip route
• show ip eigrp traffic

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.

1. Dallas#show ip protocols
2. Routing Protocol is "eigrp 100"
3. Outgoing update filter list for all interfaces is
4. Incoming update filter list for all interfaces is
5. Default networks flagged in outgoing updates
6. Default networks accepted from incoming updates
7. EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
8. EIGRP maximum hopcount 100
9. EIGRP maximum metric variance 1
10. Redistributing: eigrp 100
11. Automatic network summarization is in effect
13. 192.168.2.0/24 for Ethernet0, Serial1
14. 172.16.0.0/16 for Serial0
15. Summarizing with metric 281600
16. Routing for Networks:
17. 172.16.0.0
18. 192.168.2.0
19. Routing Information Sources:
20. Gateway Distance Last Update
21. (this router) 5 00:00:30
22. 192.168.2.2 90 00:00:30
23. 172.16.11.2 90 00:00:30
24. Distance: internal 90 external 170
25. Dallas#
26. <<<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.

27. Dallas#show ip eigrp neighbors
28. IP-EIGRP neighbors for process 100
29. H Address Interface Hold Uptime SRTT RTO Q Seq
30. (sec) (ms) Cnt Num
31. 1 172.16.11.2 Se1 12 00:03:53 324 1944 0 5
32. 0 192.168.2.2 Se0 10 00:04:35 797 4782 0 6
33. Dallas#
34. <<<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.

35. Dallas#show ip eigrp topology
36. IP-EIGRP Topology Table for process 100
37. Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
39. P 192.168.1.0/24, 1 successors, FD is 10537472
40. via 192.168.2.2 (10537472/281600), Serial0
41. P 192.168.2.0/24, 1 successors, FD is 10511872
42. via Connected, Serial0
43. P 192.168.3.0/24, 2 successors, FD is 46738176
44. via 192.168.2.2 (46738176/46226176), Serial0
45. via 172.16.11.2 (46738176/46226176), Serial1
46. P 172.16.20.0/24, 1 successors, FD is 2195456
47. via 172.16.11.2 (2195456/281600), Serial1
48. P 172.16.10.0/24, 1 successors, FD is 281600
49. via Connected, Ethernet0
50. P 172.16.11.0/24, 1 successors, FD is 2169856
51. via Connected, Serial1
52. P 172.16.0.0/16, 1 successors, FD is 281600
53. via Summary (281600/0), Null0
54. Dallas#
55. <<<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