Link State Protocols

Link State Protocols work differently than distance-vector protocols. Where a distance-vector protocol periodically sends out its entire routing table to neighboring routers, a link state protocol instead builds a topology database that give it perspective on finding the best or “shortest” loop-free path to other networks. A link state protocol will usually build 3 databases. The first database is known as the neighbor or adjacency database, and keeps track of other routers on directly connected networks. The second database is the link state or “topology” database. This database keeps track of the “state” of the links on other routers on the network. Link state routers periodically send out what are known as “hello” messages, which are sent to neighboring routers as a type of keepalive message. An OSPF router will also periodically send out link state advertisements (LSAs), which are flooded across an internetwork. These messages contain information on the router’s active links, its IP address, subnet mask, and the routers it knows about. The information stored in the topology database is ultimately used to calculate the shortest path to a destination network. It is also used to create the final database, the routing table.

Although the flooding of these LSA messages sounds dangerous, in reality their scope is limited, as we’ll see when we look at OSPF. Ultimately, a link state router stores the complete topology of the internetwork in its database built on first-hand knowledge rather than the rumors passed by neighbor. Another efficiency is found in link state protocols because they don’t actually broadcast out their routing tables, or take nearly as long to converge. On the downside, link state protocols typically involve more planning to implement than their distance vector alternatives. Common examples of link state protocols include Open Shortest Path First (OSPF) and Netware Link State Protocol (NLSP).

Avoiding Routing Loops

Distance vector routing protocols use four main techniques in attempting to prevent routing loops. These include:

Defining Infinity. Instead of allowing a packet to just loop around an internetwork endlessly, distance-vector protocols define what is considered to be infinity by specifying a maximum hop count. For example, RIP considers any route that takes more than 15 hops to reach to be unreachable. Remember that TTL value that gets decremented by 1 each time a router is crossed? Once the TTL reaches 0, the packet is discarded. While this technique doesn’t eliminate routing loops on its own, it does ensure that a packet doesn’t loop around an internetwork forever.

Split Horizon. In looking at the routing loop example, you should have noticed that Router A ultimately let Router B know about a route to network 172.16.0.0, even though it originally learned that route from Router B. Split horizon is a rule that specifies that a router can never send information about a route back to the router that originally supplied the information. Had split horizon been used in our example, Router A would not have included information about network 172.16.0.0 in its update to Router B.

Route Poisoning. Usually used in conjunction with split horizon, route poisoning involves explicitly poisoning a routing table entry for an unreachable network. In our example, once Router C learned that network 172.16.0.0 was unavailable it would have immediately poisoned the route to that network by setting its hop count to the routing protocol’s infinity value. In the case of RIP, that would mean a hop count of 16.

Triggered Updates. Obviously the interval between routing table updates is part of the problem that leads to routing loops. Instead of relying on regular periodic updates, distance vector protocols will send out a triggered update when a metric to reach a network increases. In our example, Router C would immediately send out an update about network 172.16.0.0 not being available to Router B, who would then immediately send out an update to Router A. While triggered updates cause a little more network traffic in the short term, they go a long way towards faster convergence on a distance-vector network.

Holddowns. Holddowns are a technique used to ensure that a route recently removed or changed is not reinstated by a routing table update from another router. Even with the use of triggered updates, it will still take some time for the information to reach all routers on the network. As such, there is still the possibility that a not-yet-current routing table update will attempt to reinstate a route that is unreachable. Holddowns make a router wait a period of time before accepting an update for a network whose status or metric has recently changed, giving a network the opportunity to converge.

Routing Loops

One of the main issues with distance-vector routing protocols is that they are susceptible to routing loops – a direct result of their slow convergence times. A routing loop can occur in the distance vector world because of the way routers exchange information. For example, let’s say that we have a network as shown in the figure below. Three routers exist in this example, connecting a total of four networks. We’ll begin with a network that is fully converged – that is, all routers are aware of all networks, as shown in the diagram. On a fully converged network, everything works well.

