From RIP to EIGRP
The following subsections briefly introduce the RIP, IGRP, and EIGRP routing protocols. IGRP and EIGRP were developed to overcome the limitations of the original RIP design.
RIP—A Distance-Vector Routing Protocol (Bellman-Ford-Fulkerson)
RIP had been around for quite a while. As Jeff Doyle put it, "RIP is either unjustly maligned or undeservedly popular."[2] RIP comes in two flavors: RIPv1, which is classful, and RIPv2, which is classless. It supports multicast, broadcast, and (under certain conditions) unicast behavior. The most dominant constraint of both RIP versions is the hop-count limit of 15, which limits the network diameter of deployments.
RIP is a distance-vector protocol, designed for rather small networks, contiguous address blocks, and homogeneous data links. From the protocol point of view, RIPv1 and RIPv2 speakers and listeners can happily coexist; the necessary compatibility mechanisms work well. However, this usually introduces undesirable effects with regard to classful behavior and summarization. Therefore, the recommendation is not to use RIPv1 whenever possible or at least not mix RIPv1 and RIPv2. In addition, RIPv2 introduces authentication and prefix tagging and is based on multicast transmission facilitating 224.0.0.9 and 520/udp as a transport vehicle.
Contrasting common beliefs that it is archaic and obsolete, RIP still plays an important role in system-integration scenarios. It is the least common denominator for Microsoft gateways and cheap appliance routers that lack support of more sophisticated dynamic routing protocols. Besides, in small LAN topologies, RIP certainly is up to the job, and system administrators can easily grasp its concepts and feel comfortable. Service providers can as well easily control RIP routes within customer virtual private networks (VPNs), while allowing customer premises equipment (CPE) to inject routes themselves.
(E)IGRP
The proprietary Cisco protocols IGRP and EIGRP were originally developed to overcome some of the limitations of RIP. IGRP has almost entirely disappeared and is not deployed anymore, although it is still supported.
EIGRP has evolved into quite a powerful and useful routing protocol including advanced features, the DUAL algorithm (Diffuse Update Algorithm), and a composite metric. EIGRP is the only routing protocol that supports non-IP network layer protocols such as AppleTalk and Internetwork Packet Exchange (IPX), with the notable exception of IS-IS, which natively supports IP and ISO CLNP (Connectionless Network Protocol).
Discussion of (E)IGRP goes beyond the scope of this book. Once again, I recommend Jeff Doyle's excellent two volumes of Routing TCP/IP for an in-depth introduction as well Ivan Pepelnjak's classic textbook EIGRP Network Design Solutions (Cisco Press, 2000).
Lab 9-1: RIPv2 Scenario
For this lab, GateD is running on ganymed, MRTd is running on castor and callisto, and Cisco IOS Software is running on scar. Figure 9-1 shows the topology.
For a detailed log output of gated, send a kill –SIGINT to the running gated process. You can also access the gated interactive interface via telnet localhost 616 or use the ripquery utility for RIP status information. A possible expansion of this setup would be to include routed, which was discussed thoroughly in Chapter 1, "Operating System Issues and Features—The Big Picture."
The lab uses regular interfaces, VLAN interfaces, alias addresses, and loopback addresses to demonstrate the independence of the routing engines from Layer 2 and virtual interfaces. This is also valid for WAN subinterfaces and tunnels of various kinds as long as the operating system is capable of providing a proper interface abstraction (virtual interface).
As you can see from the routing table outputs, the dynamic daemons internally use the concept of administrative distance (preference), but externally only the notion of metrics has relevance. Throughout this lab, we use RIPv2 multicast only. Example 9-1 shows the 224.0.0.9 multicast address in the netstat output (highlighted line); it is automatically added by the kernel.
NOTE
Per default, GateD turns RIP on. If you do not want to run the RIP module, you have to explicitly turn it off in the GateD configuration file with the command rip off (as presented in the GateD configuration in Example 9-1) or disable this behavior at compile time, as demonstrated in the GateD setup in Chapter 1.
Example 9-1. GateD RIPv2 Configuration and Output on Ganymed
[root@ganymed:~#] cat /etc/gated.cfg #rip off; rip on{ interface ne4 ne3 vlan0 ripin ripout version 2 multicast; }; [root@ganymed:~#] netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 111.11.117.1 UGS 1 3831 1500 ne5 127/8 127.0.0.1 UR 0 0 33224 lo0 127.0.0.1 127.0.0.1 UH 1 0 33224 lo0 192.168.1/24 link#1 UC -210 0 1500 ne3 192.168.1.1 52:54:5:e3:51:87 UHL 1 1916 1500 ne3 192.168.1.2 8:0:46:64:74:1b UHL 1 4615 1500 ne3 192.168.1.254 127.0.0.1 UGHS 0 0 33224 lo0 192.168.2/24 link#2 UC 0 0 1500 ne4 192.168.2.7 0:10:5a:c4:2c:4 UHL 5 2505 1500 ne4 192.168.7/24 192.168.2.7 UG 2 821 1500 ne4 192.168.13.0/29 192.168.2.7 UG 0 0 1500 ne4 192.168.14/24 192.168.1.1 UG 0 0 1500 ne3 192.168.17.0/29 192.168.2.7 UG 0 0 1500 ne4 192.168.44.1 192.168.44.1 UH 0 0 33224 lo1 192.168.45/24 192.168.2.7 UG 0 0 1500 ne4 192.168.80/24 link#16 UC 0 0 1496 vlan0 192.168.201.2 192.168.2.7 UGH 0 0 1500 ne4 111.11.117/24 link#3 UC 0 0 1500 ne5 111.11.117.1 0:5:9a:5b:23:fc UHL 1 0 1500 ne5 224.0.0.9 127.0.0.1 UH 1 1315 33224 lo0
Example 9-2 shows the advanced capabilities of the Linux ip tool. It presents the dynamic source that the routes were learned from via identifiers (Zebra, MRT, GateD), as well as the callisto MRTd configuration. The MRTd intrinsic routing table shows how cost (preference) is used internally with regard to the RIB (highlighted text). Note that connected and static routes are explicitly marked as Kernel in the MRTd global routing table (highlighted text). Example 9-3 presents the topology from castor's point of view.
Example 9-2. MRTd RIPv2 Configuration and Output on Callisto
[root@callisto:~#] ip route 192.168.201.2 via 192.168.14.254 dev eth0 proto mrt 192.168.44.1 via 192.168.45.254 dev eth1 proto mrt 192.168.17.0/29 via 192.168.14.254 dev eth0 proto mrt 192.168.13.0/29 via 192.168.14.254 dev eth0 proto mrt 192.168.7.0/24 via 192.168.14.254 dev eth0 proto mrt 111.11.117.0/24 via 192.168.45.254 dev eth1 proto mrt 192.168.2.0/24 via 192.168.45.254 dev eth1 proto mrt 192.168.80.0/24 via 192.168.45.254 dev eth1 proto mrt 192.168.1.0/24 dev eth1 scope link 192.168.1.0/24 dev ipsec0 proto kernel scope link src 192.168.1.1 192.168.14.0/24 dev eth0 scope link 192.168.45.0/24 dev eth1 proto kernel scope link src 192.168.45.1 127.0.0.0/8 dev lo scope link default via 192.168.1.254 dev eth1 [root@callisto:~#] netstat -rne Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.201.2 192.168.14.254 255.255.255.255 UGH 0 0 0 eth0 192.168.44.1 192.168.45.254 255.255.255.255 UGH 0 0 0 eth1 192.168.17.0 192.168.14.254 255.255.255.248 UG 0 0 0 eth0 192.168.13.0 192.168.14.254 255.255.255.248 UG 0 0 0 eth0 192.168.7.0 192.168.14.254 255.255.255.0 UG 0 0 0 eth0 111.11.117.0 192.168.45.254 255.255.255.0 UG 0 0 0 eth1 192.168.2.0 192.168.45.254 255.255.255.0 UG 0 0 0 eth1 192.168.80.0 192.168.45.254 255.255.255.0 UG 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.45.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1 callisto-MRTd# sh config ! enable password ******** router rip network 192.168.1.0/24 network 192.168.14.0/24 redistribute connected redistribute static redistribute kernel ! route 0.0.0.0/0 192.168.1.254 debug all /var/log/mrtd.log 0 callisto-MRTd# sh rib 38 active prefixes 17 active generic attributes 13 active route heads 17 active route nodes 7 inet gateway(s)/nexthop(s) registered 0.0.0.0 on lo flags 0x8 (count 3) 0.0.0.0 on eth0 flags 0x8 (count 4) 0.0.0.0 on eth1 flags 0x8 (count 7) 0.0.0.0 on ipsec0 flags 0x8 (count 3) 192.168.1.254 on eth1 flags 0x2 (count 1264) 192.168.14.254 on eth0 flags 0x2 (count 668) 192.168.45.254 on eth1 flags 0x2 (count 19) callisto-MRTd# sh ip rip Routing Protocol is "rip" Listening on port 520 (socket 13) Sending updates every 30 seconds jitter [-50..50], next due in 20 seconds Triggered update and split horizon (no poisoned reverse) implemented Invalid after 180, hold down 120, flushed after 300 seconds Interface enabled: eth1 eth0 Number of routes in routing table: 12 Callisto-MRTd# sh ip rip routes P Pref Time Destination Next Hop f Cost Time * R 120 04:57:04 0.0.0.0/0 192.168.14.254 eth0 2 20 > S 1 05:04:39 0.0.0.0/0 192.168.1.254 eth1 1 ---- * R 120 05:04:30 192.168.1.0/24 192.168.45.254 eth1 2 2 > C 0 05:04:39 192.168.1.0/24 0.0.0.0 ipsec0 1 ---- R 120 00:00:20 192.168.2.0/24 192.168.14.254 eth0 3 20 > R 120 00:00:02 192.168.2.0/24 192.168.45.254 eth1 2 2 R 120 00:00:02 192.168.7.0/24 192.168.45.254 eth1 3 2 > R 120 04:57:06 192.168.7.0/24 192.168.14.254 eth0 2 20 R 120 00:00:02 192.168.13.0/29 192.168.45.254 eth1 4 2 > R 120 04:56:44 192.168.13.0/29 192.168.14.254 eth0 2 20 * R 120 05:02:39 192.168.14.0/24 192.168.45.254 eth1 3 2 > C 0 05:04:39 192.168.14.0/24 0.0.0.0 eth0 1 ---- R 120 00:00:02 192.168.17.0/29 192.168.45.254 eth1 4 2 > R 120 04:56:23 192.168.17.0/29 192.168.14.254 eth0 2 20 > R 120 00:00:02 192.168.44.1/32 192.168.45.254 eth1 2 2 * R 120 00:00:02 192.168.45.0/24 192.168.45.254 eth1 5 2 > C 0 00:47:47 192.168.45.0/24 0.0.0.0 eth1 1 ---- R 120 00:00:20 192.168.80.0/24 192.168.14.254 eth0 3 20 > R 120 00:00:02 192.168.80.0/24 192.168.45.254 eth1 2 2 R 120 00:00:02 192.168.201.2/32 192.168.45.254 eth1 4 2 > R 120 04:57:06 192.168.201.2/32 192.168.14.254 eth0 2 20 > R 120 00:00:02 111.11.117.0/24 192.168.45.254 eth1 2 2 callisto-MRTd# sh ip routes Number of Unique Destinations: 13, Number of Entries: 17 Status code: > best, * valid, i - internal, x - no next-hop, X - no install P Pref Time Destination Next Hop If Kernel > S 1 05:04:57 0.0.0.0/0 192.168.1.254 eth1 K R 120 04:57:22 0.0.0.0/0 192.168.14.254 eth0 >iC 0 05:04:57 127.0.0.0/8 0.0.0.0 lo K > C 0 05:04:57 192.168.1.0/24 0.0.0.0 ipsec0 K R 120 05:04:48 192.168.1.0/24 192.168.45.254 eth1 > R 120 00:00:20 192.168.2.0/24 192.168.45.254 eth1 > R 120 04:57:24 192.168.7.0/24 192.168.14.254 eth0 > R 120 04:57:02 192.168.13.0/29 192.168.14.254 eth0 > C 0 05:04:57 192.168.14.0/24 0.0.0.0 eth0 K R 120 05:02:57 192.168.14.0/24 192.168.45.254 eth1 > R 120 04:56:41 192.168.17.0/29 192.168.14.254 eth0 > R 120 00:00:20 192.168.44.1/32 192.168.45.254 eth1 > C 0 00:48:05 192.168.45.0/24 0.0.0.0 eth1 R 120 00:00:20 192.168.45.0/24 192.168.45.254 eth1 > R 120 00:00:20 192.168.80.0/24 192.168.45.254 eth1 > R 120 04:57:24 192.168.201.2/32 192.168.14.254 eth0 > R 120 00:00:20 111.11.117.0/24 192.168.45.254 eth1
Example 9-3. RTd RIPv2 Configuration and Output on Castor
castor-MRTd# sh config ! enable password ******** router rip network 192.168.2.0/24 network 192.168.7.0/24 network 192.168.80.0/24 redistribute connected redistribute static redistribute kernel ! route 0.0.0.0/0 192.168.2.254 debug all /var/log/mrtd.log 0 castor-MRTd# show timers Timer Master: Interval=(37), NextFire=(5) Timer RIP update timer: Interval 37 Base 30 Exponent 0 Jitter 0 [-50..50] Flags 0x20Timeleft 5 Timer kernel routes timeout timer: Interval 120 Base 120 Exponent 0 Jitter 0 [0..0] Flags
Example 9-4 shows a standard Cisco RIPv2 configuration, and Example 9-5 shows the corresponding Cisco Express Forwarding (CEF) output to demonstrate CEF's view of two equal-cost paths with per-packet load sharing configured (highlighted text). This CEF example should also be seen as a demonstration of the forwarding discussion in Chapter 8.
NOTE
This book does not contain a detailed CEF introduction. Consult Cisco.com for a better understanding of Example 9-5, which is presented only to show the correlation of the CEF and routing table.
Example 9-4. Cisco IOS RIPv2 Configuration and Output on Scar
scar# sh running-config ... router rip version 2 traffic-share min across-interfaces redistribute connected redistribute static passive-interface Serial0 passive-interface Serial1 passive-interface Serial2 passive-interface Serial3 network 192.168.7.0 network 192.168.14.0 maximum-paths 2 no auto-summary ... scar# sh ip rip database 0.0.0.0/0 auto-summary 0.0.0.0/0 redistributed [1] via 0.0.0.0, 192.168.1.0/24 auto-summary 192.168.1.0/24 [1] via 192.168.14.1, 00:00:04, Ethernet1 192.168.2.0/24 auto-summary 192.168.2.0/24 [1] via 192.168.7.7, 00:00:14, Ethernet0 192.168.7.0/24 auto-summary 192.168.7.0/24 directly connected, Ethernet0 192.168.13.0/24 auto-summary 192.168.13.0/29 redistributed [1] via 0.0.0.0, 192.168.14.0/24 auto-summary 192.168.14.0/24 directly connected, Ethernet1 192.168.17.0/24 auto-summary 192.168.17.0/29 redistributed [1] via 0.0.0.0, 192.168.44.0/24 auto-summary 192.168.44.1/32 [2] via 192.168.7.7, 00:00:14, Ethernet0 [2] via 192.168.14.1, 00:00:04, Ethernet1 192.168.45.0/24 auto-summary 192.168.45.0/24 [1] via 192.168.14.1, 00:00:04, Ethernet1 192.168.80.0/24 auto-summary 192.168.80.0/24 [1] via 192.168.7.7, 00:00:14, Ethernet0 192.168.201.0/24 auto-summary 192.168.201.2/32 redistributed [1] via 0.0.0.0, 111.11.117.0/24 auto-summary 111.11.117.0/24 [2] via 192.168.7.7, 00:00:14, Ethernet0 [2] via 192.168.14.1, 00:00:04, Ethernet1 scar# sh ip route Codes: C - connected, S - static, I - IGRP, 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, E - EGP i - IS-IS, 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 Gateway of last resort is 192.168.7.7 to network 0.0.0.0 192.168.13.0/29 is subnetted, 1 subnets C 192.168.13.0 is directly connected, TokenRing0 C 192.168.14.0/24 is directly connected, Ethernet1 192.168.44.0/32 is subnetted, 1 subnets R 192.168.44.1 [120/2] via 192.168.14.1, 00:00:12, Ethernet1 [120/2] via 192.168.7.7, 00:00:06, Ethernet0 R 192.168.45.0/24 [120/1] via 192.168.14.1, 00:00:12, Ethernet1 192.168.201.0/32 is subnetted, 1 subnets C 192.168.201.2 is directly connected, Loopback0 R 192.168.80.0/24 [120/1] via 192.168.7.7, 00:00:06, Ethernet0 R 111.11.117.0/24 [120/2] via 192.168.14.1, 00:00:12, Ethernet1 [120/2] via 192.168.7.7, 00:00:06, Ethernet0 C 192.168.7.0/24 is directly connected, Ethernet0 192.168.17.0/29 is subnetted, 1 subnets C 192.168.17.0 is directly connected, TokenRing1 R 192.168.1.0/24 [120/1] via 192.168.14.1, 00:00:12, Ethernet1 R 192.168.2.0/24 [120/1] via 192.168.7.7, 00:00:06, Ethernet0 S* 0.0.0.0/0 [1/0] via 192.168.7.7 scar# sh ip route 192.168.44.1 Routing entry for 192.168.44.1/32 Known via "rip", distance 120, metric 2 Redistributing via rip Last update from 192.168.7.7 on Ethernet0, 00:00:01 ago Routing Descriptor Blocks: 192.168.14.1, from 192.168.14.1, 00:00:16 ago, via Ethernet1 Route metric is 2, traffic share count is 1 * 192.168.7.7, from 192.168.7.7, 00:00:01 ago, via Ethernet0 Route metric is 2, traffic share count is 1 scar# traceroute 192.168.44.1 Type escape sequence to abort. Tracing the route to 192.168.44.1 1 192.168.7.7 0 msec 192.168.14.1 4 msec 192.168.7.7 0 msec 2 192.168.44.1 4 msec 0 msec 0 msec
Example 9-5. Cisco IOS CEF Configuration and Output on Scar
scar# sh ip cef summary IP CEF with switching (Table Version 43), flags=0x0 30 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 1 30 leaves, 18 nodes, 22496 bytes, 52 inserts, 22 invalidations 2 load sharing elements, 632 bytes, 2 references universal per-destination load sharing algorithm, id C5B17D30 3(0) CEF resets, 4 revisions of existing leaves Resolution Timer: Exponential (currently 1s, peak 1s) 2 in-place/0 aborted modifications refcounts: 4905 leaf, 4864 node Adjacency Table has 2 adjacencies scar# sh ip cef Prefix Next Hop Interface 0.0.0.0/0 192.168.7.7 Ethernet0 0.0.0.0/32 receive 192.168.1.0/24 192.168.14.1 Ethernet1 192.168.2.0/24 192.168.7.7 Ethernet0 192.168.7.0/24 attached Ethernet0 192.168.7.0/32 receive 192.168.7.7/32 192.168.7.7 Ethernet0 192.168.7.254/32 receive 192.168.7.255/32 receive 192.168.13.0/29 attached TokenRing0 192.168.13.0/32 receive 192.168.13.1/32 receive 192.168.13.7/32 receive 192.168.14.0/24 attached Ethernet1 192.168.14.0/32 receive 192.168.14.1/32 192.168.14.1 Ethernet1 192.168.14.254/32 receive 192.168.14.255/32 receive 192.168.17.0/29 attached TokenRing1 192.168.17.0/32 receive 192.168.17.1/32 receive 192.168.17.7/32 receive 192.168.44.1/32 192.168.14.1 Ethernet1 192.168.7.7 Ethernet0 192.168.45.0/24 192.168.14.1 Ethernet1 192.168.80.0/24 192.168.7.7 Ethernet0 192.168.201.2/32 receive 111.11.117.0/24 192.168.14.1 Ethernet1 192.168.7.7 Ethernet0 224.0.0.0/4 0.0.0.0 224.0.0.0/24 receive 255.255.255.255/32 receive scar# sh ip cef 192.168.44.1 192.168.44.1/32, version 40, per-packet sharing 0 packets, 0 bytes via 192.168.14.1, Ethernet1, 0 dependencies traffic share 1, current path next hop 192.168.14.1, Ethernet1 valid adjacency via 192.168.7.7, Ethernet0, 0 dependencies traffic share 1 next hop 192.168.7.7, Ethernet0 valid adjacency 0 packets, 0 bytes switched through the prefix scar# sh cef not-cef-switched CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag RP 0 0 0 0 2987 0 0 0 scar#sh cef drop CEF Drop Statistics Slot Encap_fail Unresolved Unsupported No_route No_adj ChkSum_Err RP 0 0 0 4 0 0
Example 9-6. Zebra RIPv2 Configuration and Output on Castor
[root@castor:~#] telnet localhost 2602 Trying 127.0.0.1... Connected to localhost (127.0.0.1) Escape character is '^]'. Hello, this is zebra (version 0.94). Copyright 1996-2002 Kunihiro Ishiguro. User Access Verification Password: castor-ripd# sh running-config Current configuration: ! hostname castor-ripd password zebra log file /var/log/ripd.log ! interface xl0 ip rip send version 2 ip rip receive version 2 ! interface ed0 ip rip send version 2 ip rip receive version 2 ! interface lo0 interface vlan8 router rip redistribute kernel redistribute connected redistribute static network 192.168.2.0/24 network 192.168.7.0/24 network 192.168.80.0/24 ! line vty ! end castor-ripd# sh ip protocols Routing Protocol is "rip" Sending updates every 30 seconds with +/-50%, next due in 8 seconds Timeout after 180 seconds, garbage collect after 120 seconds Outgoing update filter list for all interface is not set Incoming update filter list for all interface is not set Default redistribution metric is 1 Redistributing: kernel connected static Default version control: send version 2, receive version 2 Interface Send Recv Key-chain xl0 2 2 ed0 2 2 vlan8 2 2 Routing for Networks: 192.168.2.0/24 192.168.7.0/24 192.168.80.0/24 Routing Information Sources: Gateway BadPackets BadRoutes Distance Last Update 192.168.2.254 0 0 120 00:00:21 192.168.7.254 0 0 120 00:00:25 192.168.80.254 0 0 120 00:00:21 Distance: (default is 120) castor-ripd# sh ip rip Codes: R - RIP, C - connected, O - OSPF, B - BGP (n) - normal, (s) - static, (d) - default, (r) - redistribute, (i) - interface Network Next Hop Metric From Time K(r) 0.0.0.0/0 192.168.2.254 1 self K(r) 192.168.1.0/24 192.168.2.254 1 self C(i) 192.168.2.0/24 0.0.0.0 1 self C(i) 192.168.7.0/24 0.0.0.0 1 self K(r) 192.168.13.0/29 192.168.7.254 1 self K(r) 192.168.14.0/24 192.168.7.254 1 self K(r) 192.168.17.0/29 192.168.7.254 1 self K(r) 192.168.44.1/32 192.168.2.254 1 self K(r) 192.168.45.0/24 192.168.7.254 1 self C(i) 192.168.80.0/24 0.0.0.0 1 self K(r) 192.168.201.2/32 192.168.7.254 1 self K(r) 111.11.117.0/24 192.168.2.254 1 self
Lab 9-2: RIP Neighbor Granularity
For this lab, we look at the communication between scar (running Cisco IOS RIPv2 as well in Example 9-7) and callisto (running Zebra RIPv2 in Example 9-8). A combination of the passive-interface and neighbor commands offers granularity in the choice of RIP neighbors that cannot be achieved with the network command alone.
This lab results in unicast RIPv2 communication between the two neighbors, while suppressing multicast messages on 192.168.14.0/24 via the passive-interface command. An additional benefit of the unicast neighbor command is its use for nonbroadcast media such as Frame Relay. The same effect (unicast behavior) can be accomplished with GateD via the sourcegateways
For even more granularity, Zebra, GateD, and to some extent MRTd offer offset- lists, route maps, distribute lists, access lists, and metric and distance/preference manipulation.
Example 9-7. Cisco IOS RIPv2 Neighbor Configuration on Scar
scar# sh running-config
...
router rip
version 2
traffic-share min across-interfaces
redistribute connected
redistribute static
passive-interface Ethernet1
passive-interface Serial0
passive-interface Serial1
passive-interface Serial2
passive-interface Serial3
network 192.168.7.0
network 192.168.14.0
neighbor 192.168.14.1
maximum-paths 2
no auto-summary
...
Example 9-8. Zebra RIPv2 Neighbor Configuration on Callisto
[root@callisto:~#] cat /usr/local/etc/ripd.conf ... router rip redistribute connected redistribute static network 192.168.1.0/24 network 192.168.14.0/24 neighbor 192.168.14.254 passive-interface eth0 ...
Lab 9-3: RIPv2 via GateD
All UNIX gateways are running GateD now to demonstrate its RIP capabilities. The GateD Interactive Interface (GII), as shown in Example 9-9, provides the RIP information on callisto.
Example 9-9. GateD RIPv2 Configuration and Output on Callisto
[root@callisto:~#] cat /etc/gated.cfg rip on{ interface eth0 eth1 ripin ripout version 2 multicast; }; [root@callisto:~#] telnet localhost 616 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Password? 100 Gated Interactive Interface. Version gated-public-3_6 GateD-callisto> show interface 100 #ind name address mtu flags 100 #1 lo 127.0.0.1 16436/16372 Up Loopback 100 #2 eth0 192.168.14.1 1500/1436 Up Broadcast Multicast 100 #3 eth1 192.168.1.1 1500/1436 Up Broadcast Multicast 100 #3 eth1 192.168.45.253 1500/1436 Up Broadcast Multicast GateD-callisto> show timer 100 Name Task Last Next Intrvl Jitter flags 100 AGE IF 00:00s 00:57s 00:00s 00:00s100 Flash RIP 00:01s 00:00s 00:00s 00:00s 100 Update RIP 00:03s 00:27s 00:30s 00:00s <> 100 Age RIP 00:00s 00:35s 00:00s 00:00s 100 IfCheck KRT 00:08s 00:07s 00:15s 00:00s <> 100 Timeout KRT 00:00s 00:00s 00:00s 00:00s 100 Age Redirect 00:00s 00:52s 00:00s 00:00s 100 Startup SMUX 01:00s 00:00s 01:00s 00:00s <> GateD-callisto> show rip summary 100 Gateway LastHeard Flags 100 192.168.14.1 0 100 192.168.1.1 0 100 192.168.45.253 0 100 192.168.1.254 1334 A 100 192.168.45.254 909 A 100 192.168.14.254 1339 A 100 RIP summary, 6 gateways. 100 Flags: 100 S This is a source gateway 100 T This is a trusted gateway 100 A We have accepted a packet from this gateway 100 R We have rejected a packet from this gateway 100 Q We have received a RIP query packet from this gateway 100 F This gateway failed authentication GateD-callisto> show rip routes 0/0 100 Proto Route/Mask NextHop Tag 100 RIP 0.0.0.0/0 192.168.14.254 0 100 RIP 192.168.2/24 192.168.1.254 0 100 RIP 192.168.7/24 192.168.14.254 0 100 RIP 192.168.13/29 192.168.14.254 0 100 RIP 192.168.17/29 192.168.14.254 0 100 RIP 192.168.44.1/32 192.168.1.254 0 100 RIP 192.168.80/24 192.168.1.254 0 100 RIP 192.168.201.2/32 192.168.14.254 0 100 RIP 111.11.117/24 192.168.1.254 0 GateD-callisto> show ip walkdown 0/0 100 RIP 0.0.0.0/0 192.168.14.254 IGP (Id 1) 100 Sta 127/8 127.0.0.1 IGP (Id 1) 100 Dir 127.0.0.1/32 127.0.0.1 IGP (Id 1) 100 Dir 192.168.1/24 192.168.1.1 IGP (Id 1) 100 RIP 192.168.2/24 192.168.1.254 IGP (Id 1) 100 RIP 192.168.7/24 192.168.14.254 IGP (Id 1) 100 RIP 192.168.13/29 192.168.14.254 IGP (Id 1) 100 Dir 192.168.14/24 192.168.14.1 IGP (Id 1) 100 RIP 192.168.17/29 192.168.14.254 IGP (Id 1) 100 RIP 192.168.44.1/32 192.168.1.254 IGP (Id 1) 100 Dir 192.168.45/24 192.168.45.253 IGP (Id 1) 100 RIP 192.168.80/24 192.168.1.254 IGP (Id 1) 100 RIP 192.168.201.2/32 192.168.14.254 IGP (Id 1) 100 RIP 111.11.117/24 192.168.1.254 IGP (Id 1) GateD-callisto> show ip route 192.168.7.0/24 100 Route 192.168.7 - 255.255.255 entries 1 Announced 1 Depth 0 <> 100 Proto Next Hop Source Gwt Preference/2 Metric/2 100 * RIP 192.168.14.254 192.168.14.254 100/0 2/0
Exercise 9-1: RIPv2 over Frame Relay Topologies
If you are blessed with a WAN network interface card (NIC) that supports Frame Relay, try to configure RIPv2 for a Frame Relay WAN network using the neighbor feature discussed in Lab 9-2.
Exercise 9-2: RIPv2 Metric Manipulation and Redistribution Control
Use the offset-list command in the RIP router section to manipulate the metric for incoming/outgoing updates. In addition, use the distribute-list command in combination with the default-metric command to add granularity to the redistribution of routing updates, and default-information originate to inject default routes. Remember that the passive-interface command results in the respective interface not sending any updates except to RIP neighbors specified with the neighbor command. This does not affect the processing of received updates.
Introduction to Link-State Routing Protocols
Link-state routing protocols are based on Edsger W. Dijkstra's Shortest Path First (SPF) algorithm, a result of applied graph theory. Link-state protocols establish and maintain adjacencies via hello packets (connection-oriented) with their neighbors (peers), speaking the same routing protocol. The name link-state stems from the underlying concept that every participant distributes (floods) all the information states and conditions of its directly attached links.
The routers communicate via link-state advertisements (LSAs) with all their established neighbors. This behavior is referred to as flooding. The receiving routers never alter the LSA information, but add a copy to their link-state databases. After some convergence time, all the participants have a full, identical, and complete view (graph) of the area topology stored in their topology databases. Every router now calculates its own best paths (SPF) for all prefixes from its individual point of view and position in this topology. Hellos are also used as a keepalive mechanism between adjacent neighbors.
NOTE
A new approach referred to as incremental SPF (iSPF) or incremental Dijkstra allows SPF protocols to converge faster under certain conditions by recomputing only the part of the shortest path tree (SPT) that has changed. This calculation is considerably faster only under special circumstances. For more information, search Cisco.com for "incremental SPF" or "incremental Dijkstra." At the time of this writing, the implementation solely is a proprietary vendor playground.
The following discussion introduces two fundamental concepts of organizing routing realms: areas and autonomous systems.
Area Concepts
Areas are smaller realms (subsets) of a routing domain (autonomous system). It became obvious during the design of link-state protocols that the intrinsic mechanisms become problematic in large flat topologies with several hundreds to thousands of nodes. This involved convergence time, link bandwidth, node memory, and CPU consumption. The designers' response was a subdivision-area concept and, recently, incremental approaches to SPF.
Area separation in terms of a contiguous backbone area and attached leaf areas via area border routers (ABRs) considerably improved the matter by restricting LSA flooding to the area boundaries. This resulted in smaller topology databases, faster SPF computation with less memory/CPU consumption, and ultimately improved convergence behavior.
ABRs maintain several databases and need to be consulted for interarea routing. In general, ABRs inject default routes into the leaf area. OSPF has a "rich" repertoire of leaf-area flavors: stub areas, total stub areas, not so stubby areas (NSSAs), and NSSA total stub. For a concise discussion of the differences, see the "Recommended Reading" section at the end of this chapter.
All leaf areas need to have at least one connection to the backbone area. If this is not possible because of migration constraints or topology limitations, OSPF virtual links are used to establish backbone connectivity via a transit area. This concept is not implemented (or necessary) in IS-IS. Both protocols use a contiguous backbone.
Table 9-1 shows the four different area specifiers used within Cisco IOS Software and their GateD and Zebra counterparts if applicable.
| Area Specifier | GateD Notation | Zebra Notation |
|---|---|---|
| Stub | Stub | Stub |
| Total stub | Stub + restrict clause | Stub, no summary |
| NSSA | Not implemented | NSSA |
| NSSA total stub | Not implemented | NSSA, no summary |
NOTE
The Full Picture—Autonomous Systems and Areas
Figure 9-2 shows a complete view of the macroscopic world. Autonomous systems can be organized into areas—either a flat backbone area or a backbone area with multiple connected leaf areas. Autonomous systems are not isolated; they communicate via Exterior Gateway Protocols (EGPs) with other autonomous systems, upstream carriers, or public peering points. BGPv4 is the dominant EGP used in today's Internet
NOTE
Chapter 10, "ISP Connectivity with BGPv4: An Exterior Gateway Path-Vector Routing Protocol for Interdomain Routing," is dedicated to BGPv4 and interdomain issues.
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
