Lesson 42 - OSPF Fundamentals Part 5 - The Lab

I try to keep these posts as short and informative as possible. Since it takes a moment to do this lab and analyze the results, the troubleshooting section is going to be included in the form of a video presentation at the end of this post (available soon).

Here is our topology. I have removed Frame-Relay links as it goes beyond the scope of this tutorial (some really crazy workbook/journal I started a few days ago might give you an idea about this complexity.

But let's get back to business!

Pic. 1 - OSPF Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Since there are five different routers and three types of networks (broadcast, point-to-point and loopback) I will create an action plan and implement it step by step. I'll include some stipulations in order to show you a few things which I might have not talked about yet.

Task List

General Requirements:

• ALL interfaces should be enabled in area 0. 
• ALL loopback addresses must be advertises with their configured network mask length (/24) or (/28). 

1. Enable OSPF in the broadcast network connecting R1, R2 and R3. Make sure that R1 is elected the DR and R2 is elected the BDR in the broadcast segment (172.31.123.0/24).
2. Advertise the loopback subnets on R1, R2 and R3. On R3 do NOT use the network statement to advertise the subnet of Loopback1. On R3, while enabling OSPF on Loopback2 using the 'network' statement, use the wildcard bits corresponding to the network mask configured (/28).
3. Enable OSPF between R1 and R4. Advertise the subnet found on R4's loopback0.
4. Enable OSPF between R2 and R5. On R5 use only one network statement to enable OSPF on ALL interfaces (also the ones created in the future).
5. Enable the Simple Password authentication in area 0. Use the password 'cisco'.

Lab Solution

Step 1
Enable OSPF in the broadcast network connecting R1, R2 and R3.

Note!
Configuration must be done in this order to ensure R1 is elected the DR, R2 is elected the BDR.

R1 Configuration: 

!

R1#conf t

R1(config)#interface f1/0

R1(config)#ip ospf priority 20

R1(config-if)#router ospf 1
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 172.31.123.1 0.0.0.0 area 0
R1(config-router)#exit  

R2 Configuration:

!

R2#conf t

R2(config)#interface f1/0

R2(config-if)#ip ospf priority 10

R2(config-if)#router ospf 1
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 172.31.123.2 0.0.0.0 area 0

R2(config-router)#exit

R3 Configuration:

!

R3#conf t

R3(config)#router ospf 1
R3(config-router)#router-id 3.3.3.3
R3(config-router)#network 172.31.123.3 0.0.0.0 area 0

R3(config-router)#exit

Now, let's give the routers a few seconds to go through the finding neighbors, creating adjacencies. Then a quick verification step shows the following:

Pic. 2 - OSPF Adjacencies.

R3 is adjacent with R1 (DR) and R2 (BDR).

Step 2 
Advertise the loopback subnets on R1, R2 and R3. On R3 do NOT use the network statement to advertise the subnet of Loopback1. 

Note!
Loopback interfaces are considered the 'stub' networks by OSPF process and advertised with /32 network mask by default. In order to change it, the 'ip ospf network point-to-point' should be used on loopback interfaces.

Note!
After you have enabled OSPF on the loopbacks, you should check before proceeding to the next router's configuration. Use the following command:
Router#show ip ospf int brief 

R1 Configuration:

!

R1(config)#

R1(config)#interface loopback 1

R1(config-if)#ip ospf network point-to-point

R1(config-if)#router ospf 1

R1(config-router)#network 172.31.1.1 0.0.0.0 area 0

R1(config-router)#exit

R2 Configuration:

!

R2(config)#

R2(config)#interface loopback 1

R2(config-if)#ip ospf network point-to-point

R2(config-if)#router ospf 1

R2(config-router)#network 172.31.2.1 0.0.0.0 area 0

R2(config-router)#exit

Note!
The task stipulates that the subnet of Loopback1 must NOT be advertised like others (no network statement). Also, while enabling OSPF on the Loopback2 use the wildcard mask corresponding to the network mask configured there (/28).

R3 Configuration:

!

R3(config)#
R3(config)#interface loopback 2
R3(config-if)#ip ospf network point-to-point

R3(config-if)#interface loopback 1

R3(config-if)#ip ospf network point-to-point

R3(config-if)#ip ospf 1 area 0

R3(config-if)#router ospf 1

R3(config-router)#network 172.31.3.16 0.0.0.15 area 0

R3(config-router)#

Step 3 
Enable OSPF between R1 and R4. Advertise the subnet found on R4's loopback1.

R1 Configuration:

!

R1(config)#

R1(config)#router ospf 1

R1(config-router)#

R1(config-router)#network 172.31.14.1 0.0.0.0 area 0

R1(config-router)#exit

R4 Configuration:

!

R4(config)#interface loopback1

R4(config-if)#ip ospf network point-to-point

R4(config-if)#router ospf 1

R4(config-router)#router-id 4.4.4.4

R4(config-router)#network 172.31.14.4 0.0.0.0 area 0

R4(config-router)#network 192.168.4.1 0.0.0.0 area 0
R4(config-router)#exit

Step 4
Enable OSPF between R2 and R5. On R5 use only one network statement to enable OSPF on ALL interfaces (also the ones created in the future).

R2 Configuration:

!

R2(config)#

R2(config)#router ospf 1

R2(config-router)#network 172.31.25.2 0.0.0.0 area 0
R2(config-router)#exit

R5 Configuration:

!

R5(config)#interface loopback1

R5(config-if)#ip ospf network point-to-point

R5(config-if)#router ospf 1
R5(config-router)#router-id 5.5.5.5
R5(config-router)#network 0.0.0.0 255.255.255.255 area 0
R5(config-router)#exit

Note! 
Of course, before you proceed to the the final step (OSPF authentication) you should check if all neighbors are adjacent and all routers can reach all the addresses in the network.

Step 5 
Enable the Simple Password authentication in area 0. Use the password 'cisco'.

Note!
This configuration is going to break and re-establish OSPF adjacency.

R1 Configuration:

!

R1(config)#

R1(config)#router ospf 1

R1(config-router)#area 0 authentication

R1(config-router)#int f1/0

R1(config-if)#ip ospf authentication-key cisco

R1(config-if)#int s0/2

R1(config-if)#ip ospf authentication-key cisco

R2 Configuration:

R2(config)#

R2(config)#router ospf 1

R2(config-router)#area 0 authentication

R2(config-router)#int f1/0

R2(config-if)#ip ospf authentication-key cisco

R2(config-if)#int s0/2

R2(config-if)#ip ospf authentication-key cisco

R3 Configuration:

R3(config)#

R3(config)#router ospf 1

R3(config-router)#area 0 authentication

R3(config-router)#int f1/0

R3(config-if)#ip ospf authentication-key cisco

R4 Configuration:

R4(config)#

R4(config)#router ospf 1
R4(config-router)#area 0 authentication
R4(config-router)#int s0/2
R4(config-if)#ip ospf authentication-key cisco

R5 Configuration:

R5(config)#

R5(config)#router ospf 1
R5(config-router)#area 0 authentication
R5(config-router)#int s0/2
R5(config-if)#ip ospf authentication-key cisco

After OSPF authentication has been configured you should check if all the adjacencies have been formed and reachability is restored. If you have a problem with this lab in the troubleshooting sections you will find some tips helping you make this lab work.

Troubleshooting

Troubleshooting short videos available soon.

During the weekend your colleague, who's newly hired junior network administrator, was re-configuring your system. He has accidentally erased all backup configurations and also lost the track of all changes that he introduced. You have been called to help him restore the system.

Initial diagnostics the junior administrator has performed revealed the following problems:

Ticket 1
The subnets: 172.31.3.0/28 and 172.31.3.16/28 are no longer reachable from any other router but R3(loopback1 and loopback2 on R3).

Video Presentation:
http://www.youtube.com/watch?v=vKZASyZbDmE

Ticket 2
R4 lost connectivity to all subnets in the network except for directly connected ones.

Video Presentation:
http://www.youtube.com/watch?v=HEOrvxKmQSU

Ticket 3
R5 lost connectivity to all subnets in the network except for directly connected ones.

Video Presentation:
http://www.youtube.com/watch?v=BlS3Z5kV_Rk

Final Verification
Ping using Tcl script - an elegant way of checking connectivity.

Video Presentation:
http://www.youtube.com/watch?v=VuubpKq0rxg

The next post is going to be an introduction to EIGRP routing protocol.

Lesson 36 - Routing Information Protocol Part2

In this post I'm going to reinforce all the theory discussed in the two previous posts. But I would like to make it more practical this time. This should help you understand RIPv1 better and hone your skills regarding its implementation. RIPv1 is a good prelude to learning RIPv2 as well since the verification commands are identical for both versions of the protocol. I will finish this lesson off by showing you one quick optimization technique used often with both versions of RIP.

Our topology diagram remains the same.

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In my previous post I enabled RIP protocol on all the routers and interfaces in the topology presented. Now is the time to verify its operation.

The first RIP verification command I'd like to introduce is the powerful: 'show ip protocols'. It provides information about which dynamic routing protocols are enabled on a router, if any, also displaying specific information about them (here's RIPv1 information).