Figure: Fully converged network, prior to routing loop.

Routing loops become a potential issue when our network experiences a problem. For example, imagine that network 192.168.2.0 experiences a failure – maybe the switch it was connected to malfunctioned, or somebody simply disconnected the cable. At any rate, Router C recognizes that network 192.168.2.0 is unavailable, and passes this information to Router B in its next routing table update. Once the update arrives, Router B removes the entry for network 192.168.2.0 from its routing table. So far, things are going well. However, there is one little problem – Router A is also sending out routing table updates, and is telling Router B that network 192.168.0.0 is available through it, with a hop count of two, as shown in the figure below. See a problem developing?

Figure: Update from Router A creates a routing loop between Routers A and B.

Now we have a network where Router B thinks it can get to network 192.168.2.0 via Router A. Without anything else occurring, think about what happens here. When Router B gets a packet destined for network 192.168.2.0, it will send it to Router A. Router A will look at the packet, and will send it back to Router B – that is the direction of network 192.168.2.0 as far as Router A is concerned, after all. The packet will actually end up being passed back and forth forever and ever. This is certainly not a very comforting thought.

The problem just described is a directly related to slow convergence. Router C did its job in getting information about the unavailable network to Router B, but unfortunately Router A also sent an update to Router B prior to the “correct” information arriving at Router A. On a larger network, the problem would be even worse. Remember that distance vector routing protocols are not terribly discerning – they simply trust their neighbors to provide them with correct information. Thankfully, distance vector routing protocols take a number of steps to try to avoid the routing loops just described.

Multiple Network Paths

On any internetwork, it is possible that more than one path to a destination may exist, with the same distance. For example, consider the figure below. This network consists of three networks. From Router A, network 172.16.0.0 can be reached in two possible ways – both via Router B and Router C. In both cases, the hop count to network 172.16.0.0 is identical – 1 hop. A distance vector protocol like RIP decides which route to take based on hop count, but can also load-balance over routes with the same hop-count in a round-robin fashion. In this case, some packets will be sent to network 172.16.0.0 via Router B, and some via Router C. It’s worth remembering, however, that hop count is the only metric used by RIP. For example, the link between A and C is only 64kbps, while the link between A and B is a T3 line. Even though AB is a much faster link than AC, Router A still sees both paths as equal. Such is how RIP sees the world.

Figure: Network 172.16.0.0 is available to Router A via two paths, both with a hop count of 1.

Distance Vector Routing Protocols

Distance vector routing protocols create their routing tables based on the networks to which they are directly connected, and the information passed to them by neighboring routers in the form of routing table updates. The term “distance-vector” actually describes the way in which these protocols work. The “vector” is simply a combination of two pieces of information that describe how to get to a network – the direction, and the distance.
For example, a router may find out that a previously unknown network is accessible via its E0 interface (the direction), with a metric of 2 hops (the distance). A metric is simply the piece – or pieces – of information that a router uses in determining which path is the “best” in reaching a destination network. In the case of a protocol like RIP, the metric is the number of routers that need to be crossed in getting to a destination, also called the hop count. In other distance-vector protocols, like IGRP, the default metric is a calculation based on network bandwidth and delay. While we’ll look at both shortly, for now it’s enough to say that a metric is used by a routing protocol to find the best path to reach a destination network.

Distance-vector protocols work on a principle that is sometimes called “routing by rumor”. This is because a router running a distance-vector protocol learns about other networks based on the information provided by neighboring routers. In other words, the knowledge it obtains is not first-hand. The way in which a router learns from neighboring routers is by routing table updates. At certain intervals, a router sends out its complete routing table, which will be received by other routers running the same routing protocol. These other routers look at the information contained in the routing table update, and add routes to their own tables for networks they didn’t previously know about.

Figure: RIP update broadcast from Router A.

