Home > Articles > Software Development & Management

  • Print
  • + Share This
Like this article? We recommend

Layer 3—RIP Network Redundancy

The Routing Information Protocol (RIP) is based on the Bellman-Ford distance vector algorithm. The idea behind the RIP is that each RIP router builds a one-dimensional array that contains a scalar notion of hops, to reach all other hops. (OSPF was able to more accurately use the notion of cost, which could capture information such as link speed.) RIP routers flood each other with their view of the network by first starting with directly connected neighbor routers, then modifying their vector if they find from peer updates that there is a shorter path.

After a few updates, a complete routing table is constructed. When a router detects a failure, the distance is updated to infinity. Ideally, all routers would eventually receive the proper update and adjust their tables accordingly. However, if the network is designed with redundancy, there can be issues in properly updating the tables to reflect a failed link. There are problems such as count to infinity and split horizon, which have various fixes to this protocol. The RIP was a first implementation of the distance vector algorithm. The RIPv2, the most common, addresses scalability and other limitations of the RIP.

To better understand the failover capabilities of RIPv2, the following test network was set up, shown in FIGURE 16.

Figure 16FIGURE 16 RIP Network Setup

CODE EXAMPLE 10 shows the server-to-client path before node failure. The highlighted lines show the path through the switch sw3.

CODE EXAMPLE 10 Server-to-Client Path Before Node Failure

server># traceroute client 
traceroute: Warning: Multiple interfaces found; using 11.0.0.51 @ hme0
traceroute to client (16.0.0.51), 30 hops max, 40 byte packets
 1 11.0.0.1 (11.0.0.1) 0.711 ms 0.524 ms 0.507 ms
 2 12.0.0.2 (12.0.0.2) 1.448 ms 0.919 ms 0.875 ms
 3 13.0.0.2 (13.0.0.2) 1.304 ms 0.977 ms 0.964 ms
 4 14.0.0.2 (14.0.0.2) 1.963 ms 1.091 ms 1.151 ms
 5 15.0.0.2 (15.0.0.2) 1.158 ms 1.059 ms 1.037 ms
 6 client (16.0.0.51) 1.560 ms 1.170 ms 1.107 ms

The following code examples show the initial routing tables. The highlighted line in CODE EXAMPLE 11 shows the path to the client through the switch sw3.

CODE EXAMPLE 11 Switch sw1 Initial Routing Table

 OR Destination    Gateway     Mtr  Flags   Use M-Use VLAN   Acct-1
*s 10.100.0.0/24   12.0.0.1     1 UG---S-um  32   0 net12  0   
*r 11.0.0.0/8     12.0.0.1     2 UG-----um  15   0 net12  0   
*d 12.0.0.0/8     12.0.0.2     1 U------u-  184   0 net12  0   
*d 13.0.0.0/8     13.0.0.1     1 U------u-  52   0 net13  0   
*r 14.0.0.0/8     13.0.0.2     2 UG-----um   1   0 net13  0   
*r 15.0.0.0/8     18.0.0.2     3 UG-----um   0   0 net18  0   
*r 16.0.0.0/8     13.0.0.2     4 UG-----um  10   0 net13  0   
*r 17.0.0.0/8     18.0.0.2     2 UG-----um   0   0 net18  0   
*d 18.0.0.0/8     18.0.0.1     1 U------u-  12   0 net18  0   
*d 127.0.0.1/8    127.0.0.1     0 U-H----um   0   0 Default 0   

CODE EXAMPLE 12 Switch sw2 Initial Routing Table

sw2:3 # sh ipr

 OR Destination    Gateway     Mtr  Flags   Use M-Use VLAN   Acct-1
*s 10.100.0.0/24   18.0.0.1     1 UG---S-um  81   0 net18  0   
*r 11.0.0.0/8     18.0.0.1     3 UG-----um   9   0 net18  0   
*r 12.0.0.0/8     18.0.0.1     2 UG-----um  44   0 net18  0   
*r 13.0.0.0/8     18.0.0.1     2 UG-----um   0   0 net18  0   
*r 14.0.0.0/8     17.0.0.2     2 UG-----um   0   0 net17  0   
*r 15.0.0.0/8     17.0.0.2     2 UG-----um   0   0 net17  0   
*r 16.0.0.0/8     17.0.0.2     3 UG-----um   3   0 net17  0   
*d 17.0.0.0/8     17.0.0.1     1 U------u-  17   0 net17  0   
*d 18.0.0.0/8     18.0.0.2     1 U------u-  478   0 net18  0 
*d 127.0.0.1/8    127.0.0.1     0 U-H----um   0   0 Default 0 
#
#