Pic. 2 - The 'show ip protocols' output on R1.

Get familiar with the output and pay a special attention to the highlighted pieces of information. The output shows us the following (pic.2):

• Outgoing/incoming filter list - currently, there are no filters applied to updates being sent or received (more on ACLs which are used to do filtering in the upcoming posts).
• Sending updates - RIP is advertising its routing table every 30 seconds and the next update is going to be sent in 16 seconds.
• Invalid after - The routing entry is invalidated (can no longer be used) if it is not refreshed by neighbor(s) in 180 seconds.
• hold down - If the router receives a 'route-poison' message from the neighbor(s), it still does not trust it entirely for another 180 seconds (it is possibly down). After that period of time it invalidates the prefix. Meanwhile, the router keeps sending packets to the destination marked as possibly down like everything is 'a-ok'.
• flushed after  - The routing entry is removed from the routing table after 240 seconds if not refreshed by the neighbor(s).
• Default version control - the router is advertising version 1 updates, but able to accept updates from both RIPv1 and RIPv2 enabled routers.
• Automatic Summarization - Automatic summarization is enabled (more on this in 'RIP rules' section later in the post).
• Maximum paths - currently the router can use up to 4 equal cost path (metric identical) to a given destination (configurable: up to 16 in most IOS versions as of writing this post).
• Routing for networks - the router has interfaces in 172.31.0.0 class B networks.
• Routing Information Sources - neighboring router's addresses which the router heard from. The time shows when was the last time R1 received the advertisement from its neighbors (e.g. neighbor 172.31.15.5 sent its update to R1 8 seconds ago). This timer should never show you more than 30 seconds under normal circumstances. If the last update from a neighbor arrived longer than 30 seconds ago, it means that the either the neighbor stopped sending its updates or they do not get through.