Consider the figure above, in which Router A sends out its routing table, which is ultimately received by Router B. Router A knows about networks 192.168.1.0 and 10.0.0.0. Router B doesn’t yet have an entry for network 192.168.1.0, so it adds it to its routing table with a hop count of 1, as shown in Figure 10. When Router B needs to reach network 192.168.1.0, it will forward the packets to Router A. In the same way, Router B will also send out updates to Router A. Through these, Router A will learn that network 172.16.0.0 is available via router B with a hop count of 1. Recall that the hop count is the number of routers that need to be traversed in order to reach a network. Because Router B only needs to go through one other router to reach network 172.16.0.0, the hop count is 1. Hop count is the metric used by RIP. In other words, RIP will choose the best path to a network based on the lowest number of hops.

Figure: Routing table on Router B after RIP update.

If Router C (running the same distance vector routing protocol) were added to our network as shown in the figure above, it would also begin exchanging updates with its neighbors. In this case, it would send a routing table update to Router B, letting it know about network 192.168.2.0. Router B will add this to its routing table with a hop count of 1. In Router B’s next update to Router A, this network would also be included in the table. Router A would thus add it to its routing table, with a hop count of 2. Once all the updates were complete, and all routers knew about all networks, the network is considered to have converged. At that point, the routing tables would appear as shown in the figure below.

Figure: Router C and network 192.168.2.0 added to the existing network.

Figure: Routing tables after the network has converged.

Dynamic Routing

In the real world, and especially in larger environments, companies usually rely on dynamic routing protocols to keep routing tables updated. Quite simply, it is easier to configure all routers to use a dynamic routing protocol and have them learn about unconnected networks from other routers, rather than statically defining a route to each and every network on every router. Dynamic routing protocols also provide a degree of fault tolerance. If a network or router fails on a network using dynamic routing protocols, other routers will find out about it, either through updates from neighboring routers, or via the absence of updates messages. In contrast, with only static routes defined, neighboring routers do not exchange information. When a network or router fails in a static routing environment, other routers do nothing to compensate for the failure.

Certainly dynamic routing protocols have their advantages, but they also have drawbacks. For one, the update messages that are passed between routers running dynamic routing protocols add traffic to the network. Secondly, some routing protocols also increase resource usage on the router, since they calculate the best route to a network from updates received. Finally, it takes time for routers to find out about a network that is unavailable, and for all routers to have consistent routing table information. Once all routers have knowledge of all available networks, the network is referred to as being converged.

Not all routing protocols are equal in these respects. Some converge faster, but use up more of a router’s processing resources. Others go easy on resource usage, but cause more network traffic. Some make routing decisions based on very basic information, while others take into account a variety of factors. Using a routing protocol almost always involves some type of tradeoff, and deciding which works “best” will largely depend on the characteristics of the network you are dealing with. Routing protocols generally fall into two main categories – distance vector and link state.

Static Routing

In our second example we looked at configuring routing statically. Static routing really involves nothing more than telling a router about a non-connected network, and the next-hop address to reach it (or local interface on which to forward the packet). While it may be a little more work than using dynamic routing, static routes are a quick and effective way to configure routing, especially on small networks.

On larger internetworks that consist of many routers and networks, static routing will probably not be the best option. This is because of what transpires when a router or network becomes unreachable – with static routing, a router won’t be able to do anything to find another path through the internetwork. With dynamic routing, when a path becomes unavailable, a router will find out about it from other routers, and will attempt to use a different path, if one exists. That’s not to say that dynamic routing protocols are the solution to all of life’s routing problems. In fact, they can sometimes cause just as many problems as they solve, as we’ll see a little later in this chapter.

Even before our router is configured with static routes, it has a routing table. Each routed protocol (like IP or IPX) maintains its own routing table. To view the IP routing table on a Cisco router, use the show ip route command, as shown below.

RouterA#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
C 10.0.0.0/8 is directly connected, Serial0
C 192.168.1.0/24 is directly connected, Ethernet0

