Chapter: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Cisco IOS Essentials
John Albritton, CCIE
 $55.00  0-07-134743-7
Backward Forward

Reserve your copy at a
Bet@ Bookstore near you!
Contact Bet@ Books
© 1999 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use.

Chapter 7

  1. Configuring IP
  2. 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.

    1. IP Addressing

All hosts that run IP must have a unique IP address. An IP address is a logical address that is independent of a hostís hardware. IP addressing is perhaps the most mystifying part of IP for people who are new to the networking world; however, it really is very simple. To understand, you just need to use a little bit of binary (base 2) arithmetic and decimal (base 10) arithmetic.

IP addresses are 32 bits long, and the normal way of writing them is called dotted-decimal notation. To write an address in dotted-decimal notation, we divide the 32 bits of the address into four 8-bit chunks. Each 8-bit chunk is called an octet or a byte. We then convert the octets from binary to decimal and put dots (.) between them. Figure 7-1 shows four forms of the same IP host address.

<<<J115 Ė Figure 7-1 IP Address Notations>>>

The first form in Figure 7-1 is normal binary, just a string of 32 ones and zeros; each one and zero is a bit. This form is difficult for people to read, but it is what a computer, like a router, sees. The decimal representation of the binary address has a rather large value; 32 bits can represent decimal numbers between 0 and 4,294,967,295. The second line is the decimal equivalent of the first line. How would you like to read a number like that every time you wanted to communicate a host address to someone?

The third line of Figure 7-1 is just an intermediate step toward the last line, with the 32 bits divided into four octets. The last form, dotted-decimal notation, is the one that we use, and it is the easiest to read and write.

Since each of the four quarters (octets) of an IP address is eight bits and the decimal values that can be represented with eight bits range from 0 to 255, the value of any one of the numbers in a dotted-decimal IP address cannot exceed 255.

IP addresses have two main parts Ė a network part that identifies the network where a host resides and a node part that identifies a specific host on the network (sort of like a street name and a house number). The network and node parts together make up the full IP address of a host. The network part is used by routing software to determine for which network a packet is destined. The node part is used by routing software to send a packet to an individual host once the packet has reached the hostís network. Just to make this a little more exciting, the line between network and node moves.

There are three things that can be used to tell which part of an address is network and which part of an address is node. These are as follows:

The network mask explicitly specifies which part of an IP address represents a network. The network mask is 32 bits long and is normally written in dotted-decimal notation just like an address. An IP address and mask are usually written together, with the mask immediately after the address.

A network mask has binary ones in the bit positions that represent the network part of an address and binary zeros in the bit positions that represent the node part of an address. The binary ones must start from the left (most-significant) side of the mask and extend contiguously (They must be side by side.) until the network part ends; the rest of the mask must be all zeros. For example, the mask

255.255.255.0

when paired with an IP address, would tell us that the first 24 bits of the address is considered network and the last eight bits are node. This becomes clear when the binary equivalent of this mask is examined as shown below:

11111111 11111111 11111111 00000000 (Binary)

255 . 255 . 255 . 0 (Dotted-Decimal)

We see that the mask has 24 ones, starting from the left, and eight zeros. Let us apply this mask to the IP address in Figure 7-1.

11000000 10101000 10000001 01100011 (Address)

11111111 11111111 11111111 00000000 (Mask)

Since the mask indicates that the first 24 bits of the address are the network, the network address must be

11000000 10101000 10000001 01100011

192 . 168 . 129 . 0

An IP address that has binary zeros in all of the node bits represents a network, not a host. An IP address that has binary ones in all of the node bits represents all of the hosts on a network; this is called a broadcast address. The broadcast address of the 192.168.129.0 network in the above example is:

10101100 00010000 10000001 11111111

192 . 168 . 129 . 255

The node values between all zeros and all ones identify individual hosts on a network. Therefore, the 192.168.129.0 255.255.255.0 network can have hosts with addresses between 192.168.129.1 and 192.168.129.254. That is 254 valid host addresses on this particular network. Figure 7-2 shows the simple formula for calculating the number of valid host addresses on a network.

<<<J117 Ė Figure 7-2 Network Hosts Formula>>>

Applying this formula to our running example with eight node bits has the following results:

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.

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

For example, in our mask, the last non-zero octet is the fourth octet and its value is 224. Subtracting 224 from 256 yields 32. The subnet seed is 32, and all of the subnet addresses are multiples of 32 in the fourth octet. The network addresses of our six subnets are as follows:

That is six subnets just like Figure 7-5 indicated. The first and last combinations of the three subnets are not normally used, even though they can be used. These combinations yield subnet addresses 192.168.129.0 and 192.168.129.224. We will call these the zero subnet and the all-ones subnet, respectively. IOS will support the use of these special subnets, but not all other hosts will; therefore, to be safe, we are not including them here.

The broadcast address of each subnet is the address one less that the next higher subnet. For example, the broadcast address of the 192.168.129.96 subnet is 192.168.129.127. Remember that the valid host addresses for a network or subnet are those addresses between the networkís address and its broadcast address; therefore, the valid host addresses for the 192.168.129.96 255.255.255.224 network range from 192.168.129.97 through 192.168.129.126. That is 30 hosts just like we calculated.

Our example IP host address, 192.168.129.99, is in this range; therefore, it is a host on the 192.168.129.96/27 subnet. We could have just calculated this by using a calculation similar to the one we used to calculate the subnet addresses. The last non-zero value in the network mask is 224 is in the fourth octet. Dividing the fourth octet of the host address (99) by the subnet seed (32) gives a result of 3 (never mind the remainder). Multiplying the result (3) by the seed (32) yields the subnet addressí fourth octet value (96).

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

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.

    1. IP Overview
    2. 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.

      1. Layers 1 and 2
      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.

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

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

The source IP address is the 32-bit IP address of the host that originated the packet. The destination IP address is the 32-bit IP address that routers examine to determine where to route a packet. The destination IP address can be a unicast host address, a broadcast address, or a multicast address. Neither the source IP address nor the destination IP address normally changes from the time a packet leaves a host to the time the packet arrives at its destination.

The time to live (TTL) field in a packetís IP header is decremented each time the packet is routed by a router. The use of TTL keeps a packet from being routed endlessly on an internetwork when its destination cannot be found. When a router decrements a packetís TTL to zero (0), the router must drop the packet. The router can then send an ICMP message to the packetís source indicating the reason the packet was dropped (TTL exceeded). The TTL field has a maximum value of 255; therefore, in theory, if the source host sent a packet with a beginning TTL of 255, the packet could get routed 255 times before it got dropped.

The protocol number identifies the next level protocol, that is, what is after the IP header in the packet. Following are some examples of items that could follow the IP header and their associated protocol numbers:

TCP Header Ė Protocol Number 6

UDP Header Ė Protocol Number 17

ICMP Message Ė Protocol Number 1

IGRP Message Ė Protocol Number 9

Upper-layer applications usually use TCP or UDP, but before a host gets to the application data, it must read a TCP or UDP header. TCP and UDP are probably the most used protocol numbers.

        1. Address Resolution Protocol (ARP)

Hosts use ARP to acquire the MAC address of another host to which a frame is being transmitted. This is done during the frame encapsulation process. A source host presumably would already know the IP address of a destination host and would be able to build the layer-3 (IP) header containing both source and destination IP addresses. However, the source host also must build a frame header for encapsulation of the packet on a LAN. The frame header contains the source and destination MAC addresses. The source host knows its own MAC address, but it needs to know the destination hostís MAC address to complete the frame header.