As you recall, the 'network' statement we used to enable RIP on the interfaces takes a classful IP address as its argument (like explained in the previous post). There is no other additional keyword available for RIP (others protocols use wildcard mask to accomplish this). In case your router has multiple interfaces configured as subnets of the same major network, they all are going to participate in the RIP domain.

For instance, if on R1 I wanted to enable RIP protocol on S0/2 interface only, with my addressing scheme it is not possible. All interfaces are subnets of the same class B major network (172.31.0.0) and will be automatically encompassed in RIP process. If you try to outsmart it and use the following classless statement, it will be accepted by IOS syntax rules but the resulting configuration is going to look like shown in pic. 3 anyway.

Configuration attempting to enable RIP on S0/2 only:

R1(config)#router rip

R1(config)#network 172.31.14.0

Resulting is the following running configuration:

Pic. 3 - RIP's classless statement result.

Of course, it is possible to filter out what is going to be advertised or which updates are going to be accepted by the RIP process. This however is beyond the scope of this lesson as you do not know necessary tools to accomplish that yet.

Another command that you may find useful if you want to see what is currently in the RIP database is the following:

Pic. 4 - RIP Database.

 

The best entries in the RIP database (normal route selection process applies) are going to populate the routing table. You already know the command 'show ip route' which displays the full routing table including connected and static routes as well. But you can also try to display RIP routing entries only rather than the whole routing table. Here's your command:

Pic. 5 - RIP Routing Table.

The routing table contains two class C network addresses advertised by R4 and R5 respectively: 

• 192.168.4.0
• 192.168.5.0

Also, it tells us that the R1 has seven subnets of 172.31.0.0 class B network. Hang on a second! We can only see three of them listed in pic. 5:

• 172.31.25.0
• 172.31.24.0
• 172.31.2.0

Where are the remaining four subnets?
Take a closer look at pic. 4 which shows the whole RIP database. Can you see the missing four subnets now? In case you can't spot them in pic. 4 look at the following one (pic. 6) which shows all seven of them. For clarity, I have removed class C networks and highlighted the subnets in question.

Pic. 6 - R1's RIP Subnets.

There are seven subnets of 172.31.0.0 class B network indeed! The RIP database shows them all, but the ones that are directly connected subnets, are not making their way to the routing table. Do you still remember why?

The reason is, of course, related to the route selection process already explained in the previous posts. The router knows them as directly connected subnets with the administrative distance of 1,and the same entries are now in the RIP database (as the 'network' statement encompasses them). Recall that RIP's administrative distance value is: 120. The directly connected networks are always the most preferred ones. That is why, we see them as connected rather than RIP generated entries.

Notice the two entries in the routing table: 172.31.24.0 and 172.31.25.0. They both have two equal cost paths (the same metric) which is correct according to our topology. In that case traffic-sharing (load balancing) is going to occur when packets are sent to these destinations.

However, R1 has not learned 172.31.3.0/28 and 172.31.3.16/28 subnets that should be advertised byR3.

What is the explanation to this?

Let's do some diagnostics on R3 in order to find out what is going on. I'm going to start by checking that RIPv1 has been enabled properly on R3. I want to make sure that the loopback1, loopback2, and F1/0 interfaces participate in the RIP domain (the 'network' statement encompasses them). Here is the result of the test.

Pic. 7 - R3's RIP Information.

It seems that configuration is correct! So, let's take a closer look at what R3 is advertising to their neighbors. In order to see that, we must use 'debug ip rip' command.

---

WARNING!
Extreme care must be taken when using any debug commands on the production equipment. After the diagnostics have been completed, the debug command(s) must be turned off immediately.
All 'debug' commands are VERY dangerous if used on the production routers. They have enormous impact on the CPU and can potentially crash the device. They are typically used as the commands of the last resort during troubleshooting of a given technology when problem cannot be resolved without data they provide. So we tend to use them only in situations when we cannot do any more damage than there has already been done :-).

---

However, in the lab it is recommended to learn what information can be obtained using 'debug' commands. They help us gain a deeper understanding of a given technology and may be very helpful in troubleshooting.

Since I use the lab equipment (dynamips/dynagen emulator to be accurate), I can safely enable the following debug command to trace the RIP process without any damage to my gear. In practice, it is best if you redirect the output of the debug commands to RAM memory and then copy its content to a text editor for analysis. Here's how you can do this:

Step 1
Make sure that CPU is not heavily utilized first. Enabling 'debug' commands can create high CPU utilization on the production equipment.

R3#show processes cpu

The first line shows the cpu utilization for the last five seconds, one minute and five minutes. If CPU is not very busy you can proceed to step 2.

Step 2
Disable the time stamp service (optionally) to obtain a better output, disable logging to the console and redirect the output to the RAM memory instead.

R3#configure terminal

R3(config)#no service timestamps

R3(config)#no logging console

R3(config)#logging buffered

R3(config)#end

Step 3
Enable appropriate 'debug' command (here: rip process is being debugged)

R3#debug ip rip

Step 4
Wait a period of time till output is sent to the RAM memory. Nothing will show on a screen as per step 2. Then disable debugging (here, the alias is used which disables debugging of all processes which is the fastest method). You can disable the specific one as well. In case of my debug this could be: 'undebug ip rip', or 'no debug ip rip'.

R3#u all