Before any static (or dynamic) routes exist, a routing table will show entries for only directly connected networks. In this case, the output of show ip route shows two connected networks, 10.0.0.0/8 and 192.168.1.0/24. In both cases, the fact that they are directly connected is clear according to the message following the network ID. However, the letter “C” that precedes the entries also identifies the networks as being directly connected. The codes shown at the beginning of the command output describe how a router knows about a network in its routing table.

Adding a static route isn’t terribly difficult at all. The command to add a static IP route is ip route. The complete syntax of the command is:

ip route [destination network] [mask] [next hop address OR exit interface] [administrative distance] [permanent]

Not all of the options listed above need to be entered. In this case, we’ll enter only the destination network, subnet mask, and next-hop address information. We’ll discuss the other options shortly. Let’s assume that our network is configured as shown in the figure below. In it, RouterA is directly connected to networks 192.168.1.0/24 and 10.0.0.0/8. We’ll need to add a static route on RouterA, telling it that network 172.16.0.0/12 can be reached via the next hop address of 10.0.0.2.

Figure: Router A and Router B interconnecting 3 networks.

RouterA#config t
Enter configuration commands, one per line. End with CNTL/Z.
RouterA(config)#ip route 172.16.0.0 255.240.0.0 10.0.0.2
RouterA(config)#^Z
RouterA#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 not set
C 10.0.0.0/8 is directly connected, Serial0
C 192.168.1.0/24 is directly connected, Ethernet0
S 172.16.0.0/12 [1/0] via 10.0.0.2

Notice that a new entry has been added to the routing table, and is preceded by an “S”. This designates the route as static. In this case, network 172.16.0.0/12 is accessible via the next-hop address, which is interface S0 on Router B – 10.0.0.2. If you’re setting up static routes and you notice that the route just added doesn’t appear after issuing the show ip route command, it likely means that the next-hop address you specified cannot be contacted. In order for the route to appear in the table, the next-hop address must be accessible. If you want to add a static route and have it appear in the routing table regardless of whether it’s available, add the permanent keyword to the end of the ip route command, as shown below.

RouterA(config)#ip route 172.16.0.0 255.240.0.0 10.0.0.2 permanent
RouterA(config)#^Z
RouterA#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 not set
S 172.16.0.0/12 [1/0] via 10.0.0.2
C 192.168.1.0/24 is directly connected, Ethernet0

In the example above, I unplugged the S0 interface on RouterB. Notice how network 10.0.0.0/8 no longer appears as directly connected, since the address 10.0.0.2 cannot be reached. However, the use of the permanent keyword keeps the new entry for network 172.16.0.0/12 in the routing table, even though the next hop address is unavailable.
After adding the static route to network 172.16.0.0/12 on RouterA, the next step is to add a static route to network 192.168.1.0/24 on RouterB.

RouterB#config t
Enter configuration commands, one per line. End with CNTL/Z.
RouterB(config)#ip route 192.168.1.0 255.255.255.0 10.0.0.1
RouterB(config)#^Z
RouterB#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 not set
C 10.0.0.0/8 is directly connected, Serial0
C 172.16.0.0/12 is directly connected, Ethernet0
S 192.168.1.0/24 [1/0] via 10.0.0.1

In order to remove a static route, use the “no” version of the ip route command, followed by the network address and subnet mask of the route you wish to remove. For example, to remove the static route to network 192.168.0.0/24 from RouterB, you would enter:

RouterB(config)#no ip route 192.168.0.0 255.255.255.0

Recall that another option for the ip route command allows you to add what is known as an administrative distance. An administrative distance is simply a number that designates how reliable or “trustworthy” the information about a particular route source is considered to be. For example, a directly connected interface is always considered the most trustworthy, and has an administrative distance of 0. A static route is also considered trustworthy, since an administrator will have manually defined it, after all. Static routes are assigned an administrative distance of 1 by default. The lower an administrative distance, the more trustworthy a route is considered to be. Consider the routing table entry below. The administrative distance of this route is 1, as shown by the value in the first portion of the square brackets.