The source host locates a destination hostís MAC address by sending a layer-2 broadcast frame onto the LAN asking for the MAC address associated with a given IP address; this frame is called an ARP request. Every host on a network examines a layer-2 broadcast frame. If the destination host is on the network, it will recognize the IP address in the ARP request frame and send an ARP reply to the source host. The ARP reply contains the destination hostís MAC address that the source host uses to complete the frame header. The source host also puts the destination hostís MAC address and IP address into a table, called the ARP cache. The next time the source host wants to send a frame to the destination host, it can just look up the destination hostís MAC address in the ARP cache and not send the ARP request.

If a router receives an ARP request for a destination host on a network other than the one on which the request was received, the router can reply on behalf of the destination host. The source host receives an ARP reply containing the router interfaceís MAC address, thus instructing the source host to send its frame to the router to be routed. The feature, called proxy ARP, is enabled by default in IOS, but we can disable it if we desire.

ARP is extremely important in IP-based networks. Some textbooks call ARP a layer-2 protocol because its messages are never routed at layer 3. ARP is included at layer 3 here only because the ARP messages follow the layer-2 header.

      1. Layer 4
      2. 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.

        1. Transmission Control Protocol (TCP)
        2. 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.

        3. User Datagram Protocol (UDP)
        4. 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.

        5. Internet Control and Messaging Protocol (ICMP
        6. 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.

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

      3. Layers 5, 6, and 7
      4. 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.

        1. TCP Applications

TCP applications that can run on IOS include:

Telnet is a remote session application that is used to when configuring a remote router. rcp is a file copy application that can be used to copy files to and from a Cisco router. HTTP is the application used to transfer World Wide Web (WWW) pages from web servers to web clients (browsers).

        1. UDP Applications

UDP applications that can run on IOS include:

TFTP is a file copy application that is used to copy files to and from a Cisco router. SNMP is a network management application used to monitor and manage network devices, and DNS is the application used to translate host names to IP addresses and vice versa.

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

    1. Configuring IP on an Interface
    2. The command to tell IOS to route IP packets on an interface is:

      ip address address mask

      where address is the IP address, in dotted-decimal notation, that should be assigned to the interface, and mask is the addressí network mask in dotted-decimal notation. The ip address command is an interface configuration mode and subinterface configuration mode command. This makes sense because we must specify the interface that will get the address before we assign the address.

      The address specified with this command becomes the primary IP address for an interface. To change an interfaceís IP address, we can just type this command again in interface configuration mode with the new IP address and mask.

      The ip address command will be used in the next section when we add a router to our test internetwork.

    3. Adding a Router

We already have an internetwork configured to route IP traffic. We configured this internetwork of two routers, Dallas and FortWorth, in Chapter 3 using the System Configuration Dialog. Figure 7-8 shows the existing internetworkís IP configuration.

<<<J112 Ė Figure 7-8 Two-Router IP Internetwork>>>

The current routing table for Dallas is shown in Figure 7-7. The two routers are using the RIP routing protocol to exchange information about their networks.

To illustrate the configuration of IP, we are going to add a router to the internetwork and do its configuration from scratch using the IOS command line interface. The new internetwork of three routers is shown in Figure 7-9. We are going to add a router named Austin, and this three-router internetwork will be used for most of the examples throughout the rest of this book.

<<<J110 Ė Figure 7-9 Three-Router IP Internetwork with Interface Addresses>>>

Austin has a 256 kbps leased line to Dallas and a 56 kbps leased line to FortWorth. Figure 7-9 has the IP addresses of each of the new interfaces that we will be using to connect Austin into the internetwork. Notice that abbreviations for the interfaces are being used to conserve space; Ethernet is E, and Serial is S.

The implementation of Austin will be done using the following steps:

Dallas and FortWorth already have working configurations; therefore, they each need only one interface configured. Austin will be booted with no startup configuration, and we will answer No to the initial configuration dialog question (see Section 3.5.1) to avoid entering the System Configuration Dialog.

      1. 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
    4. Dallas(config-if)#ip address 192.168.2.1 255.255.255.0
    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.

      1. 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
    4. FortWorth(config-if)#ip address 192.168.3.1 255.255.255.0
    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.

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

Press RETURN to get started!

When we do not run the System Configuration Dialog on a new router, the result is a running configuration that essentially does nothing useful. The router has the default name Router; all of the interfaces are shut down (administratively down state), and there are no passwords. We will start from the user mode prompt and configure the host name, the passwords, and the interfaces. All of the commands for accomplishing this are shown in Figure 7-12.

    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
    6. Austin(config)#enable password enableme
    7. Austin(config)#line vty 0 4
    8. Austin(config-line)#password letmein
    9. Austin(config-line)#login
    10. Austin(config-line)#line con 0
    11. Austin(config-line)#password letmein
    12. Austin(config-line)#login
    13. Austin(config-line)#interface ethernet0
    14. Austin(config-if)#ip address 192.168.1.1 255.255.255.0
    15. Austin(config-if)#description Austin Ethernet LAN
    16. Austin(config-if)#no shutdown
    17. Austin(config-if)#interface serial0
    18. Austin(config-if)#ip address 192.168.3.2 255.255.255.0
    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
    23. Austin(config-if)#ip address 192.168.2.2 255.255.255.0
    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).

Every router needs passwords; therefore, we will take the opportunity to define them. The two types of enable passwords are configured first. The enable secret password is set with the enable secret command (Line 5), and the regular enable password is set with the enable password command (Line 6). The passwords for the five VTY terminal lines, 0 through 4, must be defined in line configuration mode, so we issue the line vty 0 4 command (Line 7) indicating to IOS that the next commands are to be applied to all of the VTYís. Once in line configuration mode, we assign the VTY passwords with the password command (Line 8) and allow logins with the login command (Line 9). If the VTYís do not have passwords, no one will be able to establish a telnet connection to Austin. The last password is the one for the console. The console is another terminal line device so we type the line con 0 command (Line 10) to go to line configuration mode for the console. The line command is a global configuration command; therefore, it can be typed in any configuration mode. We used the line command in line configuration mode, and IOS just changed the line we were configuring. The command prompt did not change; it is very important to realize that IOS did not tell us that we are configuring a different line; we must be aware of what we are doing. Console password authentication is enabled with the password command (Line 11) and the login command (Line 12).

To configure an interface, we must be in interface configuration mode; the interface command is used to put us there. Just like the line command, interface is a global configuration command and can be used in any configuration mode. The interface ethernet0 command (Line 13) informs IOS that we wish to enter interface configuration mode and type commands that affect Ethernet0. From there, we assign the IP address (Line 14) and description (Line 15) for Ethernet0. The no shutdown command (Line 16) activates the interface.

The configurations of Serial0 (Lines 17 through 21) and Serial1 (Lines 22 through 26) are similar to that of Ethernet0 except for the bandwidth commands that set the informational bandwidth parameter to an appropriate value for each interface. The IP addresses for the three interfaces were taken directly from Figure 7-9.

We could have done most of this configuration with the System Configuration Dialog. Typing the commands on the command line is usually faster than answering questions even though the command line may not be quite as intuitive. The command line does not limit what we can do. The System Configuration Dialog cannot be used to set a console password, define an interfaceís bandwidth, or define an interfaceís description. Since we wanted to perform those functions, we had to use the command line anyway. So why not just do it all from the command line?

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

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

      The command to add the static route is on Line 3. The network address of the Dallas Ethernet LAN is 172.16.10.0/24; therefore, the network entry we want to add to the routing table has the address 172.16.10.0 and the network mask 255.255.255.0. The ip route command requires the network mask; the prefix length cannot be used. The last address on the command is the address of the next hop gateway. The gateway is the address of the router to which Austin should send packets destined for the indicated network. The gateway address should be on a network that is already in the Austin routing table. In this case, the gateway address is the Dallas Serial0 interface, which is directly connected to Austin. Austinís new routing table is shown in Figure 7-18.

    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.

      1. 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>
    10. Target IP address: 172.16.10.1
    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.

      1. Adding More Static Routes

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.

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

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