Step 5 
Display the content of the debug from the memory buffer and copy it to a text editor for analysis.

R3#show logging

Step 6
Bring back the previous settings (logging to the console and time stamps).

R3#configure terminal

R3(config)#no logging buffered

R3(config)#logging console

R3(config)#service timestamps
R3(config)#end

For clarity's sake, I have broken the output of 'debug ip rip' into pieces so it is easier for us to analyze the information it provides. In practice, either you learn how to properly interpret the output the way it is presented to you by the system or you can rearrange the output in a text editor.

The first debug output (pic. 8) illustrates what R3 is advertising out its Loopback1 interface. It's worth mentioning, that RIPv1 uses broadcast address (255.255.255.255) to announce networks/subnets as explained in lesson 35. RIPv2 will use the multicast address 224.0.0.9.

Pic. 8 - R3's Update out Loopback 1.

Next output (pic. 9) shows what R3 is announcing out its Loopback2 interface. Both loopback interfaces are enabled in RIP so, naturally, the updates are sent out these interfaces. Take a look at the output and analyse both (pic. 8 and pic. 9) comparing them with the topology diagram (pic. 1).

Pic. 9 - R3's Update out Loopback 2.

Finally, what we have waited for is the answer to the question why R1 and R2 do not receive the subnets /28 from R3. Look at the below picture (pic. 10).

Pic. 10 - R3's update out F1/0.

Suprisingly, R3 does NOT advertise ANYTHING out towards R1 and R2 (out F1/0 interface). We understand, that R3 will not advertise out F1/0 what has been learned on this interface (split-horizon). But why does it not advertise both subnets configured on the loopback interfaces (172.31.3.0/28 and 172.31.3.16/28)?

The answer is the rules used in RIP in terms of sending and receiving updates.
However, before I'll show you all the rules RIP uses, let's finish our diagnostics and look at what R3is receiving from one of its neighbors R2 (pic. 11). Notice, that the update R3 receives from R2 does NOT contain network mask, only metric (hop-count) like explained in the previous lesson.

Pic. 11 - R2 Advertisement for R1 and R3.

RIPv1 Sending and Receiving Updates Rules
Now, let me show you the update rules RIP uses which should clarify its behavior shown in this lesson.

Pic. 12 - RIP Rules for Sending Updates.

Clearly, according to pic.12, R3 will not advertise /28 subnets since the egress interface (F1/0) DOES belong to the same major B network, but the network mask on this interface is NOT the same as the subnets being advertised. Egress interface uses /24, whereas the subnet candidates for advertisement use /28.

The only way to resolve this issue is to either re-address the subnets according to what is allowed in RIPv1 or use RIPv2 instead.

As for the receiving updates in RIP protocol, the rules look as follows:

Pic. 13 - RIP Rules for Receiving Updates.

Passive Interface in RIP Protocol

You may have noticed that updates are sent out of all interfaces enabled for RIP. Otherwise routing would not work properly.

But what if there is no router listening to these advertisements? A router can be connected to networks with no other routers in them. They must be advertised out other interfaces still. In such situation it is a waste of the bandwidth to send RIP advertisements every 30 seconds if no router listens to them.

The solution is to use the 'passive-interface' command under the RIP process. When used with RIP protocol, the command will prevent a router from sending advertisements out the passive interface, but the subnet/network address of this interface is going to be included in the updates sent out other interfaces. Also, passive interface in RIP is capable of receiving updates and processing them.

Be careful with making the interface 'passive' while using other routing protocol than RIP. The behavior of the same command will be different. In OSPF or EIGRP routing protocols, the 'passive-interface' command prevents these protocols from sending 'hello' packets which has serious implications. More on that in the upcoming posts.

As an example, in order to stop sending advertisements out R3's loopback interfaces, the configuration will look like the one shown below:

R3#configure terminal

R3(config)#router rip

R3(config-router)#passive-interface loopback1

R3(config-router)#passive-interface loopback2

This configuration optimizes RIP operation preventing it from sending its periodic advertisements out of both loopback interfaces.

Of course, in large systems using RIP is not a common solution. Those who have no other choice, would definitely choose RIPv2 rather than RIPv1. And this is going to be the topic of my next post which finalizes the discussion of RIP fundamentals.

Post Questions and Answers

As per request (look at comments below), I decided to post the explanation for the two very interesting scenarios I received from some anonymous person (forgive me but I did not see your name in the post).

First take a look at the picture below.

Pic. 14 - RIPv1 Scenarios.

Example 1

Notice that in RIPv1 auto-summarization to the class boundary is always in effect.

Also, notice that the update does NOT contain a network mask.

R1 receives two RIPv1 updates:

• 10.0.0.0 from R2.
• 10.0.1.0 from R3.

The result is as per the rules explain above (pic. 13). R1 is going to have only one RIP prefix which is 10.0.1.0 in its routing table. This is because the rule for receiving update is asking the following question (pic. 13):

Do any subnets of the same major class exist in the routing table?

Yes! 10.0.1.0 subnet exists, that is why 10.0.0.0 which is less specific (major class) is IGNORED.

Example 2

Notice that in RIPv1 auto-summarization to the class boundary is always in effect.

Also, notice that the update does NOT contain a network mask.

R1 receives the SAME prefix on two different interfaces F1/0 (10.0.4.1) and S0/1 (10.0.3.1).

If the metric is the same, R1 considers both paths: via F1/0 and S0/1 as equal cost paths and performs a load balance.