S 192.168.1.0/24 [1/0] via 10.0.0.1

Routes learned from dynamic routing protocols are also assigned default administrative distances. But how are administrative distances used? Well, assume that an administrator has defined a static route to a network, and a route to the same network is also learned from a routing protocol. In cases where this happens, the router will “keep” or use the entry with the lower administrative distance. By default, a static route will always beat an entry learned dynamically. The list below provides the default administrative distances associated with routes learned in different ways.

Directly connected interface 0
Static Route 1
EIGRP 90
IGRP 100
OSPF 110
RIP 120
Unknown 255

To set the administrative distance of a static route to 50, use the ip route command as follows:

RouterB(config)#ip route 192.168.0.0 255.255.255.0 10.0.0.1 50
RouterB(config)#^Z
RouterB#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 not set
C 10.0.0.0/8 is directly connected, Serial0
C 172.16.0.0/12 is directly connected, Ethernet0
S 192.168.1.0/24 [50/0] via 10.0.0.1

While static routing may be a great deal of work to configure and maintain, there are two scenarios where static routing will commonly be used. The first is on “stub” networks, a network from which there is only one exit router to the rest of an internetwork. The second is in demand-dial routing environments, which are looked at in more detail in Chapter 11.

Communication Across a More Complex Routed Network

A router knows about the networks to which it is directly connected. However, it’s up to you to enable a router to find out about networks to which a direct connection does not exist. As I mentioned earlier, a router primarily finds out about remote networks in one of two ways – via a static routing table entry, or through the use of a dynamic routing protocol like RIP or IGRP. Again, this is best illustrated by an example. In the figure below, our network includes four networks and three routers.

Figure: Routing tables showing directly connected networks only.

For this example, I’m again going to assume that all of our connections are via Ethernet ports. Remember that all 3 routers known about their directly connected networks. Given the current configuration, Router A can route packets between network 10.0.1.0/24 and network 10.0.2.0/24. Router B can route packets between networks 10.0.2.0/24 and 10.0.3.0/24. Finally, Router C can route packets between 10.0.3.0/24 and 10.0.4.0/24.

From the routing tables shown in the previous figure, it should be clear that each router is unaware of the two networks to which it has no direct connections. For example, Router A doesn’t know how to reach either network 10.0.3.0/24 or 10.0.4.0/24.

First off, let’s be clear on one thing – when a router doesn’t know how to get to a destination network, it will drop any packets destined for that network and send an ICMP destination unreachable message to the host. For example, if Router A receives packets destined for network 10.0.3.0/24, it will drop them as things currently stand. The router won’t guess or make any assumptions on its own, which is good news (later in the chapter we’ll discuss how this can be changed through the use of default routes). This also means that it’s up to you to make the whole network route – it actually isn’t that big a deal in this case, as you’ll see shortly.

For now, I’m going to assume that we’re setting up static routing on our simple network. If you think about things, we really need to accomplish three main goals:

  • Configure Router A with a way to get to networks 10.0.3.0/24 and 10.0.4.0/24.
  • Configure Router B with a way to get to networks 10.0.1.0/24 and 10.0.4.0/24.
  • Configure Router C with a way to get to networks 10.0.1.0/24 and 10.0.2.0/24.

Let’s start with Router A. We need to tell Router A how to get to networks 10.0.3.0/24 and 10.0.4.0/24. This will involve adding static entries to Router A’s routing table. The key thing to remember is that routers will always communicate directly with a host on a connected network, or pass a packet on to the next “hop”, which is another router. There is no magic flying across networks or avoiding routers in the path between a source and destination host. Keep in mind everything the router does will happen one hop at a time.