These routing protocols are called interior routing protocols. They are meant to be run on routers under a common administration.

The first thing that we must do before configuring a routing protocol is to determine which one best suits our needs. If we want a routing protocol that is very simple and supported by just about every IP router on the market, then RIP may be the choice. If we need a routing protocol that will work well in a large internetwork of several hundred routers, then EIGRP or OSPF may be the choice unless some of those routers are not Cisco routers; then OSPF may be the choice.

Regardless of which one is chosen, we should be consistent with its configuration on our routers. IOS can run more than one IP routing protocol, but that usually requires extra configuration and extra maintenance.

The two steps for configuring an IP routing protocol are as follows:

The forms of the router and network commands differ slightly from one routing protocol to another. We will see those differences in the coming sections as we start with RIP and migrate through each of the routing protocols.

      1. RIP (Routing Information Protocol)
      2. 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.

        1. RIP Version 1

RIP updates are sent to the IP broadcast address that is configured on an interface; the default IP broadcast address is 255.255.255.255. RIP does not include in its updates the network mask or prefix length for a network address being advertised; this makes RIP a classful routing protocol. When RIP advertises a subnet of a network out an interface that is not another subnet of the same network, RIP summarizes the subnets of the network as the classful network address. This feature is called auto-summarization, and we cannot turn it off. Because of these features, one should adhere to the following subnetting rules when addressing networks in an internetwork running RIP.

Major, classful network address refers to a class A address, a class B address, or a class C address.

Two of our routers, Dallas and FortWorth, are already running RIP. We will look at their RIP configurations to explain the command, and then we will complete the configuration to include Austin. Figure 7-26 shows the RIP configuration on Dallas, and Figure 7-27 shows the RIP configuration on FortWorth.

    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.

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

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.

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

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

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

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

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)
    4. Internet address is 172.16.20.1/24
    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.

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

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

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

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

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

      1. EIGRP (Enhanced IGRP)
      2. 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.

        1. Comparison with IGRP
        2. 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.

        3. EIGRP Terminology and Operation
        4. 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.

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

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

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
    12. Automatic address summarization:
    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,
    38. r - Reply status
    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 table for Austin.

    56. Dallas#show ip route
    57. [text omitted]
    58. 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
    59. D 172.16.20.0/24 [90/2195456] via 172.16.11.2, 00:02:29, Serial1
    60. C 172.16.10.0/24 is directly connected, Ethernet0
    61. C 172.16.11.0/24 is directly connected, Serial1
    62. D 172.16.0.0/16 is a summary, 00:02:29, Null0
    63. D 192.168.1.0/24 [90/10537472] via 192.168.2.2, 00:02:29, Serial0
    64. C 192.168.2.0/24 is directly connected, Serial0
    65. D 192.168.3.0/24 [90/46738176] via 192.168.2.2, 00:02:29, Serial0
    66. [90/46738176] via 172.16.11.2, 00:02:29, Serial1
    67. Dallas#
    68. <<<Figure 7-67 IP Routing Table on Dallas After EIGRP Configuration>>>

      When EIGRP is running, the EIGRP-learned routes have a D displayed in the left column of their routing table entries (for example, Line 4). The first number within the brackets, on the entries for routes that are not directly connected, shows that the EIGRP-learned routes have an administrative distance of 90. Whenever a router is running EIGRP and summarization is being done, IOS creates a local summary route for the route being summarized (Line 7). The local summary route points to the Null0 interface. The Null0 interface is a logical interface that goes nowhere; some people may refer to this as the bit bucket. If Dallas were to get a packet destined for a non-existent subnet of the 172.16.0.0 network, for example, 172.16.33.0, the packet would be routed to the Null0 interface and dropped, even if a default route existed. Dallas would also send an ICMP destination (host) unreachable message back to the source of the original packet. If we were to turn off auto-summarization, the local summary route would be removed.

    69. FortWorth#show ip route
    70. [text omitted]
    71. 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
    72. C 172.16.20.0/24 is directly connected, Ethernet0
    73. D 172.16.10.0/24 [90/2195456] via 172.16.11.1, 00:00:56, Serial0
    74. C 172.16.11.0/24 is directly connected, Serial0
    75. D 172.16.0.0/16 is a summary, 00:00:56, Null0
    76. D 192.168.1.0/24 [90/11049472] via 172.16.11.1, 00:00:56, Serial0
    77. D 192.168.2.0/24 [90/11023872] via 172.16.11.1, 00:00:56, Serial0
    78. C 192.168.3.0/24 is directly connected, Serial1
    79. FortWorth#
    80. <<<Figure 7-68 IP Routing Table on FortWorth After EIGRP Configuration>>>

      FortWorthís new IP routing table also contains the local summary route to the Null0 interface (Line 7). With exception of the summary route, the network addresses in the routing table are the same as the ones we saw when the routers were running IGRP (Figure 7-53). In Figure 7-53, the metric for the IGRP-learned route to the 172.16.10.0/24 network is 8576. The metric for the EIGRP-learned route is 2195456 (Line 5). When we multiply the value 8576 by 256, the result is 2195456. Remember the EIGRP composite metric uses the same parameters as the IGRP metric multiplied by 256.

    81. Austin#show ip route
    82. [text omitted]
    83. D 172.16.0.0/16 [90/10537472] via 192.168.2.1, 00:02:09, Serial1
    84. C 192.168.1.0/24 is directly connected, Ethernet0
    85. C 192.168.2.0/24 is directly connected, Serial1
    86. C 192.168.3.0/24 is directly connected, Serial0
    87. Austin#
    88. <<<Figure 7-69 IP Routing Table on Austin After EIGRP Configuration>>>

      Austinís IP routing table contains the summary route, 172.16.0.0/16, that is being advertised by Dallas (Figure 7-69, Line 3). FortWorth is also advertising the summary route, but the path to Dallas has a lower metric and is, thus, preferred. Austin has no local summary route to the Null0 interface because Austin is not directly connected to any subnets of major network addresses and is not actively summarizing its routes to Dallas and FortWorth.

      We use the show ip eigrp traffic command to check the number of packets being processed by EIGRP. Figure 7-70 shows the output of the show ip eigrp traffic command on Dallas.

    89. Dallas#show ip eigrp traffic
    90. IP-EIGRP Traffic Statistics for process 100
    91. Hellos sent/received: 303/154
    92. Updates sent/received: 13/10
    93. Queries sent/received: 1/0
    94. Replies sent/received: 0/1
    95. Acks sent/received: 5/6
    96. Input queue high water mark 1, 0 drops
    97. Dallas#

<<<Figure 7-70 Show IP EIGRP Traffic Output>>>

The number of times each type of EIGRP packet was transmitted and received is given in the output. The packet types were covered in Section 7.7.3.2. In a stable network, the number of Hello packets (Line 3) should steadily increase since they are transmitted and received periodically. The other counters should not change very much unless a network is in transition.

        1. EIGRP Configuration Summary

EIGRP configuration, at least getting it started, is very similar to that of RIP and IGRP. EIGRP is configured by entering the router eigrp command with an ASN in global configuration mode and then the appropriate network commands for enabling EIGRP on the interfaces. Just as with IGRP, all of the routers that use EIGRP to share information must have the same ASN. To stop updates on an interface, issue the passive-interface command, with the interface name, in router configuration mode for the EIGRP process. The router configuration command no auto-summary can be used to turn off auto-summarization for an EIGRP process.