I hope that clarifies these two corner case scenarios!

Lesson 35 - Routing Information Protocol Part1

Now, that you have learned the principles regarding Distance Vector algorithm, it's time to look at the operation of the oldest distance vector routing protocol: RIP.

Routing Information Protocol is seldom used these days. It has been superseded by more sophisticated protocols (OSPF, EIGRP, IS-IS). However, Cisco still keeps it in the curriculum. All professionals up to the CCIE level (as of writing this post) need to know how it works. In order to enable RIP you must choose which version you want to run. By default, if you configure RIP the version used is version 1. You can change it to version 2 which is more preferred if one want to RIP to begin with. The below table summarizes the main feature of both versions.

Table 1- RIPv1 and RIPv2 Features.

Classful, Classless, and Summarization
Routers share their information (routing table) with their neighbors using advertisements. It is important to know that the shorter the routing table is, the less time a router needs to process the incoming packets in order to find the outbound (egress) interface and expedite them.

If your network design uses proper, consecutive IP scheme, a router can advertise fewer prefixes (routing entries) to their neighbors represented by so called summary routes. A summary route represents multiple more specific destinations. But the router which receives this summary route can still send packets towards the subnets that are being summarized. Consider the following picture (pic. 1).

Pic. 1 – Route Summarization.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In the pic. 1, there are four subnets located behind R1. Router R1 can advertise them ‘as they are’ towards R2. This way, R2 will populate its routing table with all four of them (10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24) with R1 as the gateway to these subnets. However, the subnet addresses behind R1 are designed to be represented by one summary route. This route is going to represent exactly these four subnets. So R1, instead of advertising the four of them, will announce only one address:

10.1.0.0/22

So the question is: how to summarize subnets/networks?

Assuming that IP addresses subnets/networks to be summarized are consecutive numbers when converted to binary, the rule to create the summary route presented in the pic.1 can be applied using three steps.


Step 1
Convert all consecutive summary candidates into binary. List them from the lowest number to the highest like presented in pic.1.

10.1.0.0/24 = 00001010.00000001.00000000.00000000
10.1.1.0/24 = 00001010.00000001.00000001.00000000
10.1.2.0/24 = 00001010.00000001.00000010.00000000
10.1.3.0/24 = 00001010.00000001.00000011.00000000

Step 2
Find the number of bits that is identical and draw the line to see how many bits do not change.

10.1.0.0/24 = 00001010.00000001.00000000.00000000
10.1.1.0/24 = 00001010.00000001.00000001.00000000
10.1.2.0/24 = 00001010.00000001.00000010.00000000
10.1.3.0/24 = 00001010.00000001.00000011.00000000

22 bits do not change = the length of the network mask representing all four entries.

Step 3
Advertise the address with the lowest number in the range using network mask length achieved in the step 2 (bits that never change give you the length of the network mask). The actual commands will be different depending which protocols you use. I will explain them in due time.

10.1.0.0/22 = 00001010.00000001.00000000.00000000
Netmask     = 11111111.11111111.11111100.00000000 = 255.255.252.0

Optionally, you can check if the summary route covers exactly the prefixes. Notice that the two of the bits that change in the third octet will tell you how many addresses have been represented by the summary route (aka aggregate). Look at the bits that do change (in red).

10.1.0.0/24 = 00001010.00000001.00000000.00000000
10.1.1.0/24 = 00001010.00000001.00000001.00000000
10.1.2.0/24 = 00001010.00000001.00000010.00000000
10.1.3.0/24 = 00001010.00000001.00000011.00000000

There are two bits that change in this range in the third byte. This number of bits with the exponent of 2, tells you how many subnets/networks are being summarized. Here: 2 to the power of 2 = 4. Exactly, four subnets have been summarized using prefix 10.1.0.0/22. So this prefix represents exactly the subnets in question.

Now, that you know how to summarize consecutive subnets/networks, let’s see what automatic summarization to the class boundary will look like if you use RIPv1 and have different classes of IP addresses in your desing. Consider the picture presented below (pic. 2).

Pic. 2 – RIPv1 Automatic Summarization to the Class Boundary.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

The routers R1 and R3 are boundary routers between two different classes. They will advertise class A address (10.0.0.0) since RIPv1 does it by default if the outbound interface (the one to send the advertisement) belongs to different class than the subnet being advertised. This will inevitably create confusion as far as R2 is concerned. It will think that both R1 and R3 are gateways to the same class A network 10.0.0.0. As a result of that, the packets destined to the subnets 10.1.1.0 and 10.1.2.0 will not be delivered properly.

In RIPv2 you can disable this automatic summarization by using ‘no auto-summary’ keyword in the ‘config-router’ configuration context. This option makes RIPv2 classless routing protocol (it can advertise subnets of major classes). Classless routing protocols can advertise full prefix (IP address and the network mask) without summarizing it to the class like shown in the pic. 2.

RIPv1 Configuration
In order to configure RIP in our design, we need to perform two steps.

Step 1
Enable RIPv1 protocol process in the global configuration context.

Step 2
Using ‘network’ statement in ‘config-router’ context, instruct the router which interfaces should participate in the RIP process. RIP will run on these interfaces. In RIP protocol the ‘network’ statement has to be followed by the Class A, B, or C address which instructs the router which interfaces should be RIP-enabled.

---