Take another look at the previous figure. The key to configuring routing is to figure out what the next hop address is. First, we are trying to determine where Router A should send packets destined for network 10.0.3.0. Obviously it cannot communicate with network 10.0.3.0/24 directly, since it doesn’t have an interface connected to this network. As such, Router A will need to forward packets destined for network 10.0.3.0/24 to Router B – in this case, interface 10.0.2.2. The address 10.0.2.2 is our next hop address on the journey to network 10.0.3.0/24. Once packets arrive at 10.0.2.2, Router B will be able to forward them to network 10.0.3.0/24 – a directly connected network. Similarly, we need to tell Router A how to get to network 10.0.4.0/24. Since it is in the same direction, we will also add a static route that sends packets destined for network 10.0.4.0 to the next hop – which is also 10.0.2.2. Since network 10.0.4.0/24 isn’t directly connected to Router B, it will also need a route defined to this network.

Routing table entries will also need to be added to Router B and Router C. In this case, the entries below need to be added, as also shown in the figure below.

  • Router B needs a static route defined to network 10.0.1.0/24. The next hop address to reach this network would be 10.0.2.1. A route will also need to be defined to network 10.0.4.0/24, with a next hop address of 10.0.3.2.
  • Router C needs static routes defined to networks 10.0.1.0/24 and 10.0.2.0/24. In both cases, the next hop address will be 10.0.3.1.

Figure Network with complete routing table entries.

Notice that by adding just two static routing entries on each router, we end up with a fully routed network. Obviously, if there were more networks involved, additional routing table entries would be required. To get a feel for exactly what is happening on this network, let’s assume that Host A (from the previous figure) wishes to communicate with Host D. I’m not going to point out every single detail of the communications process this time, but all the same things that happened in our original example do happen again here.

  1. In this example, Host A wishes to communicate with Host C. Host A will create an IP packet with a source address of 10.0.1.99 and a destination address of 10.0.4.101. Since Host C is remote, the packet will be framed, with the destination MAC address being that of Router A’s E0 interface.
  2. Once the frame reaches Router A, it will calculate the CRC, strip off the framing, and pass the packet up to the Network Layer. In consulting its routing table, Router A will find that the next hop address to reach network 10.0.4.0 is 10.0.2.2. Router A will decrement the IP packet’s TTL by 1, and will reframe the packet. In this case, the source MAC address will be MAC address of Router A interface E1 and the destination MAC address will be that of Router B interface E0. The MAC address of Router B interface E0 will be found with an ARP request.
  3. Once the frame reaches Router B, a similar process occurs. The CRC will be calculated, the framing will be stripped off, and the packet will be passed to the Network Layer. In consulting its routing table, Router B will find that the next hop address to reach network 10.0.4.0 is 10.0.3.2. Router B will again decrement the IP packet’s TTL by 1, and will reframe the packet. In this case, the source MAC address will be MAC address of Router B interface E1, and the destination MAC address will be that of Router C interface E0.
  4. The frame is now forwarded to Router C interface E0. Router C will calculate the CRC, strip off the framing, and pass the packet up to the Network Layer. Here it will consult its routing table, and will see that network 10.0.4.0 is directly connected on interface E1. Router C will also decrement the TTL by 1, and then reframe the packet. This time, the source MAC address will be Router C’s E1 interface, and the destination MAC address will be that of Host D, which will have been found by an ARP request. The frame is then forwarded to Host D.
  5. Upon receipt at Host D, the frame is processed, and ultimately the data it contains makes its way to the appropriate application. The reply from Host D to Host A undergoes the same process, in reverse.
    In a nutshell, simple routing is no more complex than this example. If we had wanted to, we could have configured all three routers with a dynamic routing protocol, and this would have allowed them to exchange routing table information without our intervention. While this may immediately sound like a great idea, there are some downsides, as we’ll look at a little later in the chapter. For now, it’s most important that you understand the purpose of a routing table, how basic routing decisions are made, what happens when IP packets cross a router, and the constant re-framing that occurs on a packet’s journey.