The EIGRP-specific configuration commands, from the running configurations, entered for Dallas, FortWorth, and Austin are shown in Figure 7-71, Figure 7-72, and Figure 7-73, respectively.

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

    11. FortWorth#show running-config
    12. [text omitted]
    13. !
    14. router eigrp 100
    15. passive-interface Ethernet0
    16. network 172.16.0.0
    17. network 192.168.3.0
    18. !
    19. [text omitted]
    20. FortWorth#
    21. <<<Figure 7-72 FortWorth EIGRP-Specific Configuration Commands>>>

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

<<<Figure 7-73 Austin EIGRP-Specific Configuration Commands>>>

EIGRP is very easy to turn on. IOS hides most of its complexity from us.

        1. EIGRP Removal

The removal of an IP routing protocol is almost too easy. It requires a single global configuration command on each router. Figure 7-74 shows the removal of EIGRP on Dallas.

    1. Dallas#configure terminal
    2. Enter configuration commands, one per line. End with CNTL/Z.
    3. Dallas(config)#no router eigrp 100
    4. Dallas(config)#<Ctrl-Z>
    5. Dallas#

<<<Figure 7-74 Removal of EIGRP>>>

The no router eigrp 100 command (Line 3) removes all of the EIGRP-specific commands from the running configuration. After issuing the command on all three of our test routers, our internetwork is once again left without an IP routing protocol and is awaiting the configuration of another.

Remember that whenever EIGRP is referenced in configuration mode, the ASN must be included with it to uniquely identify the EIGRP process.

      1. OSPF (Open Shortest Path First)
      2. OSPF is an open standard, link state routing protocol. (See Section 2.2.2.2 for an overview of link state routing protocols.) OSPF was developed by the Internet Engineering Task Force (IETF), and its latest version, 2, is defined in RFC 2328.

        Similar to EIGRP, OSPF is classless, has a very fast convergence time and is complicated, both in operation and in configuration, just as one would expect from something developed by a committee. The following coverage provides just a glimpse into its complexity.

        1. OSPF Terminology and Operation

The nature of OSPF practically requires that some type of hierarchy be designed into an internetwork. The hierarchy can be either physical or logical.

We build a hierarchy of an internetwork running OSPF by defining areas. An area is a logical group of routers and networks. Each area has its own numeric identifier (ID). An area ID is a 32-bit value that can be written as either a decimal number or a dotted-decimal value, like an IP address. A router can be attached to multiple areas, but a network should be a part of only one area. If an OSPF network has multiple areas, one of the areas must be area 0 (or 0.0.0.0). Area 0 is the backbone area, and inter-area traffic (traffic between areas) flows through the backbone area. The backbone area should consist of stable networks. The areas of an OSPF internetwork are collectively referred to as an autonomous system.

A router with connections to multiple areas is called an Area Border Router (ABR). A router with connections to a single area is called an internal router, and a router that connects to another autonomous system is called an Autonomous System Boundary Router (ASBR).

Each router running OSPF gets a dynamically assigned router ID (RID); the router ID is derived from the IP address of one of a routerís active interfaces and is assigned when OSPF is started. If a router has a loopback interface with an IP address configured, the router ID is the IP address of loopback interface, or the highest loopback interface IP address if there are multiple loopback interfaces. If there are no loopback interfaces, the router ID is the highest IP address that is assigned to one of the other routerís active interfaces. An active interface is one that is in an up/up state. Loopback interfaces are logical interfaces that we create; they do not go down unless we manually shut them down. A routerís OSPF RID will change if the interface from which it was derived goes down.

All routers running OSPF transmit and save Link State Advertisements (LSA) in a link state database. There are many types of LSAís; the most basic ones are described in the next few paragraphs. All of the routers within an area must contain identical LSAís in their databases for the area, or areas, to which they are connected. Routers transmit LSAís when a network changes state and periodically at 30 minute intervals. The retransmission every 30 minutes happens because each LSA in the link state database must be refreshed every 90 minutes. Routers must acknowledge all valid LSAís that they receive.

A router LSA is one that is generated by each router in an OSPF autonomous system; it contains information about an individual router such as its RID and the links (for example, networks) to which it is attached. Router LSAís are propagated, or flooded, to every router that is connected to the area in which the LSA originated.

Routes to networks within an area are called intra-area routes, and routes to networks in another area of the same OSPF autonomous system are called inter-area routes. Inter-area routes are propagated by ABRís by using summary LSAís. Summary LSAís propagate within area borders. Routes to networks in another autonomous system are called external routes; external routes are injected into the OSPF autonomous system by ASBRís by using external LSAís. External LSAís propagate throughout an entire OSPF autonomous system except as indicated below.

Several types of OSPF areas are defined; we will be covering the following types:

A normal area is an area that can contain internal routers, ABRís, and ASBRís. Area 0 must be a normal area.

A stub area is one that does not allow the propagation of external routes. The ABR that connects a stub area to the backbone area blocks the propagation of external LSAís and transmits a default route along with the normal inter-area routes (by summary LSAís) into the stub area. The default route is used by all of the stub areaís internal routers to get to networks that are not a part of the OSPF autonomous system. The inter-area routes are used to get to networks that are a part of the autonomous system. A stub area cannot contain an ASBR. Stub areas are defined in the OSPF standard.

A totally stubby area is a Cisco-proprietary area type that extends the definition of a stub area. A totally stubby area does not allow the propagation of external routes (external LSAís) or inter-area routes (normal summary LSAís); instead, the ABR that connects a totally stubby area to the backbone area transmits only a default route into the totally stubby area. The default route is used by all of the totally stubby areaís internal routers to get to networks that are not a part of the local totally stubby area. Internal routers in totally stubby areas tend to have very small routing tables relative to the routers in normal areas.

Similarly to EIGRP, OSPF discovers neighbor routers by transmitting Hello packets and listening for Hello packets. OSPF routers transmit Hello packets to the multicast address designated for all OSPF routers, 224.0.0.5. Once neighbors are discovered, their information is placed into a neighbor table. In order for two routers to become OSPF neighbors, they must agree on five OSPF parameters that are contained in the Hello packets:

The hello interval is the length of time between hello packets. The default hello interval is 10 seconds. The dead interval is the amount of time that must elapse without a router hearing a Hello from a neighbor before the router will remove the neighborís information from its table. This is similar to the Hold Time that was covered for EIGRP. The default dead interval is four times the hello interval, 40 seconds.

The stub area flag is set in the hello packets transmitted by a router into an area when we define the area to be a stub area or a totally stubby area. The flag is actually just a single bit within the packet. All of the routers that connect to any kind of stub area must know that the area is a stub area.

OSPF provides password authentication just like RIPv2 and EIGRP so it is reasonable that two routers cannot be neighbors and share information if they do not know each otherís password.

On multi-access networks such as LANís and frame relay multipoint WANís, a Designated Router (DR) and a Backup Designated Router (BDR) are elected based on OSPF priority and router ID. The router with the highest OSPF priority on a multi-access network is selected to be DR; the router with the second highest OSPF priority is selected to be the BDR. The default OSPF priority of an IOS-based router is 1 (one). If multiple routers have the same priority, the RID is used as the tie-breaker. The router with the highest RID wins. Once a router has been elected DR for a network, the router continues to be DR until its connection to the network goes down. When a network loses its DR, the BDR immediately becomes the DR, and there is an election for a new BDR.