CODE EXAMPLE 13 Switch sw3 Initial Routing Table

sw3:3 # sh ipr

 OR Destination    Gateway     Mtr  Flags   Use M-Use VLAN   Acct-1
*s 10.100.0.0/24   13.0.0.1     1 UG---S-um  79   0 net13  0   
*r 11.0.0.0/8     13.0.0.1     3 UG-----um   3   0 net13  0   
*r 12.0.0.0/8     13.0.0.1     2 UG-----um  44   0 net13  0   
*d 13.0.0.0/8     13.0.0.2     1 U------u-  85   0 net13  0   
*d 14.0.0.0/8     14.0.0.1     1 U------u-  33   0 net14  0   
*r 15.0.0.0/8     14.0.0.2     2 UG-----um   0   0 net14  0   
*r 16.0.0.0/8     14.0.0.2     3 UG-----um  10   0 net14  0   
*r 17.0.0.0/8     14.0.0.2     2 UG-----um   0   0 net14  0   
*r 18.0.0.0/8     13.0.0.1     2 UG-----um   0   0 net13  0   
*d 127.0.0.1/8    127.0.0.1     0 U-H----um   0   0 Default 0   

The highlighted line in CODE EXAMPLE 14 shows the path to the server through the switch sw3.

CODE EXAMPLE 14 Switch sw4 Initial Routing Table

sw4:7 # sh ipr

 OR Destination    Gateway     Mtr  Flags   Use M-Use VLAN   Acct-1
*s 10.100.0.0/24   14.0.0.1     1 UG---S-um  29   0 net14  0   
*r 11.0.0.0/8     14.0.0.1     4 UG-----um   9   0 net14 
*r 12.0.0.0/8     14.0.0.1     3 UG-----um   0   0 net14 0   
*r 13.0.0.0/8     14.0.0.1     2 UG-----um   0   0 net14  0   
*d 14.0.0.0/8     14.0.0.2     1 U------u-  13   0 net14  0   
*d 15.0.0.0/8     15.0.0.1     1 U------u-  310   0 net15  0   
*r 16.0.0.0/8     15.0.0.2     2 UG-----um  16   0 net15  0   
*d 17.0.0.0/8     17.0.0.2     1 U------u-   3   0 net17  0   
*r 18.0.0.0/8     17.0.0.1     2 UG-----um   0   0 net17  0   
*d 127.0.0.1/8    127.0.0.1     0 U-H----um   0   0 Default 0   

The highlighted lines in the following output from running the traceroute client command show the new path from the server to the client through switch sw2 after switch sw3 fails.

server># traceroute client
traceroute: Warning: Multiple interfaces found; using 11.0.0.51 @ hme0
traceroute to client (16.0.0.51), 30 hops max, 40 byte packets
 1 11.0.0.1 (11.0.0.1) 0.678 ms 0.479 ms 0.465 ms
 2 12.0.0.2 (12.0.0.2) 1.331 ms 0.899 ms 0.833 ms
 3 18.0.0.2 (18.0.0.2) 1.183 ms 0.966 ms 0.953 ms 
 4 17.0.0.2 (17.0.0.2) 1.379 ms 1.082 ms 1.062 ms
 5 15.0.0.2 (15.0.0.2) 1.101 ms 1.024 ms 0.993 ms
 6 client (16.0.0.51) 1.209 ms 1.086 ms 1.074 ms

The following output shows the server pings.

64 bytes from client (16.0.0.51): icmp_seq=18. time=2. ms
64 bytes from client (16.0.0.51): icmp_seq=19. time=2. ms
64 bytes from client (16.0.0.51): icmp_seq=20. time=2. ms
ICMP Net Unreachable from gateway 12.0.0.2
 for icmp from server (11.0.0.51) to client (16.0.0.51)
ICMP Net Unreachable from gateway 12.0.0.2
..
..
for icmp from server (11.0.0.51) to client (16.0.0.51)
ICMP Net Unreachable from gateway 12.0.0.2
 for icmp from server (11.0.0.51) to client (16.0.0.51)
ICMP Net Unreachable from gateway 12.0.0.2
 for icmp from server (11.0.0.51) to client (16.0.0.51)
64 bytes from client (16.0.0.51): icmp_seq=41. time=2. ms
64 bytes from client (16.0.0.51): icmp_seq=42. time=2. ms
64 bytes from client (16.0.0.51): icmp_seq=43. time=2. ms

The fault detection and recovery took in excess of 21 seconds. The RIPv2 is widely available, however, the failure detection and recovery is not optimal. Further, there are other inherent robustness issues with the RIP.

  • + Share This
  • 🔖 Save To Your Account