Communication Across a Simple Routed Network

Take a look at Figure 8-1, where a single router connects to networks 192.168.0.0/16 and 10.0.0.0/8. By this point, you should recognize these network addresses as two of the private IP address ranges that are not valid on the public Internet. The router is a simple 2-port Ethernet router, with interface E0 connected to the 192.168.0.0 network, and interface E1 connected to the 10.0.0.0 network. Both interfaces on the router have already been assigned their IP addresses, 192.168.0.1 and 10.0.0.1 respectively. Using an IP address that ends in “.1” for router interfaces is fairly common. It is not a rule, but rather a convention. You may or may not choose to follow this convention, but it does make the IP address of a router interface easier to remember.

Figure: A simple routed internetwork.

Believe it or not, without configuring anything else on this router, it is already capable of routing data between network 192.168.0.0 and network 10.0.0.0. How is this possible? Well, the first thing you need to understand is that after assigning a Cisco router IP addresses, it knows about the networks that it is directly connected to, and the command ip routing is enabled by default. In other words, the router is aware that interface E0 is connected to the 192.168.0.0 network, and that interface E1 is connected to network 10.0.0.0. A router will automatically add both of these networks to its routing table. If our router receives a packet destined for the 192.168.0.0 network on interface E1, it will know to forward it out interface E0. In the same way, interface E0 knows that any traffic destined for network 10.0.0.0 should be forwarded out interface E1. A router always knows how to get to the networks to which it is directly connected, without any additional configuration. Things get a little more complex when a router needs to get to networks that are not directly connected.

Each network in this example also has a single host configured, as shown in Figure 8-2. Notice that each host has an IP address, subnet mask, and default gateway value assigned. The default gateway IP address is that of the local router interface on the host’s network. Hosts will forward traffic to the router when they calculate that the destination host is not on their local network.

Figure: Simple routed network with 1 host on each network.

In this example, each network is a Layer 2 broadcast domain, running Ethernet. Both networks are also unique Layer 3 IP networks, as shown by their logical layout. On most (but not necessarily all) networks, each broadcast domain will be associated with a unique IP network (or subnet) address.

There are cases, however, where the preceding statement is not necessarily true. For example, a company may run out of IP addresses and choose to map two subnets to a single broadcast domain. Making things work would then involve adding a second IP address to the local router interface. Even through hosts will be in the same broadcast domain, the router will still need to route packets between the different subnets. I didn’t say it was efficient, but it is something that you may come across.