NOTICE!
The ‘network’ statement is one of the most misinterpreted keywords in Cisco IOS. RIP, OSPF, EIGRP use the ‘network’ statement to inform the router which interfaces should be enabled for the routing protocol. The ‘network’ statement does NOT advertise anything. Only when BGP protocol is used, the ‘network’ statement actually advertises the prefixes since BGP is an application using TCP (port 179) and is not run on the interfaces like all IGP protocols are.

---

Having said that, let’s enable RIPv1 in my design (pic. 3).

Pic. 3 – Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

R1 Configuration:

R1#configurer terminal

R1(config)#router rip

R1(config-router)#network 172.31.0.0

R1(config-router)#

R2 Configuration:

R2#configurer terminal

R2(config)#router rip

R2(config-router)#network 172.31.0.0

R2(config-router)#

R3 Configuration:

R3#configurer terminal

R3(config)#router rip

R3(config-router)#network 172.31.0.0

R3(config-router)#

R4 Configuration:

R4#configurer terminal

R4(config)#router rip

R4(config-router)#network 172.31.0.0

R4(config-router)#network 192.168.4.0

R4(config-router)#

R5 Configuration:

R5#configurer terminal

R5(config)#router rip

R5(config-router)#network 172.31.0.0

R5(config-router)#network 192.168.5.0

R5(config-router)#

I suggest that you analyze the topology, configuration and information in this post. There will be few issues we will come across here using RIPv1 (one of them I have not discussed yet but it will rear its ugly head on R3).

I will explain these problems in my next post. I will also show you how to check the configuration of RIP ('show' and 'debug' commands). Also, I will enable RIPv2 to show you the differences in their operation, and how to optimize and verify its operation.

Lesson 34 - Dynamic Routing Protocols Introduction

If you have read the previous post, you must have noticed that using a static routing method tends to be a bit cumbersome in larger implementations. Using one of the dynamic routing protocols feels like an easier solution in these scenarios.

In this post I will briefly explain the general concepts behind dynamic routing protocols. Then, we can jump to implementation fundamentals.

One way of classifying dynamic routing protocols is based on where they are used. This criterion allows us to distinguish between two major solutions:

1. Interior Gateway Protocols  (IGP) 
2. Exterior Gateway Protocols (EGP)

Common Interior Gateway Protocols are: 

• Routing Information Protocol (RIP), 
• Open Shortest Path First (OSPF), 
• Enhanced Interior Gateway Protocol (EIGRP, Cisco proprietary protocol), 
• Intermediate System to Intermediate System (IS-IS).

Exterior Gateway Protocols (currently there is only one in use)

• Border Gateway Protocol  (BGP)

IGPs are designed to work in private networks. EGPs are used to provide paths in the public network (Internet). 

We can also classify routing protocols based on the algorithm they use to distribute and maintain information (routing table). There are three major algorithms supported by Cisco routers:

1. Distance Vector (DV, aka Bellman-Ford) – example of protocol: RIP.
2. Link-State – example of protocols: OSPF, IS-IS.
3. Advanced Distance Vector – protocols: EIGRP (also BGP is partly distance vector protocol).

Understanding the algorithms helps us determine the proper solution for a given design. There is no one best routing protocol out there, but there could be the best one in a specific design.

In this post I am going to focus in on the first algorithm listed above.

Distance Vector Algorithm Characteristics

This method is sometimes referred to as ‘routing by rumor’. The main characteristics of this approach are:

• Routers do not know the topology of the network. They only know which is the outbound interface and the next-hop router’s IP address (vector) as well as the metric value which describes how far the destination is (distance).
• Routers advertise their full routing table periodically. This method of route distribution creates two problems: routing loops and counting to infinity. Special techniques were created to solve these issues (details later in the post).
• Routers perform automatic summarization if they are connected to different classful (A, B, C) networks.
• No VLSM support. All network masks must be identical if the subnets of a major class are used in the network (RIPv1). RIPv2 is classless (VLSM supported using ‘no auto-summary’ command).
• Routers are slow to converge. It takes a lot of time to invalidate lost routes and pick the new path if one is available as well as to synchronize their routing information.
• Routers use simple metric. The metric number tells a router how many routers the packet has to traverse in order to reach the destination. In modern networks bandwidth of the path is much more important than how many hops will be used.

The above characteristics do not encourage us to use this kind of solution in our modern networks. But knowing the DV rules help us appreciate protocols such as OSPF or EIGRP which are more likely to be used in our designs.

Let’s see how things work when DV algorithm is used. As an example, I will use RIP protocol hoping to explain the principles of operation and how the two design issues have been solved (routing loop and counting to infinity).

Distance Vector Principles of Operation

Consider this simple topology. Without getting into configuration (syntax) details let’s have a quick discussion on how information is distributed using DV algorithm. Initially, the routers recognize only connected subnets. They are populated in the routing table as soon as IP addresses and network masks are configured and they are activated (no shutdown).

Pic. 1 - Connected Subnets.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Let’s assume that we have enabled RIPv2 protocol in the topology presented above (pic. 1). This version of RIP allows the routers to announce both the subnet IP addresses and the network masks (we’ll put it into practice in the next post). 

The RIP process must be activated in the ‘config’ mode. Then we need to instruct it which interfaces should be activated in the RIP domain. This is configured in the ‘config-router’ mode (‘network’ statement).  The routers begin to ‘chat’ and advertise their routing tables every 30 seconds.

