Routing protocols under the hood: Link State and Distance Vector

When you are studying for your CCNA or CCNP you will encounter routing protocols. A CCNA will encounter OSPF, CCNP students will additionally encounter EIGRP, RIP and BGP. What’s the difference between these routing protocols, and why are there so many?

Each routing protocol has its own benefits, but each routing protocol will (primarily) be categorized in one of the following types, though some protocols will have a little of both in them:

  • Distance Vector
  • Link state

Distance Vector routing protocols

Distance Vector protocols were the first routing protocols to be developed. These were fairly simple (at least back then) and worked on a principle of pointing in a direction and stating how far away the destination was. This is comparable to a signpost on an intersection. It tells you which way to go, and how far it is.

Routing protocols under the hood: Distance Vector

Distance vector protols work by routers telling other routers that they know the way to a specific destination. They tell the other router the distance to that destination and let the other router decide what to do with that information. It might be that this router will use this information to tell travelers which way to go, but it might also be discarded because the router knows of another, better route.

Let’s look at the following example. Let’s say we have a destination network connected to Amsterdam and we want to get there from router Dublin. Dublin knows it’s not connected to that network locally, so it needs to route. Based on information it got from Berlin and Copenhagen it can go two ways. Berlin tells Dublin that Amsterdam is a distance of 10 away from it. Copenhagen tells Dublin that it’s distance to Amsterdam is 15. That means that Dublin has to know the distance between it and Berlin and Copenhagen respectively. Depending on that distance Dublin will make a decision. In this case it will send traffic to Berlin since the total distance via Berlin is the shortest.

What Dublin doesn’t know is what’s between Berlin and the destination. There might be more routers between it and the destination, or there might not. The only thing it knows is that the distance between Berlin and Amsterdam is 10. For Dublin everything behind its directly connected neighbors is a mystery.

Link state routing protocols

Link state protocols work differently from Distance Vector. A real world anology would be somebody with a map of the city. That person can work out the best way to get from A to B.

Routing protocols under the hood: Link State

In the case of link state protocols a router has a complete overview of the network. It knows which routes there are, but also knows their state and cost. This means that a router knows when a specific link has failed and will use that information to select a different path to the destination.

This also means that a router needs to know of all possible destinations, links and routers within a network, otherwise it could never make those decisions. It also requires this information to be the same on all routers, as it is possible when two routers have different information they might send traffic between each other.

For example, both routers Amsterdam and Berlin have a direct connection to router Copenhagen, behind which network A is connected. Because the link between Berlin and Copenhagen is slow, Berlin chooses to send traffic destined to Copenhagen via Amsterdam. Now the link between Amsterdam and Copenhagen fails. Amsterdam knows about the alternative route via Berlin, so starts sending traffic to Berlin. Berlin however, not having heard about the failure of the Amsterdam – Copenhagen link, might still send the traffic back to Amsterdam. This is why link state protocols need to have very robust and fast ways to synchronize information between them.

Which type of routing protocol should I use?

Whenever you have two types of protocols the question which of the two is better immediately arises. Is Link State better than Distance Vector? In some cases yes, in other cases no. It always depends. However, when looking at the current state of affairs in the routing world we see that Link State protocols tend to be used more often. OSPF is probably the most implemented protocol in enterprise networks nowadays.

Advantages and disadvantages of Distance Vector

Distance Vector protocols have the following benefits:

  • fairly simple protocols
  • Possibility to apply summarization (information hiding) at any point in the network
  • Requires less processing power
  • Often very scalable

The following are some of the disadvantages of Distance Vector:

  • Converges slowly
  • Older Distance Vector protocols had issues concerning long (permanently) lived loops

Advantages and disadvantages of Link State

Link state protocols have their own benefits:

  • Very fast failover (because of complete view of the network)
  • Scalable (when using routers with sufficient processing power)

The disadvantages of Link state protocols are:

  • Requires a lot of processing power
  • Requires more bandwidth in the network due to updating the link state information
  • More complex

Summary

Looking at the benefits of each of the protocols you would expect Distance Vector protocols to be in the lead. They clearly have more benefits. However, the benefits of Link State, and especially the speed factor, are big enough that Link State protocols are used more often. We should add a footnote here however. Both OSPF and IS-IS, the best known Link State protocols use Distance Vector logic to be able to achieve larger scale. Routing between area’s in these protocols use Distance Vector technology.

CCNA Lab 13: Router on a Stick

When you have multiple vlans on a switch, devices in those vlans can’t communicate with each other. You need something to connect these vlans together. This is the function of a router. A common way for CCNA level routing is the router on a stick.

Routers know which network can be found where. They do this based on layer 3 information, the IP address and subnetmasker. There are several ways a router can get to know this kind of information:

  • based on connected interfaces
  • statically configured information
  • dynamic routing protocols