For the purpose of illustration, I’m going to assume that Host A wishes to communicate with Host B. In order for these two hosts to communicate, our router will obviously need to be involved. Let’s take a look at how the communication process occurs when Host A attempts to create an HTTP session with Host B.

  1. The first step in the process is the creation of an HTTP request at the Application Layer. In this case, Host A is requesting a web page from Host B. After formatting the HTTP request, the data is passed down to the Transport layer. Remember, our interaction is happening over TCP/IP.
  2. Once the Transport Layer on Host A receives the data, it will add header information that will include the source and destination TCP ports. In this case, the destination TCP port will be 80, and the source port some number above 1024. Once this is complete, the segment will be passed to the Network Layer.
  3. At the Network Layer, the IP header will be added. This header will include a variety of information, but most importantly the source and destination IP addresses. The source address is 192.168.0.99, and the destination address is 10.0.0.100. The next step is passing the packet down to the Data Link layer.
  4. Recall the ANDing process looked at in Chapter 5. This is the process that a host uses to determine whether a destination host is local or remote. In this case, the ANDing results will be different, which means that the destination is on a remote network. When a destination is remote, the packet cannot be sent directly to that host. Instead, it must be first sent to a router.
  5. Pay particular attention to this step. Host A knows that it needs to send this packet to its local router, but the router is not the ultimate destination IP address – 10.0.0.100 (Host B) is. In order to get this data to the router, our host must frame the packet with the destination MAC address – in this case, the MAC address associated with the router’s E0 interface. To obtain this MAC address, it will send out an ARP request looking for the MAC address associated with 192.168.0.1. Once the router responds, Host A will frame the packet. In this case, the source address is the MAC address of Host A, and the destination address is the MAC address of the router’s E0 interface.
  6. Ultimately, this frame will reach interface E0 on the router. The router will notice that the frame is destined for its MAC address, and as such it will process the frame. After calculating the frame’s CRC, it will strip off the frame header and pass the resulting packet up to the Network layer At this point, the router will notice that the destination IP address is not it’s own. When a router receives a packet that is not destined for it specifically, it looks in its routing table to see whether it has a route defined to the destination network. In this case, the router sees that it is directly connected to network 10.0.0.0/8, and also determines that it should forward the packet via interface E1. Before it can forward the packet, however, it has to pass it back down to the Data Link Layer for re-framing.
  7. At the Data Link layer, the router will re-frame the packet with a new header, meaning that source and destination MAC addresses will need to be added. In this case, the source MAC address is now the MAC address of interface E1 on the router. The destination MAC address will be obtained via an ARP request to IP address 10.0.0.100. Once Host B replies with its MAC address, this will be added to the frame as the destination MAC address. The router will then calculate a new CRC for the frame, and forward it through interface E1 as a series of bits.
  8. Eventually the frame will arrive at Host B. By inspecting the destination MAC address, Host B will recognize that the frame is meant for it, calculate the CRC, strip off the framing, and pass it up to the Network Layer.
  9. At the Network Layer, Host B will also recognize its IP address as the destination. This means that it has to process the packet further. In the IP header, it will see that the data should be passed to TCP at the Transport layer.
  10. At the Transport Layer, Host B will look at the destination TCP port, and recognize that the data contained in the segment should be sent to TCP port 80. This is the port on which the web server application is listening for connections.
  11. The web server on Host B will process the HTTP request contained in the data. Ultimately it will need to send a reply, where the whole process happens again, in reverse.

If those twelve steps seem like an awful lot of work to pass data between two hosts, you’re right. However, this is the way things work when you want to communicate between hosts on a routed network. Think of it this way – we are effectively using a Layer 3 protocol (IP) to communicate between different Layer 2 networks. In this case, both of those networks were Ethernet, but that won’t always be the case. For example, what if Host B had resided on a Token Ring network? In that case, our router would require one Ethernet interface and one Token Ring interface. When the data was sent to the router from Host A, it would have been framed for Ethernet. After the router stripped off the framing and passed the data up to the Network layer, it would determine that the packet needed to be forwarded out the Token Ring interface, where it would need to be framed for Token Ring. As even this very basic example suggests, a router is doing a great deal of work to every packet it encounters – not only does it have to make a forwarding decision based on the destination IP address, but it also has to reframe every single packet that it forwards on its way. By this point, you should be recognizing some of the reasons as to why routing is typically much slower than switching.

You should also recognize that although packets are re-framed at the router, the actual source and destination IP addresses never change. In fact, the only thing that the router touches for certain in the IP header is the time-to-live (TTL) value. Recall that a router will always decrement the TTL on an IP packet that it forwards by one, which ultimately ensures that packets don’t end up being forwarded around a network forever. Once its TTL expires, a packet is discarded.

A router may further alter an IP packet under special circumstances, such as when the maximum transmission unit (MTU) of connected networks is different. For example, imagine that the networks connected were Ethernet and Token Ring. Token Ring has a much larger maximum frame size than Ethernet. When a frame is received on a Token Ring interface, the packet it contains may be much larger than what Ethernet can handle (recall that the MTU of an Ethernet frame is only 1518 bytes). In this case, the router will “chop up” or fragment the packet into a number of smaller packets, then reframe each and send them on their way. Again, it becomes clear that there is more to what a router does than initially meets the eye.