- Physical Network Topology and Availability
- Layer 2 Availability: Trunking —802.3ad—Link Aggregation
- Layer 2 Trunking Availability Strategies using SMLT and DMLT
- Layer 2 Availability: Spanning Tree Protocol
- Layer 3—VRRP Router Redundancy
- Layer 3—IPMP—Host Network Interface Redundancy
- Layer 3—Integrated VRRP and IPMP
- Layer 3—OSPF Network Redundancy— Rapid Convergence
- Layer 3—RIP Network Redundancy
- Conclusion
- About the Authors
Layer 3RIP 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 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.