The DR is responsible for advertising the network to the rest of the OSPF routers using a network LSA. The network LSA contains the networkís address and mask along with the RIDís of all of the routers attached to the network. The propagation of network LSAís is bounded by an areaís border, just as that of router LSAís and summary LSAís are.

Each multi-access network gets its own DR and BDR. All routers on the multi-access network build adjacencies only with the DR and the BDR; this usually reduces the number of adjacencies that must be maintained by all of the routers except the DR and BDR. When routers transmit LSAís meant for the DR and BDR, the routers send the LSAís to the multicast address designated for all DRís and BDRís, 224.0.0.6. An adjacency is the synchronization of the routersí link state databases so that they have identical LSAís for the area in which the network exists.

There is no DR and BDR election on point-to-point networks; the routers on each end do, however, establish an adjacency with each other.

OSPF uses a single metric called cost. The cost is calculated from the bandwidth assigned to an interface; this bandwidth is defined the same way as the bandwidth used in the composite metric for IGRP and EIGRP. The cost of a link is included in the LSA that is being used to advertise the link. OSPF costs are additive. To get the total metric from one network to another, routers simply add the costs of the individual networks that must be crossed to get to a destination. The default formula for calculating the outbound cost of an interface is as follows:

108 / bandwidth (in bps) = cost

For example, the default cost of a 10 Mbps Ethernet interface is 10 as shown below.

108 / bandwidth = 108 / 10,000,000 = 108 / 107 = 10

So now there are all of these types of LSAís being transmitted and collected by different types of routers within different types of areas. We still have not reached the point where a router running OSPF can route packets using the information it has gathered in its link state database.

The OSPF process runs a special algorithm called the Shortest Path First (SPF) algorithm against the link state database. The algorithm is also called the Dijkstra algorithm. The running of the SPF algorithm produces a map of an internetwork in the form of a tree with the local router as the root. From the network tree, the router takes the shortest path to each network and places that path into the IP routing table.

When the link state database is updated, a router must run the SPF algorithm, produce another network tree, and then update the routing table. Because of this three-step process, routers running OSPF use more CPU time than those running the other routing protocols we have covered. The existence of the neighbor table, the link state database, and the network tree requires a little more RAM, also.

        1. OSPF Basic Configuration

The configuration of OSPF requires the designation of an OSPF process with the router ospf command along with a process ID (PID). The PID identifies the local OSPF process only, and does not have to be the same on all of the routers running OSPF. OSPF is enabled on a routerís interfaces by using the network area command. The network area command associates a wildcard mask with an address, and it specifies the area to which interfaces that match the address and wildcard mask pair are connected. This gives us control over exactly which interfaces have OSPF enabled and which area each interface is in. The command syntax looks like this.

network address wildcard-mask area area-ID

The address is the dotted-decimal address of a network, a subnet, or an interface. The wildcard-mask is a 32-bit, dotted-decimal value sometimes called an inverse mask because the meanings of its bits are inverted from their meanings in a network mask. We covered network masks when we did IP address subnetting. In a network mask, a binary one in a bit position means that the bit position is important in routing, and a binary zero in a bit position means that the bit position has no significance in routing. The opposite is true for a wildcard mask. In a wildcard mask, a binary zero means that the bit position should be checked in matching an address, and a binary one means that the bit position should be ignored during the matching process. A wildcard mask of 255.255.255.255 is used to match any address, and a wildcard mask of 0.0.0.0 is used to match only the specific address with which is paired. Those are the two extremes of the wildcard mask; the configuration examples will provide more insight. The area-ID is the number that we have assigned to the area to which all interfaces with addresses matching the address/wildcard-mask pair are connected.

The OSPF internetwork that we are going to configure is shown in Figure 7-75. There are two areas, 0 and 1. The area boundaries are highlighted. Area 0 will contain Dallasís Ethernet0 and Serial1 interfaces and FortWorthís Ethernet0 and Serial0 interfaces. Area 1 will contain Dallasís Serial0 interface, FortWorthís Serial1 interface, and all of Austinís interfaces. Dallas and FortWorth will be ABRís, and Austin will be an internal router.

<<<J120 Ė Figure 7-75 OSPF Area Diagram>>>

Figure 7-76 shows the configuration of our OSPF design on Dallas. Figure 7-77 shows the OSPF configuration on FortWorth, and Figure 7-78 has the configuration of OSPF on Austin.

    1. Dallas#configure terminal
    2. Enter configuration commands, one per line. End with CNTL/Z.
    3. Dallas(config)#router ospf 100
    4. Dallas(config-router)#network 172.16.10.1 0.0.0.0 area 0
    5. Dallas(config-router)#network 172.16.11.1 0.0.0.0 area 0
    6. Dallas(config-router)#network 192.168.2.1 0.0.0.0 area 1
    7. Dallas(config-router)#<Ctrl-Z>
    8. Dallas#
    9. <<<Figure 7-76 OSPF Configuration on Dallas>>>

      The configuration of OSPF is initiated on Dallas with the router ospf 100 command (Line 3). The PID is 100; this identifies the OSPF process on Dallas. This number does not have to be the same on the other routers. As a matter of fact, we purposely used a different PID on each router to illustrate this. Under normal circumstances, we would have used the same PID on all the routers just to be consistent and to avoid having to figure out which PID we used each time that we wanted to configure OSPF on a router. On the Line 4 network area command, we have an address of 172.16.10.1 with a wildcard mask of 0.0.0.0. The interfaces with addresses matching this address/mask pair are to run OSPF for area 0. Since the wildcard mask is all zeros, there can be only one matching address. This particular command enables OSPF on Dallasí Ethernet0 interface and places the Ethernet LAN in area 0 because the Ethernet0 interface has the exact address 172.16.10.1. The next network area command (Line 5) enables OSPF on the Serial1 interface for area 0. The last network area command (Line 6) enables OSPF on the Serial0 interface for area 1.

      The network area commands are processed from top to bottom so the order in which they are typed is important when an interfaceís address matches multiple statements. When using the 0.0.0.0 wildcard mask, the order does not really matter since each statement can possibly match only one address.

    10. FortWorth#configure terminal
    11. Enter configuration commands, one per line. End with CNTL/Z.
    12. FortWorth(config)#router ospf 200
    13. FortWorth(config-router)#network 172.16.0.0 0.0.255.255 area 0
    14. FortWorth(config-router)#network 192.168.3.0 0.0.0.255 area 1
    15. FortWorth(config-router)#<Ctrl-Z>
    16. FortWorth#
    17. <<<Figure 7-77 OSPF Configuration on FortWorth>>>

      We used the PID 200 on FortWorth (Line 3, Figure 7-77). The first network area command (Line 4) enables OSPF on both the Ethernet0 and the Serial0 interfaces and places them both in area 0. The address of 172.16.0.0 paired with the wildcard mask of 0.0.255.255 means that the interfaces with addresses beginning with 172.16 match the statement; those are Ethernet0 and Serial0. The Line 5 command puts Serial1 into area 1 because the address of Serial1 starts with 192.168.3.

    18. Austin#configure terminal
    19. Enter configuration commands, one per line. End with CNTL/Z.
    20. Austin(config)#router ospf 300
    21. Austin(config-router)#network 192.0.0.0 0.255.255.255 area 1
    22. Austin(config-router)#<Ctrl-Z>
    23. Austin#

<<<Figure 7-78 OSPF Configuration on Austin>>>

