Troubleshooting RIP

In this lesson we’ll take a look RIP, an old distance vector routing protocol that uses hop count as its metric. Unlike OSPF or EIGRP, RIP doesn’t establish a neighbor adjacency. Most of the RIP troubleshooting issues are about missing routing information.

Here are a number of things that could go wrong with RIP:

  • Wrong network command(s): the network command is used to tell RIP what networks to advertise but also where to send RIP routing updates to. Wrong (or missing) network commands will cause issues.
  • Interface shut: A network on an interface that is in shutdown will not be advertised.
  • Passive interface: An interface that has been configured as passive will not send any RIP updates.
  • Version mismatch: RIP has two versions, both routers should use the same version.
  • Max hop count: When the hop count is 16, the network is considered unreachable.
  • Route Filtering: Filters might prevent RIP updates from beint sent or received.
  • Authentication: Both RIP routers should have the same authentication parameters.
  • Split horizon: Networks that are learned on an interface are not advertised out of the same interface.
  • Auto-summarization: Causes issues with discontigious networks.

Let’s walk through these different issues and I’ll show you how to find and fix them.

RIP Network Command Issue

I’ll use these two routers:

R1 R2 loopback behind R2

R1 is supposed to learn about 2.2.2.0 /24 but there’s nothing in its routing table:

R1#show ip route rip
Codes: L - local, C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

It’s always a good idea to check on which interfaces RIP has been enabled or not:

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 0 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    192.168.21.0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 120)
R2#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 26 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Loopback0             2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    2.0.0.0
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 120)

Show ip protocols is a quick way to check on which interfaces RIP has been enabled. As you can see, RIP is running on R1 and R2. Take a close look at the networks though…R1 has an incorrect network. Let’s fix that:

R1(config)#router rip
R1(config-router)#no network 192.168.21.0
R1(config-router)#network 192.168.12.0

Let’s see if that helped:

R1#show ip route rip
Codes: L - local, C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets
R        2.2.2.0 [120/1] via 192.168.12.2, 00:00:17, FastEthernet0/0

There we go, problem solved!

Lesson learned: Make sure the correct network commands have been used.

RIP Interface Issue

Next issue, same two routers:

R1 R2 loopback behind R2

Just like the previous example, R1 is supposed to learn about 2.2.2.0 /24 but there’s nothing in the routing table:

R1#show ip route rip
Codes: L - local, C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

Let’s see if the networks have been configured correctly:

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 18 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.2         120      00:00:56
  Distance: (default is 120)
R2#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 6 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Loopback0             2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    2.0.0.0
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.1         120      00:00:03
  Distance: (default is 120)

No issues there, the correct networks are activated. Let’s check R2 since that’s the router that is supposed to advertise network 2.2.2.0 /24:

R2#show ip rip database
192.168.12.0/24    auto-summary
192.168.12.0/24    directly connected, FastEthernet0/0

The RIP database is a good place to check. If it’s not in the database, it can’t be advertised. R2 did have the correct network command so the network should be in its database. If you don’t see it here, it has to be an interface-related problem. Let’s check that:

R2#show ip interface brief | include Loopback0
Loopback0            2.2.2.2         YES manual administratively down down

Here’s the problem…the interface is down. RIP won’t put a network in its database when the interface is not up/up. Let’s fix it:

R2(config)#interface loopback 0
R2(config-if)#no shutdown

Take a look at the RIP database now:

R2#show ip rip database
2.0.0.0/8    auto-summary
2.2.2.0/24    directly connected, Loopback0
192.168.12.0/24    auto-summary
192.168.12.0/24    directly connected, FastEthernet0/0

There it is, now it can be advertised to R1. Let’s check R1:

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets
R        2.2.2.0 [120/1] via 192.168.12.2, 00:00:19, FastEthernet0/0

Problem solved! Lesson learned: Make sure your interfaces are up and running.

RIP Passive Interface Issue

Let’s check the next problem, same two routers:

R1 R2 loopback behind R2

Same issue, R1 is not learning 2.2.2.0 /24:

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

It’s empty…let’s check show ip protocols again:

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 6 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.2         120      00:46:14
  Distance: (default is 120)
R2#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 23 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Loopback0             2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    2.0.0.0
    192.168.12.0
  Passive Interface(s):
    FastEthernet0/0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.1         120      00:49:15
  Distance: (default is 120)

The output of show ip protocols is very valuable for troubleshooting. You can see that the networks have been configured correctly but R2 has a passive interface. This prevents it from advertising anything. Let’s fix it:

R2(config)#router rip
R2(config-router)#no passive-interface FastEthernet 0/0

Let’s check R1:

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets
R        2.2.2.0 [120/1] via 192.168.12.2, 00:00:12, FastEthernet0/0

Problem solved! Lesson learned: Make sure interfaces that connect to other RIP routers are not configured as passive.

RIP Version Mismatch Issue

Onto the next problem! Same two routers:

R1 R2 loopback behind R2

R1 isn’t learning 2.2.2.0 /24:

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