When a router has an interface which has an IP address and subnetmasker which is part of a network it automatically knows how to find that network. It is connected to it. When the router is not connected to the network it needs to figure out where to find it. That’s where static configuration or dynamic protocols come in to play. Well known dynamic routing protocols are OSPF, EIGRP and BGP.

Most routers are placed strategically in the network, like a spider in a web. It will likely have multiple interfaces, for example an inside and outside interface. Or an interface in different zones of the network. A router on a stick is a different kind of deployment. In this deployment the router actually only has one interface. This interface is connected to a switch using a trunk. On this trunk multiple vlans are transported. The router is used to route between these vlans, possibly with some level of security.

The image shows the concept of a router on a stick. Here you can also see we’re using something called a ‘subinterface’. Subinterfaces are virtual interfaces, so from the standpoint of the router it actually has multiple interfaces. The image is also the topology we’ll be using for this lab.

Download the topology file here:

CCNA router on a stick

Preparing the lab

Perform the following tasks to prepare the lab.

  1. Configure the following vlans on Berlin:
Vlan numberVlan name
10Sales
20HR
  1. Configure Gi1/0/2 as an access port in vlan 10
  2. Configure Gi1/0/3 as an access port in vlan 20
  3. Configure Gi1/0/1 as a trunk port, allow only vlans 10 and 20 on it.

Below is the configuration you should perform:

It depends on the platform whether you need the “switchport trunk encapsulation dot1q” command. In this case it was needed. If you don’t use it, but try to configure the port as a trunk port it will tell you. The message you will get is:

‘Command rejected: An interface whose trunk encapsulation is “Auto” can not be configured to “trunk” mode.’

That way you will know that you need to add the encapsulation command.

Configure router on a stick

Switching configuration done we can move on to the routing configuration. Before we begin, let’s verify that the PC’s can’t ping each other.

  1. Open the command prompt on PC0.
  2. ping 192.168.20.2

This should fail.

  1. Connect to Amsterdam and enter configuration mode.
  2. Enter interface configuration mode for interface Fa0/0
  3. Ensure the interface is online (unshut it).
  4. Type the command: “interface fa0/0.10”

Now you have created a subinterface. Subinterfaces are created automatically when you enter a subinterface number on the CLI. This also means that sometimes when you make a typo you might create one by accident. You can easily remove them by using the no form of the command. Just be sure that when you do you are not making a typo.

  1. Type the command: “encapsulation dot1q 10”

This command will tell the router to watch for frames arriving with a dot1q vlan tag of 10. When a frame containing this tag enters the switch on interface Fa0/0 it will be processed by the subinterface.

  1. Type the command: “ip address 192.168.10.1 255.255.255.0”

Now we have assigned an IP address to the interface. This is one of the most common commands you’re likely to perform on the CLI.

  1. Ensure the interface is not shutdown.
  2. Configure subinterface fa0/0.20 with vlan 20 and IP address 192.168.20.1/24

I used a new kind of notation for the IP address. You notice the /24 behind the IP address? This refers to the subnet mask. This method of writing down the subnet mask is also called the CIDR (pronounced as cider) notation. The /24 defines the number of bits with a value of 1. In this case 24 of them are a 1. That means that the subnet mask is 255.255.255.0 in this case. In another lab we will dive into this notation and provide (a lot) of practice with the notation.

You should have entered the following configuration:

Verification

  1. Enter the command “show ip interface brief”
Amsterdam#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        unassigned      YES unset  up                    up
FastEthernet0/0.10     192.168.10.1    YES manual up                    up
FastEthernet0/0.20     192.168.20.1    YES manual up                    up
FastEthernet0/1        unassigned      YES unset  administratively down down
Vlan1                  unassigned      YES unset  administratively down down

You can see the interfaces are configured and Up. That means we’ve done our work correctly. Or, at least we created the subinterfaces and we defined IP addresses on them. What we don’t see in this view is whether we applied the right encapsulation on the interface. To be able to see that we need another command:

  1. Type the command “show interface fa0/0.10”
Amsterdam#show interface fa 0/0.10
FastEthernet0/0.10 is up, line protocol is up (connected)
  Hardware is PQUICC_FEC, address is 0001.4305.cc01 (bia 0001.4305.cc01)
  Internet address is 192.168.10.1/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID 10
  ARP type: ARPA, ARP Timeout 04:00:00,
  Last clearing of "show interface" counters never

Now you can see the vlan ID which is used on this interface. In this case vlan 10, which is correct.

Now we’ve done our work, let’s check whether everyting is working. PC0 and PC1 should be able to ping each other.

  1. Connect to the command prompt on PC0
  2. Ping 192.168.20.2

It might take a short while for the pc’s to start pinging, so you might see some timeouts occurring. But you should have connectivity between the two PC’s:

C:\>ping 192.168.20.2

Pinging 192.168.20.2 with 32 bytes of data:

Request timed out.
Request timed out.
Reply from 192.168.20.2: bytes=32 time=1ms TTL=127
Reply from 192.168.20.2: bytes=32 time<1ms TTL=127