Austin gets another different PID, 300 (Line 3, Figure 7-78). We used a single network area command (Line 4) to put all of Austinís interfaces into OSPF area 1. With the wildcard mask of 0.255.255.255, only the first octet of an interfaceís address is checked in the statement. All of Austinís addresses begin with 192; therefore, all of them get placed into area 1.

        1. OSPF Verification

The commands we will use to verify the operation of OSPF are as follows:

Since we started the verification of all the other routing protocols with the show ip protocols command, we will do the same thing here. Figure 7-79 shows the output of the show ip protocols command on Dallas.

    1. Dallas#show ip protocols
    2. Routing Protocol is "ospf 100"
    3. Sending updates every 0 seconds
    4. Invalid after 0 seconds, hold down 0, flushed after 0
    5. Outgoing update filter list for all interfaces is
    6. Incoming update filter list for all interfaces is
    7. Redistributing: ospf 100
    8. Routing for Networks:
    9. 172.16.10.1/32
    10. 172.16.11.1/32
    11. 192.168.2.1/32
    12. Routing Information Sources:
    13. Gateway Distance Last Update
    14. 192.168.3.2 110 00:01:24
    15. 192.168.3.1 110 00:01:34
    16. Distance: (default is 110)
    17. Dallas#
    18. <<<Figure 7-79 Show IP Protocols Output After OSPF Configuration>>>

      As shown on Line 2, OSPF with the PID of 100 is running. OSPF updates are triggered, not periodic; that is why the timers are all 0 (Lines 3 and 4). The addresses that match our address/wildcard mask pairs on the network area commands are specified on Lines 9, 10, and 11. Dallas is receiving routing from both FortWorth (Line 15) and Austin (Line 14). The addresses shown are the RIDís for the routers. OSPFís default administrative distance of 110 (Line 16) is lower than that of RIP but higher than that of IGRP and EIGRP.

      The IP routing tables are an indication of the type of connectivity our internetwork has. Figure 7-80 shows the IP routing table for Dallas. Figure 7-81 has FortWorthís IP routing table, and Figure 7-82 has Austinís IP routing table.

    19. Dallas#show ip route
    20. [text omitted]
    21. 172.16.0.0/24 is subnetted, 3 subnets
    22. O 172.16.20.0 [110/74] via 172.16.11.2, 00:02:31, Serial1
    23. C 172.16.10.0 is directly connected, Ethernet0
    24. C 172.16.11.0 is directly connected, Serial1
    25. O 192.168.1.0/24 [110/400] via 192.168.2.2, 00:01:43, Serial0
    26. C 192.168.2.0/24 is directly connected, Serial0
    27. O 192.168.3.0/24 [110/2175] via 192.168.2.2, 00:01:43, Serial0
    28. Dallas#
    29. <<<Figure 7-80 Dallas IP Routing Table After OSPF Configuration>>>

      Dallasís routing shows the usual routes. The routes learned via OSPF have the letter O in the left column of their entries. The administrative distance of 110 is shown in the brackets for the OSPF-learned routes. As usual, the second number within the brackets is the metric. The metric for these routes is the OSPF cost. Let us do a quick calculation of a routeís metric. The route to network address 172.16.20.0 has a cost of 74 (Line 4). This is a route to FortWorthís Ethernet LAN across the T1. The cost for the T1 is 64, and the cost for FortWorthís Ethernet0 interface is 10; the total cost is 74.

    30. FortWorth#show ip route
    31. [text omitted]
    32. 172.16.0.0/24 is subnetted, 3 subnets
    33. C 172.16.20.0 is directly connected, Ethernet0
    34. O 172.16.10.0 [110/74] via 172.16.11.1, 00:04:49, Serial0
    35. C 172.16.11.0 is directly connected, Serial0
    36. O 192.168.1.0/24 [110/1795] via 192.168.3.2, 00:03:59, Serial1
    37. O 192.168.2.0/24 [110/2175] via 192.168.3.2, 00:03:59, Serial1
    38. C 192.168.3.0/24 is directly connected, Serial1
    39. FortWorth#
    40. <<<Figure 7-81 FortWorth IP Routing Table After OSPF Configuration>>>

      The IP routing table on FortWorth shows the same basic routes as the one on Dallas.

    41. Austin#show ip route
    42. [text omitted]
    43. 172.16.0.0/24 is subnetted, 3 subnets
    44. O IA 172.16.20.0 [110/464] via 192.168.2.1, 00:05:15, Serial1
    45. O IA 172.16.10.0 [110/400] via 192.168.2.1, 00:05:15, Serial1
    46. O IA 172.16.11.0 [110/454] via 192.168.2.1, 00:05:15, Serial1
    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#
    51. <<<Figure 7-82 Austin IP Routing Table After OSPF Configuration>>>

      The IP routing table of Austin shows some differences from what we saw with the other routing protocols. Austin knows about each of the 172.16.0.0 subnets (Lines 4, 5, and 6). OSPF does not do auto-summarization; OSPF summarization must be manually configured. The subnets have the additional letters IA after the O in the left column. The IA indicates that these are inter-area routes; the networks are in another area to which Austin is not connected. According to Figure 7-75 and our configuration, they are in area 0 while Austin is entirely within area 1.

      General information about OSPF operation can be obtained with the show ip ospf command. Figure 7-83 shows the output of the show ip ospf command on Dallas.

    52. Dallas#show ip ospf
    53. Routing Process "ospf 100" with ID 192.168.2.1
    54. Supports only single TOS(TOS0) routes
    55. It is an area border router
    56. Summary Link update interval is 00:30:00 and the update due in 00:26:24
    57. SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
    58. Number of DCbitless external LSA 0
    59. Number of DoNotAge external LSA 0
    60. Number of areas in this router is 2. 2 normal 0 stub 0 nssa
    61. Area BACKBONE(0)
    62. Number of interfaces in this area is 2
    63. Area has no authentication
    64. SPF algorithm executed 4 times
    65. Area ranges are
    66. Link State Update Interval is 00:30:00 and due in 00:26:23
    67. Link State Age Interval is 00:20:00 and due in 00:16:23
    68. Number of DCbitless LSA 0
    69. Number of indication LSA 0
    70. Number of DoNotAge LSA 0
    71. Area 1
    72. Number of interfaces in this area is 1
    73. Area has no authentication
    74. SPF algorithm executed 4 times
    75. Area ranges are
    76. Link State Update Interval is 00:30:00 and due in 00:26:22
    77. Link State Age Interval is 00:20:00 and due in 00:16:22
    78. Number of DCbitless LSA 0
    79. Number of indication LSA 0
    80. Number of DoNotAge LSA 0
    81. Dallas#
    82. <<<Figure 7-83 Show IP OSPF Output>>>

      The only OSPF process running has PID 100, and the RID selected for that process is 192.168.2.1 (Line 2). The address 192.168.2.1 is the highest IP address assigned to an active interface on Dallas. Dallas is connected to two areas Ė 0 (Line 10) and 1 (Line 20). Being connected to two areas makes Dallas an ABR (Line 4). Dallas has two interfaces in area 0 (Line 11) and one interface in area 1 (Line 21). We also see the number of times that the SPF algorithm has been run for each of the areas (Lines 13 and 23). This is good statistic to monitor. If it starts increasing rapidly, we probably have an unstable network somewhere.

      The OSPF neighbor table contains the RIDís for all of the routers that the local router has discovered as neighbors. Figure 7-84 shows the neighbor table displayed on Dallas after issuing the show ip ospf neighbor command.

    83. Dallas#show ip ospf neighbor
    84. Neighbor ID Pri State Dead Time Address Interface
    85. 192.168.3.2 1 FULL/ - 00:00:31 192.168.2.2 Serial0
    86. 192.168.3.1 1 FULL/ - 00:00:35 172.16.11.2 Serial1
    87. Dallas#
    88. <<<Figure 7-84 Show IP OSPF Neighbor Output>>>

      Dallasí two neighbor routers are Austin (Line 4) and FortWorth (Line 5). The Neighbor ID column shows the RIDís for the routers, not the addresses of their directly-connected interfaces. The neighborsí directly-connected interface addresses are given in the Address column, and the interface to which the neighbor is connected is shown in the Interface column. The State column shows the status of the neighbor relationship. A full state indicates that an adjacency has been established with a neighbor. The Dead Time column indicates the amount of time left in the dead interval either to receive a Hello packet from a neighbor or to remove the neighbor from the table.

    89. Dallas#show ip ospf interface
    90. BRI0 is administratively down, line protocol is down
    91. OSPF not enabled on this interface
    92. BRI0:1 is administratively down, line protocol is down
    93. OSPF not enabled on this interface
    94. BRI0:2 is administratively down, line protocol is down
    95. OSPF not enabled on this interface
    96. Ethernet0 is up, line protocol is up
    97. Internet Address 172.16.10.1/24, Area 0
    98. Process ID 100, Router ID 192.168.2.1, Network Type BROADCAST, Cost: 10
    99. Transmit Delay is 1 sec, State DR, Priority 1
    100. Designated Router (ID) 192.168.2.1, Interface address 172.16.10.1
    101. No backup designated router on this network
    102. Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    103. Hello due in 00:00:01
    104. Neighbor Count is 0, Adjacent neighbor count is 0
    105. Suppress hello for 0 neighbor(s)
    106. Serial0 is up, line protocol is up
    107. Internet Address 192.168.2.1/24, Area 1
    108. Process ID 100, Router ID 192.168.2.1, Network Type POINT_TO_POINT, Cost: 390
    109. Transmit Delay is 1 sec, State POINT_TO_POINT,
    110. Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    111. Hello due in 00:00:08
    112. Neighbor Count is 1, Adjacent neighbor count is 1
    113. Adjacent with neighbor 192.168.3.2
    114. Suppress hello for 0 neighbor(s)
    115. Serial1 is up, line protocol is up
    116. Internet Address 172.16.11.1/24, Area 0
    117. Process ID 100, Router ID 192.168.2.1, Network Type POINT_TO_POINT, Cost: 64
    118. Transmit Delay is 1 sec, State POINT_TO_POINT,
    119. Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    120. Hello due in 00:00:05
    121. Neighbor Count is 1, Adjacent neighbor count is 1
    122. Adjacent with neighbor 192.168.3.1
    123. Suppress hello for 0 neighbor(s)
    124. Serial2 is administratively down, line protocol is down
    125. OSPF not enabled on this interface
    126. Serial3 is administratively down, line protocol is down
    127. OSPF not enabled on this interface
    128. Dallas#
    129. <<<Figure 7-85 Show IP OSPF Interface Output>>>

      Figure 7-85 shows the output of the show ip ospf interface command on Dallas. The show ip ospf interface command shows the status of OSPF on a routerís interfaces. Figure 7-85 shows that Dallas has OSPF enabled on interfaces Ethernet0, Serial0, and Serial1 (Lines 9, 19, and 28). We will look at some of the information given for the Serial1 interface (starting on Line 27). The Serial1 interface is connected to area 0 (Line 28) for Dallasís OSPF PID 100 (Line 29). Dallasí RID is 192.168.2.1 (Line 29). The network to which Serial1 is connected is a point-to-point network with a cost of 64. The cost of 64 is based on the bandwidth of the Serial1 interface being set to the fast-serial interface default value of 1544. That is 1544 kbps, or 1,544,000 bps, to plug into the formula for calculating OSPF cost. The OSPF timers are given on Line 31. Dallas has one neighbor out its Serial1 interface (Line 33), and an adjacency has been established with that neighbor (Line33). The neighborís RID (192.168.3.1) is given on Line 34; the neighbor is Austin.

      The link state database is another useful item to examine when verifying the operation of OSPF. Figure 7-86 shows the output of the show ip ospf database command on Dallas.

    130. Dallas#show ip ospf database
    131. OSPF Router with ID (192.168.2.1) (Process ID 100)
    132. Router Link States (Area 0)
    133. Link ID ADV Router Age Seq# Checksum Link count
    134. 192.168.2.1 192.168.2.1 280 0x80000003 0x36B3 3
    135. 192.168.3.1 192.168.3.1 279 0x80000002 0x7668 3
    136. Summary Net Link States (Area 0)
    137. Link ID ADV Router Age Seq# Checksum
    138. 192.168.1.0 192.168.2.1 222 0x80000001 0x5B79
    139. 192.168.1.0 192.168.3.1 224 0x80000001 0x358
    140. 192.168.2.0 192.168.2.1 232 0x80000001 0xEBF1
    141. 192.168.2.0 192.168.3.1 225 0x80000001 0xDDFE
    142. 192.168.3.0 192.168.2.1 222 0x80000001 0xD903
    143. 192.168.3.0 192.168.3.1 235 0x80000001 0x89D9
    144. Router Link States (Area 1)
    145. Link ID ADV Router Age Seq# Checksum Link count
    146. 192.168.2.1 192.168.2.1 232 0x80000003 0x668D 2
    147. 192.168.3.1 192.168.3.1 237 0x80000003 0x3FB 2
    148. 192.168.3.2 192.168.3.2 229 0x80000003 0xCB3B 5
    149. Summary Net Link States (Area 1)
    150. Link ID ADV Router Age Seq# Checksum
    151. 172.16.10.0 192.168.2.1 323 0x80000001 0xD926
    152. 172.16.10.0 192.168.3.1 276 0x80000001 0x5569
    153. 172.16.11.0 192.168.2.1 281 0x80000001 0xECDB
    154. 172.16.11.0 192.168.3.1 277 0x80000001 0xE5E1
    155. 172.16.20.0 192.168.2.1 272 0x80000001 0xEDC7
    156. 172.16.20.0 192.168.3.1 277 0x80000001 0x6490
    157. Dallas#