Let’s compare show ip protocols:

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 14 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 1, receive version 1
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       1     1
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.2         120      00:01:33
  Distance: (default is 120)
R2#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 27 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Loopback0             2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    2.0.0.0
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.1         120      01:03:49
  Distance: (default is 120)

If you look closely then you can see that we have a version mismatch. R1 is using RIP version 1 while R2 is using RIP version 2. Let’s fix this:

R1(config)#router rip
R1(config-router)#version 2

This should fix the problem…

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets
R        2.2.2.0 [120/1] via 192.168.12.2, 00:00:20, FastEthernet0/0

And it’s fixed.

Lesson learned: Make sure you use the same RIP version on both sides.

RIP Hop Count Issue

Same two routers:

R1 R2 loopback behind R2

Once again R1 is not learning 2.2.2.0 /24:

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

Let’s compare show ip protocols first:

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 22 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.2         120      00:00:27
  Distance: (default is 120)
R2#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Outgoing routes will have 15 added to metric
  Sending updates every 30 seconds, next due in 4 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Loopback0             2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    2.0.0.0
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.1         120      00:00:34
  Distance: (default is 120)

Everything seems to be OK. Correct networks, same version, no passive interfaces.

Let’s check if the network is in the RIP database of R2:

R2#show ip rip database
2.0.0.0/8    auto-summary
2.2.2.0/24    directly connected, Loopback0
192.168.12.0/24    auto-summary
192.168.12.0/24    directly connected, FastEthernet0/0

It’s in the RIP database. This might be a good moment to enable a debug:

R1#debug ip rip
RIP protocol debugging is on

RIP: received v2 update from 192.168.12.2 on FastEthernet0/0
     2.2.2.0/24 via 0.0.0.0 in 16 hops  (inaccessible)

There we go. R1 does receive an update but network 2.2.2.0 /24 has a hop count of 16. This can’t be installed in the routing table. In large networks this problem might occur but for this example I used an offset-list:

R2(config)#router rip
R2(config-router)#no offset-list 0 out 15

This should fix the problem:

R1#
RIP: received v2 update from 192.168.12.2 on FastEthernet0/0
     2.2.2.0/24 via 0.0.0.0 in 1 hops

R1 now shows a hop count of 1, this can be installed:

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets
R        2.2.2.0 [120/1] via 192.168.12.2, 00:00:04, FastEthernet0/0

There we go, problem solved.

Lesson learned: a hop count of 16 is unreachable for RIP. If the network is small, check for offset-lists that increased the metric.

RIP Authentication Issue

Onto the next issue…

R1 R2 loopback behind R2

This is getting old but R1 once again can’t learn 2.2.2.0 /24:

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

Nothing here…let’s check show ip protocols:

R1#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 23 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2                    MY_CHAIN
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.2         120      00:01:01
  Distance: (default is 120)
R2#show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 12 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Loopback0             2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    2.0.0.0
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.1         120      00:15:43
  Distance: (default is 120)

Everything is looking good, you can see that R1 has a key-chain. This means that R1 has authentication enabled.

Just to try something else, let’s enable a debug on these routers:

R1 & R2 #debug ip rip
RIP protocol debugging is on

You’ll see this:

R2#
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.2)
RIP: build update entries
        2.2.2.0/24 via 0.0.0.0, metric 1, tag 0

R2 is sending the RIP update, no issues here so it’s probably related to R1:

R1#
RIP: ignored v2 packet from 192.168.12.2 (invalid authentication)

There we go, R1 is ignoring the RIP update because of an authentication mismatch. RIP authentication is done on the interface so let’s check the differences:

R1#show run interface FastEthernet 0/0
Building configuration...

Current configuration : 171 bytes
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip rip authentication mode md5
 ip rip authentication key-chain MY_CHAIN
 duplex auto
 speed auto
end
R2#show run interface FastEthernet 0/0
Building configuration...

Current configuration : 97 bytes
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 duplex auto
 speed auto
end

There we go, R1 has authentication while R2 doesn’t. Let’s fix it:

R1(config)#interface FastEthernet 0/0
R1(config-if)#no ip rip authentication mode md5
R1(config-if)#no ip rip authentication key-chain MY_CHAIN

The “quick fix” is to disable authentication. This should do the job:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

579 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. In the last case route summarization . Was it the rip actually load balancing that causes some packets not to reach?

  2. Hello Jobin

    In a sense, you are correct. RIP does perform load balancing across multiple paths to the same destination that have the same metric. In this case, the problem is that RIP is interpreting specific networks using their classful subnet masks and the load balancing feature is being implemented with incorrect criteria.

    Specifically, R2 is being told that it can reach 172.16.3.0/24 via R3 and 172.16.1.0/24 via R1. However, when R2 receives this information, what it does is it replaces the /24 prefix with the /16 classful prefix, because the specific r

    ... Continue reading in our forum

  3. Means this network is 2 hops away i.e. via 1 router then another.

  4. ‘RIP is an old distance vector protocol’. Does this mean it is not used much in actual networking nowadays?

4 more replies! Ask a question or join the discussion by visiting our Community Forum