Local
Content
Basic IP Routing Concepts
And
RIP, EIGRP, OSPF with ACL
Tharaka Guruge, CISCO Certified lecturer Vocational Training Authority of Sri Lanka – Galle Branch
Local-area networks, or LANs, are really nothing more than a collection of computing devices connected together by some means in order to share or pool resources. The physical method, or medium, by which these devices are connected together is commonly referred to as the data link. The data link may be a fiber-optic cable, twistedpair wires, coaxial cable, or even radio waves and infrared light. Whatever the medium, all the devices share a common interface for accessing the data link to send communications to each other.
Like communications in the real word, just having the ability to speak and listen is not enough to carry on a conversation. For instance, if two people are speaking to each other and they both try to speak at the same time, one party must decide to stop speaking and start listening. In the real world, we refer to the rules that govern conversation as etiquette, but in data networking, this set of rules is referred to as the Media Access Control protocol, or MAC. Having a set of rules dictating who can speak when is a good start, but it is often not sufficient when complicated conversations are taking place. Take, for example, a crowded room where multiple conversations may be going on at the same time. The people in the room must know what parts of conversations are destined for them, even though they may be hearing all the other conversations going on. In the real world, we attempt to handle this situation by addressing intended receivers by their name, and they listen only for conversations prefixed with their name. In data communications, a similar method is used. As stated before, when devices are attached to a LAN they share a common method for accessing the data link. This method is accomplished via the network interface card, or
NIC. The NIC encapsulates the data a device wants to send to another device in what is called a frame. The NIC is often referred to as the interface of a device.
A frame is like an electronic envelope. Just as you would place a letter containing your data inside an envelope and address the outside with the recipient's name and your return address, the NIC encapsulates the data of the computing device with a destination and return address. Frame: Destination Address Source (Return) Address DATA
In the MAC protocol, the address refers to a unique number that is assigned to every NIC by its manufacturer. This number, known variously as the burned-in address (BIA), physical address, or most commonly the MAC address, is actually not an address at all. It gives no reference to where the NIC or machine is located. It is actually just a unique name that identifies the NIC from every other NIC in the world. Unfortunately, the term "address" has stuck with this concept and, throughout this module, this number will be referred to as the MAC address of the device. The figure below shows a typical MAC address, which is composed of 48 bits and is often represented in three, four hexadecimal digit groups: MAC Address: 0000.0c47.93c1 000 0 0 000 0 0 000 0 0 000 0 0. 000 0 0 110 0 c 010 0 4 011 1 7. 100 1 9 001 1 3 110 0 c 000 1 1
Now that the data is encapsulated in a frame with a destination and source address, the NIC can transmit the frame onto the data link. Just as you would listen for your name in a crowded room to know if someone was trying to speak to you, NICs listen to the data link for frames with a destination address that matches their own MAC address. When a frame is "heard" by a NIC with its own MAC address, the NIC knows to copy the frame
and send the data portion on to the computing device for processing. Since the frame was created with a return address, the receiver instantly knows the sender of the frame, and two-way communications can occur. Although somewhat oversimplified, this process describes basic data communications on a LAN. All devices are attached to the same medium, or data link, and when one device wishes to communicate with another, it encapsulates the data in a frame with a destination and source MAC address and transmits it.
Imagine now that you're back in that crowded room trying to have a conversation and the room is becoming more and more crowded. As additional conversations occur, it becomes difficult to talk to someone without being interrupted. At some point it becomes impossible to have a conversation because everyone is trying to talk over everyone else. The same situation occurs on LANs. As more devices than the medium can support are added, communications become inefficient. Additionally, as more devices become available in geographically dispersed areas, it becomes impossible to join them together on a single data link. In the overcrowded room, a possible solution is to have some of the people move into another room; a similar approach is used on LANs. When LANs become overcrowded, boundaries must be created between groups of devices. This scenario is accomplished via a piece of equipment known as a bridge. A bridge effectively takes a large LAN and breaks it down into smaller segments. It then learns the MAC address of all the devices on each of its attached segments. After learning the addresses, the bridge prevents frames destined between two devices on the same segment from traversing the data links on other segments. If a device wishes to speak to a device on a different segment, the bridge knows which segment to forward the frame to, and communications can occur. The overall effect of this filtering is a decreased use in bandwidth on each of the individual segments. It is important to note when bridging a frame that as the frame moves through the internetwork, its destination and source MAC addresses always stay the same. They do not take on the MAC address of the interfaces on the bridge.
Although effective at reducing the overall traffic on each of the new, smaller segments, bridges don't solve all the problems of overpopulated LANs. Because some frames do not have a destination of a specific device, but rather to all devices on the network, the bridge must forward these broadcast packets to all segments. As the number of devices on each segment begins to grow, this broadcast traffic can increase to the point where it starts to become a hindrance, similar to those that the bridge was designed to alleviate. Bridges also don't address the problems of connecting geographically dispersed LANs (called wide-area networks, or WANs) where expensive communication links need to be used in the most efficient manner. A different type of boundary is needed to handle problems such as broadcast traffic and the efficient joining of LANs and WANs; such a boundary allows networks to be grouped into larger networks, or internetworks. The device that makes internetworking possible is the router.
Unlike the data link that directly connects two or more devices together to form a network, a router connects two or more devices together on separate networks. The primary difference is that on the data link a physical path is the connection between the devices. On a router, the connection between devices is a logical path that may span many routers and data links. The job of the router is to keep track of which path to use
when transferring data from one network to another. The path that data follows between networks is known as the route. As data moves along the route passing through routers, each router it passes through is commonly referred to as a hop. In complex internetworks where multiple routes exist between data links, it is also the job of the router to determine which path is the most optimal. To determine which routes to use and which routes are the most optimal, routers use a set of rules called routing protocols and store the results in routing tables. When data travels between devices at the data link layer, MAC addresses are used to identify the sender and receiver. As mentioned previously, a MAC address is simply a unique name given to the NIC card and contains no reference to its relative location. Since the purpose of a router is to send data between different data links, or networks, a method is needed to identify which network a device is located on so that it does not have to travel every network in search of the receiver. Think of a piece of mail destined for you. The first thing the sender does when addressing the envelope is to write your name on it. Is this sufficient to get the letter to you? The postman would have to go to everyone in the world, and ask them if the letter had their name on it. A way is needed to narrow down the possible destinations. To do this, an address is added to the envelope describing where you are located. A street, city, state, and zip code aid in pinpointing your position to a precise location. These elements also make it easier for the post office to sort mail into groups of items destined for similar destinations. When the postman finally delivers the envelope to your house, does he care whose name is above the address? Usually not. There may be several people at the address with the same last name, but it is not the job of the postman to determine which person the envelope belongs to. He just leaves the envelope in the mailbox and lets the people living at that address decide whom the letter is for, based on the name on the envelope. Internetworking works on the same principles. Just as a frame is data encapsulated with a destination and source MAC addresses, a packet is data encapsulated with a destination and source network address. Routers use packets to move data between networks, and the network address helps the routers determine the general location of the recipient. Packet: Destination MAC Address Source MAC Address Destination Network Address Source Network Address DATA
When a router receives a packet, it makes a routing decision based on the network destination address portion of the packet. If the destination address is within a known network, the router forwards the packet to the next-hop router for that destination network. After the packet leaves the router, the next-hop router is responsible for
forwarding the packet to its final destination. The entire route is not known at the onset of the journey, just the next hop. If the router does not have the destination network in its routing table, it does one of two things: The router either forwards the packet to a predetermined default router, or it drops the packet and informs the sending device that the network is not reachable. It is important to note when routing a packet that as the packet moves through the internetwork, its destination and source network addresses always stay the same. But, since the packet is moving across several data links, the destination and source MAC addresses change with each data link. In the diagram below, assume the computer wants to converse with the server. Since communications are being carried out over multiple networks, the computer needs to encapsulate the data with a destination and source network address. Without this information, the routers would not know where to forward the packet. Since the packet also needs to be transmitted to the router over a data link, the computer encapsulates the packet in a frame with a destination and source MAC address. (Note: Because the router maintains an interface on the data link, it follows the same MAC protocol and MAC addressing standard as every other device on the shared medium.) As the packet moves from network to network, the frame information is stripped off the packet and replaced by new frame information with MAC addressing significant to the current data link. When the packet reaches the final router, the router knows that the destination network is directly attached and forwards the packet to the MAC address of the destination.
The previous section mentioned that when the computer has data it wants to send to a device on a different network, it sends its frames to the router and lets the router deliver them. How does the sending device know that the receiving device is on another network? To that extent, how does the sending device know what the address of the router is? The device knows that the recipient is on another network by doing a simple comparison between its network address and the network address of the recipient. If the two do not match, the sender knows the frame is destined for another network. How does it know what address the router is? When using network-level addressing, all devices on the data link need to be configured with what is called a default gateway
address. The default gateway address is the address of the router. The communication protocol then states: If the destination network doesn't match your own network, forward the frame to the default gateway for delivery. Remember the fundamental concept of routing: As the data moves through the network, the destination and source network addresses stay the same, while the data-link address changes with each different network. Like the mailman, routers in general are concerned only with the location of networks and not the individual devices residing on the network. The exception is when the router sees that the destination network is directly connected to it. When the mailman can match the address on the envelope to an address on his route, he needs to know how to leave the mail. Some addresses may have mail boxes, while some have mail slots. The mailman needs to know how every address on his route likes to receive mail. When a router needs to deliver a packet to its final network destination, the router acts as a station on the data link and transmits the data according to the proper MAC protocol. Routers use routing tables to store information about destinations in the internetwork. Some routing protocols maintain an entry for each possible path to a destination. Other protocols maintain only the most desirable path to each destination. Information that a routing table contains includes the destination address, interface, and the desirability of a path. An IP routing table consists of destination address/next-hop pairs. The next hop is the IP address of the router that the outbound packet is handed to. Routing table entries can be interpreted as meaning: To reach network A, send the packet out Node A via interface 0. Destination/Next-Hop Routing Table To Reach Network: 27 57 17 24 52 16 26 Send Packet to Node: Node A Node B Node C Node A Node A Node B Node C Via Interface: Interface E0 Interface E1 Interface E2 Interface E0 Interface E0 Interface E1 Interface E2
Routers communicate with one another (and maintain their routing tables) through the transmission of a variety of messages. The routing update message is one such message. Routing updates generally consist of all or a portion of a routing table. By analyzing routing updates from adjacent routers, a router can build a detailed picture of network topology.
A link-state advertisement is another example of a message sent between routers. Linkstate advertisements inform other routers of the state of the sender's links. Link information can also be used to build a complete picture of network topology. When the network topology is understood, routers can determine optimal routes to network destinations.
Locating computer systems on an internetwork is an essential component of any network system. Various addressing schemes are used for this purpose, depending on the protocol family being used. In other words, AppleTalk addressing is different from TCP/IP addressing, which in turn is different from Open System Interconnection (OSI) addressing, and so on. Unlike link-layer addresses, which usually exist within a flat address space, networklayer addresses are hierarchical. In other words, they are like mail addresses, which describe a person's location by providing a country, a state, a zip code, a city, and a street. Hierarchical addresses make address sorting and recall easier by eliminating large blocks of logically similar addresses through a series of comparison operations. For example, all other countries can be eliminated if an address specifies the country Ireland. Easy sorting and recall is one reason that routers use network-layer addresses as the basis for routing. Network-layer addresses differ, depending on the protocol family being used, but they typically use similar logical divisions to find computer systems on an internetwork. Some of these logical divisions are based on physical network characteristics (such as the data-link segment a device is located on); others are based on groupings that have no physical basis (for example, the AppleTalk zone). End systems require one networklayer address for each network-layer protocol they support (assuming that the device has only one physical network connection). Routers and other internetworking devices require one network-layer address per physical network connection for each networklayer protocol supported. For example, a router with three interfaces, each running AppleTalk, TCP/IP, and OSI, must have three network-layer addresses for each interface. The router, therefore, has nine network-layer addresses. One final concept in network addressing must be understood: the host address. We've learned that the data-link address is significant only to the local segment and that when the frame enters a router, the data-link addressing is stripped off and just the packet passes from router to router. So how does the router know which data-link address to send the packet to when it gets to the proper network? The answer to the question is that all devices on the network need their network address to be broken down into two parts, a network identifier and a host identifier. Conceptually, you may think of this like a street address. Most, if not all, street addresses are broken down into two parts, the actual name of the street and a number representing each house on the street. The mailman must know both of these pieces of
information about the street address in order to get the mail to its final destination address. The street name corresponds to the network identifier, and the house number corresponds to the host identifier. On a router, when the final network identifier address is reached, the router looks at the network, host identifier section of the address. Since the router is participating on the local data-link segment, it maintains a list of all the data-link addresses and corresponding network addresses on the segment. At this point, delivering the data is a simple matter of matching the incoming host identifier with an entry in the MAC address table of the router and encapsulating the packet with the proper data-link MAC address.
RFC 791 states: The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. This is done by passing the datagrams from one internet module to another until the destination is reached. The internet modules reside in hosts and gateways in the internet system. The datagrams are routed from one internet module to another through individual networks based on the interpretation of an internet address. Thus, one important mechanism of the internet protocol is the internet address..... A distinction is made between names, addresses, and routes. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primarily with addresses. IP addresses are globally unique, 32-bit numbers assigned by the Network Information Center (NIC). Globally unique addresses permit IP networks anywhere in the world to communicate with each other. For simplicity and clarity, these bits are normally represented as four sets of octets (8 bits per octet, or 1 byte). Each octet is then represented as a decimal number between 0 and 255 and separated by a period, or dot. This scenario is known as dotted-decimal notation. For example, a 32-bit IP address could be the following: 10101100000100000011001000001010 To represent this address in standard format, we break the address down into 4 octets (8-bit segments): 10101100 00010000 00110010 00001010
and convert each of the octets into a decimal number:
172
16
50
10
The address is then written as 172.16.50.10 and spoken as""172 dot 16 dot 50 dot 10." Remember that the dotted decimal notation is just a convention used to make working with 32-bit IP addresses easier. As far as devices on the network are concerned, they are dealing with a single 32-bit binary number. As mentioned in the Network Addressing section, network addresses are broken down into two parts, a network identifier and a host identifier. In IP, the portion of the overall IP address allocated to the network and host identifiers varies, making IP very flexible in the number of networks and hosts it can accommodate. In IP, the network identifier is commonly referred to as the network prefix, and the host identifier as the host portion. These terms are used for the remainder of this module. For example: Here, more of the bits are allocated to the network prefix: Network Prefix: 101011000001000000110010 Host Portion: 00001010
This setup allows for more networks. In the next example, more of the address is allocated to the host portion: Network Prefix: 101011000001 Host Portion: 00000011001000001010
so more possible host combinations are available. Classful Addressing In general, there are basically three types of networks: large, medium, and small. They can be described as follows:
Large networks have a tremendous number of hosts (in the millions) per network. There are very few large networks. Medium networks fall in the range between large and small networks. Small networks have a small number of hosts per network. A large number of networks fall into the small category.
To accommodate different size networks and aid in classifying them, IP addresses are divided into categories called classes. Each of the IP classes is designed to accommodate a different size network. As stated in RFC 791:
To provide for flexibility in assigning address to networks and allow for the large number of small to intermediate sized networks, the interpretation of the address field is coded to specify a small number of networks with a large number of host[sic], a moderate number of networks with a moderate number of hosts, and a large number of networks with a small number of hosts. This scenario is known as classful addressing, and it follows a few basic rules:
Each class uses subsequently fewer of the bits in the address as the host portion and subsequently more of the bits as the network prefix. The boundary between the network and host identification sections is fixed in each class. Each class uses the most significant bits of the address to identify where the boundary is.
The following table describes how classful addressing works:
When viewed in context of the dotted-decimal notation, this translates to: Class A Class Identifier First octet in the range 1–126* Network Prefix First octet N.H.H.H or 1.xxx.xxx.xxx to 126.xxx.xxx.xxx First two octets N.N.H.H or 128.0.xxx.xxx to 191.255.xxx.xxx First three octets N.N.N.H or 192.0.0.xxx to 223.255.255.xxx Host Portion Remaining three octets N.H.H.H or xxx.0.0.0 to xxx.255.255.255 Remaining two octets N.N.H.H or xxx.xxx.0.0 to xxx.xxx.255.255 Remaining octet N.N.N.H or xxx.xxx.xxx.0 to xxx.xxx.xxx.255
B
First octet in the range 128–191
C
First octet in the range 192– 223**
*Note that addresses starting with 0 and 127 are reserved. ** Addresses allocated in the range beyond 223 (224–254) will be discussed later:
Class D addresses are reserved for multicast groups. In Class D addresses, the four highest-order bits are set to 1110 (224–239). Class E addresses are also defined by IP but are reserved for future use. In Class E addresses, the four highest-order bits are all set to 1 (240–254).
To provide further functionality, some IP addresses are reserved for special purposes. First is the address 0.0.0.0. The all-zeros address is reserved as the default network, which is used in routers as a way to identify where to send a packet when there is no match for it in a routing table. Next is the network 127.0.0.0. This address is known as the internal loopback network. Routers or other devices can use this address to send packets to themselves. Any address with all the host bits set to zero is used to represent the address of the network itself. This concept can be a bit confusing. A good way to think of it is a street address that contains only the name of the street. Generally, devices should not use host address where all the host bits are set to zero, because it can confuse routing protocols (see the IP Subnet Zero section for more information on this subject). Finally, addresses with all the host bits set to 1 are known as broadcast addresses. Every device on the network will receive packets addressed to the broadcast address. So, typical classful IP addresses look like the following: Class A host address: 124.32.90.10 Class B network address: 172.68.0.0 Class C broadcast address: 212.200.50.255 All networks broadcast address: 255.255.255.255 Default route: 0.0.0.0 Given the above parameters, this system allows for the following combinations of valid Internet network and host addresses: Class Possible Networks Possible Hosts Total Possible Host Addresses Percent of Total Available Address 50%
A
126
16,777,214
2,113,928,964
B
16,384
65,534
1,073,709,056
25%
C
2,097,152
254
532,676,608
12.5%
(To determine the number of possible networks or hosts, use the formula 2n – 2, where n is the number of bits in the network or host space. The subtraction of 2 is for the actual network and broadcast address. Note that the table above is meant to show only the available host addresses in a given network. It is possible that these numbers may be slightly larger with the use of the ip subnet-zero command covered later in this section, but these numbers are generally correct. As noted, the numbers above also exclude the broadcast address of each network, since these may not be assigned to a host.) Several networks are reserved for private use and cannot be used on the Internet. They include: Class A B Address Range 10.x.x.x 172.16.x.x through 172.31.x.x 192.168.x.x
C
These addresses are commonly used for corporate intranets and for testing. When the Internet Protocol was first proposed in the early 1980s, classful addressing, in theory, seemed to provide a limitless amount of address space. In practice, it became quickly apparent that there were limitations. The major drawback to the system is that, although easy to understand and implement, the boundaries set by the Class A, B, and C addresses do not foster efficient use of the available addresses.
From the table above, you can see that the Class A address space uses a full 50 percent of the available address space, but it allows for only 126 separate networks. Since there are actually very few organizations assigned Class A addresses, a large portion of the total address space goes unused. The Class C address, with only 254 possible hosts, is often too small, causing an organization to move to a Class B address. But the Class B, with ~65,000 hosts, is often too large, causing tens of thousands of addresses to go unused. Remember, each link must be uniquely identified, so if an organization has two separate data-link segments with 300 stations on each, it will need two Class B addresses and will effectively use 130,000 addresses for 300 stations! In response to this problem, organizations use multiple Class C addresses instead of using a single Class B address. But this has the negative impact of
increasing the size of the global Internet routing table because more networks need to be tracked. Because every data link needs to be uniquely identified, there just are not enough network addresses to go around. The rapid growth of corporate intranets, when compounded with the explosion of the Internet, has created a demand for network addresses that the original classful addressing scheme could not meet.
In order to address these problems, a modification to the system is needed that allows the addresses to be used more efficiently. In 1985, RFC 950 was written to standardize a procedure for dividing Class A, B, and C networks into smaller, more manageable sections. This procedure is known as subnetting.
The classful address scheme creates a two-level hierarchy in the Internet: a top level representing the Internet as a whole, and a level below representing the individual networks. For the reasons stated above, what is really needed is a three-level hierarchy that allows for networks to be divided into smaller segments, or subnets. To accomplish this, the host portion of the address is broken down into two sections, a subnet number and the remaining host portion: Two-Level Classful Hierarchy:
Network Prefix
Host Portion
Three-Level Subnet Hierarchy:
Network Prefix
Subnet Number
Host Portion
The subnet number now identifies a local segment attached to the router. Because only the network portion of the address is advertised to the Internet, subnetworks are only locally significant. Here's how subnetting works: Suppose you have been assigned the network address of 128.60.0.0. Converting this from dotted-decimal notation into binary, you get: Network Prefix 128 60 0 Host Portion 0
1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 If you take the first four bits of the host portion and use them to identify subnets, you get the following possible binary combinations: Network Prefix Subnet Host Portion
1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 Converting these addresses back to dotted-decimal notation, you get: Network Subnet/Host Prefix Portion 128 60 128 60 128 60 128 60 128 60 128 60 128 60 0 16 32 48 64 80 96 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
128 60 112 128 60 128 128 60 144 128 60 160 128 60 176 128 60 192 128 60 208 128 60 224 128 60 240
Now in addition to having the major network of 128.60.0.0, you also have up to 16 subnetworks: 128.60.0.0, 128.60.16.0, 128.60.32.0,...128.60.240.0. Each of these subnetwork addresses can be used to define a data-link segment, with the remaining 12 bits of each subnet being used to identify specific hosts on those segments. Note, however, that the subnet 128.60.0.0, which is the same network as the major network, is only available as a subnet if you are using the ip subnet-zero command. The zero subnet will be further explained later in this section. Because the network prefix is the only portion of the address that is significant to the Internet, the subnets are not visible outside of the private network of the local organization. The route from the Internet to any subnet of a given IP address is the same, no matter which subnet the destination host is on. It is the job of the local routers to determine which subnet a particular host is on. This setup reduces the complexity of the Internet routing table because only a single network address is needed to reach an organization, and also prevents the depletion of available network addresses because each data link does not need to take up a full IP network. If we look at the 128.60.16.x subnet and start assigning hosts, we can create addresses 128.60.16.0 through 128.60.31.255: Network Prefix 128 128 128 128 128 ... 128 128 128 128 128 60 60 60 60 60 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 0 0 1 1 1 0 1 0 1 60 60 60 60 60 Subnet Host Portion
0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0
Anything beyond 128.60.31.255 is on the next subnet. The 128.60.32.0 to 128.60.47.255 subnet follows: Network Prefix 128 128 128 60 60 60 Subnet Host Portion
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0
128 128 ... 128 128 128 128 128 60 60 60 60 60 0 0 0 0 0
60 60
0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0
0 0 0 0 0
1 1 1 1 1
0 0 0 0 0
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
0 1 1 1 1
1 0 0 1 1
1 0 1 0 1
The bits that are used for the network number and subnet number are commonly referred to together as the extended network prefix.
A device needs a way to tell what subnet it is located on. As you learned in the addressing section, a device learns the class of its address from the most significant bits of the address (for example, if the first 2 bits are "10," the device knows that the first 16 bits of the address indicate its network and the last 16 bits indicate its host address). With subnetting, a way is needed to tell the device to look beyond its class to determine its subnet. This is done via a subnet mask. A subnet mask is a 32-bit binary number that corresponds bit for bit to the IP address of the device. The bits of the subnet mask are set to 1 if the system examining the address should treat the corresponding bit in the IP address as part of the extended network prefix. The bits in the mask are set to 0 if the system should treat the bit as part of the host number. Only extended network prefixes using contiguous bits that are flush left against the network field are supported. For example, a subnet mask for the example above would read: 11111111111111111111000000000000 There are sixteen 1s for the network address portion and four 1s for the subnet. The dotted-decimal notation is again used as a way to simplify reading subnet masks. The mask above would be read as 255.255.240.0. 11111111 11111111 11110000 00000000 255 255. 240. 0
Another way to represent the mask above is to annotate the number of bits in the subnet mask. The mask above could also be referred to as 20 bits of masking, or /20 following the address: 128.60.16.40 /20.
When present, routing protocols carry the full 32-bit subnet mask and not just a one-byte field in their header that contains the number of bits in the extended-network prefix. When a device is configured with an IP address, it now needs two pieces of information in order to calculate what its host address is and what its subnet and network are: the actual address and the mask. The device calculates what subnet it is on by doing a logical "AND" between its address and the mask. Performing an "AND" operation means that anytime you "AND" a 0 value to another 0 or a 1 value, the result is 0. Only a 1 ANDed with another 1 value will result in a 1 value. Here's how it works: 0 AND 0 IS 0 0 AND 1 IS 0 1 AND 1 IS 1 Some examples follow: Example 1: Class B Let's use a Class B address to illustrate how subnetting works. Let's say you were assigned the Class B address 172.16 from the Network Information Center (NIC). First determine how many subnets you need, and how many nodes per subnet you need to define. A typical (and easy-to-use) Class B subnet mask would be 8 bits. Since the third octet is the first "free" octet for Class B, you will start there. So, an 8-bit subnet mask would be 255.255.255.0. This means you have 254* subnets available and 254 addresses for nodes per subnet. *Why are there only 254 subnets available instead of 256 (0–255)? You should not use subnet 0 or a subnet of all 1s. With an all 1s subnet mask, this is also your broadcast address. You can configure this subnet, but it is neither proper nor recommended to make your subnet the same as your broadcast address. Subnet 0 is also not recommended. Cisco allows the use of subnet 0 with the ip subnet-zero command. Example 2: Class B Let's say you have just assigned an interface the address 172.16.10.50 with a mask of 255.255.255.0. What subnet is it in? First represent the bits in binary (for Class B, you start with the third octet since octets 1 and 2 are fixed). SUBNET HOST 00001010 00110010 (address representation - 10.50) 11111111 00000000 (subnet mask representation - 255.0) ----------------00001010 00000000 (results of logical "AND" - subnet 10)
This address is in subnet 10 (172.16.10.0). Valid addresses for subnet 10 would be 172.16.10.1 through 172.16.10.254. Address 172.16.10.255 is the broadcast address for this subnet. According to the standard, any host ID consisting of all 1s is reserved for broadcast. Example 3: Class B Let's say you have a need for more subnets than 254. (Remember, this is the maximum number of subnets in a single octet.) Sticking with our Class B address, let's configure an 11-bit subnet. This means we will use all 8 bits from our third octet and the first three bits from the fourth octet. The subnet mask is now 255.255.255.224 (128 + 64 + 32 = 224). Now you need to find out what subnet the following address is in: 172.16.10.170 255.255.255.224. First, denote the address in binary representation (just octets 3 and 4 for a Class B address) like this: 00001010 10101010 (address representation 10.170) 11111111 11100000 (subnet mask representation 255.224-first 11 bits subnet) ----------------00001010 10100000 (results of logical "AND") 10 160 So, the address here is in subnet 172.16.10.160. The valid addresses for this subnet are 172.16.10.161 through 172.16.10.190 (.191 is the broadcast address). As soon as you hit 10.192, the bits in the subnet change and you move into subnet 10.192. Example 4: Class B Consider an example where the mask is shorter than one octet. Now we want only a few subnets, but need many hosts per subnet. We'll use a 3-bit subnet mask. Now we have: 172.16.65.170 255.255.224.0 (the mask is now the first 3 bits of the third octet). What subnet is this address in? 01000001 10101010 (address representation 65.170) 11100000 00000000 (subnet mask representation 224.0) ----------------01000000 00000000 (results of logical "AND" - subnet 64) 64 So the subnet here is 172.16.64.0. The range of addresses that would fall into subnet 64 would be 172.16.64.1–172.16.95.254, with 172.16.95.255 as the broadcast address. The next subnet would be 172.16.96.0. Class A and Class C map out exactly as Class B. The only differences are the octet at which subnetting starts and how many octets you can use for subnetting.
Example 5: Class C Suppose the NIC assigned the address 192.1.10. You will need to use the fourth octet for your subnetting needs. Let's use a 4-bit subnet mask and map out the following address: 192.1.10.200 255.255.255.240: 11001000 (address representation for 200) 11110000 (subnet mask representation for 240) -------11000000 (results of logical "AND" - 128+64=192) So, address 192.1.10.200 is in subnet 192. The valid range of addresses in this subnet would be 192.1.10.192 through 192.1.10.206, with .207 as the broadcast address. The next subnet would be .208. Keeping the same subnet mask, you can choose different addresses to be in different subnets. For instance, address 192.1.10.17 255.255.255.240 is in subnet 16 and, therefore, has another unique subnet address, with valid addresses in the range of 192.1.10.17 through 192.1.10.30. If you want no subnetting, use these default masks (255 — strictly follow number, 0 — wildcard): Class A: 255.0.0.0 Class B: 255.255.0.0 Class C: 255.255.255.0 How does a router using a routing protocol that does not transmit masking information know what mask to use when it learns a new route? If the router has a subnet of the same network number assigned to a local interface, it assumes that the learned subnetwork was defined using the same mask as the locally configured interface. If the router does not have a subnet of the learned network number assigned to a local interface, the router has to assume that the network is not subnetted and applies the natural classful mask of the route. Subnet Design Considerations Below is a handy chart that can help you determine how much subnetting to use: Host/Subnet Quantities Table Class B # bits ------2 3 Mask --------------255.255.192.0 255.255.224.0 Effective Subnets --------2 6 Effective Hosts --------16382 8190
4 5 6 7 8 9 10 11 12 13 14 Class C # bits ------2 3 4 5 6
255.255.240.0 255.255.248.0 255.255.252.0 255.255.254.0 255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
14 30 62 126 254 510 1022 2046 4094 8190 16382 Effective Subnets --------2 6 14 30 62
4094 2046 1022 510 254 126 62 30 14 6 2 Effective Hosts --------62 30 14 6 2
Mask --------------255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
*Subnet all zeroes and all ones excluded. *Host all zeroes and all ones excluded.
Recall that you should not use a subnet address in which all the subnet bits are set to zero. The reason is that some routing protocols do not transmit the subnet mask being used on a network in their routing updates. The protocols Routing Information Protocol (RIP) Version 1 and Interior Gateway Routing Protocol (IGRP) are two such protocols. RIP Version 2, however, does transmit the subnet mask. When no masking information is available, the routing protocol assumes that the address is configured for traditional classful addressing and sometimes cannot tell the subnet address from the network address. For example: 128.60.0.0/16 10000000.00111100.|00000000.00000000 128.60.0.0/24 10000000.00111100.|00000000.|00000000 In this example, if a data-link segment has been assigned the subnet of 128.60.0, the router may not be able to tell the difference between that subnet and the entire 128.60 network. It is important to remember that the dotted-decimal format is just a representation of the 32-bit address and mask. An address on subnet 0 can sometimes be hard to determine because of this. For example:
192.10.20.50/24 11000000.00001010.00010100.|00110010 192.10.20.50/26 11000000.00001010.00010100.|00|110010 In the first example, 192.10.20.50 is on the 192.10.20 network, a setup that is fine. But in the second example, 192.10.20.50 is on the 192.10.20.0 subnet, a setup that could be a problem. Configuring addresses in the subnet zero range is generally not recommended because of the confusion inherent in having a network and subnet with indistinguishable addresses, as in Example 1 above. If you truly need to use subnet zero, you can add the ip subnet-zero command in the router configuration. This setup allows users to configure addresses in the subnet zero subnet.
Route summarization procedures condense routing information. Without summarization, each router in a network must retain a route to every subnet in the network. With summarization, routers can reduce some sets of routes to a single advertisement, reducing both the load on the router and the perceived complexity of the network. The importance of route summarization increases with network size. The diagram below illustrates an example of route summarization. In this environment, Router R2 maintains one route for all destination networks beginning with B, and Router R4 maintains one route for all destination networks beginning with A. This setup is the essence of route summarization. Router R1 tracks all routes because it exists on the boundary between A and B.
Route Summarization Example
The preceding example shows the simplest type of route summarization: collapsing all the subnet routes into a single network route. Some routing protocols also support route summarization at any bit boundary (rather than just at major network number boundaries) in a network address. A routing protocol can summarize on a bit boundary only if it supports variable-length subnet masks. Some routing protocols summarize automatically. Other routing protocols require manual configuration to support route summarization.
Traditionally, all subnets of the same network number use the same subnet mask. In other words, a network manager chooses an 8-bit mask for all subnets in the network. This strategy is easy to manage for both network administrators and routing protocols. However, this practice wastes address space in some networks. Some subnets have many hosts and others have only a few, but each consumes an entire subnet number equal to the needs of the largest subnet. Serial lines are the most extreme example,
because each has only two hosts that can be connected via a serial-line subnet. Consider the following network:
Suppose you have been assigned a Class C address of 192.168.100.0 and need to subnet the address to accommodate this network. With traditional subnetting techniques, you would not be able to accomplish this task. You would need to allocate at least 100 host addresses for the Token Ring segment requiring 7 bits for host address, so you would have only 1 bit for subnetting and would be able to create only two subnets (192.168.100.0 and 192.168.100.128). As IP subnets have grown, administrators have looked for ways to use their address space more efficiently. One of the techniques that has resulted is called variable-length subnet mask (VLSM). With VLSM, a network administrator can use a long mask on networks with few hosts and a short mask on subnets with many hosts. In order to use VLSM, a network administrator must use a routing protocol that supports it. Cisco routers support VLSM with Open Shortest Path First (OSPF), Integrated Intermediate System-to-Intermediate System (Integrated IS-IS), Enhanced IGRP (EIGRP), RIP Version 2, and static routing. In the example above, a solution can be obtained by using VLSM in the following manner: 1. For the Token Ring segment, we know we need at least 100 host addresses, so using the standard formula 2^n >100, we know that 7 bits must be used for the host portion on this segment, leaving 1 bit for the subnet address. Using 1 bit of subnetting allows for the creation of two subnets, 192.168.100.0 and 192.168.100.128. For the Token Ring segment, we can assign the hosts 192.168.100.1 through 192.168.100.126. This leaves us with 192.168.100.128 and above.
Network Address 192 192 168 168 100 100
Subnet / Host 0 x x x x x x x 1 x x x x x x x
2. Taking the next highest density of hosts, 25 on each Ethernet segment, we know that we need 2^n > 25 or 5 bits for host addresses, leaving 3 bits for subnetting. Using 3 bits of subnetting on the 192.168.100.x network gives us the 192.168.100.128, 192.168.100.160, 192.168.100.192, and 192.168.100.224 subnets. Since we need to assign host addresses only in the first two subnets, we still have everything above 192.168.100.192 to work with.
Network Address
Subnet/Sub-Subnet / Host
192 168 100 1 0 0 x x x x x 192 168 100 1 1 0 x x x x x 192 168 100 1 1 1 x x x x x 3. The next highest number of hosts is the 10 on the Fiber Distributed Data Interface (FDDI) ring. For 10 hosts, we need 2^n > 10, or 4 bits for host address, leaving 4 bits for subnetting. Applying 4 bits of subnetting to 192.168.100.x, we get the 192.168.100.192, 192.168.100.208, 192.168.100.224, and 192.168.100.240 subnets. Since we need only ten host addresses, we still have everything above 192.168.100.208 to deal with.
Network Address
Subnet / SubSubnet/Host
192 168 100 1 1 1 0 x x x x 192 168 100 1 1 1 1 x x x x 4. The remaining segment, a serial link, needs only two host addresses, so it needs only 2 bits for host addresses (2^n > 2), leaving 6 bits for the subnet portion. Applying these bits, we get subnets 192.168.100.208 through subnet 192.168.100.252. We can use the first subnet for the serial link since it gives us two host addresses, 192.168.100.209 and 192.168.100.210. The remaining subnets are reserved for future use.
Network Address
Subnet /Sub-Subnet/ Host
192 168 100 1 1 1 1 0 0 x x
192 168 100 1 1 1 1 1 0 x x 192 168 100 1 1 1 1 1 1 x x
After using VLSM, an address assignment for the network might be the following:
From the steps in the example, you should be able to see a pattern when using VLSM. By filling in the available bits in the subnet/host section from right to left, you can create progressively smaller subnets within the overall network segment. Conversely, the same pattern will work for host addresses if you need to add more hosts to a subnet. By filling in the bits from left to right and paring down the amount of subnet bits, you can create a larger pool of host addresses. Remember, to take advantage of VLSM, you must be using a routing protocol that supports it, such as EIGRP or OSPF.
VLSM provides the ability to aggregate routes in order to reduce the overall size of, and simplify, the routing table. Like route summarization, route aggregation is the process that combines multiple subnets into a single routing update. In the following example,
route aggregation is used to simplify the routing tables:
In this example, the subnets of 172.68.70 are aggregated to a 24-bit mask when advertised. Similarly, the subnets of 172.68.60 are also aggregated to a 24-bit mask. The result is that only one entry is needed in each router to get to various subnets. To effectively utilize route aggregation, the IP addressing scheme must be topologically significant. Subnets must be assigned in a manner so that they are contiguous to one another. Supernetting Supernetting is the opposite of subnetting. Subnetting is the process of taking a network and dividing it into smaller subnetworks. Supernetting is the process of taking several discrete networks and advertising them in one routing update; for example, if an organization had been assigned a full block of Class C addresses, say 192.10.1.0 /24 to 192.10.254.0 /24. Instead of advertising 254 separate networks to the Internet, the organization may advertise only the single route to 192.10.0.0 /16 to the Internet. Full connectivity is possible because any datagram destined for a 192.10.x network is bound for the same organization. When the packet gets to the organization, it is the responsibility of the routers of the organizations to get the datagram to the proper network.
Supernetting is a component of an overall concept known as classless interdomain routing, described in the next section. In order to use supernetting techniques on Cisco IOS® routers, you must use the global configuration command ip classless.
A network is referred to as discontiguous if it has been subnetted but the subnets are not physically accessible to each other via a router. In the example below, note that the 172.70 network is configured with a 24-bit mask and two subnets have been created, 172.70.10.x and 172.70.20.x. But also notice that to get to one subnetwork from the other, you must cross a different network, 172.68.
Discontiguous networks may cause problems when route summarization is taking place. Because the routers in the example are attached by the 172.68 network, they will summarize the 172.70 network in their routing updates to each other. When the routing update is received, each router will see that it has both a connected route to the 172.70 network and a more specific route to the 172.70 network via its subnet. For some routing protocols, such as RIP V.1 and IGRP, this scenario will cause routing problems.
In RIP V.1, for example, the router will disregard an update for a summarized route if it has a directly connected route to the same network.
Classless interdomain routing, or CIDR, is based on "route aggregation," the process of creating a single piece of routing information that specifies how to handle traffic for many destinations. In some ways, the result of this process is similar to that of IP subnetting. With subnetting, what appears to the outside world as a single IP network is actually broken up into numerous smaller subnets, each of which typically corresponds to a serial link or a LAN segment. With CIDR, several IP networks are combined, from the point of view of networks outside the group, into a single, larger entity. Under CIDR, any entry in the routing table of a router describes the path to a class of IP destinations whose addresses share a given initial bit string. Such an entry is called a "prefix route;" the shared initial bit string is a prefix of the address of every destination that the route covers. An ordinary IP network route is a prefix route; a route to the Class C network 198.92.35.0 includes all IP addresses whose first three bytes are 198, 92, and 35. CIDR is different in that prefixes can be of any length; it would be valid for a route to include, for example, all IP addresses that started with 198 and 92, even though that route would cover 256 entire Class C networks. Consider the following scenario: Company X buys its Internet connection from Network Service Provider A. Internally, Company X uses two Class C networks, each of which is divided into four subnets, with the network mask 255.255.255.192 assigned to each network. Under CIDR, Company X receives its addresses from Provider A instead of getting them directly from the central addressing authority. Provider A has a block of Class C networks assigned to it by the central authority. For example, suppose Provider A has been assigned networks 207.42.0.0 through 207.42.255.0. Provider A assigns Company X two network numbers from this bloc—say 207.42.12.0 and 207.42.13.0. One of the side benefits of CIDR is that it makes it easy to use Class C network numbers in this way. There was a time when Company X would have been assigned a Class B network address. In that situation, most of the IP addresses assigned to Company X would have gone unused. Because Class B address space is in danger of exhaustion, Class C network numbers are now being assigned in blocks, and CIDR makes it possible to support this approach easily. Under the original IP model, routers belonging to the major backbone networks and to many other service providers would have to keep track of individual routes for both of Company X's network numbers and for networks belonging to any of Provider A's other subscribers. Under CIDR, those routers instead maintain knowledge of a route to Provider A's entire network number range; they know that all addresses of the form
207.42.x.y belong to Provider A's subscribers, and that datagrams for those addresses should be sent to Provider A. Under the old scheme, routers that lie outside Provider A's network might have had to keep as many as 254 routing table entries for 207.42.x.0 networks. With CIDR, one routing table entry is enough. CIDR operates much the same way as IP subnetting—by assigning a bit mask to each routing table entry. This mask is really a way of specifying the length of the prefix associated with each routing table entry. Bits that are set to 1 in the mask are considered to lie within the prefix, while bits that are set to 0 lie outside the prefix and are not important for destination matching. A mask of 255.0.0.0, for instance, means that the prefix length is 8 bits. Any IP address whose first byte is the same as that of the address specified by the routing table entry is matched. For instance, a route to 145.0.0.0 with a mask of 255.0.0.0 would match a packet addressed to 145.13.1.2. A route to 145.12.0.0 with a mask of 255.255.0.0 would not match that packet because the second octet in the destination address of the packet (13) lies within the prefix of the route and doesn't match the second octet in the destination of the route (12). With subnetting, the mask always covers the IP network field of the address (and need not strictly specify a prefix, although Cisco strongly recommends against the use of such discontiguous masks, even for subnetting). Therefore, all the network-field bits are always significant in deciding whether or not a particular routing table entry matches a given destination address. With CIDR, the mask may exclude some parts of the IP network field from the routing decision. Routers don't use ordinary IP addressing classes to choose which parts of the address are significant for the routing decision; only the mask associated with the routing entry is important. For our example, routers outside of Provider A's network would have a routing entry for 207.42.0.0, with a mask of 255.255.0.0. That entry would send traffic for all of Provider A's subsidiary networks to Provider A via some common path. Provider A itself would, of course, need to maintain an individual routing entry for each of the subnets to which it had assigned addresses. These subnets would be reachable through different border routers. However, if two of the subnets were reachable by the same path, Provider A could choose to use a single route for both of them. Suppose, for example, that Company X had only one border router, which Provider A used to reach both networks 207.42.12.0 and 207.42.13.0. Each of Provider A's routers could then maintain a single routing entry for 207.14.12.0 with mask 255.255.254.0. Because the least-significant bit of the third byte wouldn't be significant for deciding whether this route was applicable, it would direct traffic for both 207.42.12.0 and 207.42.13.0 to Company X's border router. Now, suppose that Company X were to change network providers and start using Provider B. It would no longer be appropriate for all of Company X's traffic to be sent to Provider A. From the point of view of routing efficiency, the best way for Company X to
respond would be to change all its IP addresses—an arduous task. Company X might be slow to make the change, if indeed it can change the addresses at all. A better solution is for routers to create and propagate throughout the Internet what's known as an "exception route," so that all traffic for 207.42.0.0 would be sent to Provider A, with the exception of traffic for 207.42.12.0 and 207.42.13.0, which would be sent to Provider B. The CIDR approach implements such exceptional routes by using a longest-prefix rule. If a destination of a packet matches two routing table entries, the router uses the entry with the longest matching prefix. That entry is more specific than the one with the shorter prefix and presumably represents an exception route. For an IP route, having a longer matching prefix is equivalent to having more bits in its mask set to 1. To avoid ambiguity, discontiguous subnet masks (masks with zero bits between the one bits) aren't used in CIDR. Routing Protocols for CIDR To make CIDR useful in the Internet, service providers must be able to exchange prefix routing information. The Border Gateway Protocol (BGP) routing protocol used between most service providers has been enhanced in Version 4 to support prefix routes. The major change to the protocol consists of explicitly passing bit masks in routing updates instead of having the routers infer prefix lengths from IP address classes. In addition, the interior routing protocol used with CIDR must support classless addresses. Cisco supports this capability, too, with the routing protocols EIGRP, OSPF, and IS-IS.
On some media (such as IEEE 802 LANs), media addresses and IP addresses are dynamically discovered through the use of an additional member of the Internet Protocol suite: the Address Resolution Protocol (ARP). ARP uses broadcast messages to determine the hardware Media Access Control (MAC)-layer address corresponding to a particular internetwork address. ARP is sufficiently generic to allow use of IP with virtually any type of underlying media-access mechanism.
The ARP process works in the following manner:
A default route is a routing table entry that is used to direct frames for which a next hop is not explicitly listed in the routing table. Using a default route allows the router to be aware only of the destinations internal to its own administrative systems. This setup can be beneficial in large networks, where topology changes occur often. In smaller networks, default routes can also be useful because of decreased memory and processor utilization. However, with smaller networks, the benefits of default routes decrease as the number of routes decreases. Several types of routes fall into this category: Gateway of Last Resort A gateway of last resort is a destination network that a router should send packets to if it does not have a specific entry to the destination network in its routing table. The gateway address can either be configured directly on the router or it can be learned from another router. To designate a route as the gateway of last resort in Cisco IOS® software, use the ip default-network command. Often there is confusion between the ip default-network command and the ip defaultgateway command. The ip default-gateway command is used when the router does not have IP routing configured. Its purpose is to tell the router the address of the next hop to which to send packets that are not for a locally connected network. The ip default-network command tells the router which network to send a packet to if it does not have a more specific entry in the routing table. The ip default-gateway command has no effect on IP routing if IP routing is turned on.
Note that when using the ip default-network command the router needs to know how to get to the specified default network, through either the routing table or a static route. Also note that default networks do not apply for routes to subnets of a local connected major network. Static Routes A static route is a route that you manually configure into a routing table. With a static route you can specify that packets destined for a specific network, subnet, or host should be forwarded to a desired network or interface. You can also assign administrative distances to static routes. To configure a static route, use the ip route destination mask next-hop/interface distance command. When using static routes, be sure to understand that the router will forward packets to the next hop even if the final destination is no longer valid. This scenario can cause undesirable results. By default, static routes are not advertised to other routers. If you want a static route to be advertised, use the redistribute static command. Static routes by default have a distance of 1, so the router will always choose the static route over one learned dynamically unless configured to do otherwise. Floating Static Routes A floating static route is a static route that is configured with an administrative distance greater than that of the same route learned dynamically. A floating static route will cause the router to use the dynamic route until it is lost, and then switch to the static route. This setup is useful when using dialup connections as a backup to a primary route. Since dynamic routing protocols broadcast periodic updates, they are not desirable on a dial link where they will cause the link to go up, even though no user data needs to cross the link. Using a static route to the link will keep the line from going up with routing updates, but will still let the router know where to send packets in case the primary path fails. The Null Interface As mentioned in the static route section, you can configure a route to go to a specific interface. One of the interfaces you can select is the virtual null0 interface. This is not a physical interface. Directing packets to the null0 interface will prevent the router from sending an Internet Control Message Protocol (ICMP) network unreachable message when it receives a
packet with an unknown destination. A situation in which you might want to use the null0 interface is when you have configured a default network, but want packets destined for a particular network to be dropped. If a static route is configured for the network to the null0 interface, the packets will be dropped without the ICMP message or without having to configure an access list.
Routing involves two basic activities: determination of the best routing paths, called path determination, and the transport of packets through an internetwork, referred to as path switching. Routed Versus Routing Protocols The terms routed protocol and routing protocol often cause confusion. Routed protocols are routed through an internetwork; examples include the Internet Protocol (IP), DECnet, AppleTalk, NetWare, Open System Interconnection (OSI), Banyan VINES, and Xerox Network Systems (XNS). Routing protocols implement routing algorithms; they route routed protocols through an internetwork. Examples include Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP), Open Shortest Path First (OSPF), Exterior Gateway Protocol (EGP), Border Gateway Protocol (BGP), OSI Routing, Advanced Peer-to-Peer Networking (APPN), Intermediate System-to-Intermediate System (IS-IS), and Routing Information Protocol (RIP). This course covers OSPF and IS-IS. Path Determination Path determination enables a router to select the most appropriate interface for forwarding a packet, a logical grouping of information and user data. Path determination enables a routing protocol to determine the desirability of a given path to a destination. The desirability of a path is based on one or more routing metrics. As paths are configured or discovered, they are recorded as entries in a routing table. Routing table entries associate destinations with next-hop routers (the router to which traffic should be forwarded next). Routers use the information in routing tables to forward packets, as follows: 1. When a router receives a packet on an interface, it examines the Destination Address field. 2. The router checks its routing table to see if it knows how to forward the packet toward the destination. 3. If the destination network is not contained in the routing table, the router drops the packet. If the destination network is contained in the routing table, the router checks the entry to see which is the most desirable path for the packet to take. 4. When it has determined the preferred path to the destination, the router checks the routing table entry to see which of its interfaces leads to the next hop in that
path. The next hop might be another intermediate router or the destination network itself. 5. The router queues the packet at the appropriate interface, and sends the packet on its way to the next hop in the path to the destination. Path Switching Path switching allows a router to accept a packet on one interface and then forward it on a second interface using simple switching algorithms. Before path switching can occur, path determination must occur. Path Switching Process When a router receives a packet, it must determine whether it can forward it toward the destination, as follows: 1. An end system has packets to send to another end system. 2. The source end system addresses the packets using the Media Access Control (MAC) address of the nearest intermediate system (such as a router) and the network address of the destination end system. 3. The source end system sends the packets to the specified intermediate system. 4. The intermediate system (the router) examines the destination network address to see if it can forward the packets. If it cannot forward the packets, they are dropped. If it can forward the packets, the router changes the destination MAC address to that of the next hop in the path to the destination. 5. The router then sends the packets to the next-hop device (either another intermediate system or the destination end system). As the packet moves through the internetwork, its destination MAC address changes, but its network address remains the same. Routing Metrics To aid the process of path determination, routing algorithms initialize and maintain routing tables, which contain a listing of network addresses and how they can be reached. Routing metrics are used by the routing algorithm to determine the best route. Sophisticated routing algorithms can base route selection on multiple metrics, combining them in a single (hybrid) metric. The following sections cover various routing metrics. Path Length Path length is the most common routing metric. Some routing protocols allow network administrators to assign arbitrary costs to each network link. In this case, path length is the sum of the costs associated with each link traversed. Other routing protocols define
hop count, a metric that specifies the number of passes through internetworking products (such as routers) that a packet must take en route from a source to a destination. Reliability Reliability, in the context of routing algorithms, refers to the reliability (usually described in terms of the bit-error rate) of each network link. Some network links may go down more often than others. When down, some network links may be repaired more easily or more quickly than other links. Any reliability factors can be accounted for in the assignment of reliability ratings, which are usually assigned to network links by network administrators. They are typically arbitrary numeric values. Routing Delay Routing delay refers to the length of time required to move a packet from source to destination through the internetwork. Delay depends on many factors, including the bandwidth of intermediate network links, the port queues at each router along the way, network congestion on all intermediate network links, and the physical distance to be traveled. Because it is a conglomeration of several important variables, delay is a common and useful metric. Bandwidth Bandwidth refers to the available traffic capacity of a link. All other parameters being equal, a 10-Mbps Ethernet link would be preferable to a 64-kbps leased line. Although bandwidth is a rating of the maximum attainable throughput on a link, routes through links with greater bandwidth do not necessarily provide better routes than routes through slower links. If, for example, a faster link is much busier, the actual time required to send a packet to the destination may be greater through the fast link. Load Load refers to the degree to which a network resource (such as a router) is busy. Load can be calculated in a variety of ways, including CPU utilization and packets processed per second. Monitoring these parameters on a continual basis can itself be resource intensive. Communication Cost Communication cost is another important metric. Some companies may not care about performance as much as they care about operating expenditures. Even though line delay might be longer, they will send packets over their own lines rather than through public lines that will cost money for usage time.
Routing Algorithms Routing algorithms use a variety of metrics that affect calculation of optimal routes. There are various types of routing algorithms, and each algorithm has a different impact on network and router resources. Some examples of routing algorithm attributes follow: Optimality Optimality refers to the ability of the routing algorithm to select the "best" route, which depends on the metrics and metric weightings used to make the calculation. For example, one routing algorithm might use the number of hops and delay, but might weigh delay more heavily in the calculation. Naturally, routing protocols must strictly define their metric calculation algorithms. Simplicity Routing algorithms are also designed to be as simple as possible. The routing algorithm must offer its functionality efficiently, with a minimum of software and utilization overhead. Efficiency is particularly important when the software implementing the routing algorithm must run on a computer with limited physical resources. Robustness Routing algorithms need to be robust. They should perform correctly in the face of unusual or unforeseen circumstances such as hardware failures, high load conditions, and incorrect implementations. Because routers are located at network junction points, they can cause considerable problems when they fail. The best routing algorithms are often those that have withstood the test of time and have proven stable under a variety of network conditions. Rapid Convergence Routing algorithms must converge rapidly. Convergence is the process of agreement, by all routers, on optimal routes. When a network event causes routes to either go down or become available, routers distribute routing update messages. Routing update messages permeate networks, stimulating recalculation of optimal routes and eventually causing all routers to agree on these routes. Routing algorithms that converge slowly can cause routing loops or network outages. Flexibility Routing algorithms should also be flexible. Routing algorithms should quickly and accurately adapt to a variety of network circumstances. For example, assume that a network segment has gone down. Many routing algorithms, on becoming aware of this problem, will quickly select the next-best path for all routes that normally use that
segment. Routing algorithms can be programmed to adapt to changes in network bandwidth, router queue size, network delay, and other variables. Routing algorithms can also be classified by type. For example, types of algorithms include: Static or Dynamic Algorithms Static routing algorithms are hardly algorithms at all. Static routing table mappings are established by the network administrator prior to the beginning of routing. They do not change unless the network administrator changes them. Algorithms that use static routes are simple to design and work well in environments where network traffic is relatively predictable and network design is relatively simple. Because static routing systems cannot react to network changes, they are generally considered unsuitable for today's large, constantly changing networks. Most of the dominant routing algorithms in the 1990s are dynamic. Dynamic routing algorithms adjust, in real time, to changing network circumstances by analyzing incoming routing update messages. If the message indicates that a network change has occurred, the routing software recalculates routes and sends out new routing update messages. These messages permeate the network, stimulating routers to rerun their algorithms and change their routing tables accordingly. Dynamic routing algorithms may be supplemented with static routes where appropriate. For example, a router of last resort (a router to which all unroutable packets are sent) may be designated. This router acts as a repository for all unroutable packets, ensuring that all messages are at least handled in some way. Single-Path or Multipath Algorithms Some sophisticated routing protocols support multiple paths to the same destination. These multipath algorithms permit traffic multiplexing over multiple lines; single-path algorithms do not. The advantages of multipath algorithms are obvious; they can provide substantially better throughput and reliability. Flat or Hierarchical Algorithms Some routing algorithms operate in a flat space, while others use routing hierarchies. In a flat routing system, all routers are peers of all others. In a hierarchical routing system, some routers form what amounts to a routing backbone. Packets from nonbackbone routers travel to the backbone routers, where they are sent through the backbone until they reach the general area of the destination. At this point, they travel from the last backbone router through one or more nonbackbone routers to the final destination.
Routing systems often designate logical groups of nodes called domains, autonomous systems, or areas. In hierarchical systems, some routers in a domain can communicate with routers in other domains, while others can communicate only with routers within their domain. In very large networks, additional hierarchical levels may exist. Routers at the highest hierarchical level form the routing backbone. The primary advantage of hierarchical routing is that it mimics the organization of most companies and, therefore, supports their traffic patterns very well. Most network communication occurs within small company groups (domains). Intradomain routers need to know only about other routers within their domain, so their routing algorithms can be simplified. Depending on the routing algorithm being used, routing update traffic can be reduced accordingly. Host-Intelligent or Router-Intelligent Algorithms Some routing algorithms assume that the source end node will determine the entire route—usually referred to as source routing. In source-routing systems, routers merely act as store-and-forward devices, mindlessly sending the packet to the next stop. Other algorithms assume that hosts know nothing about routes. In these algorithms, routers determine the path through the internetwork based on their own calculations. In the first system, the hosts have the routing intelligence. In the latter system, routers have the routing intelligence. The trade-off between host-intelligent and router-intelligent routing is one of path optimality versus traffic overhead. Host-intelligent systems choose the better routes more often, because they typically discover all possible routes to the destination before the packet is actually sent. They then choose the best path based on the definition of optimal for that particular system. The act of determining all routes, however, often requires substantial discovery traffic and a significant amount of time. Intradomain or Interdomain Algorithms Some routing algorithms work only within domains; others work within and between domains. The nature of these two algorithm types is different. It stands to reason, therefore, that an optimal intradomain routing algorithm would not necessarily be an optimal interdomain routing algorithm. Link-State or Distance-Vector Algorithms Link-state algorithms (also known as shortest-path-first algorithms) flood routing information to all nodes in the internetwork. However, each router sends only that portion of the routing table that describes the state of its own links. Distance-vector algorithms (also known as Bellman-Ford algorithms) call for each router to send all or some portion of its routing table, but only to its neighbors. In essence, link-state
algorithms send small updates everywhere, whereas distance-vector algorithms send larger updates only to neighboring routers. Because they converge more quickly, link-state algorithms are somewhat less prone to routing loops than distance-vector algorithms. On the other hand, link-state algorithms require more CPU power and memory than distance-vector algorithms. Link-state algorithms can, therefore, be more expensive to implement and support. Despite their differences, both algorithm types perform well in most circumstances. This course discusses the link-state routing protocols. Click on the SPF Movie icon to see a short movie describing link-state algorithms.
Routing loops occur when routing tables have not converged. Convergence is the process routers go through when a route (network) or group of routes has become unavailable because a link has gone down in the network or because a link has lost a large number of packets. This loss results in the routers flushing the lost routes and listening to see whether other routes are available. Routers usually store the best route to a network in their routing tables. Other, high-cost routes may exist, but the router ignores them if it believes that the better route still exists. An example of a routing loop follows:
In this case, a packet arrives at Router R1 at time t1. Router R1 has already been updated and thus knows that the optimal route to the destination calls for Router R2 to be the next stop. Router R1, therefore, forwards the packet to Router R2. Router R2 has not yet been updated, so it believes that the optimal next hop is Router R1. Router R2, therefore, forwards the packet back to Router R1. The packet will continue to bounce back and forth between the two routers until Router R2 receives its routing update or until the packet has been switched the maximum number of times allowed. The following sections discuss the ways in which routing loops can be prevented.
Count to Infinity Many routing protocols impose an upper limit on routing metric values. This imposed maximum metric value, referred to as count to infinity, provides the external boundary condition necessary to prevent routing loops from continuing indefinitely. The value of infinity must be large enough that the metric for a valid route would not reach that value, but small enough that routing loops cannot exist for extended periods of time. Hold Down The hold-down mechanism is used to prevent regular routing updates from inappropriately reinstating incorrect routing information. When a router receives an update that contains a topology change, it starts the hold-down timer, which prevents a router from implementing any changes to its routing table until the timer expires. Any update received during this period is discarded. The hold-down period is usually slightly longer than the time necessary for the entire network to converge on the topology change. In the following scenario, incorrect routing information is advertised because the holddown mechanism is not implemented: 1. A route goes down and neighboring routers detect the failure. 2. These routers calculate new routes and send out routing update messages to inform neighbors of the route change. 3. A device that has not yet been informed of a network failure sends a regular update message indicating that the failed route is good. 4. This update reaches a device that has just been notified of the failure. That device inserts the bad route back into the routing table and now contains incorrect routing information, which it proceeds to advertise in the routing updates it sends to its neighbors. Split Horizon The split-horizon rule states that it is never useful for a routing protocol to send information about a route back to the router from which the route was learned. An example of a split-horizon implementation follows: 1. Router R1 advertises that it has a route to Network A. 2. Router R2 receives the update from Router R1 and inserts the information about Network A in its routing table. 3. When Router R2 sends a regular routing update, it does not include the entry for Network A in the update sent to Router R1, because that route was learned from Router R1 in the first place.
Routing Information Protocol ( RIP) is an Interior Gateway Protocol (IGP), meaning it is used within an autonomous system. A distance-vector protocol, RIP was designed to work with small to medium-sized networks. The original version of RIP is based on the program routed (pronounced "route dee"), distributed with the 4.3 Berkeley Software Distribution. RIP was in widespread use as a routing protocol before it was formally defined in RFC 1058. RIP Version 2, defined in RFC 2453, added some additional features and functionality to the original version. Both versions of RIP are discussed in this module. RFC 2091 specified additional extensions for RIP to allow support for demand circuits (Triggered RIP). Support for Triggered RIP was added in 12.0(1)T and will not be discussed here. Some advantages of using RIP, especially in small networks, is that there is very little overhead, in terms of bandwidth used and configuration and management time. RIP is also easy to implement, compared to newer IGPs, and has been implemented in networks around the world.
RIP is a distance-vector protocol. As you learned in the "Cisco Interactive Mentor: Basic IP Routing Concepts" module, a distance-vector protocol is based on the exchange of routing-table information. Each router using a distance-vector protocol maintains information about all the destinations within the system. In general, the information about all the entities connected to one network (or subnet) is summarized within a single entry. This entry includes the next destination to which datagrams are destined, a metric measuring the total distance to the entity, the time delay in sending the messages, and the cost of sending the messages. Distance-vector protocols compute the optimal routes from this information and then share that information with adjacent entities on the same network. Routers running RIP may participate as either active or passive devices. A device running in active mode will advertise its routes, while a passive device will silently listen to advertisements. For obvious reasons, routers generally run in active mode while hosts often run in passive mode when running RIP.
RIP is used to convey information about routes to destinations. RIP relies on access to information about its directly connected networks. An active RIP device accomplishes this access by periodically advertising its routing information. The information that RIP uses to construct these updates is taken from the routing table (or the RIP database in Cisco IOS® 12.0T and later). The routing table contains one entry for every destination that is reachable within the system. Each entry has the following information:
IP address of the destination A metric that represents the total cost of getting a datagram from the host to the destination
The IP address of the next router along the path to the destination Timers associated with the router The route change flag that indicates that the information about the route has changed recently
The following is an example of a RIP routing table:
RIP maintains only the best route to a destination. In order to prevent routing information from oscillating between two or more equal-cost paths, the RFC specifies that updates from different next hops should be used only if the reported metric is less than the currently installed route. Metric changes received from the existing gateway are installed immediately. The Cisco implementation allows routes with identical metrics for the same network to be simultaneously installed for load balancing. Network topology changes can cause changes in routes. These changes can result in a new route becoming the best route to a particular destination. When network topology changes occur, they are reflected in routing update messages. For example, when a router detects a link or router failure, it recalculates its routes and sends routing update messages. Each router receiving a routing update message that includes a change updates its tables and propagates the change.
RIP uses a single routing metric, hop count, to measure the distance between the source and destination networks. Each hop in this path is assigned a hop-count value, which with RIP is usually 1. When a router receives a routing update that contains a new or changed destination-network entry, the router adds one to the metric value indicated in the update and enters the network in the routing table. The IP address of the sender is used as the next hop. This method for incrementing the routing metric will theoretically provide loop-free routing information in a perfectly stable environment, but when the topology changes or when networks become inaccessible, it can lead to two
classic problems faced by traditional distance-vector routing algorithms: slow convergence or count to infinity. Routing information about topology changes propagates slowly throughout a network because of inconsistencies between the routing tables of the routers in the network. Limiting the number of hops in a network helps to improve this convergence problem. Limiting the number of hops allowed also prevents routing loops from continuing indefinitely. RIP is limited to networks whose longest path involves 15 hops. With RIP, if a router receives a routing update that contains a new or changed entry, and if increasing the metric by one causes the metric to be 16, the network destination is considered unreachable. In other words, 16 is equivalent to "infinity" in a RIP network. If a network becomes completely inaccessible, then routers could mutually deceive each other and "count to infinity," as shown in the following example:
Router_C is advertising the network 192.100.10.x with a cost of one. Router_A is advertising the network 192.100.10.x with a cost of two. If the connection between Router_C and the network 192.100.10.x is lost, then Router_C will advertise it with a cost of 16 (infinity). If Router_A advertises the network 192.100.10.x back to Router_C before the "infinite" metric is received, then Router_C may incorrectly believe that Router_A can still reach the target network with a cost of two. Router_C will advertise the network 192.100.10.x back to Router_A with a cost of three. This routing loop will continue until both routers eventually "count to infinity." RIP designers chose 16 to be infinity because they wanted the number to be small enough that when networks become completely inaccessible, the counting would stop as soon as possible. The choice of 16 as infinity is a tradeoff between network size and the speed of convergence. The designers of RIP believed that it would be impractical to implement RIP in networks with diameters larger than 15.
RIP also uses timers both to regulate its performance and to help prevent routing loops like those shown above. All routers that use RIP send an update message to all of their neighbors approximately every 30 seconds; this process is termed advertising. The RFC specifies that advertisements should be randomized by up to +/– five seconds in order to prevent synchronization of routing updates. The Cisco implementation sends updates every 30 seconds minus up to 15 percent, or 4.5 seconds.
If a neighbor has not responded in 180 seconds, it is assumed that the neighboring router is unavailable or the network connecting it to the router has become unusable. When the neighbor has not responded for 180 seconds, the route is marked invalid; 180 seconds is long enough that a route won't be invalidated by a single missed update message. The neighbor is shown to be unreachable by sending a normal update message with a metric of "infinity;" in the case of RIP, this number is 16. If an advertisement is received from a neighbor with a metric of infinity, then the route is placed into holddown state, advertised with a distance of 16, and kept in the routing table. No updates from other neighbors for the same route are accepted while the route is in holddown state. If other neighbors are still advertising the same route when the holddown timer expires, then their updates will then be accepted. The route will be advertised with an infinity metric for a period of time after the holddown state if no alternate paths are found. The actual timers used to accomplish the above tasks are a routing-update timer, a route-invalid timer, a route-holddown timer, and a route-flush timer. The RIP routingupdate timer is generally set to 30 seconds, ensuring that each router will send a complete copy of its routing table to all neighbors every 30 seconds. The route-invalid timer determines how much time must expire without a router having heard about a particular route before that route is considered invalid. When a route is marked invalid or put in holddown state, neighbors are notified of this fact. This notification must occur prior to expiration of the route-flush timer. When the route flush-timer expires, the route is removed from the routing table. Typical initial values for these timers are 180 seconds for the route-invalid and route-holddown timers and 240 seconds for the route-flush timer. The values for each of these timers can be adjusted with the timers basic router configuration command. Information concerning the RIP process, including the timers, can be seen with the show ip protocol command. A sample output from this command is shown in the following example: Router-1#show ip protocol Routing Protocol is "rip" Sending updates every 30 seconds, next due in 18 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Outgoing routes will have 10 added to metric if on list 1 Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain Ethernet0/0 1 1 2 Routing for Networks: 172.16.0.0 Routing Information Sources: Gateway Distance Last Update
172.16.4.1 120 Distance: (default is 120) Router-1#
00:00:20
To adjust for rapid network-topology changes, RIP specifies numerous stability features that are common to many routing protocols. RIP implements split horizon with poisonreverse and holddown mechanisms to prevent incorrect routing information from being propagated. Split horizon prevents incorrect messages from being propagated by not advertising routes over an interface that the router is using to reach the route. Implementing split horizon helps avoid routing loops. Poison reverse operates by advertising routes that are unreachable with a metric of infinity back to the original source of the route. Holddown is a method of marking routes invalid (expired). As discussed above, no updates from other neighbors for the same route are accepted while the route is in holddown state. Triggered updates are also an included convergence and stability feature. Updates are triggered whenever a metric for a route changes. Triggered updates may also contain only information regarding routes that have changed, unlike scheduled updates. There is a minimum delay of five seconds between triggered updates to prevent update storms.
RIP is a User Datagram Protocol (UDP)-based protocol. Each router that uses RIP has a routing process that sends and receives datagrams on UDP port number 520, the RIP port. All communications for the RIP process of the router use this port. All routing update messages are sent from the RIP port and unsolicited routing update messages have both the source and destination port equal to this port. RIP V1 traffic is sent as a broadcast to the 255.255.255.255 IP address by default. The following is the packet format for the original version of RIP, defined in RFC 1058:
The Command field indicates whether the packet is a request or a response. The request asks a router to send all or part of its routing table. The response can be an unsolicited update message or a reply to a request. Responses contain routing-table entries. Multiple RIP packets are used to contain information for large routing tables. The Version Number field specifies the RIP version used. This field can signal potentially incompatible versions. The Zero field is not used. The Address-Family Identifier (AFI) specifies the address family used. RIP is designed to carry routing information for several different protocols. Each entry has an AFI to indicate the type of address being specified. The AFI for IP is 2. The Metric, as stated earlier, indicates how many hops have been traversed in the trip to the destination. The value is between 1 and 15 for a valid route, or 16 for an unreachable route. The RIP V1 packet format does not distinguish among different types of addresses. Fields that are labeled "address" can contain any of the following:
Host address Subnet number Network number Zero (default route)
Entities that use RIP V.1 are supposed to use the most specific information available when routing a datagram. First, the destination address of the datagram is checked against the list of node addresses. Then it is checked to determine whether it matches any known subnet or network number. If none of these match, the default route is used. Note: All routes received on an interface are assumed to have the subnet mask of that interface. Because of this, if the subnet masking is different on interfaces within the same major network, updates will not be exchanged between these interfaces because of the possible resulting ambiguity. Updates that do not fit with the assumed subnet mask are considered to be host routes. If an update including a route from a different major network is received on an interface, the router must assume that the update is for the entire major network. For this reason, there is no way to disable autosummarization with RIP V.1. Default Routes in RIP As mentioned above, a default route will be used to route packets if a longer match is not found in the routing table. When RIP is used to advertise the default route, the address field in the packet contains zero, referring to the 0.0.0.0 IP network address.
Unlike other protocols, RIP will automatically advertise the default route as long as a default route from any source is installed in the routing table on the router; no additional redistribution commands are necessary. In versions prior to 12.0(1)T, a default can be forcibly advertised using the default-information originate command even though no default route is known by the router.
RIP Version 2, or RIP V.2, was created to add additional functionality to the original RIP and also cope with some new issues that arose after RIP was defined. RIP V.2 uses the same basic algorithms as RIP V.1, but supports external route tags, subnet masks, next-hop addresses, and authentication. RIP V.2 is backward compatible with RIP V.1. External Route Tags RIP V.2 includes a Route Tag field, which is an attribute assigned to a route that must be preserved and readvertised with a route. This field provides a mechanism to separate "internal" RIP routes (routes for networks within the RIP routing domain) from "external" RIP routes, which may have been imported from an Exterior Gateway Protocol (EGP) or another IGP. Subnet Mask RIP V.2 allows the use of variable subnet masks on the network. In RIP V.1, there is a subnet/host ambiguity because nodes do not know the subnet masks, so evaluating the address can be ambiguous. In RIP V.2 there is a Subnet Mask field, which is applied to the IP address to yield the nonhost portion of the address. If this field is zero, then no subnet mask has been applied. Next-Hop Addresses RIP V.2 supports next-hop addresses; this setup allows for optimization of routes in an environment that uses multiple routing protocols. For example, if RIP V.2 was running on a network with Enhanced Interior Gateway Routing Protocol (EIGRP) and one router ran both protocols, then the router could indicate if a better next hop than itself exists for a given destination. This setup eliminates packets from being routed through extra hops in the system. The Next-Hop field is an "advisory" field, and if the provided information is ignored, another suboptimal route may be taken. If the received next hop is not directly reachable, it should be treated as 0.0.0.0.
Authentication RIP V.2 offers an authentication mechanism, which is a per-message function. With RIP V.2, there is only a 2-octet field available in the message header and since 2 octets are obviously not enough, the authentication scheme uses the space of an entire RIP entry. To identify if the entry contains authentication, check to see if the AFI of the first entry is 0xFFFF. If it is, there can be a maximum of 24 RIP entries in the remainder of the message. The AFI or 0xFFFF should not be used if authentication is not being used. The authentication type for RIP V.2 is a simple password, and it is type 2. The remaining 16 octets contain a plaintext password. If the password is under 16 octets, it must be left-justified to the right with nulls (0x00).
Multicasting RIP V.2 packets may be multicast instead of being broadcast. The multicast address is 224.0.0.9. Multicasting reduces the load on hosts that do not support routing protocols, and also allows RIP V.2 routers to share information that RIP V.1 routers cannot hear. This feature is useful since a router running the original version of RIP may misinterpret route information because it cannot apply the subnet mask.
The RIP V.2 specification, described in RFC 2453, allows for the above functionality to be incorporated as information into the packet. The following shows a RIP V.2 packet:
The Command field indicates whether the packet is a request or a response. The request asks that a router send all or part of its routing table. The response can be an unsolicited regular routing update or a reply to a request. Responses contain routingtable entries. Multiple RIP packets are used to convey information from large routing tables. The Version field specifies the RIP version used. In a RIP packet implementing any of the RIP V.2 fields or using authentication, the value is set to 2.
The Unused field has a value set to zero. The Address Format Identifier (AFI) field specifies the address family used. RIP is designed to carry routing information for several different protocols. Each entry has an AFI to indicate the type of address specified. The AFI for IP is 2. If the AFI for the first entry in the message is 0xFFFF, the remainder of the entry contains authentication information. The Route Tag field provides a method for distinguishing between internal routes, learned by RIP, and external routes that were learned from other protocols. The IP Address field specifies the IP address for the entry. The Subnet Mask contains the subnet mask for the entry. If this field is zero, no subnet mask has been specified for the entry. The Next-Hop field indicates the number of hops that have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route. Note: Up to 25 occurrences of the AFI, address, and metric fields are permitted in a single RIP packet. In other words, up to 25 destinations may be listed in any single RIP packet. Multiple RIP packets are used to convey information from larger routing tables. Interaction between RIP V.1 and RIP V.2 Since RIP V.1 packets do not contain subnet mask information, routers on networks that contain both RIP V.1 and RIP V.2 should use the semantics employed by RIP V.1 only. If not, there is the possibility of routes for networks that do not exist or excessive routing information in a Version 1 environment. By default, Cisco IOS software receives RIP V.1 and RIP V.2 packets, but sends only RIP V.1 packets. You can configure the software to receive and send only Version 1 packets. Alternatively, you can configure the software to receive and send only Version 2 packets. In some RIP implementations, autosummarization is used. Autosummarization is an attempt to summarize groups of adjacent routes into single entries in order to reduce the number of entries in routing tables. Summarization is done on major network boundaries. When using RIP V.2, autosummarization can be disabled.
Early routing protocols were based on distance vectors; they were very simple and easy to implement but had the severe drawbacks of counting to infinity and routing loops. These problems were reduced using techniques such as split horizon, holddowns, and
so on. These techniques, however, introduced long convergence times. Routing protocols based on link states have been implemented to address the problem of slow convergence in distance-vector protocols, but they add complexity in configuration and troubleshooting. EIGRP is an advanced distance-vector protocol that scales well, is easy to configure, and provides extremely quick convergence times with minimal network traffic. EIGRP is a classless protocol, meaning that it supports variable-length subnet mask (VLSM) and aggregation. An aggregate is a summarized group of addresses. In addition, EIGRP implements modules for IP, Internetwork Packet Exchange (IPX), and AppleTalk, which are responsible for the protocol-specific routing tasks. This training module includes information about only the IP module. Typically, distance-vector protocols maintain the information about only one path to the destination, the best path. This information consists of total metric (distance) and the next hop (vector) to the destination. For example:
If a router, Router_A, learns about a destination (Network A) from two different routers, it chooses the best path by examining the total metric of each path. After it chooses the best path, it discards any information about the alternate (nonbest) path. In the above example, the best path would be through Router_C (assuming hop count as a metric). All information about the path through Router_B is discarded. If the path between Router_A and Network A is somehow broken, Router_A removes the route from its routing table after a certain amount of time, usually three update periods (in the case of Routing Information Protocol (RIP), this time would be 90 seconds, not including any hold-down timers). After this route is removed from the routing table, Router_A then learns about Network A via Router_B (because Router_B has been sending periodic updates). It could take from 90 to 120 seconds before Router_A installs the new route to Network A through Router_B. EIGRP, on the other hand, builds a topology table from information it learns from each of its neighbors. The information sent by EIGRP is nonperiodic and contains only new information. Using the Diffusing Update Algorithm (DUAL), EIGRP then chooses a best path (successor) and alternate loop-free paths (feasible successors) that allow for fast convergence. This information is kept in a topology table separate from the routing table. Upon losing a route to a destination, EIGRP looks for feasible successors in its
topology table. If a feasible successor does exist, EIGRP begins using it immediately. If no feasible successors exist, EIGRP queries its neighbors. For all the above to be accomplished, the components of EIGRP must provide:
Reliable transport mechanism Neighbor discovery/recovery process, which allows EIGRP routers to discover and track other EIGRP speaking routers that are on directly connected networks; part of this process must be done reliably (guaranteed) A way to discover which paths are loop free A process to clear bad routes from the topology table of all routers on the network A process for querying neighbors to find paths for lost destinations
The DUAL algorithm cannot be effective if messages are not transmitted reliably. Therefore, a reliable transport for ordered delivery and acknowledgment must be part of EIGRP. The Reliable Transport Protocol is a component of EIGRP that guarantees the delivery and order of EIGRP packets. EIGRP updates and hellos are destined to the multicast address 224.0.0.10. Each EIGRP neighbor receiving a multicast reliable packet will unicast an acknowledgment. State variables, such as sequence number and acknowledgment number, are maintained on a per-neighbor basis to ensure ordered delivery. EIGRP uses multiple packet types for reliable transport, all of which are identified by protocol number 88 in the IP header.
Hello packets are used to discover and recover neighbors. They are multicast and use unreliable delivery (no acknowledgment necessary). Acknowledgments are used for reliable delivery and are always unicast. Updates are used to convey route information. Updates are transmitted only when there is a change in the topology; they contain only the changed information, and they are sent only to routers that require the information. If only one router requires the update information, the updates are unicast; otherwise the updates are multicast. Updates use reliable delivery. Queries and replies are used by DUAL. Queries can be multicast or unicast, and replies are always unicast. Queries and replies use reliable delivery.
Because EIGRP updates are nonperiodic and contain information only on paths that have changed, EIGRP relies on neighbor relationships to reliably propagate routingtable changes throughout the network. When an EIGRP router is initialized, it starts sending hello packets. Hello packets, when used for neighbor discovery, are always sent multicast addressed (224.0.0.10). The hello packet includes the EIGRP K-values (discussed later). Two routers will become neighbors only if the K-values in the hello packets are the same. This scenario enforces consistent metric usage throughout the network. Upon startup, two routers will become EIGRP neighbors when they see each other's hello packets on a common network. Hello packets are sent out, by default, once every five seconds on high-bandwidth media and every 60 seconds on low-bandwidth media. The rate at which the hello packets are sent is called the hello interval. This interval can be changed on a perinterface basis with the interface subcommand ip hello-interval eigrp. When a router receives a hello packet, the packet includes a hold time, the amount of time for which a router will consider a neighbor up without receiving a hello. Because the hold time is included in the hello packet, it is possible for two routers to become EIGRP neighbors even though the hello and hold timers do not match. The hold time is typically three times the hello interval. The hold time can be changed on a per-interface basis with the ip hold-time eigrp subinterface command. Information about each neighbor is maintained in a neighbor table, which can be viewed with the show ip eigrp neighbor command. The following is an example of the neighbor information for Router_B in the network shown above:
Router_B#show ip eigrp neighbor IP-EIGRP neighbors for process 7 H Address Interface Q Seq Cnt Num 2 170.170.3.4 0 8 1 170.170.3.3 0 18 0 170.170.1.1 0 17 Router_B# Et0 Et0 Se0
Hold Uptime (sec) 10 00:15:39 11 00:15:55 14 00:16:27
SRTT (ms) 12 15 9
RTO
200 200 200
The following is a description of what is included in the EIGRP neighbor table:
Show IP EIGRP Neighbors Field Descriptions Field Process 7 Address Interface Description Autonomous system number specified in the IP router configuration command IP address of the enhanced IGRP peer Interface on which the router is receiving hello packets from the peer Length of time, in seconds, that the router will wait to hear from the peer before declaring it down; if the peer is using the default hold time, this number will be less than 15; if the peer configures a nondefault hold time, it will be reflected here Elapsed time, in hours, minutes, and seconds, since the local router first heard from this neighbor Smooth round-trip time—the number of milliseconds it takes for an IP-enhanced IGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet Retransmission timeout, in milliseconds—the amount of time the router waits before retransmitting a packet from the retransmission queue to a neighbor Number of IP-enhanced IGRP packets (update, query, and reply) that the router is waiting to send Sequence number of the last update, query, or reply packet that was received from this neighbor
Hold Time
Uptime
SRTT
RTO
Q Count
Seq Num
When a router receives the hello packet from a new neighbor, EIGRP attempts to exchange routing updates with the neighbor. The updates contain all routes known by the sending routers and the metrics of those routes. When an EIGRP router receives updates from its neighbors, it builds a second table, the topology table, from which it builds a routing (forwarding) table. The topology table contains information needed to build a set of metrics and next hops to each reachable network, including:
Lowest bandwidth on the path to the destination Total delay
Path reliability Path loading Minimum-path maximun transmission unit (MTU) Feasible distance Reported distance Route source
We will see later how we can view the contents of the topology table.
As with most other routing protocols, the best path to a destination is the path with the lowest metric. EIGRP has the ability to use several variables to compute the metric to a destination network. The first five listed above are those variables: bandwidth, delay, reliability, load, and MTU. Only bandwidth and delay are used by default. It is highly recommended that the defaults be maintained, because using other variables can result in unknown problems in your network. The values of bandwidth and delay are determined from the bandwidth and delay values associated with the router interfaces. There are default values, but the values can be changed per interface with the bandwidth and delay subinterface commands. The formula for computing EIGRP metrics follows: Metric – {[K1 * Bandwidth + (K2 * Bandwidth)/(256 – Load) + K3 * Delay] * [K5/(Reliability + K4)]} * 256 The default K-values follow: K1 = 1; K2 = 0; K3 = 1; K4 = 0; K5 = 0; therefore, the metric formula can be simplified to: Metric = (Bandwidth + Delay) * 256 Bandwidth = 10000000/Minimum bandwidth along path; and Delay = Sum of delays along path. Therefore, the final metric formula becomes: ([10000000/Minimum bandwidth] + Sum of delay/10) * 256 Note: Formula uses the bandwidth in kilobits per second and delay as configured on the interface, which is in microseconds. Metric example:
In this example, the total cost (metric) for Router_A to get to Network A through Router_B would be: Minimum bandwidth = 128kbps Total delay = 100 + 100 + 1000 = 1200/10 ms ([10000000/128] + 1200/10) * 256 = 20030720 The total cost to the same destination through Router_C follows: Minimum bandwidth = 512kbps Total delay = 1000 + 100 + 100 = 1200/10 ms ([10000000/512] + 1200/10) * 256 = 5030720 The path through Router_C has the lowest cost. Router_A would, therefore, choose the path through Router_C as the best path and put it in its routing table. This path would then be known as the successor (explained later). In the above topology, the metric of Router_B to Network A would be 307200. Router_C would also have a metric of 307200 to Network A.
(successor, feasible distance, reported distance, and feasible successor explained) Successor is the best path to a given destination; it is the path that is installed into the routing table. Feasible distance (FD) is the lowest calculated metric to each destination. In the above metric example, the path through Router_C was the best path because the calculated metric was the lowest through that path. Router_A would have a feasible distance of 5307200 for Network A.
Reported distance (RD) is the metric to a destination as advertised by a neighbor. In the above metric example, the metric that Router_C calculates for Network A is 307200. Router_A would see this metric as a reported distance. A feasible successor (FS) is a path whose reported distance is less than the feasible distance. This condition, reported distance < feasible distance, is also known as the feasibility condition. A path that satisfies the feasible condition is considered loop free. A path that has a distance larger than the feasible distance could possibly be through this router, causing a loop. In the above metric example, the reported distance of Router_A for the path through Router_B is 307200 (the same as the path through Router_C). This value is less than the feasible distance of Router_A of 5307200, a value that meets the feasibility condition, and Router_B will be the feasible successor of Router_A for Network A. All of the calculated metrics and distances defined above as well as some additional information can be viewed in an EIGRP router by issuing the show ip eigrp topology command. The following is the output when issuing a show ip eigrp topology on Router_A (Network A in this case is 170.170.4.0/24): Router_A#show ip eigrp topology IP-EIGRP Topology Table for process 7 Codes: P - Passive, A - Active, U - Update, Q - Query, R Reply, r - Reply status P 170.170.1.0/24, 1 successors, FD is 20256000 via Connected, Serial0 P 170.170.2.0/24, 1 successors, FD is 5025536 via Connected, Serial1 P 170.170.3.0/24, 1 successors, FD is 5281536 via 170.170.2.3 (5281536/281600), Serial1 via 170.170.1.2 (20281600/281600), Serial0 P 170.170.4.0/24, 1 successors, FD is 5307136 via 170.170.2.3 (5307136/307200), Serial1 via 170.170.1.2 (20307200/307200), Serial0 Router_A#
From the above output, we can see that for network 170.170.4.0, Router_A has a FD of 5307136, which is also the metric of the best route (route through serial 0). The reported distance of Router_B is 307200. Because 307200 is less than 5307136, the feasibility
condition is met and the route through Router_B is a FS. Note that show ip eigrp topology shows successors as well as FSs for each destination. Let's look at the topology table of another router. If we display the topology table for Router_B, we will see the following: Router_B#show ip eigrp topology IP-EIGRP Topology Table for process 7 Codes: P - Passive, A - Active, U - Update, Q - Query, R Reply, r - Reply status P 170.170.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 170.170.2.0/24, 1 successors, FD is 5281536 via 170.170.3.3 (5281536/5255936), Ethernet0 via 170.170.1.1 (20512000/5255936), Serial0 P 170.170.3.0/24, 1 successors, FD is 281600 via Connected, Ethernet0 P 170.170.4.0/24, 1 successors, FD is 307200 via 170.170.3.4 (307200/281600), Ethernet0 Now for network 170.170.4.0, we see a successor via 170.170.3.4 and a FD of 307200. However, we don't see any FSs. Looking at the topology above, we see that Router_B should also hear about the network 170.170.4.0 from Router_A. This route is not displayed because it is not a FS. We can see all routes for destinations, including those that are not FSs, by using the show ip eigrp topology all-links command. The following is the output for Router_B: Router_B#show ip eigrp topology all-links IP-EIGRP Topology Table for process 7 Codes: P - Passive, A - Active, U - Update, Q - Query, R Reply, r - Reply status P 170.170.1.0/24, 1 successors, FD is 2169856, serno 15 via Connected, Serial0 P 170.170.2.0/24, 1 successors, FD is 5281536, serno 18 via 170.170.3.3 (5281536/5255936), Ethernet0 via 170.170.1.1 (20512000/5255936), Serial0 P 170.170.3.0/24, 1 successors, FD is 281600, serno 1 via Connected, Ethernet0 via 170.170.1.1 (20537600/5281536), Serial0 P 170.170.4.0/24, 1 successors, FD is 307200, serno 11 via 170.170.3.4 (307200/281600), Ethernet0
via 170.170.1.1 (20563200/5307136), Serial0
Now we can see that Router_B has learned about network 170.170.4.0 through a second path. But we also see that the reported distance for this second path is 5307136, greater that the FD; therefore, this second path is not a FS.
As mentioned previously, if a router loses its best path (successor) to a given destination, it will check its EIGRP topology table for a FS. If one exists, it becomes the successor and the router can begin using it immediately. What happens if a router does not have a FS? EIGRP then needs a process to clear the bad route from the topology table of all routers in the network and a process to find new paths to the destination. These processes are defined by the DUAL state machine. An EIGRP route is said to be in a passive state when EIGRP is not performing any DUAL computations for it. Certain events can occur to make EIGRP reassess the FS list for a given destination: 1. When there is a direct change to the topology table, such as changing the state of a directly connected link 2. When an EIGRP update, query, or reply packet is received The reassessment could result in an existing FS becoming the successor, in which case the FD is updated and updates are sent to all neighbors. The route remains passive during the reassessment. If a FS cannot be found in the topology table, EIGRP begins performing a DUAL computation and the route becomes active. When a route is active, a router sends queries to all of its neighbors. Each neighbor then performs its own local computation. If the neighbor has at least one FS for the destination in question, it sends a reply, containing its metric to the destination, to the router that originated the query. If the neighbor does not have any FSs, it also generates queries to all of its neighbors, meaning that the route becomes active in the neighboring router as well. In some instances, it may take a very long time before a querying router receives a reply from one or more of its neighbors. Possible causes are that the network is very large, the network has low-quality links, or high CPU utilization, and so on. If a querying router does not receive all expected replies within a certain amount of time, the route is declared "stuck in active" (SIA). At this point, the router that originated the query will reset the neighbor that hasn't responded to the query. A query example follows:
In the above diagram, Router_A has two possible paths to get to network 170.170.4.0/24. If we calculate the metrics for this network, we find that the the best path of Router_A to Network A is through Router_B with a metric of 20307200. Therefore, the FD is 20307200. Router_C is reporting a distance of 20537600, the distance for its best path through Router_D. As far as Router_A is concerned, the distance reported from Router_C is greater than the FD; therefore, the feasibility condition is not met and Router_A does not have any FS.
If the link between Router_A and Router_B fails, as shown in first diagram, Router A checks its topology table for a FS. We determined earlier that Router_A does not have a FS, so it queries all the other EIGRP neighbors, as shown in the second diagram. Router_C then checks its topology table for a valid successor or FS. If either one is found, Router_C sends a reply to Router_A, as shown in the diagram below. The reply includes the metric of Router_C to the network.
Router_A then installs the new route to the network in its topology table and into its routing table.
Two types of summarization can be used with EIGRP: autosummarization and manual summarization. By default, EIGRP autosummarizes on major network boundaries when it is first configured. This behavior is similar to other distance-vector protocols, such as RIP and IGRP. An example of autosummarization follows:
In the topology shown in the above diagram, Router_B advertises only 180.180.0.0/16 to Router_D because Router_B is a boundary between two major networks, network 180.180.0.0 and network 170.170.0.0. For this same reason, Router_B advertises only network 170.170.0.0/16 to Router_A. Because Router_B is doing the summarization, it installs a route for the summarized address with a next hop of null0 (see the output below). Router_B#sh ip route 170.170.0.0 Routing entry for 170.170.0.0/16, 3 known subnets Attached (1 connections) Variably subnetted with 2 masks
Redistributing via eigrp 7 D 170.170.0.0/16 is a summary, 00:00:27, Null0 C 170.170.3.0/24 is directly connected, Ethernet0 D 170.170.4.0/24 [90/307200] via 170.170.3.4, 00:00:42, Ethernet0 Router_B#
Router_B#show ip eigrp topology 170.170.0.0 255.255.0.0 IP-EIGRP topology entry for 170.170.0.0/16 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600 Routing Descriptor Blocks: 0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0 Composite metric is (281600/0), Route is Internal Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 1000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 0 To get Router_B to advertise the subnets of networks 170.170.0.0 and 180.180.0.0, we could turn off autosummarization with the EIGRP no auto-summary configuration command. This step is usually desirable in topologies that have discontiguous networks. If in the above example of autosummarization Router_A were also configured to run EIGRP on its Ethernet link and autosummarization turned off, Router_B would receive the subnet information about 190.190.1.0/24 from Router_A. However, even if Router_B has autosummarization enabled, Router_B would not summarize 190.190.1.0 down to 190.190.0.0/16 when it advertised the network to Router_C because network 190.190.0.0/16 is not directly connected to Router_B. EIGRP autosummarizes internal networks; it does not autosummarize external networks. An external network is a network that originated in another autonomous system and was redistributed into this EIGRP network (redistribution is discussed in the next section) but which will not be summarized automatically. External networks can be summarized manually with the EIGRP ip summary-address eigrp interface subcommand. An example of manual summarization follows: In the topology of the previous figure, if the network 190.190.1.0 is not part of the EIGRP process running on Router_A, the only way to get the network advertised is to
redistribute it into EIGRP, making it an external route as far as Router_B is concerned. See below: Router_B#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E EGP i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2, * candidate default U - per-user static route Gateway of last resort is not set 190.190.0.0/24 is subnetted, 1 subnets D EX 190.190.1.0 [170/2560256256] via 180.180.1.1, 00:00:31, Serial0 180.180.0.0/16 is variably subnetted, 2 subnets, 2 masks D 180.180.0.0/16 is a summary, 04:10:02, Null0 C 180.180.1.0/24 is directly connected, Serial0 170.170.0.0/16 is variably subnetted, 3 subnets, 2 masks D 170.170.0.0/16 is a summary, 04:09:47, Null0 C 170.170.3.0/24 is directly connected, Ethernet0 D 170.170.4.0/24 [90/307200] via 170.170.3.4, 04:10:02, Ethernet0 As we can see above, Router_B receives all the subnet information for network 190.190.1.0; the network is not autosummarized. It shows up as an external network denoted by the D EX flag in the above output. Now if we configure the following ip summary-address eigrp 7 190.190.0.0 255.255.0.0 command, under the serial interface of Router_A, we will see the following in the routing table of Router_B: Router_B#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E EGP i - ISIS, L1 - ISIS level-1, L2 - ISIS level-2, * candidate default U - per-user static route
Gateway of last resort is not set D 190.190.0.0/16 [90/2560256256] via 180.180.1.1, 00:00:08, Serial0 180.180.0.0/16 is variably subnetted, 2 subnets, 2 masks D 180.180.0.0/16 is a summary, 00:51:59, Null0 C 180.180.1.0/24 is directly connected, Serial0 170.170.0.0/16 is variably subnetted, 3 subnets, 2 masks D 170.170.0.0/16 is a summary, 00:00:08, Null0 C 170.170.3.0/24 is directly connected, Ethernet0 D 170.170.4.0/24 [90/307200] via 170.170.3.4, 00:51:59, Ethernet0
Notice that the network has been summarized and is now seen as an internal EIGRP network. The ip summary-address eigrp command allows us not only to summarize subnets down to the major network, but also to aggregate major networks into a single supernet. For example, networks 200.200.64.0/24 through 200.200.95.0/25 could be aggregated by the single route 200.200.64.0/18.
It is possible for a router to be running multiple routing processes. These processes could be different processes of the same routing protocol or different routing protocols altogether. When the processes are different protocols, the router needs a way to determine which route to install in the routing table. This determination is done with the administrative distance. Administrative distance is a number given to each protocol—the lower the administrative distance, the more believable the protocol is as far as the router is concerned. The administrative distance is a number that is local to the router; it is not included in any advertisements. EIGRP has an administrative distance of 90; external EIGRP has an administrative distance of 170. A list of route sources and their default administrative distances follows:
Connected Route Static Route EIGRP Summary Route External BGP
0 1 5 20
EIGRP Internal Route IGRP OSPF ISIS RIP EGP EIGRP External Route Internal BGP
90 100 110 115 120 140 170 200
Redistribution is the means of taking routes learned via a given routing protocol and advertising those routes via another routing protocol or a different process of the same protocol. When routes are redistributed into EIGRP, they become EIGRP external routes, as we saw in previous examples. These external routes will have an administrative distance of 170. The redistribute command is used to redistribute routes into EIGRP. If the routes that we want to redistribute into EIGRP are learned via a protocol that does not have EIGRP-compatible metrics (IGRP is the only other protocol that has EIGRP-compatible metrics), we must tell EIGRP what metric to use when it advertises the route. We do this as part of the redistribute command or with the default-metric command. We will discuss redistribution in slightly more detail in one of the configuration labs.
Like other Interior Gateway Protocols (IGPs), EIGRP load balances across equal cost paths to a given destination. By default, EIGRP installs up to four equal cost paths into the routing table. The variance command allows EIGRP to load balance over unequal cost paths. Variance is a multiplier by which we multiply the best metric to a given destination. Any path to the same destination that has a metric less than the best path multiplied by variance will be installed in the routing table. For example, we have four paths to a given destination with the following metrics: Path 1: 500 Path 2: 500 Path 3: 1100 Path 4: 2000
By default, the router with the above metrics to a given destination installs Paths 1 and 2 in the routing table because they have equal metrics. If variance 3 is configured under router eigrp for this router, then Paths 1, 2, and 3 are all installed in the routing table because 1100 < (3 x 500). However, Path 4 is not installed because 2000 is not less then 3 x 500. The router then divides the traffic between Paths 1, 2, and 3 by dividing the metric for each path into the largest metric allowed, with variance and rounding down to the nearest integer.
For example: Path 1 1100/500 = 2 Path 2 1100/500 = 2 Path 3 1100/1100= 1 Thus we will send two packets via Path 1, one packet via Path 2, and one packet via Path 3. Then the router starts with Path 1 again.
A default route is a route in the routing table that is used as a last resort for a particular destination, meaning that there aren't any more specific routes in the routing table for the destination. A default route can be injected into EIGRP in three different ways. One way is to use the ip default-network command. This command works the same way that it does for IGRP. The second way is to have a static default route and redistribute it into EIGRP. For example: ip route 0.0.0.0 0.0.0.0 x.x.x.x (x.x.x.x is the next hop) router eigrp 10 redistribute static metric 10000 1 255 1 1500 Finally, a third way is to use manual summarization to generate a default route. For example: int s 0 ip summary-address eigrp 7 0.0.0.0 0.0.0.0
This third method is desirable when we want to limit to whom we want to send the default route. Because the ip summary-address eigrp command is an interface subcommand, we have flexibility on a per-interface basis.
OSPF is a routing protocol that calls for the sending of link-state advertisements (LSAs) to all other routers within the same hierarchical area. An area is a group of contiguous networks and attached hosts. OSPF LSAs include information on attached interfaces, metrics used, and other variables. As OSPF routers accumulate information, the routers use the SPF algorithm to calculate the shortest path to each node. This is different from the way distance-vector protocols work. Distance-vector protocols send all or a portion of their routing tables in routing-update messages to their neighbors. Configuring and troubleshooting OSPF networks is more complex than with its distance-vector counterparts.
The following is an overview on how OSPF operates:
Routers running OSPF will send OSPF hello packets to all OSPF-enabled interfaces. Routers sharing a common data link will become OSPF neighbors if their hello packets contain certain information that is mutually agreed upon. OSPF neighboring routers may form an OSPF adjacency if it is determined that there are certain commonalties between the routers exchanging hellos and the network over which the hellos are exchanged. Not all neighboring routers will form adjacencies. Routers will send (flood) LSAs over all adjacencies. All routers will build identical databases the LSAs. Shortest-path trees are calculated from the newly assembled routing tables.
Hellos OSPF neighbors are identified by their router IDs. A router ID is an IP address by which the router is uniquely identified within the OSPF domain. A Cisco router selects its router ID as the highest IP address on any loopback interfaces configured on the router. If no loopback interfaces are configured on the router, the router chooses the highest IP address of any of its physical interfaces.
Routers that share a common segment may become neighbors on that segment. Neighbors are discovered via the OSPF Hello protocol and are recorded in a neighbor table. The Hello protocol:
Provides a way to discover OSPF neighbors Acts as a keepalive between neighbors Ensures bi-directional communication between neighbors Is used for designated router (DR) and backup designated router (BDR) election on certain types of networks
Hello packets are sent out all OSPF-enabled interfaces. They are sent out periodically with a special multicast address as the destination. Routers will become neighbors when they see themselves (their own router ID) in their neighbor’s hello packets and they agree upon certain parameters included in the hello packets. Neighbor negotiation will take place on the primary IP address only, not over secondary addresses. If secondary addresses are configured on the interface, they are restricted to be in the same OSPF area as the primary address. Two routers will become neighbors if the following parameters are agreed upon:
Area ID — The two routers sharing a common network segment must have their interfaces configured to be in the same area. Authentication — OSPF allows for configuration of a password for a specified area. Routers that want to become neighbors must exchange the same password over the common segment. Hello and Dead intervals — The hello interval is the amount of time between hello packets that a router sends out on an OSPF-enabled interface. The dead interval is the amount of time, in seconds, that a router will wait for a hello packet from a neighbor before declaring the neighbor down. These interval times are included in the hello packet and must be agreed upon by neighbors. Stub area flag — Two neighboring routers must also agree on the stub area flag in the hello packets in order to become neighbors. (Stub areas will also be discussed later.)
All of the above parameters are included in hello packets. Also included in hello packets are the following:
The router ID of the originating router The address and mask of the originating interface Router priority, which is used for DR election (discussed later) The DR and BDR Flag bits for option capabilities; one of these is the stub area flag mentioned above Router IDs of the originating router neighbors
Network Types After two-way communication between neighbors is established, OSPF routers move on to the next step, which is building adjacencies. Adjacent routers are routers that go beyond the hello protocol exchange and proceed into the database exchange process. As previously mentioned, not all neighboring routers become adjacent. Whether or not an adjacency is formed depends on the type of network to which the neighboring routers are connected. The types of networks that OSPF defines follow:
Point-to-point networks Broadcast networks Non-Broadcast Multi-Access networks (NBMA) Point-to-multipoint networks
Point-to-point networks, such as serial lines, connect a single pair of routers. OSPF will always form an adjacency with the neighbor on the other side of a point-to-point interface. There is no concept of DR or BDR on point-to-point networks. The destination address of OSPF packets on these networks will always be sent to 224.0.0.5, otherwise known as the ALLSPFRouters multicast address. Broadcast networks, such as Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI), are multi-access, meaning they are able to connect more than two devices; a packet sent by one router will be received by all connected routers. On broadcast networks, OSPF will elect a DR and a BDR. Hello packets on broadcast networks are sent to the destination address of 224.0.0.5. All packet originated by the DR and BDR are also sent to the this address. All other non-DR and non-BDR routers will send linkstate updates to the address 224.0.0.6, also known as AllDRouters. NBMA networks, such as Frame Relay, ATM, and X.25, can connect multiple devices, but they have no broadcast capability. (For more information on Frame Relay, please read the Frame Relay document.) A packet sent by a router will not be received by all the other routers attached to the network. Special care should be taken when configuring OSPF over NBMA networks. OSPF considers these media to be just like any other broadcast media such as Ethernet or Token Ring. As a result, extra configuration may be required for NBMA networks. OSPF routers elect a DR and BDR, and all OSPF packets are unicast. Point-to-multipoint networks are NBMA networks in which the networks are treated as a collection of point-to-point links. Routers on these networks do not elect a DR and BDR because the network is seen as point-to-point links. OSPF packets are multicast on these networks.
Designated Router and Backup Designated Router The DR and BDR are elected on broadcast networks in order to prevent certain problems. First, if every router attached to a broadcast network formed an adjacency with every other router attached to the network, there would be n(n - 1)/2 adjacencies. Second, if a router flooded its LSAs to all of the router neighbors and all routers in turn flooded the LSA to their neighbors, there would be multiple copies of the same LSA on the same network. The idea behind the DR is that every router attached to the network would form an adjacency with the DR. Only the DR would send LSA to the rest of the attached network. OSPF also elects a BDR in the event that the DR fails. This prevents routers from having to reelect a DR and reforming adjacencies with the new DR. Instead, the routers attached to the network form an adjacency with both the DR and BDR. If the DR goes down, the BDR becomes the DR; since the other routers already have a formed adjacency with the BDR, there is little, if any, network unavailability. DR and BDR election is done via the Hello protocol. Hello packets are exchanged via IP multicast packets on each segment. The router with the highest OSPF priority on the segment will become the DR. Default priority is one for Cisco router interfaces. This process is repeated for the BDR. If the priorities are the same, the router with the highest router ID will become the DR. A single DR/BDR pair is elected on each attached segment. A router that is the DR of one segment may not be the DR or BDR of another attached segment. Setting the OSPF priority of an interface can be done with the interface subcommand: ip ospf priority [value] A priority value of zero indicates that the interface will not be elected as the DR or BDR. Note that once a DR and a BDR have been elected, a new router coming on line that has a higher priority will not override the DR and BDR. When the new OSPF router becomes active and discovers its neighbors, it checks for valid DR and BDR. If the DR and BDR exist, the new router will accept them. Routers that are not the DR or BDR are known as DRother.
In the diagram above, the router that will be elected DR for Segment 1 will be Router_F. This is because the priorities of all the router interfaces are equal (P = 1 on all the interfaces). This results in the router with the highest router ID (RID) as being elected the designated router. Router_F has the highest RID and is, therefore, the DR. On segment 2, Router_C does not have the highest RID, but it still is elected the DR because its OSPF interface priority, which is 2, is higher than all the rest. The diagram below shows the resulting adjacencies that will be formed on segment 1 of the diagram above. Note that the routers that are not DR will form adjacencies only with the DR. In this illustration, the BDR is not shown, but adjacencies would also be formed with the BDR.
Building Adjacencies After neighbor discovery takes place and bi-directional communication is established (a router sees its own router ID in neighbor hello packet), neighboring routers attempt to
synchronize their link-state databases. When database synchronization in successful, the neighbors are fully adjacent. Neighbors on point-to-point and point-to-multipoint networks always become adjacent unless the parameters of the hello packets are not agreed upon. On broadcast networks and NBMA networks, the DR and BDR become adjacent with all neighbors. No adjacencies will be formed between the DRothers. The following are states through which OSPF routers will transition neighbors before being considered fully adjacent:
Down –— This is the initial state of the neighbor, indicating no information has been received from any router on the segment. Attempt –— On NBMA networks, where neighbors are manually configured, this state indicates that no recent information has been received from the neighbor. An effort is made to contact the neighbor by sending hello packets. Init –— This state indicates that a hello is received from a neighbor; however, bidirectional communication is not yet established. Two-way –— The router has seen itself in the neighbor hello packets. Bidirectional communication is now established. On broadcast networks DR and BDR are elected at the end of this state. When this state ends, a decision is made whether or not to proceed in building an adjacency. The decision is based on whether the neighbor is a DR or BDR or the network link is point-to-point. ExStart –— The router and its neighbor establish a master/slave relationship and determine the initial sequence number that is going to be used in the exchange of database description packets. Exchange –— Routers will describe their entire link-state database by sending database description packet to neighbors that are in the exchange state. Loading –— Routers build a link-state request list and retransmission list. Any information that looks outdated or incomplete will be put on the request list. Any update that has not been acknowledged will be put on the retransmission list. Full –— The adjacency is now complete. Adjacent routers will have identical linkstate databases.
Flooding The OSPF link-state database consists of all the LSAs the router has received. Each node in the network maintains an identical link-state database. A change in the topology means a change in one or more of the LSAs. Flooding is the process by which these new LSAs are sent throughout the network in order to ensure that the databases in all routers remain identical.
Areas Because of its complexity with multiple databases and flooding algorithms, OSPF can be memory and processor intensive. The demand for memory and processor utilization grows as the network grows. OSPF uses areas to reduce the strain on router memory and processor utilization. An area is a logical grouping of routers that break the OSPF network into subdomains. Routers must share identical databases with routers in its area only, not with the entire network. This reduces the memory demand. The smaller database results in a smaller number of LSAs to process, thereby reducing the demand of processing power. Most flooding is also limited within an area. Areas are interface specific and are identified with an area ID. The introduction of areas also introduces a different type of traffic. Intra-area traffic consists of packets that are contained within an area; inter-area packets travel between routers in different areas. External traffic consists of packets that travel between routers belonging to an OSPF domain and another autonomous system. Backbone If more than one area is configured, one of these areas must be defined as area 0. Area 0 is known as the backbone area. All other areas must be logically connected to area 0 either physically or through a virtual-link. Virtual-links are explained below. Each area gives routing information to area 0 which in turn disseminates that information to all other connected areas. For this reason, all inter-area traffic must pass through area 0. Non-backbone areas cannot exchange packets directly with one another. Virtual Links As mentioned above, all other areas must be physically connected to the backbone area, area 0. In some cases where this is not possible, a virtual link can be used. The virtual link will provide a link to the backbone through a nonbackbone area. Virtual links are also used to connect two parts of a partitioned backbone through a nonbackbone area.
As shown in the above diagram, virtual links can be established between two area border routers (ABRs) that have a common area, with one ABR connected to the backbone. The transit area is defined as the area between two ends of a virtual link. The transit area must be connected to area 0 to have full routing information and cannot be a stub area. OSPF classifies virtual links as point-to-point networks with no IP subnets associated with them. Router Types As mentioned above, areas are interface specific, meaning that a router can have one interface configured in one area and a second interface configured in a second area. Therefore, routers can be categorized in relation to areas. There are three types of OSPF routers.
Internal routers (IRs) –— An internal router is a router with all of its interfaces in the same area. Area border routers (ABRs) –— An ABR is a router that has interfaces in multiple areas. An ABR must always have at least one interface in the backbone area. Autonomous system boundary routers (ASBRs) –— ASBRs are routers that act as gateways between OSPF and other routing protocols or other OSPF routing processes. In other words, redistribution takes place on the ASBRs.
All valid LSAs received by a router are stored in a link-state database. These LSAs describe the topology of an area. Routers use the LSAs to calculate the shortest path tree. The list of LSAs in the database can be viewed with the command show ip ospf database. This list shows only the information in the LSA header, but it also contains LSAs from multiple areas if the router were an ABR. More detailed information of each LSA can be viewed with different commands, which will be explained later. An example output of the show ip ospf database command follows: Router_B#show ip ospf database OSPF Router with ID (170.170.3.2) (Process ID 7) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 170.170.3.2 170.170.3.2 17 0x80000002 0x8B6 1 170.170.8.4 170.170.8.4 217 0x80000003 0xAA02 1 170.170.13.3 170.170.13.3 218 0x80000002 0x5156 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.3.3 170.170.13.3 18 0x80000002 0xA0B2 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.7.0 170.170.8.4 240 0x80000001 0x6ED0 Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum 170.170.11.6 170.170.8.4 129 0x80000001 0xF73C Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 200.200.200.0 170.170.11.6 135 0x80000001 0xE4FA 0 Router_B# As can be seen from the information in the database in the above diagram, there are different types of LSAs defined by OSPF. Each type describes a different portion of the OSPF network. The table below lists the different LSA types and type codes and how the link-state is identified. Following the table is a description of the LSAs. Different LSA Types Type Code 1 2 3 4 5 7 LSA Router LSA Network LSA Network summary LSA ASBR summary LSA AS external LSA NSSA external LSA Link-State ID Originating router ID of the router Interface IP address of the DR Destination network number Router ID of AS boundary router External network number External network number
Router LSAs are generated by every router. The router LSA is a list of links attached to the router, as well as the state of the link and the outgoing OSPF cost associated with the link. To view details of the router LSA, use the show ip ospf database router command. Router LSA
Network LSAs are generated by the DR on a multi-access segment. They are the representation of the multi-access segment and all the routers attached to the segment. Segments that do not have a DR, such as point-to-point, will not have a network LSA. To view detailed information of the network LSA, use the show ip ospf database network command. Network LSA
Network summary LSAs are generated by ABRs. This is how network reachability information is advertised. ABRs are responsible for injecting information into the backbone and the backbone will pass the information on to other areas. The show ip ospf database summary command can be used to view detailed information of the summary LSA. Network Summary LSA
ASBR summary LSAs are also generated by the ABR. This LSA describes the location of an ASBR, not a network. The details can be viewed with the show ip ospf database asbr-summary command. ASBR Summary LSA
Autonomous System (AS) External LSAs are originated by the ASBRs and describe a network outside of the AS. They can be viewed with the show ip ospf database external command. AS External LSA
Not-So-Stubby Area (NSSA) external LSAs are originated by the ASBR within the NSSA. These types of LSAs are flooded only throughout the NSSA. These are unlike external LSAs, which are flooded throughout the entire network
Stub Areas ASBR routers will flood external routes throughout the OSPF domain. For this reason, OSPF allows certain areas to be configured as stub areas. Stub areas are areas into which external LSAs are not flooded. Routing from these areas to other parts of the OSPF network is done via the default route. The advantage to using stub areas is that the reduction of the link-state database reduces the requirements for memory. All OSPF routers inside a stub area must be configured as stub routers. Since all interfaces belonging to the area will start exchanging hello packets, the stub flag must be set in order to successfully form a neighbor relationship. Also, virtual links cannot be configured within or transit a stub area. Examples of stub areas and how to configure them will be shown in the "Configuring OSPF" section. Totally Stubby Areas Totally stubby areas are areas into which external LSAs and summary LSAs (inter-area routes) are not flooded. The only thing injected into the totally stubby area are intra-area routes and the default route (0.0.0.0). The default route is the only type 3 (summary) LSA that the ABR will allow into the totally stubby area. An example of totally stubby areas and their configuration is discussed in the "Configuring OSPF" section. Not-So Stubby Areas In some cases, it may be necessary to connect a stub area to an external AS and redistribute the external routes into OSPF. Unfortunately, this means that the stub area router will become an ASBR, meaning the area can no longer be a stub area. NSSAs allow external routers to be advertised into the OSPF AS while retaining the characteristics of a stub area. The ASBR in the NSSA will originate type 7 LSAs. These external NSSA LSAs are flooded throughout the NSSA but are blocked at the ABR. The ABR will translate this into a type 5 LSA and flood it into the other areas. An example of NSSAs and their configuration is discussed in the "Configuring OSPF" section.
OSPF On-Demand Circuits OSPF demand circuit is an enhancement to the OSPF protocol that allows efficient operation over on-demand circuits such as ISDN and dial-up lines. Prior to this feature, periodic hellos and LSA updates would be exchanged between routers that connected the on-demand link, even when there were no changes in the Hello or LSA information. With this feature, periodic Hellos are suppressed and periodic refresh of LSAs are not flooded over demand circuits. These packets bring up the link only when they are exchanged for the first time, or when there is a change in the information they contain.
Enabling OSPF As with other routing protocols, enabling OSPF requires that you: 1. Create an OSPF routing process. 2. Specify the range of IP addresses to be associated with the routing process, and assign area IDs to be associated with that range of IP addresses. Use the following commands, starting in global configuration mode: Step 1. Command router ospf process-id Purpose Enable OSPF routing, placing you in router configuration mode. Define an interface on which OSPF runs and define the area ID for that interface.
2.
network address wildcard-mask area areaid
The OSPF process ID is a numerical value that is local to the router. It does not have to match any process IDs that might be running on other routers. It is possible to run more than one process on the same router. However, this will create multiple databases and cause more overhead on the router. The wildcard mask in the network command allows a user to configure multiple interfaces into the same area with a single configuration line. The wildcard mask is an inverse mask and is used the same as an inverse mask with access lists. The area ID is the area in which the interface(s) will be configured. It can be an integer 0 to 4294967295 or it can take the form of a dotted decimal number such as 0.0.0.0.
Router_D: interface ethernet 0 ip address 170.170.3.4 255.255.255.0 interface serial 0 ip address 170.170.7.4 255.255.255.0 router ospf 7 network 170.170.3.0 0.0.0.255 area 0 network 170.170.7.0 0.0.0.255 area 51 In above example, the router ospf 7 command enables OSPF on Router_D. The first network command enables OSPF on interface Ethernet 0 and puts it in area 0. The second network statement enables OSPF on interface serial 0 and puts it in area 51. Note that network area commands are executed consecutively. The second network area command affects only interfaces that do not match the first command. For example: router ospf 7 network 100.100.0.0 0.0.255.255 area 0 network 100.100.10.0 0.0.0.255 area 2 All interfaces with an IP address of 100.100.x.x will be placed into area 0; therefore, the second network area command is never applied. Configuring OSPF Interface Parameters As mentioned before, OSPF exchanges Hello packets on each OSPF-enabled segment. This is a form of keepalives as well as a method for neighbor discovery and DR/BDR election. The rate at which OSPF sends the hello packets out is called the "Hello Interval." The amount of time an OSPF router will wait for a hello packet before declaring the neighbor down is called the "Dead Interval." OSPF requires that these
intervals be the same between two neighbors; otherwise the two routers will not become OSPF neighbors. Use the following commands to modify these parameters on an interface basis: Command ip ospf hello-interval seconds Purpose Specify the length of time between the hello packets that the Cisco IOS® software sends on an OSPF interface. Set the number of seconds that a device's hello packets must not have been seen before its neighbors declare the OSPF router down.
ip ospf dead-interval seconds
An OSPF interface parameter that plays a very important role in the election of the DR and BDR is the OSPF priority. On a given segment the router with the highest priority will become the DR. If the priorities are the same, the DR will be the router with the highest router ID. To reiterate, the router ID is defined as the highest numerical ip address of the router's interfaces or the highest loopback ip address if it exists at the time that OSPF was configured on the router. If a user wishes a particular router to become the DR or if the user wishes that a particular router not be eligible as a DR/BDR, the following command can be used to modify the OSPF interface priority: Command ip ospf priority number Purpose Set priority to help determine the OSPF-designated router for a network.
If the ospf priority on the interface is set to 0, then the router can never become the DR or BDR for that network segment. The metric that OSPF uses to determine shortest path is called the OSPF cost. This interface parameter can also be modified in order to manipulate routing decisions. The command follows: Command ip ospf cost cost Purpose Explicitly specify the cost of sending a packet on an OSPF interface.
OSPF interface parameters can be viewed with the command show ip ospf interface, as seen in the following example:
Router_D#show ip ospf interface ethernet 0 Ethernet0 is up, line protocol is up Internet Address 170.170.3.4/24, Area 0 Process ID 7, Router ID 170.170.8.4, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 170.170.13.3, Interface address 170.170.3.3 Backup Designated router (ID) 170.170.8.4, Interface address 170.170.3.4 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:08 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 3 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 170.170.3.2 Adjacent with neighbor 170.170.13.3 (Designated Router) Suppress hello for 0 neighbor(s) Router_D# Configuring OSPF over Different Physical Networks As mentioned above, OSPF classifies networks as being broadcast, NBMA, or point-topoint. When configuring OSPF over NBMA networks, special care should be taken. Most NBMA networks, such as Frame Relay, are partially meshed networks and the physical topology does not provide the multi-access connectivity that OSPF assumes is there. The selection of DR becomes a very important issue because the DR and BDR have to have physical connectivity to all the neighboring routers. The neighbor command is used to give the DR/BDR a static list of all other routers attached to the network. This is needed because of the lack of broadcast capabilities. The command follows: Command neighbor ip-address [priority number] [poll-interval seconds] Purpose Configure a router interconnecting to nonbroadcast networks.
In the above command, the IP address and priority are values given to the neighbor. The poll interval is the amount of time a NBMA interface will wait before sending a hello to a presumably dead neighbor.
Note that after the release of Cisco IOS 10.0, the neighbor command is not necessary. There are other ways of running OSPF over NBMA networks that are much more efficient. Point-to-Point Subinterfaces The use of subinterfaces is a way to split a physical interface into multiple logical interfaces. Each subinterface can be defined as point-to-point. A point-to-point subinterface has the properties of any physical point-to-point interface. As far as OSPF is concerned, an adjacency is always formed over a point-to-point network without electing a DR or BDR. One drawback of point-to-point subinterfaces is that each point-to-point segment requires its own subnet. The following is an example of configuring point-to-point subinterfaces with OSPF. In the topology below, the serial 2 interface of Router_F can be logically split into two point-to-point subinterfaces. Each subinterface is assigned an address out of a unique subnet. Router_G and Router_H also have a subinterface configured.
Excerpts from the configurations for Router_F and Router_G follow: Router_F: interface Serial2 no ip address encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial2.7 point-to-point ip address 170.170.11.6 255.255.255.0 frame-relay interface-dlci 101 ! interface Serial2.8 point-to-point ip address 170.170.10.6 255.255.255.0 frame-relay interface-dlci 103 router ospf 7
network 170.170.11.0 0.0.0.255 area 0 network 170.170.10.0 0.0.0.255 area 0 Router_G: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.6 point-to-point ip address 170.170.11.7 255.255.255.0 frame-relay interface-dlci 110 router ospf 7 network 170.170.11.0 0.0.0.255 area 0 Selecting Interface Network Types The following command can be used to define the network type of an OSPF interface: Command ip ospf network {broadcast | nonbroadcast | {point-to-multipoint [nonbroadcast] }} Purpose Configure the OSPF network type for a specified interface.
Each network type that can be configured with the above command will be explained below. Point-to-Multipoint Interfaces A point-to-multipoint interface is defined as a numbered point-to-point interface that has multiple neighbors. Users do not have to worry about having a subnet for each point-topoint link, and the "NBMA cloud" could be configured as one subnet. Since the links are still considered point-to-point, the user would not have to worry about the election of DR and BDR. Point-to-multipoint exchanges additional link-state updates that contain descriptions of the connectivity to the neighboring routers, resulting in host routes for all the neighbors. An example of how point-to-multipoint is configured follows:
Following are excerpts from the configurations of Router_E and Router_G in the above topology. Router_E: interface Serial1 ip address 170.170.9.5 255.255.255.0 no ip mroute-cache encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 170.170.9.7 121 broadcast frame-relay map ip 170.170.9.8 123 broadcast router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Router_G: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.5 multipoint ip address 170.170.9.7 255.255.255.0 ip ospf network point-to-multipoint frame-relay map ip 170.170.9.5 112 broadcast router ospf 7 network 170.170.9.0 0.0.0.255 area 0 As mentioned earlier, when point-to-multipoint interfaces are configured, host routes are generated for all the neighbors. This can be seen in the output from a show ip route on Router_E: Router_E#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR Gateway of last resort is not set 170.170.0.0/16 is variably subnetted, 5 subnets, 2 masks O 170.170.9.8/32 [110/64] via 170.170.9.8, 00:07:01, Serial1 C 170.170.9.0/24 is directly connected, Serial1 O 170.170.9.7/32 [110/64] via 170.170.9.7, 00:07:01, Serial1 Router_E# Because of these host routes, Router_G will not need a Frame Relay map statement for Router_H, and Router_H will not need one for Router_G. Also note there is not a DR or BDR elected on a point-to-multipoint interface: Router_E#show ip ospf interface serial 1 Serial1 is up, line protocol is up Internet Address 170.170.9.5/24, Area 0 Process ID 7, Router ID 170.170.9.5, Network Type POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:04 Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 170.170.12.8 Adjacent with neighbor 170.170.12.7 Suppress hello for 0 neighbor(s) Router_E# Broadcast Interfaces Setting the interface type to broadcast will logically set the interface to be a broadcast interface, and it will behave as if the router were connected to a LAN or broadcast network. DR and BDR election will take place, so if there is not a full mesh topology, care must be taken about which router will become the DR. Use of the OSPF priority command should be considered if necessary. The following is an example configuration for broadcast interfaces:
Router_E configuration: interface Serial1 ip address 170.170.9.5 255.255.255.0 no ip mroute-cache encapsulation frame-relay ip ospf network broadcast ip ospf priority 5 frame-relay map ip 170.170.9.7 121 broadcast frame-relay map ip 170.170.9.8 123 broadcast ! router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Router_G configuration: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.5 multipoint ip address 170.170.9.7 255.255.255.0 ip ospf network broadcast frame-relay map ip 170.170.9.5 112 broadcast ! router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Router_H configuration: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.5 multipoint ip address 170.170.9.8 255.255.255.0
ip ospf network broadcast frame-relay map ip 170.170.9.5 132 broadcast ! router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Note that in the configuration of Router_E, the interface OSPF priority was set to 5 (default is 1). This was because Router_E is the common router in the network; therefore, this should be the DR. Setting the priority to 5 while the others stayed at default 1 results in Router_E becoming the DR, as can be seen with the show ip ospf interface serial 1 command: Router_E#sh ip ospf interface serial 1 Serial1 is up, line protocol is up Internet Address 170.170.9.5/24, Area 0 Process ID 7, Router ID 170.170.9.5, Network Type BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 5 Designated Router (ID) 170.170.9.5, Interface address 170.170.9.5 Backup Designated router (ID) 170.170.12.8, Interface address 170.170.9.8 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:05 Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 170.170.12.8 (Backup Designated Router) Adjacent with neighbor 170.170.12.7 Suppress hello for 0 neighbor(s) Router_E# It can also be seen that Router_H is the BDR from the output above. This may not be desirable since Router_H and Router_G do not have Frame Relay link between them. Router_G and Router_H could be prevented from becoming either DR or BDR by setting their interface priority to zero. Configuring Route Summarization Address summarization can help to conserve resources within the backbone area. Summarizing is the consolidation of multiple routes into one single advertisement. This is done at the ABRs or ASBRs summarizing into the direction of the backbone. This way, the backbone will receive the aggregate addresses and will inject the summarized route into other areas. Two types of summarization can be configured for OSPF:
Inter-area route summarization External route summarization
Inter-area route summarization is done on ABRs and accounts for only routes within the OSPF domain. It does not account for external routes. The router subcommand for inter-area summarization follows: Command area area-id range address mask Purpose Specify an address range for which a single route will be advertised.
In the above command, area-id is the area containing the networks to be summarized.
In the above topology, Area 51 contains networks 172.16.128.0/24 through 172.16.159.0/24. Router_B can summarize these subnets into a single route with the area range command as follows: router ospf 7 network 170.170.1.0 0.0.0.255 area 51 network 170.170.3.0 0.0.0.255 area 0 area 1 range 172.16.128.0 255.255.224.0 External route summarization is done on the ASBRs that are injecting the external routes. The router subcommand for external route summarization follows: Command summary-address address mask Purpose Specify an address and mask that covers redistributed routes, so only one summary route is advertised.
In the above topology, Router_A is redistributing several routes into OSPF: routes 172.16.128.0/24 – 172.16.159.0/24. Since these are external OSPF routes, they cannot be summarized with the area range command. To summarize external routes, use the summary-address command as shown in the example below. The summarization should take place in the ASBR; in this case, Router_A will do the summarization: router ospf 7 summary-address 172.16.128.0 255.255.224.0 redistribute static subnets network 170.170.1.0 0.0.0.255 area 51 Configuring Stub Areas and Totally Stubby Areas As mentioned previously, stub areas are areas into which external LSAs are not flooded. Routing to these areas to the external networks is done based on the default route. An extension to stub areas is totally stubby areas. A totally stubby area is an area that blocks external routes and summary routes (inter-area routes) from being flooded. Only intra-area routes and the default route are injected into the area. The router subcommand that configures an area as a stub follows: Command area area-id stub [no-summary] Purpose Define an area to be a stub area.
The keyword no-summary in the above command defines the area as a totally stubby area. If the keyword is not used, the area is just a stub area.
In the topology above, Router_A is redistributing routes 172.16.128.0/24– 172.16.159.0/24 into OSPF. If we configured area 1 as a stub area, routers in area 1 would not learn about these networks. Instead, routers in area 1 would get a default route. The configurations of Router_D and Router_F, for the topology above, are shown below: Router_D: router ospf 7 network 170.170.3.0 0.0.0.255 area 0 network 170.170.7.0 0.0.0.255 area 1 area 1 stub Router_F: router ospf 7 network 170.170.7.0 0.0.0.255 area 1 area 1 stub The following is a show ip route from Router_F; note that a default route has been injected, but the external routes are not in the routing table. Router_F#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR
Gateway of last resort is 170.170.7.4 to network 0.0.0.0 170.170.0.0/24 is subnetted, 3 subnets O IA 170.170.1.0 [110/138] via 170.170.7.4, 00:02:42, Serial0 O IA 170.170.3.0 [110/74] via 170.170.7.4, 00:02:42, Serial0 C 170.170.7.0 is directly connected, Serial0 O*IA 0.0.0.0/0 [110/65] via 170.170.7.4, 00:02:42, Serial0 Router_F# To make area 1 totally stubby, add the no-summary keyword to the area stub command as follows: Router_D: router ospf 7 network 170.170.3.0 0.0.0.255 area 0 network 170.170.7.0 0.0.0.255 area 1 area 1 stub no-summary Router_F: router ospf 7 network 170.170.7.0 0.0.0.255 area 1 area 1 stub no-summary This results in the following routing table for Router_F: Router_F#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR Gateway of last resort is 170.170.7.4 to network 0.0.0.0 170.170.0.0/24 is subnetted, 1 subnets C 170.170.7.0 is directly connected, Serial0 O*IA 0.0.0.0/0 [110/65] via 170.170.7.4, 00:00:00, Serial0 Router_F# Configuring Not-So Stubby Areas As mentioned before, it is sometimes necessary to redistribute external information into a stub area. This is possible with the NSSA. To configure NSSA, the following router subcommand is used:
Command area area-id nssa [no-redistribution] [default-information-originate]
Purpose Define an area to be NSSA.
In the above topology, area 51 is an NSSA area. Router_A is redistributing static routes into area 51. Router_A should send them to Router_B as type 7 LSAs and Router_B should translate the type 7 LSAs into type 5 LSAs and flood them to the rest of the network. The configurations for Router_A and Router_B are as follows: Router_A: router ospf 7 redistribute static subnets network 170.170.1.0 0.0.0.255 area area 51 nssa ! ip route 172.16.128.0 255.255.255.0 ip route 172.16.129.0 255.255.255.0 ip route 172.16.130.0 255.255.255.0 Router_B: router ospf 7 network 170.170.1.0 0.0.0.255 area 51 network 170.170.3.0 0.0.0.255 area 0 area 51 nssa If we take a look at the routing table of Router_B, we will see the type 7 NSSA routes: Router_B# sh ip route
51 Serial1 Serial1 Serial1
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR, P - periodic downloaded static route T - traffic engineered route Gateway of last resort is not set 170.170.0.0/24 is subnetted, 3 subnets C 170.170.1.0 is directly connected, Serial0 C 170.170.3.0 is directly connected, Ethernet0 O IA 170.170.7.0 [110/74] via 170.170.3.4, Ethernet0 172.16.0.0/24 is subnetted, 3 subnets O N2 172.16.128.0 [110/20] via 170.170.1.1, Serial0 O N2 172.16.129.0 [110/20] via 170.170.1.1, Serial0 O N2 172.16.130.0 [110/20] via 170.170.1.1, Serial0 Router_B# The OSPF database of Router_B shows that there are also type 5 LSAs. Router_B#show ip ospf database OSPF Router with ID (170.170.3.2) (Process ID 7) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 170.170.3.2 170.170.3.2 1395 0x8000002A 0xB6DD 1 170.170.8.4 170.170.8.4 973 0x80000029 0x5433 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.3.2 170.170.3.2 1773 0x80000027 0x2281 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.1.0 170.170.3.2 1773 0x80000027 0x9392 170.170.7.0 170.170.8.4 974 0x80000027 0x22F6 Router Link States (Area 51) Link ID ADV Router Age Seq# Checksum Link count 170.170.3.2 170.170.3.2 1378 0x8000002A 0x5F4C 2 170.170.13.1 170.170.13.1 1381 0x80000038 0x3D59 2 Summary Net Link States (Area 51) Link ID ADV Router Age Seq# Checksum 170.170.3.0 170.170.3.2 1398 0x8000002A 0xFE52 170.170.7.0 170.170.3.2 1398 0x80000028 0x59B5 Type-7 AS External Link States (Area 51)
Link ID ADV Router Age Seq# Checksum Tag 172.16.128.0 170.170.13.1 124 0x80000002 172.16.129.0 170.170.13.1 125 0x80000002 172.16.130.0 170.170.13.1 125 0x80000002 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 172.16.128.0 170.170.3.2 1367 0x80000001 172.16.129.0 170.170.3.2 1367 0x80000001 172.16.130.0 170.170.3.2 1367 0x80000001 Router_B#
0xFF9D 0 0xF4A7 0 0xE9B1 0 0xD6DA 0 0xCBE4 0 0xC0EE 0
Router_D and Router_F would see only the type 5 LSAs. Configuring OSPF On-Demand Circuits To allow efficient operation of OSPF over on-demand circuits such as ISDN or dial-up lines, OSPF can be configured for on-demand circuits. The following interface subcommand is used for this: Command ip ospf demand-circuit Purpose Configure OSPF on an on-demand circuit.
External routes are to destinations outside of the OSPF AS. When an external route is redistributed into OSPF, it must be assigned a metric that is compatible with OSPF. This is the responsibility of the ASBR, which can assign an OSPF metric to the external route. The ASBR is also responsible for categorizing the external route as either external type 1 (E1) or external type 2 (E2). The difference between the two is the way the metric of the route is calculated when determining shortest path. The cost of a an E2 route is always the external cost, irrespective of the internal cost. The cost of an E1 route is the sum of the internal and external costs. E1 routes are always preferred over E2 routes.
In the above topology, if the two ASBRs (Router_F and Router_C) are injecting external route 10.10.10.0/24 as E1 routes, Router_E would see the cost to 10.10.10.0/24 as 20 (5 + 10 + 5) through Router_C. The E1 cost through Router_F, as seen by Router_E, would be 30 (20 + 5 + 5). Therefore, the path through Router_C would be preferred. If the ASBRs were injecting the route as E2 routes, the Router_E cost to the network through Router_C would be 15 (10 + 5). The Router_E cost to the network through Router_F would be 10 (5 + 5). Therefore, the path through Router_F would be preferred.
If the external costs to the destination network are equal as in the above topology, and the external routes are injected as E2 routes, then the path selected as the best path would be the path with the lowest cost to the ASBR. In the above topology the external costs are equal (10), so Router_E will select the path through Router_C because its cost through Router_C is 5, versus the cost to Router_F, which is 20.
The command for redistributing external routes into OSPF is as follows: Command redistribute protocol [process-id] [metric metric-value] [metric-type typevalue] [subnets] Purpose This command redistributes routes from one routing domain into OSPF.
Originating Default Routes An ASBR does not, by default, advertise a default route into an OSPF domain. It can be forced to with the following command: Command default-information originate [always] [metric metric-value] [metric-type typevalue] [route-map map-name] Purpose Force the AS boundary router to generate a default route into the OSPF routing domain.
The "always" keyword will force the ASBR to advertise a default route, whether or not it has a default route in its routing table. Without the "always" keyword the ASBR will advertise a default route only if it has one. The "metric" and "metric-type" are the cost and type (E1/E2) assigned to the default route. The "route-map" can specify a set of conditions that need to be met before the default route will be advertised.
Access lists can be used for many purposes, such as:
Controlling transmission of packets on an interface Controlling virtual terminal access Restricting contents of routing updates Determining if an address should be translated when using Network Address Translation
Access lists are specified by either a name or a number. Prior to Cisco IOS® Version 11.2, access lists could be specified only by number. The following table lists protocols that can use access lists specified by names. Protocols with Access Lists Specified by Names
Protocol Apollo Domain IP Extended IP ISO CLNS Source-Route Bridging NetBIOS NetBIOS IPX The following table lists protocols that use access lists specified by numbers. It also includes the range of access-list numbers that is valid for each protocol. Protocols with Access Lists Specified by numbers Protocol IP Extended IP Ethernet Type Code Ethernet Address Transparent Bridging (protocol type) Transparent Bridging (vendor code) Extended Transparent Bridging DECnet and Extended DECnet XNS Extended XNS AppleTalk Range 1 to 99 100 to 199 200 to 299 700 to 799 200 to 299 700 to 799 1100 to 1199 300 to 399 400 to 499 500 to 599 600 to 699
Source-Route Bridging (protocol type) Source-Route Bridging (vendor code) IPX Extended IPX IPX SAP Standard VINES Extended VINES Simple VINES Standard IP (expanded) Extended IP (expanded)
200 to 299 700 to 799 800 to 899 900 to 999 1000 to 1099 1 to 100 101 to 200 201 to 300 1300 to 1999 2000 to 2099
As of Cisco IOS Version 12.0, IP access lists have been expanded. The table above shows that Standard and Extended IP access lists have been expanded with numbers 1300 to 2099. An access list is a sequential collection of permit and deny criteria that are checked against IP packets. The Cisco IOS software checks the IP packets against each accesslist criterion one by one. The first match determines if the packet is accepted (permitted) or rejected (denied). Once the first match has been made, the Cisco IOS software stops checking for any more matches in the access list. For this reason, the order of the access-list criteria is very important. If no match is found, the packet is implicitly rejected. Another important fact to remember is that at the end of every access list is an implicit deny all. The Cisco IOS software supports the following types of access lists for IP: 1. 2. 3. 4. 5. Standard IP Extended IP Time based Dynamic extended Reflexive
Standard IP access lists use the source IP address for matching criteria.
Extended IP access lists use the source IP address and destination IP address for matching criteria. These lists also use optional protocol-type information for more granularity. As of Cisco IOS Version 12.0T, it is possible to implement access lists based on the time of day. These access lists are known as time-based access lists. Both standard IP and extended IP access lists can be time based. Dynamic extended IP access lists grant user access per user on a specific source or destination host basis through a user-authentication process. Dynamic access lists are a security feature that will not be discussed in this module. Reflexive access lists allow IP packets to be filtered based on session information. Reflexive access lists contain temporary entries and are nested within an extended, named IP access list.
Standard Access Lists To create a standard access list, use one of the following commands in the global configuration mode. Command access-list access_list_# {deny|permit} source [source_wildcard] [log] access-list access_list_# {deny|permit} any [log] Purpose Define a standard IP access list using a source IP address and wildcard mask.
Define a standard IP access list using an abbreviation for the source and source mask of 0.0.0.0 255.255.255.255
The wildcard mask is essentially the inverse of the regular mask. For example, if we wanted to permit any IP packets that are sourced from subnet 172.16.10.0 255.255.255.0, we could create the following access list: access-list 1 permit 172.16.10.0 0.0.0.255 Notice that the wildcard mask in the access list is the inverse of the mask for the subnet. In a wildcard mask, the "zero" bits are important and the "one" bits are ignored. In the above access list, any IP packet sourced from 172.16.10.x would match the access list and, therefore, be permitted.
A packet sourced from any other source would be denied, because of the implicit "deny all" at the end of the access list. If we wanted to permit only IP packets sourced from the specific host address 172.16.10.177 255.255.255.255, the access list would look like this: access list 1 permit 172.16.10.177 0.0.0.0 Note: If you omit the wildcard mask from an associated IP host address in an access list, 0.0.0.0 is assumed to be the mask. The log keyword at the end of the command allows the Cisco IOS software to provide logging messages about packets that are permitted or denied by a standard access list. The first packet that matches the access list will cause an informational console message to appear immediately. Subsequent packets are collected over five-minute intervals before they are displayed or logged. Extended Access Lists To create an extended IP access list, use one of the following commands in the global configuration mode: Command access-list access_list_# {deny|permit} protocol source source_wildcard destination destination_wildcard [precedence precedence] [tos tos] [established] [log] access-list access_list_# {deny|permit} protocol any any Purpose Define an extended IP access list number and the access conditions. Use the log keyword to get access list logging messages, including violations.
Define an extended IP access list using an abbreviation for a source and source wildcard of 0.0.0.0 255.255.255.255, and an abbreviation for a destination and destination wildcard of 0.0.0.0 255.255.255.255. Define an extended IP access list using an abbreviation for a source and source wildcard of source 0.0.0.0, and an abbreviation for a destination and destination wildcard of destination 0.0.0.0.
access-list access_list_# {deny|permit} protocol host source host destination
Imagine that we need an extended access list meeting the following requirements:
Allow IP packets sourced from a host with address 172.16.10.1 destined for subnet 170.170.10.0 255.255.255.0. Deny any other IP packets that are destined for the same destination subnet of 170.170.10.0. Permit all other IP packets.
One access list that meets these requirements follows: access-list 101 permit ip 172.16.10.1 0.0.0.0 170.170.10.0 0.0.0.255 access-list 101 deny ip 0.0.0.0 255.255.255.255 170.170.10.0 0.0.0.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Another follows: access-list 103 permit ip host 172.16.10.1 170.170.10.0 0.0.0.255 access-list 103 deny ip any 170.170.10.0 0.0.0.255 access-list 103 permit ip any any Access list 101 and access list 103 accomplish the same thing. Access list 103 uses the "host" abbreviation for the 0.0.0.0 wildcard mask and the "any" abbreviation for 0.0.0.0 255.255.255.255. Now that we have learned how to create standard and extended access lists, it is important to mention that after an access list is initially created, any lines later added to the access list are placed at the end of the list. Also, access-list command lines cannot be removed selectively; in order to change one line of the access list, the entire access list must be removed and reconfigured. After creating the access list, it must be applied for some purpose. We will discuss some of these purposes later.
IP access lists can be identified with an alphanumeric string (a name) rather than with a number (1 to 199). This setup allows a user to configure more than 99 standard IP access list and 100 extended IP access lists. When configuring IP named access lists, keep the following in mind:
Access lists specified by name are not compatible with releases of the Cisco IOS software older than Version 11.2. Not all applications for access lists will accept a named IP access list, though access lists for packet filters and route filters on interfaces can be named. A standard access list and an extended access list cannot have the same name.
Standard Named IP Access Lists To create a standard named IP access list, complete the following steps: Step 1. Command ip access-list standard name deny {source [source_wildcard]|any}[log] or permit {source [source_wildcard]|any}[log] 3. exit Exit access-list configuration mode. Purpose Define a standard IP access list using a name. In access-list configuration mode, specify one or more conditions allowed or denied to determine whether the packet is passed or dropped.
2.
For example, if we wanted to permit any IP packets that are sourced from subnet 172.16.10.0 255.255.255.0, we could create the following access list: ip access-list standard test permit 172.16.10.0 0.0.0.255 Notice that the use of the wildcard mask is still the same. Extended Named IP Access Lists To create an extended named IP access list, complete the following steps: Step 1. Command ip access-list extended name Purpose Define an extended IP access list using a name. In access-list configuration
2.
{deny | permit} protocol source
source_wildcard destination destination_wildcard [precedence precedence] [tos tos] [established] [log]
mode, specify the conditions allowed or denied. Use the log keyword to get access-list logging messages, including violations. or
or {deny | permit} protocol any any Define an extended IP access list using an abbreviation for a source and a source wildcard of 0.0.0.0 255.255.255.255, and an abbreviation for a destination and a destination wildcard of 0.0.0.0 255.255.255.255. or Define an extended IP access list using an abbreviation for a source and a source wildcard of source 0.0.0.0, and an abbreviation for a destination and a destination wildcard of destination 0.0.0.0. 3. exit Exit access-list configuration mode.
or {deny | permit} protocol host source host destination
Imagine that we need an extended access list meeting the following requirements:
Allow IP packets sourced from a host with address 172.16.10.1 destined for subnet 170.170.10.0 255.255.255.0. Deny any other IP packets that have the same subnet, 170.170.10.0, in the destination portion of the packet. Permit all other IP packets.
One access list that meets these requirements follows: ip access-list extended test permit ip 172.16.10.1 0.0.0.0 170.170.10.0 0.0.0.255 deny ip 0.0.0.0 255.255.255.255 170.170.10.0 0.0.0.255 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
Another follows: ip access-list extended test permit ip host 172.16.10.1 170.170.10.0 0.0.0.255 deny ip any 170.170.10.0 0.0.0.255 permit ip any any
As of Cisco IOS Version 12.0T, it is possible to implement access lists based on the time of day. To do so, you create a time range that defines specific times of the day and week. The time range is identified by a name and then referenced by an access-list function, so that those time restrictions are imposed on the function itself. Currently, IP and Internetwork Packet Exchange (IPX) extended access lists are the only functions that can use time ranges. The time range allows the network administrator to define when the permit or deny statements in the access list are in effect. Prior to this feature, access-list statements were always in effect once they were applied. Both named or numbered access lists can reference a time range. Note: The time range relies on the system clock of the router. For this feature to work as intended, you need a reliable clock source. It is recommended that you use Network Time Protocol (NTP) to synchronize the router clock. Creating a time-based access list requires two steps: 1. Define a time range. 2. Reference the time range with an access-list function. To define a time range, complete the following steps: Step 1. Command time-range time-range-name Purpose Identify the time range by a meaningful name. In time-range configuration mode, specify when the function it will be applied to will be in effect. Specify some combination of these commands; multiple periodic statements are allowed; only one absolute statement is allowed.
2.
absolute [start time date] [end time date] and/or periodic days-of-the-week hh:mm to [days-of-the-week] hh:mm
Repeat these tasks if you have multiple items you want in effect at different times. For example, repeat the steps to include multiple permit or deny statements in an access list in effect at different times. To reference the time range with an access-list function, the keyword "time-range" has been added to the access-list command. The following steps show the named accesslist command with the new keyword: Step 1. Command ip access-list extended name Purpose Define an extended IP access list using a name. In access-list configuration mode, specify the conditions allowed or denied. Use the log keyword to get access-list logging messages, including violations. Specify a time range to restrict when the permit or deny statement is in effect. or Define an extended IP access list using an abbreviation for a source and source wildcard of 0.0.0.0 255.255.255.255, and an abbreviation for a destination and destination wildcard of 0.0.0.0 255.255.255.255. or {deny | permit} protocol host source host destination [log] [time-range time-rangename] Define an extended IP access list using an abbreviation for a source and source wildcard of source 0.0.0.0, and an abbreviation for a destination and destination wildcard of destination 0.0.0.0. or Define a dynamic access list. dynamic dynamic-name [timeout minutes] {deny | permit} protocol source source-wildcard destination destination-wildcard
2.
{deny|permit} protocol source source-wildcard destination destinationwildcard [precedence precedence] [tos tos] [established][log] [timerange time-range-name]
{deny | permit} protocol any any [log] [time-range timerange-name]
[precedence precedence] [tos tos] [established] [log] [time-range time-rangename]
For information about Lock and Key access, refer to the Configuring Lock-andKey Security (Dynamic Access Lists) chapter in the Security Configuration Guide.
For example, if we wanted to create a time-based access list that will deny Hypertext Transfer Protocol (HTTP) traffic on Monday through Friday between the hours of 8:00 a.m. and 6:00 p.m. on IP, and will allow User Datagram Protocol (UDP) traffic on Saturday and Sunday from noon to 8:00 p.m. only, we could create the following time ranges and access list: time-range no-http periodic weekdays 8:00 to 18:00 ! time-range udp-yes periodic weekend 12:00 to 20:00 ! ip access-list extended strict deny tcp any any eq http time-range no-http permit udp any any time-range udp-yes ! interface ethernet 0 ip access-group strict in
As of Cisco IOS Version 12.0(2)T, you can now include comments (remarks) about entries in any IP access list. The remarks make the access list easier for the network administrator to understand. Each remark is limited to 100 characters. Remarks about entries in an IP access list make the list easier to understand and scan. For example, it is not immediately clear what the purpose of the following entry is: access-list 1 permit 171.69.2.88 It is much easier to read a remark about the entry to understand its effect, as follows: access-list 1 remark Permit only Tom Jones workstation through access-list 1 permit 171.69.2.88
To write a comment about an entry in a named IP access list, use the following commands in the order shown. Step 1 is performed once; Step 2 can be performed multiple times in the access list, before or after any permit or deny command. Step 1. Command Router(config)# ip access-list standard name or Router(config)# ip access-list extended name 2. Router(config-std-nacl)# remark remark or Router(config-ext-nacl)# remark remark To write a comment about an entry in a numbered IP access list, use the following command before or after any access-list permit or access-list deny command: Command Router(config)# access-list access-listnumber remark Examples In the following example of a numbered access list, the workstation belonging to Jones is allowed access and the workstation belonging to Smith is not allowed access: access-list access-list access-list access-list 1 1 1 1 remark Permit only Jones workstation through permit 171.69.2.88 remark Do not allow Smith workstation through deny 171.69.3.13 Purpose Indicates the purpose of the permit or deny statement Indicates the purpose of the permit or deny statement Purpose Identifies the access list by name
In the following example of a numbered access list, the Winter and Smith workstations are not allowed to browse the Web:
access-list access-list access-list access-list
100 100 100 100
remark Do deny host remark Do deny host
not allow Winter to browse the web 171.69.3.85 any eq http not allow Smith to browse the web 171.69.3.13 any eq http
In the following example of a named access list, the Jones subnet is not allowed access: ip access-list standard prevention remark Do not allow Jones subnet through deny 171.69.0.0 0.0.255.255 In the following example of a named access list, the Jones host is not allowed to use outbound Telnet: ip access-list extended telnetting remark Do not allow Jones subnet to telnet out deny tcp host 171.69.2.88 any eq telnet
As mentioned before, access lists are used for a variety of purposes. Some examples follow: Note: The ip access-group command is used to apply the access list to an interface. It can be applied outbound or inbound, a scenario that is explained later. Filtering IP Packets on Router Interfaces with Standard Numbered Access Lists Network 137.77.0.0 is a Class B network that is directly connected to the Ethernet0 interface of a router. The network is subnetted to several subnets using the subnet mask 255.255.255.0. We want to filter any packets sourced from subnet 137.77.13.0, with the exception of host 137.77.13.7, from being allowed to pass through this particular router. We want all other packets sourced from 137.77.0.0 to be allowed through the router. This scenario can be accomplished with the following standard numbered access list: access-list 7 permit host 137.77.13.7 access-list 7 deny 137.77.13.0 0.0.0.255 access-list 7 permit 137.77.0.0 0.0.255.255 Note: All other packets are implicitly denied. The ip access-group command is used to apply the access list to an interface as follows:
interface ethernet 0 ip address 137.77.10.1 255.255.255.0 ip access-group 7 in Filtering IP Packets on Router Interfaces with Standard Named Access Lists The following commands accomplish the same thing with a standard named access list: IP access-list standard keepout permit host 137.77.13.7 deny 137.77.13.0 0.0.0.255 permit 137.77.0.0 0.0.255.255 interface e 0 ip address 137.77.10.1 255.255.255.0 ip access-group keepout in Filtering IP Packets on Router Interfaces with Extended Access Lists Suppose a router is connected to an "internal" Ethernet network and also has a link to the Internet via its serial 0 interface. The internal Ethernet network is the Class B network 131.108.0.0. You want to allow Internet Control Message Protocol (ICMP) messages in from the Internet to the Ethernet network for error-reporting purposes. You also want to allow TCP packets in from the Internet if they are destined to the Simple Mail Transport Protocol (SMTP) port of host 131.108.15.1 or if they are destined to ports greater that 1023 (this setup will allow TCP packets that are in response to connections generated from the internal network). This setup can be accomplished with the following extended access list: access-list 177 permit tcp 0.0.0.0 255.255.255.255 131.108.0.0 0.0.255.255 gt 1023 access-list 177 permit tcp 0.0.0.0 255.255.255.255 131.108.15.1 0.0.0.0 eq 25 access-list 177 permit icmp 0.0.0.0 255.255.255.255 131.108.0.0 0.0.255.255 interface s 0 ip address 207.200.115.6 255.255.255.252 ip access-group 177 in This access list could also be written as: access-list 177 permit tcp any 131.108.0.0 0.0.255.255 gt 1023 access-list 177 permit tcp any host 131.108.15.1 eq smtp access-list 177 permit icmp any 131.108.0.0 0.0.255.255 We could also accomplish the same thing with the following standard named access list:
ip access-list extended filter-in permit tcp any 131.108.0.0 0.0.255.255 gt 1023 permit tcp any host 131.108.15.1 eq smtp permit icmp any 131.108.0.0 0.0.255.255 interface s 0 ip address 207.200.115.6 255.255.255.252 ip access-group filter-in in Inbound Versus Outbound Access Lists The following topology will be used to describe the difference between inbound and outbound access lists. This comparison is specific to using access lists as packet filters on an interface.
If we want to protect Router_A, Router_B, and Router_D from devices in the cloud, we might want to deny Telnet packets from the cloud. An access list like the following would do the trick: Access-list 177 deny tcp any any eq telnet - this denies telnet packet from any source to any destination. The best router to apply this access list on would be Router_D, but should we apply it inbound on the serial interface or outbound on the Ethernet interfaces? If we apply it outbound on the Ethernet interfaces, if Router_D receives a Telnet packet destined for the Ethernet 1 port (187.187.1.1) of Router_A, Router_D will receive the packet and make a routing decision based on the destination address of the packet. The router decides the destination is out the Ethernet 1 interface. Ethernet 1 has an outbound access list, which denies the packet. The packet is discarded and an ICMP message is sent back to the source of the packet. In other words, in the case of an outbound access list, the access list gets checked after the router has made a routing decision.
In this scenario, if Router_D receives a Telnet packet destined for its own serial interface, it will recognize the packet as being destined for itself and accept the packet without checking the access list. However, if the access list is applied inbound on the serial interface of Router_D, a Telnet packet destined for Router_D will be dropped before Router_D has a chance to recognize it as being destined for itself. In other words, in the case of an inbound access list, the access list gets checked before the router makes any routing decisions about the packet. Note: Whether a standard access list is applied inbound or outbound, the router will always check the access list against the source of the packet. In the case of an extended access list, the router will always check the access list against the source, destination, and protocol of the packet. Controlling Content of Routing Updates Access lists can be used for controlling content of routing updates. The distribute-list command is used to apply the access list in this manner. Using Access Lists to Control the Content of Routing Updates Suppose we have two routers exchanging Routing Information Protocol (RIP) routing updates via their serial 0 interfaces. The serial network is on the 131.108.0.0 network. Router_A is learning about a private network 10.0.0.0 from a source off its Ethernet 0 interface. The network administrator does not want Router_B to learn about network 10.0.0.0. This setup can be accomplished by using the distribute-list command. The distribute list could be applied either outbound on Router_A, or inbound on Router_B. In either case the distribute list would utilize the same access list. Configuration on Router_A: router rip network 10.0.0.0 network 131.108.10.0 distribute list 7 out serial 0 access-list 7 deny 10.0.0.0 0.255.255.255 access-list 7 permit any Before Router_A sends a RIP update out serial 0, it will check to see what networks are permitted by the distribute list and include only those networks that are allowed by access list 7. Configuration on Router_B:
router rip network 131.108.0.0 distribute-list 7 in serial 0 access-list 7 deny 10.0.0.0 0.255.255.255 access-list 7 permit any Determining what Address Will Get Translated when Using Dynamic NAT Access lists are also used for Network Address Translation (NAT). They are used to determine what addresses will be translated. Using Access Lists to Determine Which Address Will Be Translated Suppose we have a router connected to private network 10.0.0.0 via its Ethernet 0 interface. It is also connected to the Internet via its serial 0 interface. The network administrator would like to configure NAT so that any user off subnet 10.10.10.0 will get translated to a legal address of 201.201.201.10 and be able to reach the Internet. The following configuration accomplishes this scenario: ip nat pool internet 201.201.201.10 201.201.201.10 netmask 255.255.255.0 ip nat inside source list 7 pool internet overload interface e 0 ip address 10.1.1.1 255.255.255.0 ip nat inside interface s 0 ip address 201.201.201.5 255.255.255.252 ip nat outside access-list 7 permit 10.10.10.0 0.0.0.255 With the above configuration, when the router receives a packet on Ethernet 0 destined for the Internet (out serial 0), it will check the source address of the packet against access list 7. If access list 7 allows the address, NAT will take place and the packet will be forwarded to the Internet.
And
RIP, EIGRP, OSPF with ACL
Tharaka Guruge, CISCO Certified lecturer Vocational Training Authority of Sri Lanka – Galle Branch
Local-area networks, or LANs, are really nothing more than a collection of computing devices connected together by some means in order to share or pool resources. The physical method, or medium, by which these devices are connected together is commonly referred to as the data link. The data link may be a fiber-optic cable, twistedpair wires, coaxial cable, or even radio waves and infrared light. Whatever the medium, all the devices share a common interface for accessing the data link to send communications to each other.
Like communications in the real word, just having the ability to speak and listen is not enough to carry on a conversation. For instance, if two people are speaking to each other and they both try to speak at the same time, one party must decide to stop speaking and start listening. In the real world, we refer to the rules that govern conversation as etiquette, but in data networking, this set of rules is referred to as the Media Access Control protocol, or MAC. Having a set of rules dictating who can speak when is a good start, but it is often not sufficient when complicated conversations are taking place. Take, for example, a crowded room where multiple conversations may be going on at the same time. The people in the room must know what parts of conversations are destined for them, even though they may be hearing all the other conversations going on. In the real world, we attempt to handle this situation by addressing intended receivers by their name, and they listen only for conversations prefixed with their name. In data communications, a similar method is used. As stated before, when devices are attached to a LAN they share a common method for accessing the data link. This method is accomplished via the network interface card, or
NIC. The NIC encapsulates the data a device wants to send to another device in what is called a frame. The NIC is often referred to as the interface of a device.
A frame is like an electronic envelope. Just as you would place a letter containing your data inside an envelope and address the outside with the recipient's name and your return address, the NIC encapsulates the data of the computing device with a destination and return address. Frame: Destination Address Source (Return) Address DATA
In the MAC protocol, the address refers to a unique number that is assigned to every NIC by its manufacturer. This number, known variously as the burned-in address (BIA), physical address, or most commonly the MAC address, is actually not an address at all. It gives no reference to where the NIC or machine is located. It is actually just a unique name that identifies the NIC from every other NIC in the world. Unfortunately, the term "address" has stuck with this concept and, throughout this module, this number will be referred to as the MAC address of the device. The figure below shows a typical MAC address, which is composed of 48 bits and is often represented in three, four hexadecimal digit groups: MAC Address: 0000.0c47.93c1 000 0 0 000 0 0 000 0 0 000 0 0. 000 0 0 110 0 c 010 0 4 011 1 7. 100 1 9 001 1 3 110 0 c 000 1 1
Now that the data is encapsulated in a frame with a destination and source address, the NIC can transmit the frame onto the data link. Just as you would listen for your name in a crowded room to know if someone was trying to speak to you, NICs listen to the data link for frames with a destination address that matches their own MAC address. When a frame is "heard" by a NIC with its own MAC address, the NIC knows to copy the frame
and send the data portion on to the computing device for processing. Since the frame was created with a return address, the receiver instantly knows the sender of the frame, and two-way communications can occur. Although somewhat oversimplified, this process describes basic data communications on a LAN. All devices are attached to the same medium, or data link, and when one device wishes to communicate with another, it encapsulates the data in a frame with a destination and source MAC address and transmits it.
Imagine now that you're back in that crowded room trying to have a conversation and the room is becoming more and more crowded. As additional conversations occur, it becomes difficult to talk to someone without being interrupted. At some point it becomes impossible to have a conversation because everyone is trying to talk over everyone else. The same situation occurs on LANs. As more devices than the medium can support are added, communications become inefficient. Additionally, as more devices become available in geographically dispersed areas, it becomes impossible to join them together on a single data link. In the overcrowded room, a possible solution is to have some of the people move into another room; a similar approach is used on LANs. When LANs become overcrowded, boundaries must be created between groups of devices. This scenario is accomplished via a piece of equipment known as a bridge. A bridge effectively takes a large LAN and breaks it down into smaller segments. It then learns the MAC address of all the devices on each of its attached segments. After learning the addresses, the bridge prevents frames destined between two devices on the same segment from traversing the data links on other segments. If a device wishes to speak to a device on a different segment, the bridge knows which segment to forward the frame to, and communications can occur. The overall effect of this filtering is a decreased use in bandwidth on each of the individual segments. It is important to note when bridging a frame that as the frame moves through the internetwork, its destination and source MAC addresses always stay the same. They do not take on the MAC address of the interfaces on the bridge.
Although effective at reducing the overall traffic on each of the new, smaller segments, bridges don't solve all the problems of overpopulated LANs. Because some frames do not have a destination of a specific device, but rather to all devices on the network, the bridge must forward these broadcast packets to all segments. As the number of devices on each segment begins to grow, this broadcast traffic can increase to the point where it starts to become a hindrance, similar to those that the bridge was designed to alleviate. Bridges also don't address the problems of connecting geographically dispersed LANs (called wide-area networks, or WANs) where expensive communication links need to be used in the most efficient manner. A different type of boundary is needed to handle problems such as broadcast traffic and the efficient joining of LANs and WANs; such a boundary allows networks to be grouped into larger networks, or internetworks. The device that makes internetworking possible is the router.
Unlike the data link that directly connects two or more devices together to form a network, a router connects two or more devices together on separate networks. The primary difference is that on the data link a physical path is the connection between the devices. On a router, the connection between devices is a logical path that may span many routers and data links. The job of the router is to keep track of which path to use
when transferring data from one network to another. The path that data follows between networks is known as the route. As data moves along the route passing through routers, each router it passes through is commonly referred to as a hop. In complex internetworks where multiple routes exist between data links, it is also the job of the router to determine which path is the most optimal. To determine which routes to use and which routes are the most optimal, routers use a set of rules called routing protocols and store the results in routing tables. When data travels between devices at the data link layer, MAC addresses are used to identify the sender and receiver. As mentioned previously, a MAC address is simply a unique name given to the NIC card and contains no reference to its relative location. Since the purpose of a router is to send data between different data links, or networks, a method is needed to identify which network a device is located on so that it does not have to travel every network in search of the receiver. Think of a piece of mail destined for you. The first thing the sender does when addressing the envelope is to write your name on it. Is this sufficient to get the letter to you? The postman would have to go to everyone in the world, and ask them if the letter had their name on it. A way is needed to narrow down the possible destinations. To do this, an address is added to the envelope describing where you are located. A street, city, state, and zip code aid in pinpointing your position to a precise location. These elements also make it easier for the post office to sort mail into groups of items destined for similar destinations. When the postman finally delivers the envelope to your house, does he care whose name is above the address? Usually not. There may be several people at the address with the same last name, but it is not the job of the postman to determine which person the envelope belongs to. He just leaves the envelope in the mailbox and lets the people living at that address decide whom the letter is for, based on the name on the envelope. Internetworking works on the same principles. Just as a frame is data encapsulated with a destination and source MAC addresses, a packet is data encapsulated with a destination and source network address. Routers use packets to move data between networks, and the network address helps the routers determine the general location of the recipient. Packet: Destination MAC Address Source MAC Address Destination Network Address Source Network Address DATA
When a router receives a packet, it makes a routing decision based on the network destination address portion of the packet. If the destination address is within a known network, the router forwards the packet to the next-hop router for that destination network. After the packet leaves the router, the next-hop router is responsible for
forwarding the packet to its final destination. The entire route is not known at the onset of the journey, just the next hop. If the router does not have the destination network in its routing table, it does one of two things: The router either forwards the packet to a predetermined default router, or it drops the packet and informs the sending device that the network is not reachable. It is important to note when routing a packet that as the packet moves through the internetwork, its destination and source network addresses always stay the same. But, since the packet is moving across several data links, the destination and source MAC addresses change with each data link. In the diagram below, assume the computer wants to converse with the server. Since communications are being carried out over multiple networks, the computer needs to encapsulate the data with a destination and source network address. Without this information, the routers would not know where to forward the packet. Since the packet also needs to be transmitted to the router over a data link, the computer encapsulates the packet in a frame with a destination and source MAC address. (Note: Because the router maintains an interface on the data link, it follows the same MAC protocol and MAC addressing standard as every other device on the shared medium.) As the packet moves from network to network, the frame information is stripped off the packet and replaced by new frame information with MAC addressing significant to the current data link. When the packet reaches the final router, the router knows that the destination network is directly attached and forwards the packet to the MAC address of the destination.
The previous section mentioned that when the computer has data it wants to send to a device on a different network, it sends its frames to the router and lets the router deliver them. How does the sending device know that the receiving device is on another network? To that extent, how does the sending device know what the address of the router is? The device knows that the recipient is on another network by doing a simple comparison between its network address and the network address of the recipient. If the two do not match, the sender knows the frame is destined for another network. How does it know what address the router is? When using network-level addressing, all devices on the data link need to be configured with what is called a default gateway
address. The default gateway address is the address of the router. The communication protocol then states: If the destination network doesn't match your own network, forward the frame to the default gateway for delivery. Remember the fundamental concept of routing: As the data moves through the network, the destination and source network addresses stay the same, while the data-link address changes with each different network. Like the mailman, routers in general are concerned only with the location of networks and not the individual devices residing on the network. The exception is when the router sees that the destination network is directly connected to it. When the mailman can match the address on the envelope to an address on his route, he needs to know how to leave the mail. Some addresses may have mail boxes, while some have mail slots. The mailman needs to know how every address on his route likes to receive mail. When a router needs to deliver a packet to its final network destination, the router acts as a station on the data link and transmits the data according to the proper MAC protocol. Routers use routing tables to store information about destinations in the internetwork. Some routing protocols maintain an entry for each possible path to a destination. Other protocols maintain only the most desirable path to each destination. Information that a routing table contains includes the destination address, interface, and the desirability of a path. An IP routing table consists of destination address/next-hop pairs. The next hop is the IP address of the router that the outbound packet is handed to. Routing table entries can be interpreted as meaning: To reach network A, send the packet out Node A via interface 0. Destination/Next-Hop Routing Table To Reach Network: 27 57 17 24 52 16 26 Send Packet to Node: Node A Node B Node C Node A Node A Node B Node C Via Interface: Interface E0 Interface E1 Interface E2 Interface E0 Interface E0 Interface E1 Interface E2
Routers communicate with one another (and maintain their routing tables) through the transmission of a variety of messages. The routing update message is one such message. Routing updates generally consist of all or a portion of a routing table. By analyzing routing updates from adjacent routers, a router can build a detailed picture of network topology.
A link-state advertisement is another example of a message sent between routers. Linkstate advertisements inform other routers of the state of the sender's links. Link information can also be used to build a complete picture of network topology. When the network topology is understood, routers can determine optimal routes to network destinations.
Locating computer systems on an internetwork is an essential component of any network system. Various addressing schemes are used for this purpose, depending on the protocol family being used. In other words, AppleTalk addressing is different from TCP/IP addressing, which in turn is different from Open System Interconnection (OSI) addressing, and so on. Unlike link-layer addresses, which usually exist within a flat address space, networklayer addresses are hierarchical. In other words, they are like mail addresses, which describe a person's location by providing a country, a state, a zip code, a city, and a street. Hierarchical addresses make address sorting and recall easier by eliminating large blocks of logically similar addresses through a series of comparison operations. For example, all other countries can be eliminated if an address specifies the country Ireland. Easy sorting and recall is one reason that routers use network-layer addresses as the basis for routing. Network-layer addresses differ, depending on the protocol family being used, but they typically use similar logical divisions to find computer systems on an internetwork. Some of these logical divisions are based on physical network characteristics (such as the data-link segment a device is located on); others are based on groupings that have no physical basis (for example, the AppleTalk zone). End systems require one networklayer address for each network-layer protocol they support (assuming that the device has only one physical network connection). Routers and other internetworking devices require one network-layer address per physical network connection for each networklayer protocol supported. For example, a router with three interfaces, each running AppleTalk, TCP/IP, and OSI, must have three network-layer addresses for each interface. The router, therefore, has nine network-layer addresses. One final concept in network addressing must be understood: the host address. We've learned that the data-link address is significant only to the local segment and that when the frame enters a router, the data-link addressing is stripped off and just the packet passes from router to router. So how does the router know which data-link address to send the packet to when it gets to the proper network? The answer to the question is that all devices on the network need their network address to be broken down into two parts, a network identifier and a host identifier. Conceptually, you may think of this like a street address. Most, if not all, street addresses are broken down into two parts, the actual name of the street and a number representing each house on the street. The mailman must know both of these pieces of
information about the street address in order to get the mail to its final destination address. The street name corresponds to the network identifier, and the house number corresponds to the host identifier. On a router, when the final network identifier address is reached, the router looks at the network, host identifier section of the address. Since the router is participating on the local data-link segment, it maintains a list of all the data-link addresses and corresponding network addresses on the segment. At this point, delivering the data is a simple matter of matching the incoming host identifier with an entry in the MAC address table of the router and encapsulating the packet with the proper data-link MAC address.
RFC 791 states: The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. This is done by passing the datagrams from one internet module to another until the destination is reached. The internet modules reside in hosts and gateways in the internet system. The datagrams are routed from one internet module to another through individual networks based on the interpretation of an internet address. Thus, one important mechanism of the internet protocol is the internet address..... A distinction is made between names, addresses, and routes. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The internet protocol deals primarily with addresses. IP addresses are globally unique, 32-bit numbers assigned by the Network Information Center (NIC). Globally unique addresses permit IP networks anywhere in the world to communicate with each other. For simplicity and clarity, these bits are normally represented as four sets of octets (8 bits per octet, or 1 byte). Each octet is then represented as a decimal number between 0 and 255 and separated by a period, or dot. This scenario is known as dotted-decimal notation. For example, a 32-bit IP address could be the following: 10101100000100000011001000001010 To represent this address in standard format, we break the address down into 4 octets (8-bit segments): 10101100 00010000 00110010 00001010
and convert each of the octets into a decimal number:
172
16
50
10
The address is then written as 172.16.50.10 and spoken as""172 dot 16 dot 50 dot 10." Remember that the dotted decimal notation is just a convention used to make working with 32-bit IP addresses easier. As far as devices on the network are concerned, they are dealing with a single 32-bit binary number. As mentioned in the Network Addressing section, network addresses are broken down into two parts, a network identifier and a host identifier. In IP, the portion of the overall IP address allocated to the network and host identifiers varies, making IP very flexible in the number of networks and hosts it can accommodate. In IP, the network identifier is commonly referred to as the network prefix, and the host identifier as the host portion. These terms are used for the remainder of this module. For example: Here, more of the bits are allocated to the network prefix: Network Prefix: 101011000001000000110010 Host Portion: 00001010
This setup allows for more networks. In the next example, more of the address is allocated to the host portion: Network Prefix: 101011000001 Host Portion: 00000011001000001010
so more possible host combinations are available. Classful Addressing In general, there are basically three types of networks: large, medium, and small. They can be described as follows:
Large networks have a tremendous number of hosts (in the millions) per network. There are very few large networks. Medium networks fall in the range between large and small networks. Small networks have a small number of hosts per network. A large number of networks fall into the small category.
To accommodate different size networks and aid in classifying them, IP addresses are divided into categories called classes. Each of the IP classes is designed to accommodate a different size network. As stated in RFC 791:
To provide for flexibility in assigning address to networks and allow for the large number of small to intermediate sized networks, the interpretation of the address field is coded to specify a small number of networks with a large number of host[sic], a moderate number of networks with a moderate number of hosts, and a large number of networks with a small number of hosts. This scenario is known as classful addressing, and it follows a few basic rules:
Each class uses subsequently fewer of the bits in the address as the host portion and subsequently more of the bits as the network prefix. The boundary between the network and host identification sections is fixed in each class. Each class uses the most significant bits of the address to identify where the boundary is.
The following table describes how classful addressing works:
When viewed in context of the dotted-decimal notation, this translates to: Class A Class Identifier First octet in the range 1–126* Network Prefix First octet N.H.H.H or 1.xxx.xxx.xxx to 126.xxx.xxx.xxx First two octets N.N.H.H or 128.0.xxx.xxx to 191.255.xxx.xxx First three octets N.N.N.H or 192.0.0.xxx to 223.255.255.xxx Host Portion Remaining three octets N.H.H.H or xxx.0.0.0 to xxx.255.255.255 Remaining two octets N.N.H.H or xxx.xxx.0.0 to xxx.xxx.255.255 Remaining octet N.N.N.H or xxx.xxx.xxx.0 to xxx.xxx.xxx.255
B
First octet in the range 128–191
C
First octet in the range 192– 223**
*Note that addresses starting with 0 and 127 are reserved. ** Addresses allocated in the range beyond 223 (224–254) will be discussed later:
Class D addresses are reserved for multicast groups. In Class D addresses, the four highest-order bits are set to 1110 (224–239). Class E addresses are also defined by IP but are reserved for future use. In Class E addresses, the four highest-order bits are all set to 1 (240–254).
To provide further functionality, some IP addresses are reserved for special purposes. First is the address 0.0.0.0. The all-zeros address is reserved as the default network, which is used in routers as a way to identify where to send a packet when there is no match for it in a routing table. Next is the network 127.0.0.0. This address is known as the internal loopback network. Routers or other devices can use this address to send packets to themselves. Any address with all the host bits set to zero is used to represent the address of the network itself. This concept can be a bit confusing. A good way to think of it is a street address that contains only the name of the street. Generally, devices should not use host address where all the host bits are set to zero, because it can confuse routing protocols (see the IP Subnet Zero section for more information on this subject). Finally, addresses with all the host bits set to 1 are known as broadcast addresses. Every device on the network will receive packets addressed to the broadcast address. So, typical classful IP addresses look like the following: Class A host address: 124.32.90.10 Class B network address: 172.68.0.0 Class C broadcast address: 212.200.50.255 All networks broadcast address: 255.255.255.255 Default route: 0.0.0.0 Given the above parameters, this system allows for the following combinations of valid Internet network and host addresses: Class Possible Networks Possible Hosts Total Possible Host Addresses Percent of Total Available Address 50%
A
126
16,777,214
2,113,928,964
B
16,384
65,534
1,073,709,056
25%
C
2,097,152
254
532,676,608
12.5%
(To determine the number of possible networks or hosts, use the formula 2n – 2, where n is the number of bits in the network or host space. The subtraction of 2 is for the actual network and broadcast address. Note that the table above is meant to show only the available host addresses in a given network. It is possible that these numbers may be slightly larger with the use of the ip subnet-zero command covered later in this section, but these numbers are generally correct. As noted, the numbers above also exclude the broadcast address of each network, since these may not be assigned to a host.) Several networks are reserved for private use and cannot be used on the Internet. They include: Class A B Address Range 10.x.x.x 172.16.x.x through 172.31.x.x 192.168.x.x
C
These addresses are commonly used for corporate intranets and for testing. When the Internet Protocol was first proposed in the early 1980s, classful addressing, in theory, seemed to provide a limitless amount of address space. In practice, it became quickly apparent that there were limitations. The major drawback to the system is that, although easy to understand and implement, the boundaries set by the Class A, B, and C addresses do not foster efficient use of the available addresses.
From the table above, you can see that the Class A address space uses a full 50 percent of the available address space, but it allows for only 126 separate networks. Since there are actually very few organizations assigned Class A addresses, a large portion of the total address space goes unused. The Class C address, with only 254 possible hosts, is often too small, causing an organization to move to a Class B address. But the Class B, with ~65,000 hosts, is often too large, causing tens of thousands of addresses to go unused. Remember, each link must be uniquely identified, so if an organization has two separate data-link segments with 300 stations on each, it will need two Class B addresses and will effectively use 130,000 addresses for 300 stations! In response to this problem, organizations use multiple Class C addresses instead of using a single Class B address. But this has the negative impact of
increasing the size of the global Internet routing table because more networks need to be tracked. Because every data link needs to be uniquely identified, there just are not enough network addresses to go around. The rapid growth of corporate intranets, when compounded with the explosion of the Internet, has created a demand for network addresses that the original classful addressing scheme could not meet.
In order to address these problems, a modification to the system is needed that allows the addresses to be used more efficiently. In 1985, RFC 950 was written to standardize a procedure for dividing Class A, B, and C networks into smaller, more manageable sections. This procedure is known as subnetting.
The classful address scheme creates a two-level hierarchy in the Internet: a top level representing the Internet as a whole, and a level below representing the individual networks. For the reasons stated above, what is really needed is a three-level hierarchy that allows for networks to be divided into smaller segments, or subnets. To accomplish this, the host portion of the address is broken down into two sections, a subnet number and the remaining host portion: Two-Level Classful Hierarchy:
Network Prefix
Host Portion
Three-Level Subnet Hierarchy:
Network Prefix
Subnet Number
Host Portion
The subnet number now identifies a local segment attached to the router. Because only the network portion of the address is advertised to the Internet, subnetworks are only locally significant. Here's how subnetting works: Suppose you have been assigned the network address of 128.60.0.0. Converting this from dotted-decimal notation into binary, you get: Network Prefix 128 60 0 Host Portion 0
1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 If you take the first four bits of the host portion and use them to identify subnets, you get the following possible binary combinations: Network Prefix Subnet Host Portion
1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 Converting these addresses back to dotted-decimal notation, you get: Network Subnet/Host Prefix Portion 128 60 128 60 128 60 128 60 128 60 128 60 128 60 0 16 32 48 64 80 96 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
128 60 112 128 60 128 128 60 144 128 60 160 128 60 176 128 60 192 128 60 208 128 60 224 128 60 240
Now in addition to having the major network of 128.60.0.0, you also have up to 16 subnetworks: 128.60.0.0, 128.60.16.0, 128.60.32.0,...128.60.240.0. Each of these subnetwork addresses can be used to define a data-link segment, with the remaining 12 bits of each subnet being used to identify specific hosts on those segments. Note, however, that the subnet 128.60.0.0, which is the same network as the major network, is only available as a subnet if you are using the ip subnet-zero command. The zero subnet will be further explained later in this section. Because the network prefix is the only portion of the address that is significant to the Internet, the subnets are not visible outside of the private network of the local organization. The route from the Internet to any subnet of a given IP address is the same, no matter which subnet the destination host is on. It is the job of the local routers to determine which subnet a particular host is on. This setup reduces the complexity of the Internet routing table because only a single network address is needed to reach an organization, and also prevents the depletion of available network addresses because each data link does not need to take up a full IP network. If we look at the 128.60.16.x subnet and start assigning hosts, we can create addresses 128.60.16.0 through 128.60.31.255: Network Prefix 128 128 128 128 128 ... 128 128 128 128 128 60 60 60 60 60 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 0 0 1 1 1 0 1 0 1 60 60 60 60 60 Subnet Host Portion
0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0
Anything beyond 128.60.31.255 is on the next subnet. The 128.60.32.0 to 128.60.47.255 subnet follows: Network Prefix 128 128 128 60 60 60 Subnet Host Portion
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0
128 128 ... 128 128 128 128 128 60 60 60 60 60 0 0 0 0 0
60 60
0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0
0 0 0 0 0
1 1 1 1 1
0 0 0 0 0
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
0 1 1 1 1
1 0 0 1 1
1 0 1 0 1
The bits that are used for the network number and subnet number are commonly referred to together as the extended network prefix.
A device needs a way to tell what subnet it is located on. As you learned in the addressing section, a device learns the class of its address from the most significant bits of the address (for example, if the first 2 bits are "10," the device knows that the first 16 bits of the address indicate its network and the last 16 bits indicate its host address). With subnetting, a way is needed to tell the device to look beyond its class to determine its subnet. This is done via a subnet mask. A subnet mask is a 32-bit binary number that corresponds bit for bit to the IP address of the device. The bits of the subnet mask are set to 1 if the system examining the address should treat the corresponding bit in the IP address as part of the extended network prefix. The bits in the mask are set to 0 if the system should treat the bit as part of the host number. Only extended network prefixes using contiguous bits that are flush left against the network field are supported. For example, a subnet mask for the example above would read: 11111111111111111111000000000000 There are sixteen 1s for the network address portion and four 1s for the subnet. The dotted-decimal notation is again used as a way to simplify reading subnet masks. The mask above would be read as 255.255.240.0. 11111111 11111111 11110000 00000000 255 255. 240. 0
Another way to represent the mask above is to annotate the number of bits in the subnet mask. The mask above could also be referred to as 20 bits of masking, or /20 following the address: 128.60.16.40 /20.
When present, routing protocols carry the full 32-bit subnet mask and not just a one-byte field in their header that contains the number of bits in the extended-network prefix. When a device is configured with an IP address, it now needs two pieces of information in order to calculate what its host address is and what its subnet and network are: the actual address and the mask. The device calculates what subnet it is on by doing a logical "AND" between its address and the mask. Performing an "AND" operation means that anytime you "AND" a 0 value to another 0 or a 1 value, the result is 0. Only a 1 ANDed with another 1 value will result in a 1 value. Here's how it works: 0 AND 0 IS 0 0 AND 1 IS 0 1 AND 1 IS 1 Some examples follow: Example 1: Class B Let's use a Class B address to illustrate how subnetting works. Let's say you were assigned the Class B address 172.16 from the Network Information Center (NIC). First determine how many subnets you need, and how many nodes per subnet you need to define. A typical (and easy-to-use) Class B subnet mask would be 8 bits. Since the third octet is the first "free" octet for Class B, you will start there. So, an 8-bit subnet mask would be 255.255.255.0. This means you have 254* subnets available and 254 addresses for nodes per subnet. *Why are there only 254 subnets available instead of 256 (0–255)? You should not use subnet 0 or a subnet of all 1s. With an all 1s subnet mask, this is also your broadcast address. You can configure this subnet, but it is neither proper nor recommended to make your subnet the same as your broadcast address. Subnet 0 is also not recommended. Cisco allows the use of subnet 0 with the ip subnet-zero command. Example 2: Class B Let's say you have just assigned an interface the address 172.16.10.50 with a mask of 255.255.255.0. What subnet is it in? First represent the bits in binary (for Class B, you start with the third octet since octets 1 and 2 are fixed). SUBNET HOST 00001010 00110010 (address representation - 10.50) 11111111 00000000 (subnet mask representation - 255.0) ----------------00001010 00000000 (results of logical "AND" - subnet 10)
This address is in subnet 10 (172.16.10.0). Valid addresses for subnet 10 would be 172.16.10.1 through 172.16.10.254. Address 172.16.10.255 is the broadcast address for this subnet. According to the standard, any host ID consisting of all 1s is reserved for broadcast. Example 3: Class B Let's say you have a need for more subnets than 254. (Remember, this is the maximum number of subnets in a single octet.) Sticking with our Class B address, let's configure an 11-bit subnet. This means we will use all 8 bits from our third octet and the first three bits from the fourth octet. The subnet mask is now 255.255.255.224 (128 + 64 + 32 = 224). Now you need to find out what subnet the following address is in: 172.16.10.170 255.255.255.224. First, denote the address in binary representation (just octets 3 and 4 for a Class B address) like this: 00001010 10101010 (address representation 10.170) 11111111 11100000 (subnet mask representation 255.224-first 11 bits subnet) ----------------00001010 10100000 (results of logical "AND") 10 160 So, the address here is in subnet 172.16.10.160. The valid addresses for this subnet are 172.16.10.161 through 172.16.10.190 (.191 is the broadcast address). As soon as you hit 10.192, the bits in the subnet change and you move into subnet 10.192. Example 4: Class B Consider an example where the mask is shorter than one octet. Now we want only a few subnets, but need many hosts per subnet. We'll use a 3-bit subnet mask. Now we have: 172.16.65.170 255.255.224.0 (the mask is now the first 3 bits of the third octet). What subnet is this address in? 01000001 10101010 (address representation 65.170) 11100000 00000000 (subnet mask representation 224.0) ----------------01000000 00000000 (results of logical "AND" - subnet 64) 64 So the subnet here is 172.16.64.0. The range of addresses that would fall into subnet 64 would be 172.16.64.1–172.16.95.254, with 172.16.95.255 as the broadcast address. The next subnet would be 172.16.96.0. Class A and Class C map out exactly as Class B. The only differences are the octet at which subnetting starts and how many octets you can use for subnetting.
Example 5: Class C Suppose the NIC assigned the address 192.1.10. You will need to use the fourth octet for your subnetting needs. Let's use a 4-bit subnet mask and map out the following address: 192.1.10.200 255.255.255.240: 11001000 (address representation for 200) 11110000 (subnet mask representation for 240) -------11000000 (results of logical "AND" - 128+64=192) So, address 192.1.10.200 is in subnet 192. The valid range of addresses in this subnet would be 192.1.10.192 through 192.1.10.206, with .207 as the broadcast address. The next subnet would be .208. Keeping the same subnet mask, you can choose different addresses to be in different subnets. For instance, address 192.1.10.17 255.255.255.240 is in subnet 16 and, therefore, has another unique subnet address, with valid addresses in the range of 192.1.10.17 through 192.1.10.30. If you want no subnetting, use these default masks (255 — strictly follow number, 0 — wildcard): Class A: 255.0.0.0 Class B: 255.255.0.0 Class C: 255.255.255.0 How does a router using a routing protocol that does not transmit masking information know what mask to use when it learns a new route? If the router has a subnet of the same network number assigned to a local interface, it assumes that the learned subnetwork was defined using the same mask as the locally configured interface. If the router does not have a subnet of the learned network number assigned to a local interface, the router has to assume that the network is not subnetted and applies the natural classful mask of the route. Subnet Design Considerations Below is a handy chart that can help you determine how much subnetting to use: Host/Subnet Quantities Table Class B # bits ------2 3 Mask --------------255.255.192.0 255.255.224.0 Effective Subnets --------2 6 Effective Hosts --------16382 8190
4 5 6 7 8 9 10 11 12 13 14 Class C # bits ------2 3 4 5 6
255.255.240.0 255.255.248.0 255.255.252.0 255.255.254.0 255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
14 30 62 126 254 510 1022 2046 4094 8190 16382 Effective Subnets --------2 6 14 30 62
4094 2046 1022 510 254 126 62 30 14 6 2 Effective Hosts --------62 30 14 6 2
Mask --------------255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
*Subnet all zeroes and all ones excluded. *Host all zeroes and all ones excluded.
Recall that you should not use a subnet address in which all the subnet bits are set to zero. The reason is that some routing protocols do not transmit the subnet mask being used on a network in their routing updates. The protocols Routing Information Protocol (RIP) Version 1 and Interior Gateway Routing Protocol (IGRP) are two such protocols. RIP Version 2, however, does transmit the subnet mask. When no masking information is available, the routing protocol assumes that the address is configured for traditional classful addressing and sometimes cannot tell the subnet address from the network address. For example: 128.60.0.0/16 10000000.00111100.|00000000.00000000 128.60.0.0/24 10000000.00111100.|00000000.|00000000 In this example, if a data-link segment has been assigned the subnet of 128.60.0, the router may not be able to tell the difference between that subnet and the entire 128.60 network. It is important to remember that the dotted-decimal format is just a representation of the 32-bit address and mask. An address on subnet 0 can sometimes be hard to determine because of this. For example:
192.10.20.50/24 11000000.00001010.00010100.|00110010 192.10.20.50/26 11000000.00001010.00010100.|00|110010 In the first example, 192.10.20.50 is on the 192.10.20 network, a setup that is fine. But in the second example, 192.10.20.50 is on the 192.10.20.0 subnet, a setup that could be a problem. Configuring addresses in the subnet zero range is generally not recommended because of the confusion inherent in having a network and subnet with indistinguishable addresses, as in Example 1 above. If you truly need to use subnet zero, you can add the ip subnet-zero command in the router configuration. This setup allows users to configure addresses in the subnet zero subnet.
Route summarization procedures condense routing information. Without summarization, each router in a network must retain a route to every subnet in the network. With summarization, routers can reduce some sets of routes to a single advertisement, reducing both the load on the router and the perceived complexity of the network. The importance of route summarization increases with network size. The diagram below illustrates an example of route summarization. In this environment, Router R2 maintains one route for all destination networks beginning with B, and Router R4 maintains one route for all destination networks beginning with A. This setup is the essence of route summarization. Router R1 tracks all routes because it exists on the boundary between A and B.
Route Summarization Example
The preceding example shows the simplest type of route summarization: collapsing all the subnet routes into a single network route. Some routing protocols also support route summarization at any bit boundary (rather than just at major network number boundaries) in a network address. A routing protocol can summarize on a bit boundary only if it supports variable-length subnet masks. Some routing protocols summarize automatically. Other routing protocols require manual configuration to support route summarization.
Traditionally, all subnets of the same network number use the same subnet mask. In other words, a network manager chooses an 8-bit mask for all subnets in the network. This strategy is easy to manage for both network administrators and routing protocols. However, this practice wastes address space in some networks. Some subnets have many hosts and others have only a few, but each consumes an entire subnet number equal to the needs of the largest subnet. Serial lines are the most extreme example,
because each has only two hosts that can be connected via a serial-line subnet. Consider the following network:
Suppose you have been assigned a Class C address of 192.168.100.0 and need to subnet the address to accommodate this network. With traditional subnetting techniques, you would not be able to accomplish this task. You would need to allocate at least 100 host addresses for the Token Ring segment requiring 7 bits for host address, so you would have only 1 bit for subnetting and would be able to create only two subnets (192.168.100.0 and 192.168.100.128). As IP subnets have grown, administrators have looked for ways to use their address space more efficiently. One of the techniques that has resulted is called variable-length subnet mask (VLSM). With VLSM, a network administrator can use a long mask on networks with few hosts and a short mask on subnets with many hosts. In order to use VLSM, a network administrator must use a routing protocol that supports it. Cisco routers support VLSM with Open Shortest Path First (OSPF), Integrated Intermediate System-to-Intermediate System (Integrated IS-IS), Enhanced IGRP (EIGRP), RIP Version 2, and static routing. In the example above, a solution can be obtained by using VLSM in the following manner: 1. For the Token Ring segment, we know we need at least 100 host addresses, so using the standard formula 2^n >100, we know that 7 bits must be used for the host portion on this segment, leaving 1 bit for the subnet address. Using 1 bit of subnetting allows for the creation of two subnets, 192.168.100.0 and 192.168.100.128. For the Token Ring segment, we can assign the hosts 192.168.100.1 through 192.168.100.126. This leaves us with 192.168.100.128 and above.
Network Address 192 192 168 168 100 100
Subnet / Host 0 x x x x x x x 1 x x x x x x x
2. Taking the next highest density of hosts, 25 on each Ethernet segment, we know that we need 2^n > 25 or 5 bits for host addresses, leaving 3 bits for subnetting. Using 3 bits of subnetting on the 192.168.100.x network gives us the 192.168.100.128, 192.168.100.160, 192.168.100.192, and 192.168.100.224 subnets. Since we need to assign host addresses only in the first two subnets, we still have everything above 192.168.100.192 to work with.
Network Address
Subnet/Sub-Subnet / Host
192 168 100 1 0 0 x x x x x 192 168 100 1 1 0 x x x x x 192 168 100 1 1 1 x x x x x 3. The next highest number of hosts is the 10 on the Fiber Distributed Data Interface (FDDI) ring. For 10 hosts, we need 2^n > 10, or 4 bits for host address, leaving 4 bits for subnetting. Applying 4 bits of subnetting to 192.168.100.x, we get the 192.168.100.192, 192.168.100.208, 192.168.100.224, and 192.168.100.240 subnets. Since we need only ten host addresses, we still have everything above 192.168.100.208 to deal with.
Network Address
Subnet / SubSubnet/Host
192 168 100 1 1 1 0 x x x x 192 168 100 1 1 1 1 x x x x 4. The remaining segment, a serial link, needs only two host addresses, so it needs only 2 bits for host addresses (2^n > 2), leaving 6 bits for the subnet portion. Applying these bits, we get subnets 192.168.100.208 through subnet 192.168.100.252. We can use the first subnet for the serial link since it gives us two host addresses, 192.168.100.209 and 192.168.100.210. The remaining subnets are reserved for future use.
Network Address
Subnet /Sub-Subnet/ Host
192 168 100 1 1 1 1 0 0 x x
192 168 100 1 1 1 1 1 0 x x 192 168 100 1 1 1 1 1 1 x x
After using VLSM, an address assignment for the network might be the following:
From the steps in the example, you should be able to see a pattern when using VLSM. By filling in the available bits in the subnet/host section from right to left, you can create progressively smaller subnets within the overall network segment. Conversely, the same pattern will work for host addresses if you need to add more hosts to a subnet. By filling in the bits from left to right and paring down the amount of subnet bits, you can create a larger pool of host addresses. Remember, to take advantage of VLSM, you must be using a routing protocol that supports it, such as EIGRP or OSPF.
VLSM provides the ability to aggregate routes in order to reduce the overall size of, and simplify, the routing table. Like route summarization, route aggregation is the process that combines multiple subnets into a single routing update. In the following example,
route aggregation is used to simplify the routing tables:
In this example, the subnets of 172.68.70 are aggregated to a 24-bit mask when advertised. Similarly, the subnets of 172.68.60 are also aggregated to a 24-bit mask. The result is that only one entry is needed in each router to get to various subnets. To effectively utilize route aggregation, the IP addressing scheme must be topologically significant. Subnets must be assigned in a manner so that they are contiguous to one another. Supernetting Supernetting is the opposite of subnetting. Subnetting is the process of taking a network and dividing it into smaller subnetworks. Supernetting is the process of taking several discrete networks and advertising them in one routing update; for example, if an organization had been assigned a full block of Class C addresses, say 192.10.1.0 /24 to 192.10.254.0 /24. Instead of advertising 254 separate networks to the Internet, the organization may advertise only the single route to 192.10.0.0 /16 to the Internet. Full connectivity is possible because any datagram destined for a 192.10.x network is bound for the same organization. When the packet gets to the organization, it is the responsibility of the routers of the organizations to get the datagram to the proper network.
Supernetting is a component of an overall concept known as classless interdomain routing, described in the next section. In order to use supernetting techniques on Cisco IOS® routers, you must use the global configuration command ip classless.
A network is referred to as discontiguous if it has been subnetted but the subnets are not physically accessible to each other via a router. In the example below, note that the 172.70 network is configured with a 24-bit mask and two subnets have been created, 172.70.10.x and 172.70.20.x. But also notice that to get to one subnetwork from the other, you must cross a different network, 172.68.
Discontiguous networks may cause problems when route summarization is taking place. Because the routers in the example are attached by the 172.68 network, they will summarize the 172.70 network in their routing updates to each other. When the routing update is received, each router will see that it has both a connected route to the 172.70 network and a more specific route to the 172.70 network via its subnet. For some routing protocols, such as RIP V.1 and IGRP, this scenario will cause routing problems.
In RIP V.1, for example, the router will disregard an update for a summarized route if it has a directly connected route to the same network.
Classless interdomain routing, or CIDR, is based on "route aggregation," the process of creating a single piece of routing information that specifies how to handle traffic for many destinations. In some ways, the result of this process is similar to that of IP subnetting. With subnetting, what appears to the outside world as a single IP network is actually broken up into numerous smaller subnets, each of which typically corresponds to a serial link or a LAN segment. With CIDR, several IP networks are combined, from the point of view of networks outside the group, into a single, larger entity. Under CIDR, any entry in the routing table of a router describes the path to a class of IP destinations whose addresses share a given initial bit string. Such an entry is called a "prefix route;" the shared initial bit string is a prefix of the address of every destination that the route covers. An ordinary IP network route is a prefix route; a route to the Class C network 198.92.35.0 includes all IP addresses whose first three bytes are 198, 92, and 35. CIDR is different in that prefixes can be of any length; it would be valid for a route to include, for example, all IP addresses that started with 198 and 92, even though that route would cover 256 entire Class C networks. Consider the following scenario: Company X buys its Internet connection from Network Service Provider A. Internally, Company X uses two Class C networks, each of which is divided into four subnets, with the network mask 255.255.255.192 assigned to each network. Under CIDR, Company X receives its addresses from Provider A instead of getting them directly from the central addressing authority. Provider A has a block of Class C networks assigned to it by the central authority. For example, suppose Provider A has been assigned networks 207.42.0.0 through 207.42.255.0. Provider A assigns Company X two network numbers from this bloc—say 207.42.12.0 and 207.42.13.0. One of the side benefits of CIDR is that it makes it easy to use Class C network numbers in this way. There was a time when Company X would have been assigned a Class B network address. In that situation, most of the IP addresses assigned to Company X would have gone unused. Because Class B address space is in danger of exhaustion, Class C network numbers are now being assigned in blocks, and CIDR makes it possible to support this approach easily. Under the original IP model, routers belonging to the major backbone networks and to many other service providers would have to keep track of individual routes for both of Company X's network numbers and for networks belonging to any of Provider A's other subscribers. Under CIDR, those routers instead maintain knowledge of a route to Provider A's entire network number range; they know that all addresses of the form
207.42.x.y belong to Provider A's subscribers, and that datagrams for those addresses should be sent to Provider A. Under the old scheme, routers that lie outside Provider A's network might have had to keep as many as 254 routing table entries for 207.42.x.0 networks. With CIDR, one routing table entry is enough. CIDR operates much the same way as IP subnetting—by assigning a bit mask to each routing table entry. This mask is really a way of specifying the length of the prefix associated with each routing table entry. Bits that are set to 1 in the mask are considered to lie within the prefix, while bits that are set to 0 lie outside the prefix and are not important for destination matching. A mask of 255.0.0.0, for instance, means that the prefix length is 8 bits. Any IP address whose first byte is the same as that of the address specified by the routing table entry is matched. For instance, a route to 145.0.0.0 with a mask of 255.0.0.0 would match a packet addressed to 145.13.1.2. A route to 145.12.0.0 with a mask of 255.255.0.0 would not match that packet because the second octet in the destination address of the packet (13) lies within the prefix of the route and doesn't match the second octet in the destination of the route (12). With subnetting, the mask always covers the IP network field of the address (and need not strictly specify a prefix, although Cisco strongly recommends against the use of such discontiguous masks, even for subnetting). Therefore, all the network-field bits are always significant in deciding whether or not a particular routing table entry matches a given destination address. With CIDR, the mask may exclude some parts of the IP network field from the routing decision. Routers don't use ordinary IP addressing classes to choose which parts of the address are significant for the routing decision; only the mask associated with the routing entry is important. For our example, routers outside of Provider A's network would have a routing entry for 207.42.0.0, with a mask of 255.255.0.0. That entry would send traffic for all of Provider A's subsidiary networks to Provider A via some common path. Provider A itself would, of course, need to maintain an individual routing entry for each of the subnets to which it had assigned addresses. These subnets would be reachable through different border routers. However, if two of the subnets were reachable by the same path, Provider A could choose to use a single route for both of them. Suppose, for example, that Company X had only one border router, which Provider A used to reach both networks 207.42.12.0 and 207.42.13.0. Each of Provider A's routers could then maintain a single routing entry for 207.14.12.0 with mask 255.255.254.0. Because the least-significant bit of the third byte wouldn't be significant for deciding whether this route was applicable, it would direct traffic for both 207.42.12.0 and 207.42.13.0 to Company X's border router. Now, suppose that Company X were to change network providers and start using Provider B. It would no longer be appropriate for all of Company X's traffic to be sent to Provider A. From the point of view of routing efficiency, the best way for Company X to
respond would be to change all its IP addresses—an arduous task. Company X might be slow to make the change, if indeed it can change the addresses at all. A better solution is for routers to create and propagate throughout the Internet what's known as an "exception route," so that all traffic for 207.42.0.0 would be sent to Provider A, with the exception of traffic for 207.42.12.0 and 207.42.13.0, which would be sent to Provider B. The CIDR approach implements such exceptional routes by using a longest-prefix rule. If a destination of a packet matches two routing table entries, the router uses the entry with the longest matching prefix. That entry is more specific than the one with the shorter prefix and presumably represents an exception route. For an IP route, having a longer matching prefix is equivalent to having more bits in its mask set to 1. To avoid ambiguity, discontiguous subnet masks (masks with zero bits between the one bits) aren't used in CIDR. Routing Protocols for CIDR To make CIDR useful in the Internet, service providers must be able to exchange prefix routing information. The Border Gateway Protocol (BGP) routing protocol used between most service providers has been enhanced in Version 4 to support prefix routes. The major change to the protocol consists of explicitly passing bit masks in routing updates instead of having the routers infer prefix lengths from IP address classes. In addition, the interior routing protocol used with CIDR must support classless addresses. Cisco supports this capability, too, with the routing protocols EIGRP, OSPF, and IS-IS.
On some media (such as IEEE 802 LANs), media addresses and IP addresses are dynamically discovered through the use of an additional member of the Internet Protocol suite: the Address Resolution Protocol (ARP). ARP uses broadcast messages to determine the hardware Media Access Control (MAC)-layer address corresponding to a particular internetwork address. ARP is sufficiently generic to allow use of IP with virtually any type of underlying media-access mechanism.
The ARP process works in the following manner:
A default route is a routing table entry that is used to direct frames for which a next hop is not explicitly listed in the routing table. Using a default route allows the router to be aware only of the destinations internal to its own administrative systems. This setup can be beneficial in large networks, where topology changes occur often. In smaller networks, default routes can also be useful because of decreased memory and processor utilization. However, with smaller networks, the benefits of default routes decrease as the number of routes decreases. Several types of routes fall into this category: Gateway of Last Resort A gateway of last resort is a destination network that a router should send packets to if it does not have a specific entry to the destination network in its routing table. The gateway address can either be configured directly on the router or it can be learned from another router. To designate a route as the gateway of last resort in Cisco IOS® software, use the ip default-network command. Often there is confusion between the ip default-network command and the ip defaultgateway command. The ip default-gateway command is used when the router does not have IP routing configured. Its purpose is to tell the router the address of the next hop to which to send packets that are not for a locally connected network. The ip default-network command tells the router which network to send a packet to if it does not have a more specific entry in the routing table. The ip default-gateway command has no effect on IP routing if IP routing is turned on.
Note that when using the ip default-network command the router needs to know how to get to the specified default network, through either the routing table or a static route. Also note that default networks do not apply for routes to subnets of a local connected major network. Static Routes A static route is a route that you manually configure into a routing table. With a static route you can specify that packets destined for a specific network, subnet, or host should be forwarded to a desired network or interface. You can also assign administrative distances to static routes. To configure a static route, use the ip route destination mask next-hop/interface distance command. When using static routes, be sure to understand that the router will forward packets to the next hop even if the final destination is no longer valid. This scenario can cause undesirable results. By default, static routes are not advertised to other routers. If you want a static route to be advertised, use the redistribute static command. Static routes by default have a distance of 1, so the router will always choose the static route over one learned dynamically unless configured to do otherwise. Floating Static Routes A floating static route is a static route that is configured with an administrative distance greater than that of the same route learned dynamically. A floating static route will cause the router to use the dynamic route until it is lost, and then switch to the static route. This setup is useful when using dialup connections as a backup to a primary route. Since dynamic routing protocols broadcast periodic updates, they are not desirable on a dial link where they will cause the link to go up, even though no user data needs to cross the link. Using a static route to the link will keep the line from going up with routing updates, but will still let the router know where to send packets in case the primary path fails. The Null Interface As mentioned in the static route section, you can configure a route to go to a specific interface. One of the interfaces you can select is the virtual null0 interface. This is not a physical interface. Directing packets to the null0 interface will prevent the router from sending an Internet Control Message Protocol (ICMP) network unreachable message when it receives a
packet with an unknown destination. A situation in which you might want to use the null0 interface is when you have configured a default network, but want packets destined for a particular network to be dropped. If a static route is configured for the network to the null0 interface, the packets will be dropped without the ICMP message or without having to configure an access list.
Routing involves two basic activities: determination of the best routing paths, called path determination, and the transport of packets through an internetwork, referred to as path switching. Routed Versus Routing Protocols The terms routed protocol and routing protocol often cause confusion. Routed protocols are routed through an internetwork; examples include the Internet Protocol (IP), DECnet, AppleTalk, NetWare, Open System Interconnection (OSI), Banyan VINES, and Xerox Network Systems (XNS). Routing protocols implement routing algorithms; they route routed protocols through an internetwork. Examples include Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP), Open Shortest Path First (OSPF), Exterior Gateway Protocol (EGP), Border Gateway Protocol (BGP), OSI Routing, Advanced Peer-to-Peer Networking (APPN), Intermediate System-to-Intermediate System (IS-IS), and Routing Information Protocol (RIP). This course covers OSPF and IS-IS. Path Determination Path determination enables a router to select the most appropriate interface for forwarding a packet, a logical grouping of information and user data. Path determination enables a routing protocol to determine the desirability of a given path to a destination. The desirability of a path is based on one or more routing metrics. As paths are configured or discovered, they are recorded as entries in a routing table. Routing table entries associate destinations with next-hop routers (the router to which traffic should be forwarded next). Routers use the information in routing tables to forward packets, as follows: 1. When a router receives a packet on an interface, it examines the Destination Address field. 2. The router checks its routing table to see if it knows how to forward the packet toward the destination. 3. If the destination network is not contained in the routing table, the router drops the packet. If the destination network is contained in the routing table, the router checks the entry to see which is the most desirable path for the packet to take. 4. When it has determined the preferred path to the destination, the router checks the routing table entry to see which of its interfaces leads to the next hop in that
path. The next hop might be another intermediate router or the destination network itself. 5. The router queues the packet at the appropriate interface, and sends the packet on its way to the next hop in the path to the destination. Path Switching Path switching allows a router to accept a packet on one interface and then forward it on a second interface using simple switching algorithms. Before path switching can occur, path determination must occur. Path Switching Process When a router receives a packet, it must determine whether it can forward it toward the destination, as follows: 1. An end system has packets to send to another end system. 2. The source end system addresses the packets using the Media Access Control (MAC) address of the nearest intermediate system (such as a router) and the network address of the destination end system. 3. The source end system sends the packets to the specified intermediate system. 4. The intermediate system (the router) examines the destination network address to see if it can forward the packets. If it cannot forward the packets, they are dropped. If it can forward the packets, the router changes the destination MAC address to that of the next hop in the path to the destination. 5. The router then sends the packets to the next-hop device (either another intermediate system or the destination end system). As the packet moves through the internetwork, its destination MAC address changes, but its network address remains the same. Routing Metrics To aid the process of path determination, routing algorithms initialize and maintain routing tables, which contain a listing of network addresses and how they can be reached. Routing metrics are used by the routing algorithm to determine the best route. Sophisticated routing algorithms can base route selection on multiple metrics, combining them in a single (hybrid) metric. The following sections cover various routing metrics. Path Length Path length is the most common routing metric. Some routing protocols allow network administrators to assign arbitrary costs to each network link. In this case, path length is the sum of the costs associated with each link traversed. Other routing protocols define
hop count, a metric that specifies the number of passes through internetworking products (such as routers) that a packet must take en route from a source to a destination. Reliability Reliability, in the context of routing algorithms, refers to the reliability (usually described in terms of the bit-error rate) of each network link. Some network links may go down more often than others. When down, some network links may be repaired more easily or more quickly than other links. Any reliability factors can be accounted for in the assignment of reliability ratings, which are usually assigned to network links by network administrators. They are typically arbitrary numeric values. Routing Delay Routing delay refers to the length of time required to move a packet from source to destination through the internetwork. Delay depends on many factors, including the bandwidth of intermediate network links, the port queues at each router along the way, network congestion on all intermediate network links, and the physical distance to be traveled. Because it is a conglomeration of several important variables, delay is a common and useful metric. Bandwidth Bandwidth refers to the available traffic capacity of a link. All other parameters being equal, a 10-Mbps Ethernet link would be preferable to a 64-kbps leased line. Although bandwidth is a rating of the maximum attainable throughput on a link, routes through links with greater bandwidth do not necessarily provide better routes than routes through slower links. If, for example, a faster link is much busier, the actual time required to send a packet to the destination may be greater through the fast link. Load Load refers to the degree to which a network resource (such as a router) is busy. Load can be calculated in a variety of ways, including CPU utilization and packets processed per second. Monitoring these parameters on a continual basis can itself be resource intensive. Communication Cost Communication cost is another important metric. Some companies may not care about performance as much as they care about operating expenditures. Even though line delay might be longer, they will send packets over their own lines rather than through public lines that will cost money for usage time.
Routing Algorithms Routing algorithms use a variety of metrics that affect calculation of optimal routes. There are various types of routing algorithms, and each algorithm has a different impact on network and router resources. Some examples of routing algorithm attributes follow: Optimality Optimality refers to the ability of the routing algorithm to select the "best" route, which depends on the metrics and metric weightings used to make the calculation. For example, one routing algorithm might use the number of hops and delay, but might weigh delay more heavily in the calculation. Naturally, routing protocols must strictly define their metric calculation algorithms. Simplicity Routing algorithms are also designed to be as simple as possible. The routing algorithm must offer its functionality efficiently, with a minimum of software and utilization overhead. Efficiency is particularly important when the software implementing the routing algorithm must run on a computer with limited physical resources. Robustness Routing algorithms need to be robust. They should perform correctly in the face of unusual or unforeseen circumstances such as hardware failures, high load conditions, and incorrect implementations. Because routers are located at network junction points, they can cause considerable problems when they fail. The best routing algorithms are often those that have withstood the test of time and have proven stable under a variety of network conditions. Rapid Convergence Routing algorithms must converge rapidly. Convergence is the process of agreement, by all routers, on optimal routes. When a network event causes routes to either go down or become available, routers distribute routing update messages. Routing update messages permeate networks, stimulating recalculation of optimal routes and eventually causing all routers to agree on these routes. Routing algorithms that converge slowly can cause routing loops or network outages. Flexibility Routing algorithms should also be flexible. Routing algorithms should quickly and accurately adapt to a variety of network circumstances. For example, assume that a network segment has gone down. Many routing algorithms, on becoming aware of this problem, will quickly select the next-best path for all routes that normally use that
segment. Routing algorithms can be programmed to adapt to changes in network bandwidth, router queue size, network delay, and other variables. Routing algorithms can also be classified by type. For example, types of algorithms include: Static or Dynamic Algorithms Static routing algorithms are hardly algorithms at all. Static routing table mappings are established by the network administrator prior to the beginning of routing. They do not change unless the network administrator changes them. Algorithms that use static routes are simple to design and work well in environments where network traffic is relatively predictable and network design is relatively simple. Because static routing systems cannot react to network changes, they are generally considered unsuitable for today's large, constantly changing networks. Most of the dominant routing algorithms in the 1990s are dynamic. Dynamic routing algorithms adjust, in real time, to changing network circumstances by analyzing incoming routing update messages. If the message indicates that a network change has occurred, the routing software recalculates routes and sends out new routing update messages. These messages permeate the network, stimulating routers to rerun their algorithms and change their routing tables accordingly. Dynamic routing algorithms may be supplemented with static routes where appropriate. For example, a router of last resort (a router to which all unroutable packets are sent) may be designated. This router acts as a repository for all unroutable packets, ensuring that all messages are at least handled in some way. Single-Path or Multipath Algorithms Some sophisticated routing protocols support multiple paths to the same destination. These multipath algorithms permit traffic multiplexing over multiple lines; single-path algorithms do not. The advantages of multipath algorithms are obvious; they can provide substantially better throughput and reliability. Flat or Hierarchical Algorithms Some routing algorithms operate in a flat space, while others use routing hierarchies. In a flat routing system, all routers are peers of all others. In a hierarchical routing system, some routers form what amounts to a routing backbone. Packets from nonbackbone routers travel to the backbone routers, where they are sent through the backbone until they reach the general area of the destination. At this point, they travel from the last backbone router through one or more nonbackbone routers to the final destination.
Routing systems often designate logical groups of nodes called domains, autonomous systems, or areas. In hierarchical systems, some routers in a domain can communicate with routers in other domains, while others can communicate only with routers within their domain. In very large networks, additional hierarchical levels may exist. Routers at the highest hierarchical level form the routing backbone. The primary advantage of hierarchical routing is that it mimics the organization of most companies and, therefore, supports their traffic patterns very well. Most network communication occurs within small company groups (domains). Intradomain routers need to know only about other routers within their domain, so their routing algorithms can be simplified. Depending on the routing algorithm being used, routing update traffic can be reduced accordingly. Host-Intelligent or Router-Intelligent Algorithms Some routing algorithms assume that the source end node will determine the entire route—usually referred to as source routing. In source-routing systems, routers merely act as store-and-forward devices, mindlessly sending the packet to the next stop. Other algorithms assume that hosts know nothing about routes. In these algorithms, routers determine the path through the internetwork based on their own calculations. In the first system, the hosts have the routing intelligence. In the latter system, routers have the routing intelligence. The trade-off between host-intelligent and router-intelligent routing is one of path optimality versus traffic overhead. Host-intelligent systems choose the better routes more often, because they typically discover all possible routes to the destination before the packet is actually sent. They then choose the best path based on the definition of optimal for that particular system. The act of determining all routes, however, often requires substantial discovery traffic and a significant amount of time. Intradomain or Interdomain Algorithms Some routing algorithms work only within domains; others work within and between domains. The nature of these two algorithm types is different. It stands to reason, therefore, that an optimal intradomain routing algorithm would not necessarily be an optimal interdomain routing algorithm. Link-State or Distance-Vector Algorithms Link-state algorithms (also known as shortest-path-first algorithms) flood routing information to all nodes in the internetwork. However, each router sends only that portion of the routing table that describes the state of its own links. Distance-vector algorithms (also known as Bellman-Ford algorithms) call for each router to send all or some portion of its routing table, but only to its neighbors. In essence, link-state
algorithms send small updates everywhere, whereas distance-vector algorithms send larger updates only to neighboring routers. Because they converge more quickly, link-state algorithms are somewhat less prone to routing loops than distance-vector algorithms. On the other hand, link-state algorithms require more CPU power and memory than distance-vector algorithms. Link-state algorithms can, therefore, be more expensive to implement and support. Despite their differences, both algorithm types perform well in most circumstances. This course discusses the link-state routing protocols. Click on the SPF Movie icon to see a short movie describing link-state algorithms.
Routing loops occur when routing tables have not converged. Convergence is the process routers go through when a route (network) or group of routes has become unavailable because a link has gone down in the network or because a link has lost a large number of packets. This loss results in the routers flushing the lost routes and listening to see whether other routes are available. Routers usually store the best route to a network in their routing tables. Other, high-cost routes may exist, but the router ignores them if it believes that the better route still exists. An example of a routing loop follows:
In this case, a packet arrives at Router R1 at time t1. Router R1 has already been updated and thus knows that the optimal route to the destination calls for Router R2 to be the next stop. Router R1, therefore, forwards the packet to Router R2. Router R2 has not yet been updated, so it believes that the optimal next hop is Router R1. Router R2, therefore, forwards the packet back to Router R1. The packet will continue to bounce back and forth between the two routers until Router R2 receives its routing update or until the packet has been switched the maximum number of times allowed. The following sections discuss the ways in which routing loops can be prevented.
Count to Infinity Many routing protocols impose an upper limit on routing metric values. This imposed maximum metric value, referred to as count to infinity, provides the external boundary condition necessary to prevent routing loops from continuing indefinitely. The value of infinity must be large enough that the metric for a valid route would not reach that value, but small enough that routing loops cannot exist for extended periods of time. Hold Down The hold-down mechanism is used to prevent regular routing updates from inappropriately reinstating incorrect routing information. When a router receives an update that contains a topology change, it starts the hold-down timer, which prevents a router from implementing any changes to its routing table until the timer expires. Any update received during this period is discarded. The hold-down period is usually slightly longer than the time necessary for the entire network to converge on the topology change. In the following scenario, incorrect routing information is advertised because the holddown mechanism is not implemented: 1. A route goes down and neighboring routers detect the failure. 2. These routers calculate new routes and send out routing update messages to inform neighbors of the route change. 3. A device that has not yet been informed of a network failure sends a regular update message indicating that the failed route is good. 4. This update reaches a device that has just been notified of the failure. That device inserts the bad route back into the routing table and now contains incorrect routing information, which it proceeds to advertise in the routing updates it sends to its neighbors. Split Horizon The split-horizon rule states that it is never useful for a routing protocol to send information about a route back to the router from which the route was learned. An example of a split-horizon implementation follows: 1. Router R1 advertises that it has a route to Network A. 2. Router R2 receives the update from Router R1 and inserts the information about Network A in its routing table. 3. When Router R2 sends a regular routing update, it does not include the entry for Network A in the update sent to Router R1, because that route was learned from Router R1 in the first place.
Routing Information Protocol ( RIP) is an Interior Gateway Protocol (IGP), meaning it is used within an autonomous system. A distance-vector protocol, RIP was designed to work with small to medium-sized networks. The original version of RIP is based on the program routed (pronounced "route dee"), distributed with the 4.3 Berkeley Software Distribution. RIP was in widespread use as a routing protocol before it was formally defined in RFC 1058. RIP Version 2, defined in RFC 2453, added some additional features and functionality to the original version. Both versions of RIP are discussed in this module. RFC 2091 specified additional extensions for RIP to allow support for demand circuits (Triggered RIP). Support for Triggered RIP was added in 12.0(1)T and will not be discussed here. Some advantages of using RIP, especially in small networks, is that there is very little overhead, in terms of bandwidth used and configuration and management time. RIP is also easy to implement, compared to newer IGPs, and has been implemented in networks around the world.
RIP is a distance-vector protocol. As you learned in the "Cisco Interactive Mentor: Basic IP Routing Concepts" module, a distance-vector protocol is based on the exchange of routing-table information. Each router using a distance-vector protocol maintains information about all the destinations within the system. In general, the information about all the entities connected to one network (or subnet) is summarized within a single entry. This entry includes the next destination to which datagrams are destined, a metric measuring the total distance to the entity, the time delay in sending the messages, and the cost of sending the messages. Distance-vector protocols compute the optimal routes from this information and then share that information with adjacent entities on the same network. Routers running RIP may participate as either active or passive devices. A device running in active mode will advertise its routes, while a passive device will silently listen to advertisements. For obvious reasons, routers generally run in active mode while hosts often run in passive mode when running RIP.
RIP is used to convey information about routes to destinations. RIP relies on access to information about its directly connected networks. An active RIP device accomplishes this access by periodically advertising its routing information. The information that RIP uses to construct these updates is taken from the routing table (or the RIP database in Cisco IOS® 12.0T and later). The routing table contains one entry for every destination that is reachable within the system. Each entry has the following information:
IP address of the destination A metric that represents the total cost of getting a datagram from the host to the destination
The IP address of the next router along the path to the destination Timers associated with the router The route change flag that indicates that the information about the route has changed recently
The following is an example of a RIP routing table:
RIP maintains only the best route to a destination. In order to prevent routing information from oscillating between two or more equal-cost paths, the RFC specifies that updates from different next hops should be used only if the reported metric is less than the currently installed route. Metric changes received from the existing gateway are installed immediately. The Cisco implementation allows routes with identical metrics for the same network to be simultaneously installed for load balancing. Network topology changes can cause changes in routes. These changes can result in a new route becoming the best route to a particular destination. When network topology changes occur, they are reflected in routing update messages. For example, when a router detects a link or router failure, it recalculates its routes and sends routing update messages. Each router receiving a routing update message that includes a change updates its tables and propagates the change.
RIP uses a single routing metric, hop count, to measure the distance between the source and destination networks. Each hop in this path is assigned a hop-count value, which with RIP is usually 1. When a router receives a routing update that contains a new or changed destination-network entry, the router adds one to the metric value indicated in the update and enters the network in the routing table. The IP address of the sender is used as the next hop. This method for incrementing the routing metric will theoretically provide loop-free routing information in a perfectly stable environment, but when the topology changes or when networks become inaccessible, it can lead to two
classic problems faced by traditional distance-vector routing algorithms: slow convergence or count to infinity. Routing information about topology changes propagates slowly throughout a network because of inconsistencies between the routing tables of the routers in the network. Limiting the number of hops in a network helps to improve this convergence problem. Limiting the number of hops allowed also prevents routing loops from continuing indefinitely. RIP is limited to networks whose longest path involves 15 hops. With RIP, if a router receives a routing update that contains a new or changed entry, and if increasing the metric by one causes the metric to be 16, the network destination is considered unreachable. In other words, 16 is equivalent to "infinity" in a RIP network. If a network becomes completely inaccessible, then routers could mutually deceive each other and "count to infinity," as shown in the following example:
Router_C is advertising the network 192.100.10.x with a cost of one. Router_A is advertising the network 192.100.10.x with a cost of two. If the connection between Router_C and the network 192.100.10.x is lost, then Router_C will advertise it with a cost of 16 (infinity). If Router_A advertises the network 192.100.10.x back to Router_C before the "infinite" metric is received, then Router_C may incorrectly believe that Router_A can still reach the target network with a cost of two. Router_C will advertise the network 192.100.10.x back to Router_A with a cost of three. This routing loop will continue until both routers eventually "count to infinity." RIP designers chose 16 to be infinity because they wanted the number to be small enough that when networks become completely inaccessible, the counting would stop as soon as possible. The choice of 16 as infinity is a tradeoff between network size and the speed of convergence. The designers of RIP believed that it would be impractical to implement RIP in networks with diameters larger than 15.
RIP also uses timers both to regulate its performance and to help prevent routing loops like those shown above. All routers that use RIP send an update message to all of their neighbors approximately every 30 seconds; this process is termed advertising. The RFC specifies that advertisements should be randomized by up to +/– five seconds in order to prevent synchronization of routing updates. The Cisco implementation sends updates every 30 seconds minus up to 15 percent, or 4.5 seconds.
If a neighbor has not responded in 180 seconds, it is assumed that the neighboring router is unavailable or the network connecting it to the router has become unusable. When the neighbor has not responded for 180 seconds, the route is marked invalid; 180 seconds is long enough that a route won't be invalidated by a single missed update message. The neighbor is shown to be unreachable by sending a normal update message with a metric of "infinity;" in the case of RIP, this number is 16. If an advertisement is received from a neighbor with a metric of infinity, then the route is placed into holddown state, advertised with a distance of 16, and kept in the routing table. No updates from other neighbors for the same route are accepted while the route is in holddown state. If other neighbors are still advertising the same route when the holddown timer expires, then their updates will then be accepted. The route will be advertised with an infinity metric for a period of time after the holddown state if no alternate paths are found. The actual timers used to accomplish the above tasks are a routing-update timer, a route-invalid timer, a route-holddown timer, and a route-flush timer. The RIP routingupdate timer is generally set to 30 seconds, ensuring that each router will send a complete copy of its routing table to all neighbors every 30 seconds. The route-invalid timer determines how much time must expire without a router having heard about a particular route before that route is considered invalid. When a route is marked invalid or put in holddown state, neighbors are notified of this fact. This notification must occur prior to expiration of the route-flush timer. When the route flush-timer expires, the route is removed from the routing table. Typical initial values for these timers are 180 seconds for the route-invalid and route-holddown timers and 240 seconds for the route-flush timer. The values for each of these timers can be adjusted with the timers basic router configuration command. Information concerning the RIP process, including the timers, can be seen with the show ip protocol command. A sample output from this command is shown in the following example: Router-1#show ip protocol Routing Protocol is "rip" Sending updates every 30 seconds, next due in 18 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Outgoing routes will have 10 added to metric if on list 1 Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain Ethernet0/0 1 1 2 Routing for Networks: 172.16.0.0 Routing Information Sources: Gateway Distance Last Update
172.16.4.1 120 Distance: (default is 120) Router-1#
00:00:20
To adjust for rapid network-topology changes, RIP specifies numerous stability features that are common to many routing protocols. RIP implements split horizon with poisonreverse and holddown mechanisms to prevent incorrect routing information from being propagated. Split horizon prevents incorrect messages from being propagated by not advertising routes over an interface that the router is using to reach the route. Implementing split horizon helps avoid routing loops. Poison reverse operates by advertising routes that are unreachable with a metric of infinity back to the original source of the route. Holddown is a method of marking routes invalid (expired). As discussed above, no updates from other neighbors for the same route are accepted while the route is in holddown state. Triggered updates are also an included convergence and stability feature. Updates are triggered whenever a metric for a route changes. Triggered updates may also contain only information regarding routes that have changed, unlike scheduled updates. There is a minimum delay of five seconds between triggered updates to prevent update storms.
RIP is a User Datagram Protocol (UDP)-based protocol. Each router that uses RIP has a routing process that sends and receives datagrams on UDP port number 520, the RIP port. All communications for the RIP process of the router use this port. All routing update messages are sent from the RIP port and unsolicited routing update messages have both the source and destination port equal to this port. RIP V1 traffic is sent as a broadcast to the 255.255.255.255 IP address by default. The following is the packet format for the original version of RIP, defined in RFC 1058:
The Command field indicates whether the packet is a request or a response. The request asks a router to send all or part of its routing table. The response can be an unsolicited update message or a reply to a request. Responses contain routing-table entries. Multiple RIP packets are used to contain information for large routing tables. The Version Number field specifies the RIP version used. This field can signal potentially incompatible versions. The Zero field is not used. The Address-Family Identifier (AFI) specifies the address family used. RIP is designed to carry routing information for several different protocols. Each entry has an AFI to indicate the type of address being specified. The AFI for IP is 2. The Metric, as stated earlier, indicates how many hops have been traversed in the trip to the destination. The value is between 1 and 15 for a valid route, or 16 for an unreachable route. The RIP V1 packet format does not distinguish among different types of addresses. Fields that are labeled "address" can contain any of the following:
Host address Subnet number Network number Zero (default route)
Entities that use RIP V.1 are supposed to use the most specific information available when routing a datagram. First, the destination address of the datagram is checked against the list of node addresses. Then it is checked to determine whether it matches any known subnet or network number. If none of these match, the default route is used. Note: All routes received on an interface are assumed to have the subnet mask of that interface. Because of this, if the subnet masking is different on interfaces within the same major network, updates will not be exchanged between these interfaces because of the possible resulting ambiguity. Updates that do not fit with the assumed subnet mask are considered to be host routes. If an update including a route from a different major network is received on an interface, the router must assume that the update is for the entire major network. For this reason, there is no way to disable autosummarization with RIP V.1. Default Routes in RIP As mentioned above, a default route will be used to route packets if a longer match is not found in the routing table. When RIP is used to advertise the default route, the address field in the packet contains zero, referring to the 0.0.0.0 IP network address.
Unlike other protocols, RIP will automatically advertise the default route as long as a default route from any source is installed in the routing table on the router; no additional redistribution commands are necessary. In versions prior to 12.0(1)T, a default can be forcibly advertised using the default-information originate command even though no default route is known by the router.
RIP Version 2, or RIP V.2, was created to add additional functionality to the original RIP and also cope with some new issues that arose after RIP was defined. RIP V.2 uses the same basic algorithms as RIP V.1, but supports external route tags, subnet masks, next-hop addresses, and authentication. RIP V.2 is backward compatible with RIP V.1. External Route Tags RIP V.2 includes a Route Tag field, which is an attribute assigned to a route that must be preserved and readvertised with a route. This field provides a mechanism to separate "internal" RIP routes (routes for networks within the RIP routing domain) from "external" RIP routes, which may have been imported from an Exterior Gateway Protocol (EGP) or another IGP. Subnet Mask RIP V.2 allows the use of variable subnet masks on the network. In RIP V.1, there is a subnet/host ambiguity because nodes do not know the subnet masks, so evaluating the address can be ambiguous. In RIP V.2 there is a Subnet Mask field, which is applied to the IP address to yield the nonhost portion of the address. If this field is zero, then no subnet mask has been applied. Next-Hop Addresses RIP V.2 supports next-hop addresses; this setup allows for optimization of routes in an environment that uses multiple routing protocols. For example, if RIP V.2 was running on a network with Enhanced Interior Gateway Routing Protocol (EIGRP) and one router ran both protocols, then the router could indicate if a better next hop than itself exists for a given destination. This setup eliminates packets from being routed through extra hops in the system. The Next-Hop field is an "advisory" field, and if the provided information is ignored, another suboptimal route may be taken. If the received next hop is not directly reachable, it should be treated as 0.0.0.0.
Authentication RIP V.2 offers an authentication mechanism, which is a per-message function. With RIP V.2, there is only a 2-octet field available in the message header and since 2 octets are obviously not enough, the authentication scheme uses the space of an entire RIP entry. To identify if the entry contains authentication, check to see if the AFI of the first entry is 0xFFFF. If it is, there can be a maximum of 24 RIP entries in the remainder of the message. The AFI or 0xFFFF should not be used if authentication is not being used. The authentication type for RIP V.2 is a simple password, and it is type 2. The remaining 16 octets contain a plaintext password. If the password is under 16 octets, it must be left-justified to the right with nulls (0x00).
Multicasting RIP V.2 packets may be multicast instead of being broadcast. The multicast address is 224.0.0.9. Multicasting reduces the load on hosts that do not support routing protocols, and also allows RIP V.2 routers to share information that RIP V.1 routers cannot hear. This feature is useful since a router running the original version of RIP may misinterpret route information because it cannot apply the subnet mask.
The RIP V.2 specification, described in RFC 2453, allows for the above functionality to be incorporated as information into the packet. The following shows a RIP V.2 packet:
The Command field indicates whether the packet is a request or a response. The request asks that a router send all or part of its routing table. The response can be an unsolicited regular routing update or a reply to a request. Responses contain routingtable entries. Multiple RIP packets are used to convey information from large routing tables. The Version field specifies the RIP version used. In a RIP packet implementing any of the RIP V.2 fields or using authentication, the value is set to 2.
The Unused field has a value set to zero. The Address Format Identifier (AFI) field specifies the address family used. RIP is designed to carry routing information for several different protocols. Each entry has an AFI to indicate the type of address specified. The AFI for IP is 2. If the AFI for the first entry in the message is 0xFFFF, the remainder of the entry contains authentication information. The Route Tag field provides a method for distinguishing between internal routes, learned by RIP, and external routes that were learned from other protocols. The IP Address field specifies the IP address for the entry. The Subnet Mask contains the subnet mask for the entry. If this field is zero, no subnet mask has been specified for the entry. The Next-Hop field indicates the number of hops that have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route. Note: Up to 25 occurrences of the AFI, address, and metric fields are permitted in a single RIP packet. In other words, up to 25 destinations may be listed in any single RIP packet. Multiple RIP packets are used to convey information from larger routing tables. Interaction between RIP V.1 and RIP V.2 Since RIP V.1 packets do not contain subnet mask information, routers on networks that contain both RIP V.1 and RIP V.2 should use the semantics employed by RIP V.1 only. If not, there is the possibility of routes for networks that do not exist or excessive routing information in a Version 1 environment. By default, Cisco IOS software receives RIP V.1 and RIP V.2 packets, but sends only RIP V.1 packets. You can configure the software to receive and send only Version 1 packets. Alternatively, you can configure the software to receive and send only Version 2 packets. In some RIP implementations, autosummarization is used. Autosummarization is an attempt to summarize groups of adjacent routes into single entries in order to reduce the number of entries in routing tables. Summarization is done on major network boundaries. When using RIP V.2, autosummarization can be disabled.
Early routing protocols were based on distance vectors; they were very simple and easy to implement but had the severe drawbacks of counting to infinity and routing loops. These problems were reduced using techniques such as split horizon, holddowns, and
so on. These techniques, however, introduced long convergence times. Routing protocols based on link states have been implemented to address the problem of slow convergence in distance-vector protocols, but they add complexity in configuration and troubleshooting. EIGRP is an advanced distance-vector protocol that scales well, is easy to configure, and provides extremely quick convergence times with minimal network traffic. EIGRP is a classless protocol, meaning that it supports variable-length subnet mask (VLSM) and aggregation. An aggregate is a summarized group of addresses. In addition, EIGRP implements modules for IP, Internetwork Packet Exchange (IPX), and AppleTalk, which are responsible for the protocol-specific routing tasks. This training module includes information about only the IP module. Typically, distance-vector protocols maintain the information about only one path to the destination, the best path. This information consists of total metric (distance) and the next hop (vector) to the destination. For example:
If a router, Router_A, learns about a destination (Network A) from two different routers, it chooses the best path by examining the total metric of each path. After it chooses the best path, it discards any information about the alternate (nonbest) path. In the above example, the best path would be through Router_C (assuming hop count as a metric). All information about the path through Router_B is discarded. If the path between Router_A and Network A is somehow broken, Router_A removes the route from its routing table after a certain amount of time, usually three update periods (in the case of Routing Information Protocol (RIP), this time would be 90 seconds, not including any hold-down timers). After this route is removed from the routing table, Router_A then learns about Network A via Router_B (because Router_B has been sending periodic updates). It could take from 90 to 120 seconds before Router_A installs the new route to Network A through Router_B. EIGRP, on the other hand, builds a topology table from information it learns from each of its neighbors. The information sent by EIGRP is nonperiodic and contains only new information. Using the Diffusing Update Algorithm (DUAL), EIGRP then chooses a best path (successor) and alternate loop-free paths (feasible successors) that allow for fast convergence. This information is kept in a topology table separate from the routing table. Upon losing a route to a destination, EIGRP looks for feasible successors in its
topology table. If a feasible successor does exist, EIGRP begins using it immediately. If no feasible successors exist, EIGRP queries its neighbors. For all the above to be accomplished, the components of EIGRP must provide:
Reliable transport mechanism Neighbor discovery/recovery process, which allows EIGRP routers to discover and track other EIGRP speaking routers that are on directly connected networks; part of this process must be done reliably (guaranteed) A way to discover which paths are loop free A process to clear bad routes from the topology table of all routers on the network A process for querying neighbors to find paths for lost destinations
The DUAL algorithm cannot be effective if messages are not transmitted reliably. Therefore, a reliable transport for ordered delivery and acknowledgment must be part of EIGRP. The Reliable Transport Protocol is a component of EIGRP that guarantees the delivery and order of EIGRP packets. EIGRP updates and hellos are destined to the multicast address 224.0.0.10. Each EIGRP neighbor receiving a multicast reliable packet will unicast an acknowledgment. State variables, such as sequence number and acknowledgment number, are maintained on a per-neighbor basis to ensure ordered delivery. EIGRP uses multiple packet types for reliable transport, all of which are identified by protocol number 88 in the IP header.
Hello packets are used to discover and recover neighbors. They are multicast and use unreliable delivery (no acknowledgment necessary). Acknowledgments are used for reliable delivery and are always unicast. Updates are used to convey route information. Updates are transmitted only when there is a change in the topology; they contain only the changed information, and they are sent only to routers that require the information. If only one router requires the update information, the updates are unicast; otherwise the updates are multicast. Updates use reliable delivery. Queries and replies are used by DUAL. Queries can be multicast or unicast, and replies are always unicast. Queries and replies use reliable delivery.
Because EIGRP updates are nonperiodic and contain information only on paths that have changed, EIGRP relies on neighbor relationships to reliably propagate routingtable changes throughout the network. When an EIGRP router is initialized, it starts sending hello packets. Hello packets, when used for neighbor discovery, are always sent multicast addressed (224.0.0.10). The hello packet includes the EIGRP K-values (discussed later). Two routers will become neighbors only if the K-values in the hello packets are the same. This scenario enforces consistent metric usage throughout the network. Upon startup, two routers will become EIGRP neighbors when they see each other's hello packets on a common network. Hello packets are sent out, by default, once every five seconds on high-bandwidth media and every 60 seconds on low-bandwidth media. The rate at which the hello packets are sent is called the hello interval. This interval can be changed on a perinterface basis with the interface subcommand ip hello-interval eigrp. When a router receives a hello packet, the packet includes a hold time, the amount of time for which a router will consider a neighbor up without receiving a hello. Because the hold time is included in the hello packet, it is possible for two routers to become EIGRP neighbors even though the hello and hold timers do not match. The hold time is typically three times the hello interval. The hold time can be changed on a per-interface basis with the ip hold-time eigrp subinterface command. Information about each neighbor is maintained in a neighbor table, which can be viewed with the show ip eigrp neighbor command. The following is an example of the neighbor information for Router_B in the network shown above:
Router_B#show ip eigrp neighbor IP-EIGRP neighbors for process 7 H Address Interface Q Seq Cnt Num 2 170.170.3.4 0 8 1 170.170.3.3 0 18 0 170.170.1.1 0 17 Router_B# Et0 Et0 Se0
Hold Uptime (sec) 10 00:15:39 11 00:15:55 14 00:16:27
SRTT (ms) 12 15 9
RTO
200 200 200
The following is a description of what is included in the EIGRP neighbor table:
Show IP EIGRP Neighbors Field Descriptions Field Process 7 Address Interface Description Autonomous system number specified in the IP router configuration command IP address of the enhanced IGRP peer Interface on which the router is receiving hello packets from the peer Length of time, in seconds, that the router will wait to hear from the peer before declaring it down; if the peer is using the default hold time, this number will be less than 15; if the peer configures a nondefault hold time, it will be reflected here Elapsed time, in hours, minutes, and seconds, since the local router first heard from this neighbor Smooth round-trip time—the number of milliseconds it takes for an IP-enhanced IGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet Retransmission timeout, in milliseconds—the amount of time the router waits before retransmitting a packet from the retransmission queue to a neighbor Number of IP-enhanced IGRP packets (update, query, and reply) that the router is waiting to send Sequence number of the last update, query, or reply packet that was received from this neighbor
Hold Time
Uptime
SRTT
RTO
Q Count
Seq Num
When a router receives the hello packet from a new neighbor, EIGRP attempts to exchange routing updates with the neighbor. The updates contain all routes known by the sending routers and the metrics of those routes. When an EIGRP router receives updates from its neighbors, it builds a second table, the topology table, from which it builds a routing (forwarding) table. The topology table contains information needed to build a set of metrics and next hops to each reachable network, including:
Lowest bandwidth on the path to the destination Total delay
Path reliability Path loading Minimum-path maximun transmission unit (MTU) Feasible distance Reported distance Route source
We will see later how we can view the contents of the topology table.
As with most other routing protocols, the best path to a destination is the path with the lowest metric. EIGRP has the ability to use several variables to compute the metric to a destination network. The first five listed above are those variables: bandwidth, delay, reliability, load, and MTU. Only bandwidth and delay are used by default. It is highly recommended that the defaults be maintained, because using other variables can result in unknown problems in your network. The values of bandwidth and delay are determined from the bandwidth and delay values associated with the router interfaces. There are default values, but the values can be changed per interface with the bandwidth and delay subinterface commands. The formula for computing EIGRP metrics follows: Metric – {[K1 * Bandwidth + (K2 * Bandwidth)/(256 – Load) + K3 * Delay] * [K5/(Reliability + K4)]} * 256 The default K-values follow: K1 = 1; K2 = 0; K3 = 1; K4 = 0; K5 = 0; therefore, the metric formula can be simplified to: Metric = (Bandwidth + Delay) * 256 Bandwidth = 10000000/Minimum bandwidth along path; and Delay = Sum of delays along path. Therefore, the final metric formula becomes: ([10000000/Minimum bandwidth] + Sum of delay/10) * 256 Note: Formula uses the bandwidth in kilobits per second and delay as configured on the interface, which is in microseconds. Metric example:
In this example, the total cost (metric) for Router_A to get to Network A through Router_B would be: Minimum bandwidth = 128kbps Total delay = 100 + 100 + 1000 = 1200/10 ms ([10000000/128] + 1200/10) * 256 = 20030720 The total cost to the same destination through Router_C follows: Minimum bandwidth = 512kbps Total delay = 1000 + 100 + 100 = 1200/10 ms ([10000000/512] + 1200/10) * 256 = 5030720 The path through Router_C has the lowest cost. Router_A would, therefore, choose the path through Router_C as the best path and put it in its routing table. This path would then be known as the successor (explained later). In the above topology, the metric of Router_B to Network A would be 307200. Router_C would also have a metric of 307200 to Network A.
(successor, feasible distance, reported distance, and feasible successor explained) Successor is the best path to a given destination; it is the path that is installed into the routing table. Feasible distance (FD) is the lowest calculated metric to each destination. In the above metric example, the path through Router_C was the best path because the calculated metric was the lowest through that path. Router_A would have a feasible distance of 5307200 for Network A.
Reported distance (RD) is the metric to a destination as advertised by a neighbor. In the above metric example, the metric that Router_C calculates for Network A is 307200. Router_A would see this metric as a reported distance. A feasible successor (FS) is a path whose reported distance is less than the feasible distance. This condition, reported distance < feasible distance, is also known as the feasibility condition. A path that satisfies the feasible condition is considered loop free. A path that has a distance larger than the feasible distance could possibly be through this router, causing a loop. In the above metric example, the reported distance of Router_A for the path through Router_B is 307200 (the same as the path through Router_C). This value is less than the feasible distance of Router_A of 5307200, a value that meets the feasibility condition, and Router_B will be the feasible successor of Router_A for Network A. All of the calculated metrics and distances defined above as well as some additional information can be viewed in an EIGRP router by issuing the show ip eigrp topology command. The following is the output when issuing a show ip eigrp topology on Router_A (Network A in this case is 170.170.4.0/24): Router_A#show ip eigrp topology IP-EIGRP Topology Table for process 7 Codes: P - Passive, A - Active, U - Update, Q - Query, R Reply, r - Reply status P 170.170.1.0/24, 1 successors, FD is 20256000 via Connected, Serial0 P 170.170.2.0/24, 1 successors, FD is 5025536 via Connected, Serial1 P 170.170.3.0/24, 1 successors, FD is 5281536 via 170.170.2.3 (5281536/281600), Serial1 via 170.170.1.2 (20281600/281600), Serial0 P 170.170.4.0/24, 1 successors, FD is 5307136 via 170.170.2.3 (5307136/307200), Serial1 via 170.170.1.2 (20307200/307200), Serial0 Router_A#
From the above output, we can see that for network 170.170.4.0, Router_A has a FD of 5307136, which is also the metric of the best route (route through serial 0). The reported distance of Router_B is 307200. Because 307200 is less than 5307136, the feasibility
condition is met and the route through Router_B is a FS. Note that show ip eigrp topology shows successors as well as FSs for each destination. Let's look at the topology table of another router. If we display the topology table for Router_B, we will see the following: Router_B#show ip eigrp topology IP-EIGRP Topology Table for process 7 Codes: P - Passive, A - Active, U - Update, Q - Query, R Reply, r - Reply status P 170.170.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 170.170.2.0/24, 1 successors, FD is 5281536 via 170.170.3.3 (5281536/5255936), Ethernet0 via 170.170.1.1 (20512000/5255936), Serial0 P 170.170.3.0/24, 1 successors, FD is 281600 via Connected, Ethernet0 P 170.170.4.0/24, 1 successors, FD is 307200 via 170.170.3.4 (307200/281600), Ethernet0 Now for network 170.170.4.0, we see a successor via 170.170.3.4 and a FD of 307200. However, we don't see any FSs. Looking at the topology above, we see that Router_B should also hear about the network 170.170.4.0 from Router_A. This route is not displayed because it is not a FS. We can see all routes for destinations, including those that are not FSs, by using the show ip eigrp topology all-links command. The following is the output for Router_B: Router_B#show ip eigrp topology all-links IP-EIGRP Topology Table for process 7 Codes: P - Passive, A - Active, U - Update, Q - Query, R Reply, r - Reply status P 170.170.1.0/24, 1 successors, FD is 2169856, serno 15 via Connected, Serial0 P 170.170.2.0/24, 1 successors, FD is 5281536, serno 18 via 170.170.3.3 (5281536/5255936), Ethernet0 via 170.170.1.1 (20512000/5255936), Serial0 P 170.170.3.0/24, 1 successors, FD is 281600, serno 1 via Connected, Ethernet0 via 170.170.1.1 (20537600/5281536), Serial0 P 170.170.4.0/24, 1 successors, FD is 307200, serno 11 via 170.170.3.4 (307200/281600), Ethernet0
via 170.170.1.1 (20563200/5307136), Serial0
Now we can see that Router_B has learned about network 170.170.4.0 through a second path. But we also see that the reported distance for this second path is 5307136, greater that the FD; therefore, this second path is not a FS.
As mentioned previously, if a router loses its best path (successor) to a given destination, it will check its EIGRP topology table for a FS. If one exists, it becomes the successor and the router can begin using it immediately. What happens if a router does not have a FS? EIGRP then needs a process to clear the bad route from the topology table of all routers in the network and a process to find new paths to the destination. These processes are defined by the DUAL state machine. An EIGRP route is said to be in a passive state when EIGRP is not performing any DUAL computations for it. Certain events can occur to make EIGRP reassess the FS list for a given destination: 1. When there is a direct change to the topology table, such as changing the state of a directly connected link 2. When an EIGRP update, query, or reply packet is received The reassessment could result in an existing FS becoming the successor, in which case the FD is updated and updates are sent to all neighbors. The route remains passive during the reassessment. If a FS cannot be found in the topology table, EIGRP begins performing a DUAL computation and the route becomes active. When a route is active, a router sends queries to all of its neighbors. Each neighbor then performs its own local computation. If the neighbor has at least one FS for the destination in question, it sends a reply, containing its metric to the destination, to the router that originated the query. If the neighbor does not have any FSs, it also generates queries to all of its neighbors, meaning that the route becomes active in the neighboring router as well. In some instances, it may take a very long time before a querying router receives a reply from one or more of its neighbors. Possible causes are that the network is very large, the network has low-quality links, or high CPU utilization, and so on. If a querying router does not receive all expected replies within a certain amount of time, the route is declared "stuck in active" (SIA). At this point, the router that originated the query will reset the neighbor that hasn't responded to the query. A query example follows:
In the above diagram, Router_A has two possible paths to get to network 170.170.4.0/24. If we calculate the metrics for this network, we find that the the best path of Router_A to Network A is through Router_B with a metric of 20307200. Therefore, the FD is 20307200. Router_C is reporting a distance of 20537600, the distance for its best path through Router_D. As far as Router_A is concerned, the distance reported from Router_C is greater than the FD; therefore, the feasibility condition is not met and Router_A does not have any FS.
If the link between Router_A and Router_B fails, as shown in first diagram, Router A checks its topology table for a FS. We determined earlier that Router_A does not have a FS, so it queries all the other EIGRP neighbors, as shown in the second diagram. Router_C then checks its topology table for a valid successor or FS. If either one is found, Router_C sends a reply to Router_A, as shown in the diagram below. The reply includes the metric of Router_C to the network.
Router_A then installs the new route to the network in its topology table and into its routing table.
Two types of summarization can be used with EIGRP: autosummarization and manual summarization. By default, EIGRP autosummarizes on major network boundaries when it is first configured. This behavior is similar to other distance-vector protocols, such as RIP and IGRP. An example of autosummarization follows:
In the topology shown in the above diagram, Router_B advertises only 180.180.0.0/16 to Router_D because Router_B is a boundary between two major networks, network 180.180.0.0 and network 170.170.0.0. For this same reason, Router_B advertises only network 170.170.0.0/16 to Router_A. Because Router_B is doing the summarization, it installs a route for the summarized address with a next hop of null0 (see the output below). Router_B#sh ip route 170.170.0.0 Routing entry for 170.170.0.0/16, 3 known subnets Attached (1 connections) Variably subnetted with 2 masks
Redistributing via eigrp 7 D 170.170.0.0/16 is a summary, 00:00:27, Null0 C 170.170.3.0/24 is directly connected, Ethernet0 D 170.170.4.0/24 [90/307200] via 170.170.3.4, 00:00:42, Ethernet0 Router_B#
Router_B#show ip eigrp topology 170.170.0.0 255.255.0.0 IP-EIGRP topology entry for 170.170.0.0/16 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600 Routing Descriptor Blocks: 0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0 Composite metric is (281600/0), Route is Internal Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 1000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 0 To get Router_B to advertise the subnets of networks 170.170.0.0 and 180.180.0.0, we could turn off autosummarization with the EIGRP no auto-summary configuration command. This step is usually desirable in topologies that have discontiguous networks. If in the above example of autosummarization Router_A were also configured to run EIGRP on its Ethernet link and autosummarization turned off, Router_B would receive the subnet information about 190.190.1.0/24 from Router_A. However, even if Router_B has autosummarization enabled, Router_B would not summarize 190.190.1.0 down to 190.190.0.0/16 when it advertised the network to Router_C because network 190.190.0.0/16 is not directly connected to Router_B. EIGRP autosummarizes internal networks; it does not autosummarize external networks. An external network is a network that originated in another autonomous system and was redistributed into this EIGRP network (redistribution is discussed in the next section) but which will not be summarized automatically. External networks can be summarized manually with the EIGRP ip summary-address eigrp interface subcommand. An example of manual summarization follows: In the topology of the previous figure, if the network 190.190.1.0 is not part of the EIGRP process running on Router_A, the only way to get the network advertised is to
redistribute it into EIGRP, making it an external route as far as Router_B is concerned. See below: Router_B#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E EGP i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2, * candidate default U - per-user static route Gateway of last resort is not set 190.190.0.0/24 is subnetted, 1 subnets D EX 190.190.1.0 [170/2560256256] via 180.180.1.1, 00:00:31, Serial0 180.180.0.0/16 is variably subnetted, 2 subnets, 2 masks D 180.180.0.0/16 is a summary, 04:10:02, Null0 C 180.180.1.0/24 is directly connected, Serial0 170.170.0.0/16 is variably subnetted, 3 subnets, 2 masks D 170.170.0.0/16 is a summary, 04:09:47, Null0 C 170.170.3.0/24 is directly connected, Ethernet0 D 170.170.4.0/24 [90/307200] via 170.170.3.4, 04:10:02, Ethernet0 As we can see above, Router_B receives all the subnet information for network 190.190.1.0; the network is not autosummarized. It shows up as an external network denoted by the D EX flag in the above output. Now if we configure the following ip summary-address eigrp 7 190.190.0.0 255.255.0.0 command, under the serial interface of Router_A, we will see the following in the routing table of Router_B: Router_B#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E EGP i - ISIS, L1 - ISIS level-1, L2 - ISIS level-2, * candidate default U - per-user static route
Gateway of last resort is not set D 190.190.0.0/16 [90/2560256256] via 180.180.1.1, 00:00:08, Serial0 180.180.0.0/16 is variably subnetted, 2 subnets, 2 masks D 180.180.0.0/16 is a summary, 00:51:59, Null0 C 180.180.1.0/24 is directly connected, Serial0 170.170.0.0/16 is variably subnetted, 3 subnets, 2 masks D 170.170.0.0/16 is a summary, 00:00:08, Null0 C 170.170.3.0/24 is directly connected, Ethernet0 D 170.170.4.0/24 [90/307200] via 170.170.3.4, 00:51:59, Ethernet0
Notice that the network has been summarized and is now seen as an internal EIGRP network. The ip summary-address eigrp command allows us not only to summarize subnets down to the major network, but also to aggregate major networks into a single supernet. For example, networks 200.200.64.0/24 through 200.200.95.0/25 could be aggregated by the single route 200.200.64.0/18.
It is possible for a router to be running multiple routing processes. These processes could be different processes of the same routing protocol or different routing protocols altogether. When the processes are different protocols, the router needs a way to determine which route to install in the routing table. This determination is done with the administrative distance. Administrative distance is a number given to each protocol—the lower the administrative distance, the more believable the protocol is as far as the router is concerned. The administrative distance is a number that is local to the router; it is not included in any advertisements. EIGRP has an administrative distance of 90; external EIGRP has an administrative distance of 170. A list of route sources and their default administrative distances follows:
Connected Route Static Route EIGRP Summary Route External BGP
0 1 5 20
EIGRP Internal Route IGRP OSPF ISIS RIP EGP EIGRP External Route Internal BGP
90 100 110 115 120 140 170 200
Redistribution is the means of taking routes learned via a given routing protocol and advertising those routes via another routing protocol or a different process of the same protocol. When routes are redistributed into EIGRP, they become EIGRP external routes, as we saw in previous examples. These external routes will have an administrative distance of 170. The redistribute command is used to redistribute routes into EIGRP. If the routes that we want to redistribute into EIGRP are learned via a protocol that does not have EIGRP-compatible metrics (IGRP is the only other protocol that has EIGRP-compatible metrics), we must tell EIGRP what metric to use when it advertises the route. We do this as part of the redistribute command or with the default-metric command. We will discuss redistribution in slightly more detail in one of the configuration labs.
Like other Interior Gateway Protocols (IGPs), EIGRP load balances across equal cost paths to a given destination. By default, EIGRP installs up to four equal cost paths into the routing table. The variance command allows EIGRP to load balance over unequal cost paths. Variance is a multiplier by which we multiply the best metric to a given destination. Any path to the same destination that has a metric less than the best path multiplied by variance will be installed in the routing table. For example, we have four paths to a given destination with the following metrics: Path 1: 500 Path 2: 500 Path 3: 1100 Path 4: 2000
By default, the router with the above metrics to a given destination installs Paths 1 and 2 in the routing table because they have equal metrics. If variance 3 is configured under router eigrp for this router, then Paths 1, 2, and 3 are all installed in the routing table because 1100 < (3 x 500). However, Path 4 is not installed because 2000 is not less then 3 x 500. The router then divides the traffic between Paths 1, 2, and 3 by dividing the metric for each path into the largest metric allowed, with variance and rounding down to the nearest integer.
For example: Path 1 1100/500 = 2 Path 2 1100/500 = 2 Path 3 1100/1100= 1 Thus we will send two packets via Path 1, one packet via Path 2, and one packet via Path 3. Then the router starts with Path 1 again.
A default route is a route in the routing table that is used as a last resort for a particular destination, meaning that there aren't any more specific routes in the routing table for the destination. A default route can be injected into EIGRP in three different ways. One way is to use the ip default-network command. This command works the same way that it does for IGRP. The second way is to have a static default route and redistribute it into EIGRP. For example: ip route 0.0.0.0 0.0.0.0 x.x.x.x (x.x.x.x is the next hop) router eigrp 10 redistribute static metric 10000 1 255 1 1500 Finally, a third way is to use manual summarization to generate a default route. For example: int s 0 ip summary-address eigrp 7 0.0.0.0 0.0.0.0
This third method is desirable when we want to limit to whom we want to send the default route. Because the ip summary-address eigrp command is an interface subcommand, we have flexibility on a per-interface basis.
OSPF is a routing protocol that calls for the sending of link-state advertisements (LSAs) to all other routers within the same hierarchical area. An area is a group of contiguous networks and attached hosts. OSPF LSAs include information on attached interfaces, metrics used, and other variables. As OSPF routers accumulate information, the routers use the SPF algorithm to calculate the shortest path to each node. This is different from the way distance-vector protocols work. Distance-vector protocols send all or a portion of their routing tables in routing-update messages to their neighbors. Configuring and troubleshooting OSPF networks is more complex than with its distance-vector counterparts.
The following is an overview on how OSPF operates:
Routers running OSPF will send OSPF hello packets to all OSPF-enabled interfaces. Routers sharing a common data link will become OSPF neighbors if their hello packets contain certain information that is mutually agreed upon. OSPF neighboring routers may form an OSPF adjacency if it is determined that there are certain commonalties between the routers exchanging hellos and the network over which the hellos are exchanged. Not all neighboring routers will form adjacencies. Routers will send (flood) LSAs over all adjacencies. All routers will build identical databases the LSAs. Shortest-path trees are calculated from the newly assembled routing tables.
Hellos OSPF neighbors are identified by their router IDs. A router ID is an IP address by which the router is uniquely identified within the OSPF domain. A Cisco router selects its router ID as the highest IP address on any loopback interfaces configured on the router. If no loopback interfaces are configured on the router, the router chooses the highest IP address of any of its physical interfaces.
Routers that share a common segment may become neighbors on that segment. Neighbors are discovered via the OSPF Hello protocol and are recorded in a neighbor table. The Hello protocol:
Provides a way to discover OSPF neighbors Acts as a keepalive between neighbors Ensures bi-directional communication between neighbors Is used for designated router (DR) and backup designated router (BDR) election on certain types of networks
Hello packets are sent out all OSPF-enabled interfaces. They are sent out periodically with a special multicast address as the destination. Routers will become neighbors when they see themselves (their own router ID) in their neighbor’s hello packets and they agree upon certain parameters included in the hello packets. Neighbor negotiation will take place on the primary IP address only, not over secondary addresses. If secondary addresses are configured on the interface, they are restricted to be in the same OSPF area as the primary address. Two routers will become neighbors if the following parameters are agreed upon:
Area ID — The two routers sharing a common network segment must have their interfaces configured to be in the same area. Authentication — OSPF allows for configuration of a password for a specified area. Routers that want to become neighbors must exchange the same password over the common segment. Hello and Dead intervals — The hello interval is the amount of time between hello packets that a router sends out on an OSPF-enabled interface. The dead interval is the amount of time, in seconds, that a router will wait for a hello packet from a neighbor before declaring the neighbor down. These interval times are included in the hello packet and must be agreed upon by neighbors. Stub area flag — Two neighboring routers must also agree on the stub area flag in the hello packets in order to become neighbors. (Stub areas will also be discussed later.)
All of the above parameters are included in hello packets. Also included in hello packets are the following:
The router ID of the originating router The address and mask of the originating interface Router priority, which is used for DR election (discussed later) The DR and BDR Flag bits for option capabilities; one of these is the stub area flag mentioned above Router IDs of the originating router neighbors
Network Types After two-way communication between neighbors is established, OSPF routers move on to the next step, which is building adjacencies. Adjacent routers are routers that go beyond the hello protocol exchange and proceed into the database exchange process. As previously mentioned, not all neighboring routers become adjacent. Whether or not an adjacency is formed depends on the type of network to which the neighboring routers are connected. The types of networks that OSPF defines follow:
Point-to-point networks Broadcast networks Non-Broadcast Multi-Access networks (NBMA) Point-to-multipoint networks
Point-to-point networks, such as serial lines, connect a single pair of routers. OSPF will always form an adjacency with the neighbor on the other side of a point-to-point interface. There is no concept of DR or BDR on point-to-point networks. The destination address of OSPF packets on these networks will always be sent to 224.0.0.5, otherwise known as the ALLSPFRouters multicast address. Broadcast networks, such as Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI), are multi-access, meaning they are able to connect more than two devices; a packet sent by one router will be received by all connected routers. On broadcast networks, OSPF will elect a DR and a BDR. Hello packets on broadcast networks are sent to the destination address of 224.0.0.5. All packet originated by the DR and BDR are also sent to the this address. All other non-DR and non-BDR routers will send linkstate updates to the address 224.0.0.6, also known as AllDRouters. NBMA networks, such as Frame Relay, ATM, and X.25, can connect multiple devices, but they have no broadcast capability. (For more information on Frame Relay, please read the Frame Relay document.) A packet sent by a router will not be received by all the other routers attached to the network. Special care should be taken when configuring OSPF over NBMA networks. OSPF considers these media to be just like any other broadcast media such as Ethernet or Token Ring. As a result, extra configuration may be required for NBMA networks. OSPF routers elect a DR and BDR, and all OSPF packets are unicast. Point-to-multipoint networks are NBMA networks in which the networks are treated as a collection of point-to-point links. Routers on these networks do not elect a DR and BDR because the network is seen as point-to-point links. OSPF packets are multicast on these networks.
Designated Router and Backup Designated Router The DR and BDR are elected on broadcast networks in order to prevent certain problems. First, if every router attached to a broadcast network formed an adjacency with every other router attached to the network, there would be n(n - 1)/2 adjacencies. Second, if a router flooded its LSAs to all of the router neighbors and all routers in turn flooded the LSA to their neighbors, there would be multiple copies of the same LSA on the same network. The idea behind the DR is that every router attached to the network would form an adjacency with the DR. Only the DR would send LSA to the rest of the attached network. OSPF also elects a BDR in the event that the DR fails. This prevents routers from having to reelect a DR and reforming adjacencies with the new DR. Instead, the routers attached to the network form an adjacency with both the DR and BDR. If the DR goes down, the BDR becomes the DR; since the other routers already have a formed adjacency with the BDR, there is little, if any, network unavailability. DR and BDR election is done via the Hello protocol. Hello packets are exchanged via IP multicast packets on each segment. The router with the highest OSPF priority on the segment will become the DR. Default priority is one for Cisco router interfaces. This process is repeated for the BDR. If the priorities are the same, the router with the highest router ID will become the DR. A single DR/BDR pair is elected on each attached segment. A router that is the DR of one segment may not be the DR or BDR of another attached segment. Setting the OSPF priority of an interface can be done with the interface subcommand: ip ospf priority [value] A priority value of zero indicates that the interface will not be elected as the DR or BDR. Note that once a DR and a BDR have been elected, a new router coming on line that has a higher priority will not override the DR and BDR. When the new OSPF router becomes active and discovers its neighbors, it checks for valid DR and BDR. If the DR and BDR exist, the new router will accept them. Routers that are not the DR or BDR are known as DRother.
In the diagram above, the router that will be elected DR for Segment 1 will be Router_F. This is because the priorities of all the router interfaces are equal (P = 1 on all the interfaces). This results in the router with the highest router ID (RID) as being elected the designated router. Router_F has the highest RID and is, therefore, the DR. On segment 2, Router_C does not have the highest RID, but it still is elected the DR because its OSPF interface priority, which is 2, is higher than all the rest. The diagram below shows the resulting adjacencies that will be formed on segment 1 of the diagram above. Note that the routers that are not DR will form adjacencies only with the DR. In this illustration, the BDR is not shown, but adjacencies would also be formed with the BDR.
Building Adjacencies After neighbor discovery takes place and bi-directional communication is established (a router sees its own router ID in neighbor hello packet), neighboring routers attempt to
synchronize their link-state databases. When database synchronization in successful, the neighbors are fully adjacent. Neighbors on point-to-point and point-to-multipoint networks always become adjacent unless the parameters of the hello packets are not agreed upon. On broadcast networks and NBMA networks, the DR and BDR become adjacent with all neighbors. No adjacencies will be formed between the DRothers. The following are states through which OSPF routers will transition neighbors before being considered fully adjacent:
Down –— This is the initial state of the neighbor, indicating no information has been received from any router on the segment. Attempt –— On NBMA networks, where neighbors are manually configured, this state indicates that no recent information has been received from the neighbor. An effort is made to contact the neighbor by sending hello packets. Init –— This state indicates that a hello is received from a neighbor; however, bidirectional communication is not yet established. Two-way –— The router has seen itself in the neighbor hello packets. Bidirectional communication is now established. On broadcast networks DR and BDR are elected at the end of this state. When this state ends, a decision is made whether or not to proceed in building an adjacency. The decision is based on whether the neighbor is a DR or BDR or the network link is point-to-point. ExStart –— The router and its neighbor establish a master/slave relationship and determine the initial sequence number that is going to be used in the exchange of database description packets. Exchange –— Routers will describe their entire link-state database by sending database description packet to neighbors that are in the exchange state. Loading –— Routers build a link-state request list and retransmission list. Any information that looks outdated or incomplete will be put on the request list. Any update that has not been acknowledged will be put on the retransmission list. Full –— The adjacency is now complete. Adjacent routers will have identical linkstate databases.
Flooding The OSPF link-state database consists of all the LSAs the router has received. Each node in the network maintains an identical link-state database. A change in the topology means a change in one or more of the LSAs. Flooding is the process by which these new LSAs are sent throughout the network in order to ensure that the databases in all routers remain identical.
Areas Because of its complexity with multiple databases and flooding algorithms, OSPF can be memory and processor intensive. The demand for memory and processor utilization grows as the network grows. OSPF uses areas to reduce the strain on router memory and processor utilization. An area is a logical grouping of routers that break the OSPF network into subdomains. Routers must share identical databases with routers in its area only, not with the entire network. This reduces the memory demand. The smaller database results in a smaller number of LSAs to process, thereby reducing the demand of processing power. Most flooding is also limited within an area. Areas are interface specific and are identified with an area ID. The introduction of areas also introduces a different type of traffic. Intra-area traffic consists of packets that are contained within an area; inter-area packets travel between routers in different areas. External traffic consists of packets that travel between routers belonging to an OSPF domain and another autonomous system. Backbone If more than one area is configured, one of these areas must be defined as area 0. Area 0 is known as the backbone area. All other areas must be logically connected to area 0 either physically or through a virtual-link. Virtual-links are explained below. Each area gives routing information to area 0 which in turn disseminates that information to all other connected areas. For this reason, all inter-area traffic must pass through area 0. Non-backbone areas cannot exchange packets directly with one another. Virtual Links As mentioned above, all other areas must be physically connected to the backbone area, area 0. In some cases where this is not possible, a virtual link can be used. The virtual link will provide a link to the backbone through a nonbackbone area. Virtual links are also used to connect two parts of a partitioned backbone through a nonbackbone area.
As shown in the above diagram, virtual links can be established between two area border routers (ABRs) that have a common area, with one ABR connected to the backbone. The transit area is defined as the area between two ends of a virtual link. The transit area must be connected to area 0 to have full routing information and cannot be a stub area. OSPF classifies virtual links as point-to-point networks with no IP subnets associated with them. Router Types As mentioned above, areas are interface specific, meaning that a router can have one interface configured in one area and a second interface configured in a second area. Therefore, routers can be categorized in relation to areas. There are three types of OSPF routers.
Internal routers (IRs) –— An internal router is a router with all of its interfaces in the same area. Area border routers (ABRs) –— An ABR is a router that has interfaces in multiple areas. An ABR must always have at least one interface in the backbone area. Autonomous system boundary routers (ASBRs) –— ASBRs are routers that act as gateways between OSPF and other routing protocols or other OSPF routing processes. In other words, redistribution takes place on the ASBRs.
All valid LSAs received by a router are stored in a link-state database. These LSAs describe the topology of an area. Routers use the LSAs to calculate the shortest path tree. The list of LSAs in the database can be viewed with the command show ip ospf database. This list shows only the information in the LSA header, but it also contains LSAs from multiple areas if the router were an ABR. More detailed information of each LSA can be viewed with different commands, which will be explained later. An example output of the show ip ospf database command follows: Router_B#show ip ospf database OSPF Router with ID (170.170.3.2) (Process ID 7) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 170.170.3.2 170.170.3.2 17 0x80000002 0x8B6 1 170.170.8.4 170.170.8.4 217 0x80000003 0xAA02 1 170.170.13.3 170.170.13.3 218 0x80000002 0x5156 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.3.3 170.170.13.3 18 0x80000002 0xA0B2 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.7.0 170.170.8.4 240 0x80000001 0x6ED0 Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum 170.170.11.6 170.170.8.4 129 0x80000001 0xF73C Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 200.200.200.0 170.170.11.6 135 0x80000001 0xE4FA 0 Router_B# As can be seen from the information in the database in the above diagram, there are different types of LSAs defined by OSPF. Each type describes a different portion of the OSPF network. The table below lists the different LSA types and type codes and how the link-state is identified. Following the table is a description of the LSAs. Different LSA Types Type Code 1 2 3 4 5 7 LSA Router LSA Network LSA Network summary LSA ASBR summary LSA AS external LSA NSSA external LSA Link-State ID Originating router ID of the router Interface IP address of the DR Destination network number Router ID of AS boundary router External network number External network number
Router LSAs are generated by every router. The router LSA is a list of links attached to the router, as well as the state of the link and the outgoing OSPF cost associated with the link. To view details of the router LSA, use the show ip ospf database router command. Router LSA
Network LSAs are generated by the DR on a multi-access segment. They are the representation of the multi-access segment and all the routers attached to the segment. Segments that do not have a DR, such as point-to-point, will not have a network LSA. To view detailed information of the network LSA, use the show ip ospf database network command. Network LSA
Network summary LSAs are generated by ABRs. This is how network reachability information is advertised. ABRs are responsible for injecting information into the backbone and the backbone will pass the information on to other areas. The show ip ospf database summary command can be used to view detailed information of the summary LSA. Network Summary LSA
ASBR summary LSAs are also generated by the ABR. This LSA describes the location of an ASBR, not a network. The details can be viewed with the show ip ospf database asbr-summary command. ASBR Summary LSA
Autonomous System (AS) External LSAs are originated by the ASBRs and describe a network outside of the AS. They can be viewed with the show ip ospf database external command. AS External LSA
Not-So-Stubby Area (NSSA) external LSAs are originated by the ASBR within the NSSA. These types of LSAs are flooded only throughout the NSSA. These are unlike external LSAs, which are flooded throughout the entire network
Stub Areas ASBR routers will flood external routes throughout the OSPF domain. For this reason, OSPF allows certain areas to be configured as stub areas. Stub areas are areas into which external LSAs are not flooded. Routing from these areas to other parts of the OSPF network is done via the default route. The advantage to using stub areas is that the reduction of the link-state database reduces the requirements for memory. All OSPF routers inside a stub area must be configured as stub routers. Since all interfaces belonging to the area will start exchanging hello packets, the stub flag must be set in order to successfully form a neighbor relationship. Also, virtual links cannot be configured within or transit a stub area. Examples of stub areas and how to configure them will be shown in the "Configuring OSPF" section. Totally Stubby Areas Totally stubby areas are areas into which external LSAs and summary LSAs (inter-area routes) are not flooded. The only thing injected into the totally stubby area are intra-area routes and the default route (0.0.0.0). The default route is the only type 3 (summary) LSA that the ABR will allow into the totally stubby area. An example of totally stubby areas and their configuration is discussed in the "Configuring OSPF" section. Not-So Stubby Areas In some cases, it may be necessary to connect a stub area to an external AS and redistribute the external routes into OSPF. Unfortunately, this means that the stub area router will become an ASBR, meaning the area can no longer be a stub area. NSSAs allow external routers to be advertised into the OSPF AS while retaining the characteristics of a stub area. The ASBR in the NSSA will originate type 7 LSAs. These external NSSA LSAs are flooded throughout the NSSA but are blocked at the ABR. The ABR will translate this into a type 5 LSA and flood it into the other areas. An example of NSSAs and their configuration is discussed in the "Configuring OSPF" section.
OSPF On-Demand Circuits OSPF demand circuit is an enhancement to the OSPF protocol that allows efficient operation over on-demand circuits such as ISDN and dial-up lines. Prior to this feature, periodic hellos and LSA updates would be exchanged between routers that connected the on-demand link, even when there were no changes in the Hello or LSA information. With this feature, periodic Hellos are suppressed and periodic refresh of LSAs are not flooded over demand circuits. These packets bring up the link only when they are exchanged for the first time, or when there is a change in the information they contain.
Enabling OSPF As with other routing protocols, enabling OSPF requires that you: 1. Create an OSPF routing process. 2. Specify the range of IP addresses to be associated with the routing process, and assign area IDs to be associated with that range of IP addresses. Use the following commands, starting in global configuration mode: Step 1. Command router ospf process-id Purpose Enable OSPF routing, placing you in router configuration mode. Define an interface on which OSPF runs and define the area ID for that interface.
2.
network address wildcard-mask area areaid
The OSPF process ID is a numerical value that is local to the router. It does not have to match any process IDs that might be running on other routers. It is possible to run more than one process on the same router. However, this will create multiple databases and cause more overhead on the router. The wildcard mask in the network command allows a user to configure multiple interfaces into the same area with a single configuration line. The wildcard mask is an inverse mask and is used the same as an inverse mask with access lists. The area ID is the area in which the interface(s) will be configured. It can be an integer 0 to 4294967295 or it can take the form of a dotted decimal number such as 0.0.0.0.
Router_D: interface ethernet 0 ip address 170.170.3.4 255.255.255.0 interface serial 0 ip address 170.170.7.4 255.255.255.0 router ospf 7 network 170.170.3.0 0.0.0.255 area 0 network 170.170.7.0 0.0.0.255 area 51 In above example, the router ospf 7 command enables OSPF on Router_D. The first network command enables OSPF on interface Ethernet 0 and puts it in area 0. The second network statement enables OSPF on interface serial 0 and puts it in area 51. Note that network area commands are executed consecutively. The second network area command affects only interfaces that do not match the first command. For example: router ospf 7 network 100.100.0.0 0.0.255.255 area 0 network 100.100.10.0 0.0.0.255 area 2 All interfaces with an IP address of 100.100.x.x will be placed into area 0; therefore, the second network area command is never applied. Configuring OSPF Interface Parameters As mentioned before, OSPF exchanges Hello packets on each OSPF-enabled segment. This is a form of keepalives as well as a method for neighbor discovery and DR/BDR election. The rate at which OSPF sends the hello packets out is called the "Hello Interval." The amount of time an OSPF router will wait for a hello packet before declaring the neighbor down is called the "Dead Interval." OSPF requires that these
intervals be the same between two neighbors; otherwise the two routers will not become OSPF neighbors. Use the following commands to modify these parameters on an interface basis: Command ip ospf hello-interval seconds Purpose Specify the length of time between the hello packets that the Cisco IOS® software sends on an OSPF interface. Set the number of seconds that a device's hello packets must not have been seen before its neighbors declare the OSPF router down.
ip ospf dead-interval seconds
An OSPF interface parameter that plays a very important role in the election of the DR and BDR is the OSPF priority. On a given segment the router with the highest priority will become the DR. If the priorities are the same, the DR will be the router with the highest router ID. To reiterate, the router ID is defined as the highest numerical ip address of the router's interfaces or the highest loopback ip address if it exists at the time that OSPF was configured on the router. If a user wishes a particular router to become the DR or if the user wishes that a particular router not be eligible as a DR/BDR, the following command can be used to modify the OSPF interface priority: Command ip ospf priority number Purpose Set priority to help determine the OSPF-designated router for a network.
If the ospf priority on the interface is set to 0, then the router can never become the DR or BDR for that network segment. The metric that OSPF uses to determine shortest path is called the OSPF cost. This interface parameter can also be modified in order to manipulate routing decisions. The command follows: Command ip ospf cost cost Purpose Explicitly specify the cost of sending a packet on an OSPF interface.
OSPF interface parameters can be viewed with the command show ip ospf interface, as seen in the following example:
Router_D#show ip ospf interface ethernet 0 Ethernet0 is up, line protocol is up Internet Address 170.170.3.4/24, Area 0 Process ID 7, Router ID 170.170.8.4, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 170.170.13.3, Interface address 170.170.3.3 Backup Designated router (ID) 170.170.8.4, Interface address 170.170.3.4 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:08 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 3 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 170.170.3.2 Adjacent with neighbor 170.170.13.3 (Designated Router) Suppress hello for 0 neighbor(s) Router_D# Configuring OSPF over Different Physical Networks As mentioned above, OSPF classifies networks as being broadcast, NBMA, or point-topoint. When configuring OSPF over NBMA networks, special care should be taken. Most NBMA networks, such as Frame Relay, are partially meshed networks and the physical topology does not provide the multi-access connectivity that OSPF assumes is there. The selection of DR becomes a very important issue because the DR and BDR have to have physical connectivity to all the neighboring routers. The neighbor command is used to give the DR/BDR a static list of all other routers attached to the network. This is needed because of the lack of broadcast capabilities. The command follows: Command neighbor ip-address [priority number] [poll-interval seconds] Purpose Configure a router interconnecting to nonbroadcast networks.
In the above command, the IP address and priority are values given to the neighbor. The poll interval is the amount of time a NBMA interface will wait before sending a hello to a presumably dead neighbor.
Note that after the release of Cisco IOS 10.0, the neighbor command is not necessary. There are other ways of running OSPF over NBMA networks that are much more efficient. Point-to-Point Subinterfaces The use of subinterfaces is a way to split a physical interface into multiple logical interfaces. Each subinterface can be defined as point-to-point. A point-to-point subinterface has the properties of any physical point-to-point interface. As far as OSPF is concerned, an adjacency is always formed over a point-to-point network without electing a DR or BDR. One drawback of point-to-point subinterfaces is that each point-to-point segment requires its own subnet. The following is an example of configuring point-to-point subinterfaces with OSPF. In the topology below, the serial 2 interface of Router_F can be logically split into two point-to-point subinterfaces. Each subinterface is assigned an address out of a unique subnet. Router_G and Router_H also have a subinterface configured.
Excerpts from the configurations for Router_F and Router_G follow: Router_F: interface Serial2 no ip address encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial2.7 point-to-point ip address 170.170.11.6 255.255.255.0 frame-relay interface-dlci 101 ! interface Serial2.8 point-to-point ip address 170.170.10.6 255.255.255.0 frame-relay interface-dlci 103 router ospf 7
network 170.170.11.0 0.0.0.255 area 0 network 170.170.10.0 0.0.0.255 area 0 Router_G: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.6 point-to-point ip address 170.170.11.7 255.255.255.0 frame-relay interface-dlci 110 router ospf 7 network 170.170.11.0 0.0.0.255 area 0 Selecting Interface Network Types The following command can be used to define the network type of an OSPF interface: Command ip ospf network {broadcast | nonbroadcast | {point-to-multipoint [nonbroadcast] }} Purpose Configure the OSPF network type for a specified interface.
Each network type that can be configured with the above command will be explained below. Point-to-Multipoint Interfaces A point-to-multipoint interface is defined as a numbered point-to-point interface that has multiple neighbors. Users do not have to worry about having a subnet for each point-topoint link, and the "NBMA cloud" could be configured as one subnet. Since the links are still considered point-to-point, the user would not have to worry about the election of DR and BDR. Point-to-multipoint exchanges additional link-state updates that contain descriptions of the connectivity to the neighboring routers, resulting in host routes for all the neighbors. An example of how point-to-multipoint is configured follows:
Following are excerpts from the configurations of Router_E and Router_G in the above topology. Router_E: interface Serial1 ip address 170.170.9.5 255.255.255.0 no ip mroute-cache encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 170.170.9.7 121 broadcast frame-relay map ip 170.170.9.8 123 broadcast router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Router_G: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.5 multipoint ip address 170.170.9.7 255.255.255.0 ip ospf network point-to-multipoint frame-relay map ip 170.170.9.5 112 broadcast router ospf 7 network 170.170.9.0 0.0.0.255 area 0 As mentioned earlier, when point-to-multipoint interfaces are configured, host routes are generated for all the neighbors. This can be seen in the output from a show ip route on Router_E: Router_E#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR Gateway of last resort is not set 170.170.0.0/16 is variably subnetted, 5 subnets, 2 masks O 170.170.9.8/32 [110/64] via 170.170.9.8, 00:07:01, Serial1 C 170.170.9.0/24 is directly connected, Serial1 O 170.170.9.7/32 [110/64] via 170.170.9.7, 00:07:01, Serial1 Router_E# Because of these host routes, Router_G will not need a Frame Relay map statement for Router_H, and Router_H will not need one for Router_G. Also note there is not a DR or BDR elected on a point-to-multipoint interface: Router_E#show ip ospf interface serial 1 Serial1 is up, line protocol is up Internet Address 170.170.9.5/24, Area 0 Process ID 7, Router ID 170.170.9.5, Network Type POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:04 Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 170.170.12.8 Adjacent with neighbor 170.170.12.7 Suppress hello for 0 neighbor(s) Router_E# Broadcast Interfaces Setting the interface type to broadcast will logically set the interface to be a broadcast interface, and it will behave as if the router were connected to a LAN or broadcast network. DR and BDR election will take place, so if there is not a full mesh topology, care must be taken about which router will become the DR. Use of the OSPF priority command should be considered if necessary. The following is an example configuration for broadcast interfaces:
Router_E configuration: interface Serial1 ip address 170.170.9.5 255.255.255.0 no ip mroute-cache encapsulation frame-relay ip ospf network broadcast ip ospf priority 5 frame-relay map ip 170.170.9.7 121 broadcast frame-relay map ip 170.170.9.8 123 broadcast ! router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Router_G configuration: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.5 multipoint ip address 170.170.9.7 255.255.255.0 ip ospf network broadcast frame-relay map ip 170.170.9.5 112 broadcast ! router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Router_H configuration: interface Serial0 no ip address encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.5 multipoint ip address 170.170.9.8 255.255.255.0
ip ospf network broadcast frame-relay map ip 170.170.9.5 132 broadcast ! router ospf 7 network 170.170.9.0 0.0.0.255 area 0 Note that in the configuration of Router_E, the interface OSPF priority was set to 5 (default is 1). This was because Router_E is the common router in the network; therefore, this should be the DR. Setting the priority to 5 while the others stayed at default 1 results in Router_E becoming the DR, as can be seen with the show ip ospf interface serial 1 command: Router_E#sh ip ospf interface serial 1 Serial1 is up, line protocol is up Internet Address 170.170.9.5/24, Area 0 Process ID 7, Router ID 170.170.9.5, Network Type BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 5 Designated Router (ID) 170.170.9.5, Interface address 170.170.9.5 Backup Designated router (ID) 170.170.12.8, Interface address 170.170.9.8 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:05 Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 170.170.12.8 (Backup Designated Router) Adjacent with neighbor 170.170.12.7 Suppress hello for 0 neighbor(s) Router_E# It can also be seen that Router_H is the BDR from the output above. This may not be desirable since Router_H and Router_G do not have Frame Relay link between them. Router_G and Router_H could be prevented from becoming either DR or BDR by setting their interface priority to zero. Configuring Route Summarization Address summarization can help to conserve resources within the backbone area. Summarizing is the consolidation of multiple routes into one single advertisement. This is done at the ABRs or ASBRs summarizing into the direction of the backbone. This way, the backbone will receive the aggregate addresses and will inject the summarized route into other areas. Two types of summarization can be configured for OSPF:
Inter-area route summarization External route summarization
Inter-area route summarization is done on ABRs and accounts for only routes within the OSPF domain. It does not account for external routes. The router subcommand for inter-area summarization follows: Command area area-id range address mask Purpose Specify an address range for which a single route will be advertised.
In the above command, area-id is the area containing the networks to be summarized.
In the above topology, Area 51 contains networks 172.16.128.0/24 through 172.16.159.0/24. Router_B can summarize these subnets into a single route with the area range command as follows: router ospf 7 network 170.170.1.0 0.0.0.255 area 51 network 170.170.3.0 0.0.0.255 area 0 area 1 range 172.16.128.0 255.255.224.0 External route summarization is done on the ASBRs that are injecting the external routes. The router subcommand for external route summarization follows: Command summary-address address mask Purpose Specify an address and mask that covers redistributed routes, so only one summary route is advertised.
In the above topology, Router_A is redistributing several routes into OSPF: routes 172.16.128.0/24 – 172.16.159.0/24. Since these are external OSPF routes, they cannot be summarized with the area range command. To summarize external routes, use the summary-address command as shown in the example below. The summarization should take place in the ASBR; in this case, Router_A will do the summarization: router ospf 7 summary-address 172.16.128.0 255.255.224.0 redistribute static subnets network 170.170.1.0 0.0.0.255 area 51 Configuring Stub Areas and Totally Stubby Areas As mentioned previously, stub areas are areas into which external LSAs are not flooded. Routing to these areas to the external networks is done based on the default route. An extension to stub areas is totally stubby areas. A totally stubby area is an area that blocks external routes and summary routes (inter-area routes) from being flooded. Only intra-area routes and the default route are injected into the area. The router subcommand that configures an area as a stub follows: Command area area-id stub [no-summary] Purpose Define an area to be a stub area.
The keyword no-summary in the above command defines the area as a totally stubby area. If the keyword is not used, the area is just a stub area.
In the topology above, Router_A is redistributing routes 172.16.128.0/24– 172.16.159.0/24 into OSPF. If we configured area 1 as a stub area, routers in area 1 would not learn about these networks. Instead, routers in area 1 would get a default route. The configurations of Router_D and Router_F, for the topology above, are shown below: Router_D: router ospf 7 network 170.170.3.0 0.0.0.255 area 0 network 170.170.7.0 0.0.0.255 area 1 area 1 stub Router_F: router ospf 7 network 170.170.7.0 0.0.0.255 area 1 area 1 stub The following is a show ip route from Router_F; note that a default route has been injected, but the external routes are not in the routing table. Router_F#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR
Gateway of last resort is 170.170.7.4 to network 0.0.0.0 170.170.0.0/24 is subnetted, 3 subnets O IA 170.170.1.0 [110/138] via 170.170.7.4, 00:02:42, Serial0 O IA 170.170.3.0 [110/74] via 170.170.7.4, 00:02:42, Serial0 C 170.170.7.0 is directly connected, Serial0 O*IA 0.0.0.0/0 [110/65] via 170.170.7.4, 00:02:42, Serial0 Router_F# To make area 1 totally stubby, add the no-summary keyword to the area stub command as follows: Router_D: router ospf 7 network 170.170.3.0 0.0.0.255 area 0 network 170.170.7.0 0.0.0.255 area 1 area 1 stub no-summary Router_F: router ospf 7 network 170.170.7.0 0.0.0.255 area 1 area 1 stub no-summary This results in the following routing table for Router_F: Router_F#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR Gateway of last resort is 170.170.7.4 to network 0.0.0.0 170.170.0.0/24 is subnetted, 1 subnets C 170.170.7.0 is directly connected, Serial0 O*IA 0.0.0.0/0 [110/65] via 170.170.7.4, 00:00:00, Serial0 Router_F# Configuring Not-So Stubby Areas As mentioned before, it is sometimes necessary to redistribute external information into a stub area. This is possible with the NSSA. To configure NSSA, the following router subcommand is used:
Command area area-id nssa [no-redistribution] [default-information-originate]
Purpose Define an area to be NSSA.
In the above topology, area 51 is an NSSA area. Router_A is redistributing static routes into area 51. Router_A should send them to Router_B as type 7 LSAs and Router_B should translate the type 7 LSAs into type 5 LSAs and flood them to the rest of the network. The configurations for Router_A and Router_B are as follows: Router_A: router ospf 7 redistribute static subnets network 170.170.1.0 0.0.0.255 area area 51 nssa ! ip route 172.16.128.0 255.255.255.0 ip route 172.16.129.0 255.255.255.0 ip route 172.16.130.0 255.255.255.0 Router_B: router ospf 7 network 170.170.1.0 0.0.0.255 area 51 network 170.170.3.0 0.0.0.255 area 0 area 51 nssa If we take a look at the routing table of Router_B, we will see the type 7 NSSA routes: Router_B# sh ip route
51 Serial1 Serial1 Serial1
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default U - per-user static route, o - ODR, P - periodic downloaded static route T - traffic engineered route Gateway of last resort is not set 170.170.0.0/24 is subnetted, 3 subnets C 170.170.1.0 is directly connected, Serial0 C 170.170.3.0 is directly connected, Ethernet0 O IA 170.170.7.0 [110/74] via 170.170.3.4, Ethernet0 172.16.0.0/24 is subnetted, 3 subnets O N2 172.16.128.0 [110/20] via 170.170.1.1, Serial0 O N2 172.16.129.0 [110/20] via 170.170.1.1, Serial0 O N2 172.16.130.0 [110/20] via 170.170.1.1, Serial0 Router_B# The OSPF database of Router_B shows that there are also type 5 LSAs. Router_B#show ip ospf database OSPF Router with ID (170.170.3.2) (Process ID 7) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 170.170.3.2 170.170.3.2 1395 0x8000002A 0xB6DD 1 170.170.8.4 170.170.8.4 973 0x80000029 0x5433 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.3.2 170.170.3.2 1773 0x80000027 0x2281 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 170.170.1.0 170.170.3.2 1773 0x80000027 0x9392 170.170.7.0 170.170.8.4 974 0x80000027 0x22F6 Router Link States (Area 51) Link ID ADV Router Age Seq# Checksum Link count 170.170.3.2 170.170.3.2 1378 0x8000002A 0x5F4C 2 170.170.13.1 170.170.13.1 1381 0x80000038 0x3D59 2 Summary Net Link States (Area 51) Link ID ADV Router Age Seq# Checksum 170.170.3.0 170.170.3.2 1398 0x8000002A 0xFE52 170.170.7.0 170.170.3.2 1398 0x80000028 0x59B5 Type-7 AS External Link States (Area 51)
Link ID ADV Router Age Seq# Checksum Tag 172.16.128.0 170.170.13.1 124 0x80000002 172.16.129.0 170.170.13.1 125 0x80000002 172.16.130.0 170.170.13.1 125 0x80000002 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 172.16.128.0 170.170.3.2 1367 0x80000001 172.16.129.0 170.170.3.2 1367 0x80000001 172.16.130.0 170.170.3.2 1367 0x80000001 Router_B#
0xFF9D 0 0xF4A7 0 0xE9B1 0 0xD6DA 0 0xCBE4 0 0xC0EE 0
Router_D and Router_F would see only the type 5 LSAs. Configuring OSPF On-Demand Circuits To allow efficient operation of OSPF over on-demand circuits such as ISDN or dial-up lines, OSPF can be configured for on-demand circuits. The following interface subcommand is used for this: Command ip ospf demand-circuit Purpose Configure OSPF on an on-demand circuit.
External routes are to destinations outside of the OSPF AS. When an external route is redistributed into OSPF, it must be assigned a metric that is compatible with OSPF. This is the responsibility of the ASBR, which can assign an OSPF metric to the external route. The ASBR is also responsible for categorizing the external route as either external type 1 (E1) or external type 2 (E2). The difference between the two is the way the metric of the route is calculated when determining shortest path. The cost of a an E2 route is always the external cost, irrespective of the internal cost. The cost of an E1 route is the sum of the internal and external costs. E1 routes are always preferred over E2 routes.
In the above topology, if the two ASBRs (Router_F and Router_C) are injecting external route 10.10.10.0/24 as E1 routes, Router_E would see the cost to 10.10.10.0/24 as 20 (5 + 10 + 5) through Router_C. The E1 cost through Router_F, as seen by Router_E, would be 30 (20 + 5 + 5). Therefore, the path through Router_C would be preferred. If the ASBRs were injecting the route as E2 routes, the Router_E cost to the network through Router_C would be 15 (10 + 5). The Router_E cost to the network through Router_F would be 10 (5 + 5). Therefore, the path through Router_F would be preferred.
If the external costs to the destination network are equal as in the above topology, and the external routes are injected as E2 routes, then the path selected as the best path would be the path with the lowest cost to the ASBR. In the above topology the external costs are equal (10), so Router_E will select the path through Router_C because its cost through Router_C is 5, versus the cost to Router_F, which is 20.
The command for redistributing external routes into OSPF is as follows: Command redistribute protocol [process-id] [metric metric-value] [metric-type typevalue] [subnets] Purpose This command redistributes routes from one routing domain into OSPF.
Originating Default Routes An ASBR does not, by default, advertise a default route into an OSPF domain. It can be forced to with the following command: Command default-information originate [always] [metric metric-value] [metric-type typevalue] [route-map map-name] Purpose Force the AS boundary router to generate a default route into the OSPF routing domain.
The "always" keyword will force the ASBR to advertise a default route, whether or not it has a default route in its routing table. Without the "always" keyword the ASBR will advertise a default route only if it has one. The "metric" and "metric-type" are the cost and type (E1/E2) assigned to the default route. The "route-map" can specify a set of conditions that need to be met before the default route will be advertised.
Access lists can be used for many purposes, such as:
Controlling transmission of packets on an interface Controlling virtual terminal access Restricting contents of routing updates Determining if an address should be translated when using Network Address Translation
Access lists are specified by either a name or a number. Prior to Cisco IOS® Version 11.2, access lists could be specified only by number. The following table lists protocols that can use access lists specified by names. Protocols with Access Lists Specified by Names
Protocol Apollo Domain IP Extended IP ISO CLNS Source-Route Bridging NetBIOS NetBIOS IPX The following table lists protocols that use access lists specified by numbers. It also includes the range of access-list numbers that is valid for each protocol. Protocols with Access Lists Specified by numbers Protocol IP Extended IP Ethernet Type Code Ethernet Address Transparent Bridging (protocol type) Transparent Bridging (vendor code) Extended Transparent Bridging DECnet and Extended DECnet XNS Extended XNS AppleTalk Range 1 to 99 100 to 199 200 to 299 700 to 799 200 to 299 700 to 799 1100 to 1199 300 to 399 400 to 499 500 to 599 600 to 699
Source-Route Bridging (protocol type) Source-Route Bridging (vendor code) IPX Extended IPX IPX SAP Standard VINES Extended VINES Simple VINES Standard IP (expanded) Extended IP (expanded)
200 to 299 700 to 799 800 to 899 900 to 999 1000 to 1099 1 to 100 101 to 200 201 to 300 1300 to 1999 2000 to 2099
As of Cisco IOS Version 12.0, IP access lists have been expanded. The table above shows that Standard and Extended IP access lists have been expanded with numbers 1300 to 2099. An access list is a sequential collection of permit and deny criteria that are checked against IP packets. The Cisco IOS software checks the IP packets against each accesslist criterion one by one. The first match determines if the packet is accepted (permitted) or rejected (denied). Once the first match has been made, the Cisco IOS software stops checking for any more matches in the access list. For this reason, the order of the access-list criteria is very important. If no match is found, the packet is implicitly rejected. Another important fact to remember is that at the end of every access list is an implicit deny all. The Cisco IOS software supports the following types of access lists for IP: 1. 2. 3. 4. 5. Standard IP Extended IP Time based Dynamic extended Reflexive
Standard IP access lists use the source IP address for matching criteria.
Extended IP access lists use the source IP address and destination IP address for matching criteria. These lists also use optional protocol-type information for more granularity. As of Cisco IOS Version 12.0T, it is possible to implement access lists based on the time of day. These access lists are known as time-based access lists. Both standard IP and extended IP access lists can be time based. Dynamic extended IP access lists grant user access per user on a specific source or destination host basis through a user-authentication process. Dynamic access lists are a security feature that will not be discussed in this module. Reflexive access lists allow IP packets to be filtered based on session information. Reflexive access lists contain temporary entries and are nested within an extended, named IP access list.
Standard Access Lists To create a standard access list, use one of the following commands in the global configuration mode. Command access-list access_list_# {deny|permit} source [source_wildcard] [log] access-list access_list_# {deny|permit} any [log] Purpose Define a standard IP access list using a source IP address and wildcard mask.
Define a standard IP access list using an abbreviation for the source and source mask of 0.0.0.0 255.255.255.255
The wildcard mask is essentially the inverse of the regular mask. For example, if we wanted to permit any IP packets that are sourced from subnet 172.16.10.0 255.255.255.0, we could create the following access list: access-list 1 permit 172.16.10.0 0.0.0.255 Notice that the wildcard mask in the access list is the inverse of the mask for the subnet. In a wildcard mask, the "zero" bits are important and the "one" bits are ignored. In the above access list, any IP packet sourced from 172.16.10.x would match the access list and, therefore, be permitted.
A packet sourced from any other source would be denied, because of the implicit "deny all" at the end of the access list. If we wanted to permit only IP packets sourced from the specific host address 172.16.10.177 255.255.255.255, the access list would look like this: access list 1 permit 172.16.10.177 0.0.0.0 Note: If you omit the wildcard mask from an associated IP host address in an access list, 0.0.0.0 is assumed to be the mask. The log keyword at the end of the command allows the Cisco IOS software to provide logging messages about packets that are permitted or denied by a standard access list. The first packet that matches the access list will cause an informational console message to appear immediately. Subsequent packets are collected over five-minute intervals before they are displayed or logged. Extended Access Lists To create an extended IP access list, use one of the following commands in the global configuration mode: Command access-list access_list_# {deny|permit} protocol source source_wildcard destination destination_wildcard [precedence precedence] [tos tos] [established] [log] access-list access_list_# {deny|permit} protocol any any Purpose Define an extended IP access list number and the access conditions. Use the log keyword to get access list logging messages, including violations.
Define an extended IP access list using an abbreviation for a source and source wildcard of 0.0.0.0 255.255.255.255, and an abbreviation for a destination and destination wildcard of 0.0.0.0 255.255.255.255. Define an extended IP access list using an abbreviation for a source and source wildcard of source 0.0.0.0, and an abbreviation for a destination and destination wildcard of destination 0.0.0.0.
access-list access_list_# {deny|permit} protocol host source host destination
Imagine that we need an extended access list meeting the following requirements:
Allow IP packets sourced from a host with address 172.16.10.1 destined for subnet 170.170.10.0 255.255.255.0. Deny any other IP packets that are destined for the same destination subnet of 170.170.10.0. Permit all other IP packets.
One access list that meets these requirements follows: access-list 101 permit ip 172.16.10.1 0.0.0.0 170.170.10.0 0.0.0.255 access-list 101 deny ip 0.0.0.0 255.255.255.255 170.170.10.0 0.0.0.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Another follows: access-list 103 permit ip host 172.16.10.1 170.170.10.0 0.0.0.255 access-list 103 deny ip any 170.170.10.0 0.0.0.255 access-list 103 permit ip any any Access list 101 and access list 103 accomplish the same thing. Access list 103 uses the "host" abbreviation for the 0.0.0.0 wildcard mask and the "any" abbreviation for 0.0.0.0 255.255.255.255. Now that we have learned how to create standard and extended access lists, it is important to mention that after an access list is initially created, any lines later added to the access list are placed at the end of the list. Also, access-list command lines cannot be removed selectively; in order to change one line of the access list, the entire access list must be removed and reconfigured. After creating the access list, it must be applied for some purpose. We will discuss some of these purposes later.
IP access lists can be identified with an alphanumeric string (a name) rather than with a number (1 to 199). This setup allows a user to configure more than 99 standard IP access list and 100 extended IP access lists. When configuring IP named access lists, keep the following in mind:
Access lists specified by name are not compatible with releases of the Cisco IOS software older than Version 11.2. Not all applications for access lists will accept a named IP access list, though access lists for packet filters and route filters on interfaces can be named. A standard access list and an extended access list cannot have the same name.
Standard Named IP Access Lists To create a standard named IP access list, complete the following steps: Step 1. Command ip access-list standard name deny {source [source_wildcard]|any}[log] or permit {source [source_wildcard]|any}[log] 3. exit Exit access-list configuration mode. Purpose Define a standard IP access list using a name. In access-list configuration mode, specify one or more conditions allowed or denied to determine whether the packet is passed or dropped.
2.
For example, if we wanted to permit any IP packets that are sourced from subnet 172.16.10.0 255.255.255.0, we could create the following access list: ip access-list standard test permit 172.16.10.0 0.0.0.255 Notice that the use of the wildcard mask is still the same. Extended Named IP Access Lists To create an extended named IP access list, complete the following steps: Step 1. Command ip access-list extended name Purpose Define an extended IP access list using a name. In access-list configuration
2.
{deny | permit} protocol source
source_wildcard destination destination_wildcard [precedence precedence] [tos tos] [established] [log]
mode, specify the conditions allowed or denied. Use the log keyword to get access-list logging messages, including violations. or
or {deny | permit} protocol any any Define an extended IP access list using an abbreviation for a source and a source wildcard of 0.0.0.0 255.255.255.255, and an abbreviation for a destination and a destination wildcard of 0.0.0.0 255.255.255.255. or Define an extended IP access list using an abbreviation for a source and a source wildcard of source 0.0.0.0, and an abbreviation for a destination and a destination wildcard of destination 0.0.0.0. 3. exit Exit access-list configuration mode.
or {deny | permit} protocol host source host destination
Imagine that we need an extended access list meeting the following requirements:
Allow IP packets sourced from a host with address 172.16.10.1 destined for subnet 170.170.10.0 255.255.255.0. Deny any other IP packets that have the same subnet, 170.170.10.0, in the destination portion of the packet. Permit all other IP packets.
One access list that meets these requirements follows: ip access-list extended test permit ip 172.16.10.1 0.0.0.0 170.170.10.0 0.0.0.255 deny ip 0.0.0.0 255.255.255.255 170.170.10.0 0.0.0.255 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
Another follows: ip access-list extended test permit ip host 172.16.10.1 170.170.10.0 0.0.0.255 deny ip any 170.170.10.0 0.0.0.255 permit ip any any
As of Cisco IOS Version 12.0T, it is possible to implement access lists based on the time of day. To do so, you create a time range that defines specific times of the day and week. The time range is identified by a name and then referenced by an access-list function, so that those time restrictions are imposed on the function itself. Currently, IP and Internetwork Packet Exchange (IPX) extended access lists are the only functions that can use time ranges. The time range allows the network administrator to define when the permit or deny statements in the access list are in effect. Prior to this feature, access-list statements were always in effect once they were applied. Both named or numbered access lists can reference a time range. Note: The time range relies on the system clock of the router. For this feature to work as intended, you need a reliable clock source. It is recommended that you use Network Time Protocol (NTP) to synchronize the router clock. Creating a time-based access list requires two steps: 1. Define a time range. 2. Reference the time range with an access-list function. To define a time range, complete the following steps: Step 1. Command time-range time-range-name Purpose Identify the time range by a meaningful name. In time-range configuration mode, specify when the function it will be applied to will be in effect. Specify some combination of these commands; multiple periodic statements are allowed; only one absolute statement is allowed.
2.
absolute [start time date] [end time date] and/or periodic days-of-the-week hh:mm to [days-of-the-week] hh:mm
Repeat these tasks if you have multiple items you want in effect at different times. For example, repeat the steps to include multiple permit or deny statements in an access list in effect at different times. To reference the time range with an access-list function, the keyword "time-range" has been added to the access-list command. The following steps show the named accesslist command with the new keyword: Step 1. Command ip access-list extended name Purpose Define an extended IP access list using a name. In access-list configuration mode, specify the conditions allowed or denied. Use the log keyword to get access-list logging messages, including violations. Specify a time range to restrict when the permit or deny statement is in effect. or Define an extended IP access list using an abbreviation for a source and source wildcard of 0.0.0.0 255.255.255.255, and an abbreviation for a destination and destination wildcard of 0.0.0.0 255.255.255.255. or {deny | permit} protocol host source host destination [log] [time-range time-rangename] Define an extended IP access list using an abbreviation for a source and source wildcard of source 0.0.0.0, and an abbreviation for a destination and destination wildcard of destination 0.0.0.0. or Define a dynamic access list. dynamic dynamic-name [timeout minutes] {deny | permit} protocol source source-wildcard destination destination-wildcard
2.
{deny|permit} protocol source source-wildcard destination destinationwildcard [precedence precedence] [tos tos] [established][log] [timerange time-range-name]
{deny | permit} protocol any any [log] [time-range timerange-name]
[precedence precedence] [tos tos] [established] [log] [time-range time-rangename]
For information about Lock and Key access, refer to the Configuring Lock-andKey Security (Dynamic Access Lists) chapter in the Security Configuration Guide.
For example, if we wanted to create a time-based access list that will deny Hypertext Transfer Protocol (HTTP) traffic on Monday through Friday between the hours of 8:00 a.m. and 6:00 p.m. on IP, and will allow User Datagram Protocol (UDP) traffic on Saturday and Sunday from noon to 8:00 p.m. only, we could create the following time ranges and access list: time-range no-http periodic weekdays 8:00 to 18:00 ! time-range udp-yes periodic weekend 12:00 to 20:00 ! ip access-list extended strict deny tcp any any eq http time-range no-http permit udp any any time-range udp-yes ! interface ethernet 0 ip access-group strict in
As of Cisco IOS Version 12.0(2)T, you can now include comments (remarks) about entries in any IP access list. The remarks make the access list easier for the network administrator to understand. Each remark is limited to 100 characters. Remarks about entries in an IP access list make the list easier to understand and scan. For example, it is not immediately clear what the purpose of the following entry is: access-list 1 permit 171.69.2.88 It is much easier to read a remark about the entry to understand its effect, as follows: access-list 1 remark Permit only Tom Jones workstation through access-list 1 permit 171.69.2.88
To write a comment about an entry in a named IP access list, use the following commands in the order shown. Step 1 is performed once; Step 2 can be performed multiple times in the access list, before or after any permit or deny command. Step 1. Command Router(config)# ip access-list standard name or Router(config)# ip access-list extended name 2. Router(config-std-nacl)# remark remark or Router(config-ext-nacl)# remark remark To write a comment about an entry in a numbered IP access list, use the following command before or after any access-list permit or access-list deny command: Command Router(config)# access-list access-listnumber remark Examples In the following example of a numbered access list, the workstation belonging to Jones is allowed access and the workstation belonging to Smith is not allowed access: access-list access-list access-list access-list 1 1 1 1 remark Permit only Jones workstation through permit 171.69.2.88 remark Do not allow Smith workstation through deny 171.69.3.13 Purpose Indicates the purpose of the permit or deny statement Indicates the purpose of the permit or deny statement Purpose Identifies the access list by name
In the following example of a numbered access list, the Winter and Smith workstations are not allowed to browse the Web:
access-list access-list access-list access-list
100 100 100 100
remark Do deny host remark Do deny host
not allow Winter to browse the web 171.69.3.85 any eq http not allow Smith to browse the web 171.69.3.13 any eq http
In the following example of a named access list, the Jones subnet is not allowed access: ip access-list standard prevention remark Do not allow Jones subnet through deny 171.69.0.0 0.0.255.255 In the following example of a named access list, the Jones host is not allowed to use outbound Telnet: ip access-list extended telnetting remark Do not allow Jones subnet to telnet out deny tcp host 171.69.2.88 any eq telnet
As mentioned before, access lists are used for a variety of purposes. Some examples follow: Note: The ip access-group command is used to apply the access list to an interface. It can be applied outbound or inbound, a scenario that is explained later. Filtering IP Packets on Router Interfaces with Standard Numbered Access Lists Network 137.77.0.0 is a Class B network that is directly connected to the Ethernet0 interface of a router. The network is subnetted to several subnets using the subnet mask 255.255.255.0. We want to filter any packets sourced from subnet 137.77.13.0, with the exception of host 137.77.13.7, from being allowed to pass through this particular router. We want all other packets sourced from 137.77.0.0 to be allowed through the router. This scenario can be accomplished with the following standard numbered access list: access-list 7 permit host 137.77.13.7 access-list 7 deny 137.77.13.0 0.0.0.255 access-list 7 permit 137.77.0.0 0.0.255.255 Note: All other packets are implicitly denied. The ip access-group command is used to apply the access list to an interface as follows:
interface ethernet 0 ip address 137.77.10.1 255.255.255.0 ip access-group 7 in Filtering IP Packets on Router Interfaces with Standard Named Access Lists The following commands accomplish the same thing with a standard named access list: IP access-list standard keepout permit host 137.77.13.7 deny 137.77.13.0 0.0.0.255 permit 137.77.0.0 0.0.255.255 interface e 0 ip address 137.77.10.1 255.255.255.0 ip access-group keepout in Filtering IP Packets on Router Interfaces with Extended Access Lists Suppose a router is connected to an "internal" Ethernet network and also has a link to the Internet via its serial 0 interface. The internal Ethernet network is the Class B network 131.108.0.0. You want to allow Internet Control Message Protocol (ICMP) messages in from the Internet to the Ethernet network for error-reporting purposes. You also want to allow TCP packets in from the Internet if they are destined to the Simple Mail Transport Protocol (SMTP) port of host 131.108.15.1 or if they are destined to ports greater that 1023 (this setup will allow TCP packets that are in response to connections generated from the internal network). This setup can be accomplished with the following extended access list: access-list 177 permit tcp 0.0.0.0 255.255.255.255 131.108.0.0 0.0.255.255 gt 1023 access-list 177 permit tcp 0.0.0.0 255.255.255.255 131.108.15.1 0.0.0.0 eq 25 access-list 177 permit icmp 0.0.0.0 255.255.255.255 131.108.0.0 0.0.255.255 interface s 0 ip address 207.200.115.6 255.255.255.252 ip access-group 177 in This access list could also be written as: access-list 177 permit tcp any 131.108.0.0 0.0.255.255 gt 1023 access-list 177 permit tcp any host 131.108.15.1 eq smtp access-list 177 permit icmp any 131.108.0.0 0.0.255.255 We could also accomplish the same thing with the following standard named access list:
ip access-list extended filter-in permit tcp any 131.108.0.0 0.0.255.255 gt 1023 permit tcp any host 131.108.15.1 eq smtp permit icmp any 131.108.0.0 0.0.255.255 interface s 0 ip address 207.200.115.6 255.255.255.252 ip access-group filter-in in Inbound Versus Outbound Access Lists The following topology will be used to describe the difference between inbound and outbound access lists. This comparison is specific to using access lists as packet filters on an interface.
If we want to protect Router_A, Router_B, and Router_D from devices in the cloud, we might want to deny Telnet packets from the cloud. An access list like the following would do the trick: Access-list 177 deny tcp any any eq telnet - this denies telnet packet from any source to any destination. The best router to apply this access list on would be Router_D, but should we apply it inbound on the serial interface or outbound on the Ethernet interfaces? If we apply it outbound on the Ethernet interfaces, if Router_D receives a Telnet packet destined for the Ethernet 1 port (187.187.1.1) of Router_A, Router_D will receive the packet and make a routing decision based on the destination address of the packet. The router decides the destination is out the Ethernet 1 interface. Ethernet 1 has an outbound access list, which denies the packet. The packet is discarded and an ICMP message is sent back to the source of the packet. In other words, in the case of an outbound access list, the access list gets checked after the router has made a routing decision.
In this scenario, if Router_D receives a Telnet packet destined for its own serial interface, it will recognize the packet as being destined for itself and accept the packet without checking the access list. However, if the access list is applied inbound on the serial interface of Router_D, a Telnet packet destined for Router_D will be dropped before Router_D has a chance to recognize it as being destined for itself. In other words, in the case of an inbound access list, the access list gets checked before the router makes any routing decisions about the packet. Note: Whether a standard access list is applied inbound or outbound, the router will always check the access list against the source of the packet. In the case of an extended access list, the router will always check the access list against the source, destination, and protocol of the packet. Controlling Content of Routing Updates Access lists can be used for controlling content of routing updates. The distribute-list command is used to apply the access list in this manner. Using Access Lists to Control the Content of Routing Updates Suppose we have two routers exchanging Routing Information Protocol (RIP) routing updates via their serial 0 interfaces. The serial network is on the 131.108.0.0 network. Router_A is learning about a private network 10.0.0.0 from a source off its Ethernet 0 interface. The network administrator does not want Router_B to learn about network 10.0.0.0. This setup can be accomplished by using the distribute-list command. The distribute list could be applied either outbound on Router_A, or inbound on Router_B. In either case the distribute list would utilize the same access list. Configuration on Router_A: router rip network 10.0.0.0 network 131.108.10.0 distribute list 7 out serial 0 access-list 7 deny 10.0.0.0 0.255.255.255 access-list 7 permit any Before Router_A sends a RIP update out serial 0, it will check to see what networks are permitted by the distribute list and include only those networks that are allowed by access list 7. Configuration on Router_B:
router rip network 131.108.0.0 distribute-list 7 in serial 0 access-list 7 deny 10.0.0.0 0.255.255.255 access-list 7 permit any Determining what Address Will Get Translated when Using Dynamic NAT Access lists are also used for Network Address Translation (NAT). They are used to determine what addresses will be translated. Using Access Lists to Determine Which Address Will Be Translated Suppose we have a router connected to private network 10.0.0.0 via its Ethernet 0 interface. It is also connected to the Internet via its serial 0 interface. The network administrator would like to configure NAT so that any user off subnet 10.10.10.0 will get translated to a legal address of 201.201.201.10 and be able to reach the Internet. The following configuration accomplishes this scenario: ip nat pool internet 201.201.201.10 201.201.201.10 netmask 255.255.255.0 ip nat inside source list 7 pool internet overload interface e 0 ip address 10.1.1.1 255.255.255.0 ip nat inside interface s 0 ip address 201.201.201.5 255.255.255.252 ip nat outside access-list 7 permit 10.10.10.0 0.0.0.255 With the above configuration, when the router receives a packet on Ethernet 0 destined for the Internet (out serial 0), it will check the source address of the packet against access list 7. If access list 7 allows the address, NAT will take place and the packet will be forwarded to the Internet.