<<<Figure 7-86 Show IP OSPF Database Output>>>

Since Dallas is an ABR with connections to both area 0 and area 1, there are two sets of link state information in the database. There are two routers with connections to area 0; therefore, there must be two router link states for area 0: one for Dallas (Line 9) and one for FortWorth (Line 10). There are two ABRís between area 0 and area 1; therefore, each of them generated summary LSAís into area 0 indicating the routes in area 1 (Lines 15 through 20). There are three routers with connections to area 1 so there must be three router link states for area 1: one for Dallas (Line 25), one for FortWorth (Line 26), and one for Austin (Line 27). The two ABRís each generated summary LSAís into area 1 indicating the routes in area 0 (Lines 32 through 37).

        1. OSPF Stub Area Configuration

Stub areas were covered in Section 7.7.4.1. We use the router configuration command area stub to convert an area into a stub area. The area stub command must be entered under the OSPF process for every router that has a connection to the area that is to be a stub area. Figure 7-87 shows the conversion of area 1 from a normal area to a stub area.

    1. Dallas#configure terminal
    2. Enter configuration commands, one per line. End with CNTL/Z.
    3. Dallas(config)#router ospf 100
    4. Dallas(config-router)#area 1 stub
    5. Dallas(config-router)#<Ctrl-Z>
    6. Dallas#
    7. ----------
    8. FortWorth#configure terminal
    9. Enter configuration commands, one per line. End with CNTL/Z.
    10. FortWorth(config)#router ospf 200
    11. FortWorth(config-router)#area 1 stub
    12. FortWorth(config-router)#<Ctrl-Z>
    13. FortWorth#
    14. ----------
    15. Austin#configure terminal
    16. Enter configuration commands, one per line. End with CNTL/Z.
    17. Austin(config)#router ospf 300
    18. Austin(config-router)#area 1 stub
    19. Austin(config-router)#<Ctrl-Z>
    20. Austin#
    21. <<<Figure 7-87 Conversion of a Normal Area to a Stub Area>>>

      The configurations of our three test routers were grouped together to show that the same command must by typed for the OSPF process on each router. The ID of the area being made a stub area must be referenced in the area stub command. The area ID goes between the area keyword and the stub keyword in the command (Lines 4, 11, and 18).

      After converting area 1 to a stub area, the IP routing tables of Dallas and FortWorth are unchanged since they are ABRís for area 1. However, the Austin routing table now contains a default route as shown in Figure 7-88.

    22. Austin#show ip route
    23. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
    24. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    25. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    26. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
    27. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
    28. U - per-user static route, o - ODR
    29. Gateway of last resort is 192.168.2.1 to network 0.0.0.0
    30. 172.16.0.0/24 is subnetted, 3 subnets
    31. O IA 172.16.20.0 [110/464] via 192.168.2.1, 00:00:13, Serial1
    32. O IA 172.16.10.0 [110/400] via 192.168.2.1, 00:00:13, Serial1
    33. O IA 172.16.11.0 [110/454] via 192.168.2.1, 00:00:13, Serial1
    34. C 192.168.1.0/24 is directly connected, Ethernet0
    35. C 192.168.2.0/24 is directly connected, Serial1
    36. C 192.168.3.0/24 is directly connected, Serial0
    37. O*IA 0.0.0.0/0 [110/391] via 192.168.2.1, 00:00:13, Serial1
    38. Austin#
    39. <<<Figure 7-88 IP Routing Table of Austin After Stub Area Conversion>>>

      The default route is shown on Line 18 as a network 0.0.0.0 with a prefix length of /0. The prefix length of /0 will cause any destination address to match this route. Austin will route all IP packets with this route unless there is another routing table match with a longer prefix length. As a general rule, the default route is used if no other match for a destination address can be found in the routing table. The default route also appears as the gateway of last resort (Line 9). The OSPF inter-area routes to the 172.16.0.0 subnets are still in the routing table. We can get rid of those by making area 1 a totally stubby area.

      To convert an area from a stub area to a totally stubby area, we need to reissue the area stub command, on the ABRís, with the keyword no-summary at the end of it. Figure 7-89 shows the conversion of area 1 from a stub area to a totally stubby area.

    40. Dallas#configure terminal
    41. Enter configuration commands, one per line. End with CNTL/Z.
    42. Dallas(config)#router ospf 100
    43. Dallas(config-router)#area 1 stub no-summary
    44. Dallas(config-router)#<Ctrl-Z>
    45. Dallas#
    46. ----------
    47. FortWorth#configure terminal
    48. Enter configuration commands, one per line. End with CNTL/Z.
    49. FortWorth(config)#router ospf 200
    50. FortWorth(config-router)#area 1 stub no-summary
    51. FortWorth(config-router)#<Ctrl-Z>
    52. FortWorth#
    53. <<<Figure 7-89 Conversion of a Stub Area to a Totally Stubby Area>>>

      Since Austin is not an ABR for area 1, the configuration of Austin remains as it is with the original area 1 stub command. The no-summary keyword (Lines 4 and 11) indicates that the usual summary LSAís containing inter-area routes are not to be injected into the area. Instead only a default route is injected. Figure 7-90 shows Austinís routing table after area 1 becomes a totally stubby area.

    54. Austin#show ip route
    55. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
    56. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    57. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    58. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
    59. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
    60. U - per-user static route, o - ODR
    61. Gateway of last resort is 192.168.2.1 to network 0.0.0.0
    62. C 192.168.1.0/24 is directly connected, Ethernet0
    63. C 192.168.2.0/24 is directly connected, Serial1
    64. C 192.168.3.0/24 is directly connected, Serial0
    65. O*IA 0.0.0.0/0 [110/391] via 192.168.2.1, 00:00:09, Serial1
    66. Austin#