Pretend that R1’s timer of sending the advertisement has just kicked in (pic. 2). R1 is advertising its routing table out of the RIP-enabled interfaces (in my example all interfaces of all routers are in the RIP domain). This way, R2 learns about 10.1.1.0/24 subnet. So from R2’s perspective, R1 router becomes the gateway towards 10.1.1.0/24. 

Now, a word about the metric being advertised. 

Metric used in DV reflects how many routers the packet has to traverse to reach the destination network/subnet (so called 'hop-count'). R1’s routing table’s entries (subnets: 10.1.1.0/24 and 10.1.12.0/24) show the metric of ‘0’ hops (pic. 1) since they are directly connected to F0/0 and F0/1 interfaces respectively (they are local to R1). While advertising them to the neighbors (pic. 2), R1adds 1 hop (itself) to the existing metric found in the routing table.

---

NOTICE!
Bear in mind, that algorithm prompts the router to send the full routing table. Current implementation changes that behavior (split-horizon) but more on this later in the post.

---

Pic. 2 – R1’s RIP advertisements.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

R2 accepts the advertisement about 10.1.1.0/24. It puts this information in the RIP’s database and then it creates the entry in the routing table (purple color). Pay a close attention to what has just happened (pic. 2). The update arrives on R2’s F0/0 interface (RIP-enabled), sourced by the IP address of 10.1.12.1. This way, R2 considers its F0/0 the egress (outbound) interface towards the subnet advertised by R1. The IP address of the sender (10.1.12.1) becomes the next-hop IP address towards the subnet 10.1.1.0/24

Next, let’s imagine R2’s timer has expired and it is sending its routing table out F0/0 and F0/1. Please take a closer look at the picture 3 which shows this process in the graphical form. Just like previously R1 router has done, R2 is sending its routing table adding itself as an additional hop added to the existing metric (existing metric +1).

Pic. 3 – R2’s RIP advertisement.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Now, R1 and R3 accept the advertisement from R2 and register the information sent in their RIP databases (the interfaces process the update as they RIP-enabled). Appropriate entries in the routing tables also show the egress interfaces and the metric expressed in the number of ‘hops’ (how many routers the packet will have to traverse to reach the destination subnet). Also, the IP address of the gateway (the sender IP address) is registered. Again, take a look at pic.3 which shows the new entries (in purple).

Now is the time for R3 to send its own advertisement. Using the same logic you should be able to tell what is going to happen. Take a look at pic. 4 to see what is going to be advertised and what is going to be learned.

The advertisement sent out R3’s F0/0 interface is useless in our topology because there is no other router listening to it. In my next post, I will show you how to prevent a router from doing it. Advertisement sent out F0/1 interface contains information about R3’s directly connected subnet 10.1.3.0/24. Since the existing metric in R3’s routing table for this subnet is ‘0’ (directly connected to F0/0), R3 will add itself as the hop and advertise it with the metric of ‘1’ (existing metric + 1). R2is going to learn it on its F0/1 interface which becomes the outbound interface to reach the subnet 10.1.3.0/24. It is the interface to reach the advertising router’s IP address 10.1.23.3 after all.

Pic. 4 – R3’s RIP Advertisement.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Picture 4 shows this process.

This whole process of advertising the routing table out of all RIP-enabled interfaces occurs every 30 seconds but in fact, there is a jitter time introduced so this may vary between 25-30 seconds. WhenR2 advertising timer expires, it will pass the information contained in the its routing table on to R1. By doing this, R1 learns about all subnets R2 can reach, including 10.1.3.0/24 now (pic. 5).

Pic. 5 – R2’s RIP Advertisement.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

The process of spreading the information explained using this method is referred to as the ‘routing by rumor’. The state in which all routers have stable information about all networks/subnets that can be reached is called the ‘convergence’. Do not confuse it with ‘convergent networks’ which allow all sort of packet transmissions (voice, video, and data).

Take a look at picture 6. It shows that all routers can reach all the subnets available in the RIP domain. Convergence has been accomplished since their routing table are synchronized and up-to-date.

Pic. 6 – Convergence Achieved.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

The method of distributing information presented is prone to introduce two problems:

• Routing Loops
• Counting to Infinity

Of course, they have been resolved by using different techniques which I am going to explain later in the post.

Let’s take a look at the downside of using distance vector algorithm.

Routing Loops
In the picture 7, R1’s F0/0 interface. As soon as the IOS detects this fact, the entry in the routing table about 10.1.1.0/24 is immediately flushed (removed from the routing table completely).

Pic. 7 – R1’s F0/0 Interface Goes Down.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

As per the DV algorithm R1 would still wait till its advertisement timer expires. So instead of sending this ‘update’ immediately after it has lost the subnet, it will wait till its timer says: ‘now you can advertise your routing table’. This behavior might create a loop between R1 and R2 as far as the 10.1.1.0/24 subnet is concerned. Consider this situation depicted below.

Pic 8 – R2’s Advertising Timer Expires.

Icons designed by: Andrzej Szoblik - http://www.newo.pl


R2 is advertising its full routing table out of all RIP-enabled interfaces. In this announcement, there is 10.1.1.0/24 subnet. The metric being advertised is: ‘2’ (the existing metric on R2 + 1). By now, you already know that the advertising router is going to add itself as the hop to the metric of the subnet/network it advertises.

Here is the issue. R1 is receiving 10.1.1/0/24 with the metric of 2 hops, the egress interface (the one the ad came on) is F0/1, and the next-hop-address is 10.1.12.2. Look at the pic. 8 and tell me (I can’t hear you though), what would you do if you were R1? Obviously, you would reject this information because by looking at the topology diagram, you already know that 10.1.1.0/24 is inaccessible (down) now, and the only way to reach it is through R1, right?