<<<Figure 7-90 IP Routing Table of Austin After Totally Stubby Area Conversion>>>

Austinís IP routing table no longer contains any inter-area routes. Instead there is a default route, which will be used to route packets to any network that not in area 1.

        1. OSPF Configuration Summary

We start OSPF by entering the router ospf command, with a process id, in global configuration mode and then the appropriate network area commands for enabling OSPF on the interfaces. The network area command, through the use of a wildcard mask, allows us to accurately control which interfaces get OSPF enabled and which area an interface is connected to.

To convert a normal area to a stub area, we use the area stub command, in router configuration mode for the OSPF process, on every router that has a connection to the area. We create a totally stubby area by using the area stub command on every router that has a connection to the area, but, on the areaís ABRís, we include the no-summary keyword on the area stub command

The current, OSPF-specific configuration commands, from the running configurations of Dallas, FortWorth, and Austin are shown in Figure 7-91, Figure 7-92, and Figure 7-93, respectively.

    1. Dallas#show running-config
    2. [text omitted]
    3. !
    4. router ospf 100
    5. network 172.16.10.1 0.0.0.0 area 0
    6. network 172.16.11.1 0.0.0.0 area 0
    7. network 192.168.2.1 0.0.0.0 area 1
    8. area 1 stub no-summary
    9. !
    10. [text omitted]
    11. Dallas#
    12. <<<Figure 7-91 Dallas OSPF-Specific Configuration Commands>>>

    13. FortWorth#show running-config
    14. [text omitted]
    15. !
    16. router ospf 200
    17. network 172.16.0.0 0.0.255.255 area 0
    18. network 192.168.3.0 0.0.0.255 area 1
    19. area 1 stub no-summary
    20. !
    21. [text omitted]
    22. FortWorth#
    23. <<<Figure 7-92 FortWorth OSPF-Specific Configuration Commands>>>

    24. Austin#show running-config
    25. [text omitted]
    26. !
    27. router ospf 300
    28. network 192.0.0.0 0.255.255.255 area 1
    29. area 1 stub
    30. !
    31. [text omitted]
    32. Austin#

<<<Figure 7-93 Austin OSPF-Specific Configuration Commands>>>

Since OSPF is the last IP routing protocol we will be covering, we will be leaving the configuration in this state.

        1. OSPF Removal

Removing an OSPF process on a Cisco router requires a single global configuration command. Just put the keyword no in front of the command that was used to configure OSPF. For example, the command to remove the current OSPF process from Dallas would be as follows:

no router ospf 100

When OSPF is referenced in configuration mode, the PID must be included with it to uniquely identify the OSPF process since there could be multiple OSPF processes running on the router.

Backward Forward
Chapter: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9


Reserve your copy at a
Bet@ Bookstore near you!
Contact Bet@ Books
© 1999 The McGraw-Hill Companies, Inc. All rights reserved.
Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use.

Bet@ Books | Bet@ Bookstores | Computing McGraw-Hill

Professional Publishing Home | Contact Us | Customer Service | For Authors | International Offices | New Book Alert | Search Catalog/Order | Site Map | What's New


A Division of the McGraw-Hill Companies
Copyright © 1999 The McGraw-Hill Companies, Inc. All rights reserved. Any use is subject to the Terms of Use the corporation also has a comprehensive Privacy Policy governing information we may collect from our customers. Bet@ Books (TM) is a registered trademark of The McGraw-Hill Companies, Inc.