But the problem is, that routers using DV algorithm do NOT know the topology like explained in the characteristics section. In fact, R1 IS going to accept the information and treat R2 as the gateway towards 10.1.1.0/24 !!!

Wow! As ridiculous as it sounds, it is exactly what would happen according to the rules set by the designers of this algorithm. So R1’s routing table is going to look like shown in the picture 8. Take a look at it now again!

We have a loop between R1 and R2 regarding 10.1.1.0/24. If R2 receives the packets destined to 10.1.1.0/24 subnet, according to its knowledge (current routing table), it is going to send it out F0/0 interface towards R1. This one in turn, will use its F0/1 interface for the destination 10.1.1.0/24, sending it back to R2. The packets will be looped until their TTL values are decremented reaching the value of TTL=0. Then, a router must drop the packet.

Counting To Infinity
A routing loop is not going to be the only problem here. R1 is going to accept advertisements fromR2 regarding 10.1.1.0/24 with the number of hops equal '2’. When R1 advertises its own routing table, it is going to add itself (as the hop) to the metric that already exists in the routing table. Look what is going to happen (pic. 9)

Pic. 9 – R1’s RIP Advertisement.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Initially, R2 is going to ignore the information about 10.1.1.0/24 from R1 containing the metric of ‘3’ hops since it has much better entry in the routing table (lower metric). However, it was R1 that initially sent the metric of ‘1’ hop. Now, the same R1 router keeps sending the metric of ‘3’ hops. The previous metric of ‘1’ is no longer refreshed. Since it uses the aging timer of 180 seconds (how long the information is valid), it finally accepts the entry with the metric of ‘3’ hops instead.

Then R2 begins to advertise the metric of 4 regarding 10.1.1.0/24 subnet out F0/0 and F0/1. You can predict what is going to happen. Remember, that entries must be refreshed every 30 seconds. If they are not refreshed, the ‘Invalidation Timer’ (180 seconds), allows to accept the entry with worse metric than previously. Take a look at the sequence of events in the picture 10.

Pic. 10 – Larger and Larger Metric Propagation.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

It would last forever despite of the fact that 10.1.1.0/24 is not reachable at all!

The Distance Vector algorithm uses a few techniques to prevent these two problems from happening. Here they are:

• Triggered Update (aka flash update)
• Route Poisoning
• Maximum Metric (RIP considers 16 hops as inaccessible)
• Poison Reverse
• Hold-Down Timer
• Split-Horizon

These methods deserve a few words of explanation.

Triggered Update

IOS uses this method to send the update immediately rather than wait for the advertisement timer to expire. However, there is no guarantee that some router in the chain is not going to send its own information before it receives this update. This might still lead to a situation where the two problems occur. So this method, as the only solution here, is not enough to make it work. Other methods must be used as well in order to avoid routing loops and counting to infinity.

Route Poisoning

Upon losing subnet/network reachability, a router is sending a triggered update. This update is going to include the maximum metric value (RIP=16 hops) which is considered as ‘subnet/network inaccessible’ (cannot be reached).

Maximum Metric (RIP=16)

If a RIP router receives an update about a network/subnet with the metric of 16 hops it is considered as inaccessible. This way, the advertising router is excluded from the list of gateways for the subnet/network advertised with the maximum metric.

Poison Reverse

Once a router receives the advertisement including the maximum metric, if it does not have an alternate path towards the subnet/network lost, it is going to send the same subnet/network prefix with the maximum metric (RIP=16) informing the other routers about it. This will also be sent back to the sender of this information it does not have an alternate path (this might be seen as violation of split-horizon, but remember the metric is the maximum value). Poisoning the path back to the advertising router is the way of informing it that the receiver of this information has no alternate path available either.

Hold-Down Timer

Upon receiving information from a neighbor that a subnet/network is inaccessible, the receiving router is going to enable a hold-down timer for 180 seconds. During this time, the receiving router keeps sending packet to the destination being inaccessible for some time rather than withdrawing the entry from its routing table. Why?

In the past, the routers did not have that much power and the media were unreliable. Interfaces were prone to flaps more often than in today’s reliable networks. An ‘interface flap’ is the condition when it goes down and up subsequently in a very short space of time (1-2 seconds perhaps). Under such circumstances, a router would advertise network as inaccessible and then as accessible again. Since it takes some CPU power to withdraw the entry and put it back in, the designers preferred to wait a bit longer to be absolutely sure (180 seconds by default) that the entry was supposed to be removed from the routing table. In case of an interface flapping, not only would the packets still be delivered but the CPU would not waste its ‘precious’ cycles on removing and putting the entry back in the routing table. 

Split-Horizon

This method prevents the loops from occurring in the scenario we have talked about. This technique prevents a router from sending information it learned back out the interface it was received on. Consider our first example. R2 sent information about 10.1.1.0/24 before R1 had had a chance to send the maximum metric towards R2 (subnet down). Split-Horizon prevents R2 from sending information about 10.1.1.0/24 it learned on its F0/0 interface back out the same interface. As a result of that, R1 is never going to receive information it sent towards R2 (10.1.1.0/24) and believe R2 could be the gateway to 10.1.1.0/24. Thus, there is no loop

In my next post I’m going to show you how to enable RIP and how all these techniques work in practice.