The routed Daemon
routed is a simple RIP-based LAN routing protocol daemon often used to communicate with other RIP hosts and gateways. It supports the Internet Router Discovery Protocol (IRDP) as well. The IRDP is discussed in more detail at the end of Chapter 12, "Designing for High Availability."
In the old days, UNIX administrators did not care about routing beyond the scope of a simple broadcast domain or LAN. RIP was the simple but reliable dynamic routing protocol of choice, supported by virtually any operating system and, combined with static routing entries, did the limited job it was required to do pretty well. routed was the vehicle providing this facility.
Feature Description of routed
routed has been around for a long time and supports RIPv1/v2 and IRDP. All you need to know about routed you can get from the manual page by typing man routed. It is a simple and reliable routing tool with the known limitations of RIP routing protocols (scalability and convergence); therefore, it is of arguable use in today's routing environments. According to the man page, it does not always detect unidirectional failures in network interfaces (for example, when the output side fails). Under certain conditions, the routed and kernel routing table might differ when redirects change or add routes. In theory, routed should note any redirects received by reading the related ICMP packets.
Installation of routed
routed comes preinstalled on virtually all UNIX platforms I am aware of. Its configuration file is /etc/gateways. However, the Linux version differs from the BSD versions because of historical reasons. Linux routed exhibits somewhat unanticipated behavior with regard to broadcast and multicast operation as well as summarization. (Lab 2-1 demonstrates this peculiarity.) Because of these implementation differences, I strongly recommend caution with Linux routed setups.
Lab 2-1: routed
This lab creates routing connectivity between the UNIX gateways ganymed, castor, and callisto and the Cisco IOS router scar.
On two gateways, ganymed and castor, routed was started by typing routed -s -T /var/log/routed.log. On callisto, routed was started by typing routed -s. The command-line options of routed are slightly different on Linux and BSD Unices. Type routed -h or consult the routed man page for details. Figure 2-1 shows the lab topology, and Examples 2-1 and 2-2 show the initial Cisco IOS RIPv2 configuration and UNIX routed configurations, respectively. Note that castor is communicating with scar and ganymed via multicast RIPv2 (224.0.0.9), whereas the Linux routed is only capable of broadcast RIPv1. The callisto /etc/gateways configuration is empty and hence omitted.
Figure 2-1. The Routed Lab Topology
Example 2-1. RIPv2 IOS Router Configuration?Routed Lab 2-1
scar# show running-config
...
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface Ethernet0
bandwidth 10000
ip address 192.168.7.254 255.255.255.0
!
interface Ethernet1
bandwidth 10000
ip address 192.168.14.254 255.255.255.0
ip rip send version 1
ip rip receive version 1
!
interface TokenRing0
ip address 10.0.1.1 255.255.255.0
early-token-release
ring-speed 16
!
router rip
version 2
redistribute connected
network 192.168.7.0
network 192.168.14.0
maximum-paths 2
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 192.168.14.1
ip route 0.0.0.0 0.0.0.0 192.168.7.7 2
...
Example 2-2. RIP Routed Configurations?Routed Lab 2-1
[root@ganymed:~#] cat /etc/gateways if=ne4 ripv2 no_rdisc if=ne5 passive # Don't send RIP updates to the Internet service provider if=vlan0 ripv2 no_rdisc [root@castor:~#] cat /etc/gateways if=ed0 ripv2 no_rdisc # Internet Router Discovery Protocol disabled if=xl0 ripv2 no_rdisc
CAUTION
The Linux version of routed offers fewer features than the BSD flavor. Linux routed comes as part of the NetKit package. According to the accompanying documentation, it was ported back to Linux from a 1995 version of NetBSD, which explains the differences and lack of compliance in some aspects of the RIPv2 RFCs. It appears to only support RIPv1 (broadcast). With the parameter pm_rdisc in the routed configuration, this router can be supplied with a route of last resort. Unfortunately, this causes suppression of more specific routes to castor as well. I have also had troubles with the RIPv2 authentication parameter; therefore, I strongly recommend the use of RIPv2 under GateD or Zebra/Quagga instead.
Examples 2-3 through 2-6 show the resulting gateway routing tables.
Example 2-3. Routing Table Ganymed?Routed Lab 2-1
[root@ganymed:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 111.11.117.1 UGS 4 60443 1500 ne5
10.0.0.1 192.168.80.1 UGH 0 0 1496 vlan0
127/8 127.0.0.1 UGRS 0 0 33224 lo0
127.0.0.1 127.0.0.1 UH 2 8 33224 lo0
192.168.1/24 link#1 UC -236 0 1500 ne3
192.168.1.1 52:54:5:e3:51:87 UHL 1 45352 1500 ne3
192.168.1.250 8:0:46:64:74:1b UHL 1 10582 1500 ne3
192.168.1.254 127.0.0.1 UGHS 0 21 33224 lo0
192.168.2/24 link#2 UC 0 0 1500 ne4
192.168.2.7 0:10:5a:c4:2c:4 UHL 1 174 1500 ne4
192.168.2.254 52:54:5:e3:e4:2f UHL 0 2 1500 lo0
192.168.7/24 192.168.80.1 UG -1 56 1496 vlan0
192.168.14/24 192.168.2.7 UG 0 1069 1500 ne4
192.168.44.1 192.168.44.1 UH 0 0 33224 lo1
192.168.45/24 link#1 UC 0 0 1500 ne3
192.168.80/24 link#16 UC 0 0 1496 vlan0
192.168.80.1 0:10:5a:c4:2c:4 UHL 2 0 1496 vlan0
111.11.117/24 link#3 UC 0 0 1500 ne5
111.11.117.1 0:5:9a:5a:fb:fc UHL 1 0 1500 ne5
111.11.117.49 0:e0:7d:9f:9b:dd UHL 0 0 1500 ne5
Example 2-4. Routing Table Castor?Routed Lab 2-1
[root@castor:~#] netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.254 UGSc 1 3 xl0
10.0.0.1 192.168.7.254 UGH 0 0 ed0
10.0.0.4 10.0.0.4 UH 0 10 lo0
10.0.1/24 192.168.7.254 UGc 0 0 ed0
127.0.0.1 127.0.0.1 UH 1 32 lo0
192.168.1 192.168.80.254 UGc 1 324 vlan8
192.168.2 link#1 UC 2 0 xl0
192.168.2.7 00:10:5a:c4:2c:04 UHLW 3 4 lo0
192.168.2.254 52:54:05:e3:e4:2f UHLW 2 297 xl0 90
192.168.7 link#2 UCc 1 0 ed0
192.168.14 192.168.7.254 UGc 0 0 ed0
192.168.45 192.168.80.254 UGc 0 0 vlan8
192.168.80 link#15 UC 1 0 vlan8
192.168.80.254 52.54.5.e3.e4.2f UHLW 3 0 vlan8 1168
111.11.117 192.168.80.254 UGc 0 0 vlan8
Also note the highlighted Cisco debug output at the end of Example 2-6. My Cisco IOS Software version refused to send and accept RIPv1 announcements on interface Ethernet1, even though it was explicitly instructed to do so in the configuration. I suspect a RIPv1 implementation bug. This is the reason why callisto and scar do not exchange RIP information.
Example 2-5. Routing Table Callisto?Routed Lab 2-1
[root@callisto:~#] netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.1 192.168.1.254 255.255.255.255 UGH 0 0 0 eth1
192.168.7.0 192.168.1.254 255.255.255.0 UG 0 0 0 eth1
111.11.117.0 192.168.1.254 255.255.255.0 UG 0 0 0 eth1
192.168.2.0 192.168.1.254 255.255.255.0 UG 0 0 0 eth1
192.168.80.0 192.168.1.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.14.0 192.168.14.1 255.255.255.0 UG 0 0 0 eth0
192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.45.0 192.168.45.1 255.255.255.0 UG 0 0 0 eth1
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
Example 2-6. ExampleRouting Table Scar?Routed Lab 2-1
scar#show 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, 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 Gateway of last resort is 192.168.14.1 to network 0.0.0.0 C 192.168.14.0/24 is directly connected, Ethernet1 R 192.168.45.0/24 [120/2] via 192.168.7.7, 00:00:28, Ethernet0 R 192.168.80.0/24 [120/1] via 192.168.7.7, 00:00:28, Ethernet0 R 111.11.117.0/24 [120/2] via 192.168.7.7, 00:00:28, Ethernet0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.0.1.0/24 is directly connected, TokenRing0 C 10.0.0.1/32 is directly connected, Loopback0 C 192.168.7.0/24 is directly connected, Ethernet0 R 192.168.1.0/24 [120/2] via 192.168.7.7, 00:00:28, Ethernet0 R 192.168.2.0/24 [120/1] via 192.168.7.7, 00:00:28, Ethernet0 S* 0.0.0.0/0 [1/0] via 192.168.14.1 scar# show ip rip database 10.0.0.0/8 auto-summary 10.0.0.1/32 directly connected, Loopback0 10.0.1.0/24 directly connected, TokenRing0 192.168.1.0/24 auto-summary 192.168.1.0/24 [2] via 192.168.7.7, 00:00:05, Ethernet0 192.168.2.0/24 auto-summary 192.168.2.0/24 [1] via 192.168.7.7, 00:00:05, Ethernet0 192.168.7.0/24 auto-summary 192.168.7.0/24 directly connected, Ethernet0 192.168.14.0/24 auto-summary 192.168.14.0/24 redistributed [1] via 0.0.0.0, 192.168.45.0/24 auto-summary 192.168.45.0/24 [2] via 192.168.7.7, 00:00:05, Ethernet0 192.168.80.0/24 auto-summary 192.168.80.0/24 [1] via 192.168.7.7, 00:00:05, Ethernet0 111.11.117.0/24 auto-summary 111.11.117.0/24 [2] via 192.168.7.7, 00:00:05, Ethernet0 scar# debug ip rip RIP protocol debugging is on scar# terminal monitor scar# 00:46:15: RIP: ignored v1 packet from 192.168.14.1 (not enabled on Ethernet1) 00:46:16: RIP: received v2 update from 192.168.7.7 on Ethernet0 00:46:16: 192.168.1.0/24 via 0.0.0.0 in 2 hops 00:46:16: 192.168.2.0/24 via 0.0.0.0 in 1 hops 00:46:16: 192.168.7.0/24 via 0.0.0.0 in 1 hops 00:46:16: 192.168.45.0/24 via 0.0.0.0 in 2 hops 00:46:16: 192.168.80.0/24 via 0.0.0.0 in 1 hops 00:46:16: 111.11.117.0/24 via 0.0.0.0 in 2 hops 00:46:18: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (192.168.7.254) 00:46:18: RIP: build update entries 00:46:18: 10.0.0.1/32 via 0.0.0.0, metric 1, tag 0 00:46:18: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0 00:46:18: 192.168.14.0/24 via 0.0.0.0, metric 1, tag 0 00:46:45: RIP: ignored v1 packet from 192.168.14.1 (not enabled on Ethernet1)
The accompanying tools, rtquery and ripquery, provide useful additional information about RIP speakers; these tools are presented in Example 2-7. Remember that callisto is a RIPv1 speaker (highlighted) and RIP's metric is hop count.
Example 2-7. Two Useful Tools (rtquery and ripquery)?Routed Lab 2-1
[root@ganymed:~#] rtquery -n 192.168.2.7 192.168.2.7: RIPv2 184 bytes 10.0.1.0/24 metric 2 nhop=192.168.7.254 192.168.1.0/24 metric 2 nhop=192.168.80.254 192.168.2.0/24 metric 1 192.168.7.0/24 metric 1 192.168.14.0/24 metric 2 nhop=192.168.7.254 192.168.45.0/24 metric 2 nhop=192.168.80.254 192.168.80.0/24 metric 1 10.0.0.1/32 metric 2 nhop=192.168.7.254 111.11.117.0/24 metric 2 nhop=192.168.80.254 [root@ganymed:~#] rtquery -n 192.168.1.254 192.168.1.254: RIPv2 164 bytes 192.168.1.0/24 metric 1 192.168.2.0/24 metric 1 192.168.7.0/24 metric 2 nhop=192.168.80.1 192.168.14.0/24 metric 2 nhop=192.168.1.1 192.168.45.0/24 metric 1 192.168.80.0/24 metric 1 10.0.0.1/32 metric 3 nhop=192.168.80.1 111.11.117.0/24 metric 1 [root@ganymed:~#] rtquery -n 192.168.1.1 192.168.1.1: RIPv1 164 bytes 10.0.0.1 metric 4 192.168.1.0 metric 1 192.168.2.0 metric 2 111.11.117.0 metric 2 192.168.7.0 metric 3 192.168.45.0 metric 1 192.168.14.0 metric 1 192.168.80.0 metric 2 [root@ganymed:~#] ripquery 192.168.1.254 164 bytes from ganymed(192.168.1.254) to 192.168.1.254 version 2: 192.168.1.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 192.168.2.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 192.168.7.0/255.255.255.0 router 192.168.80.1 metric 2 tag 0000 192.168.14.0/255.255.255.0 router 192.168.1.1 metric 2 tag 0000 192.168.45.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 192.168.80.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 10.0.0.1/255.255.255.255 router 192.168.80.1 metric 3 tag 0000 111.11.117.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 [root@ganymed:~#] ripquery 192.168.1.1 164 bytes from callisto(192.168.1.1) to 192.168.1.254 version 1: 10.0.0.1 metric 4 192.168.1.0 metric 1 192.168.2.0 metric 2 111.11.117.0 metric 2 192.168.7.0 metric 3 192.168.45.0 metric 1 192.168.14.0 metric 1 192.168.80.0 metric 2 [root@ganymed:~#] ripquery 192.168.2.7 184 bytes from castor(192.168.2.7) to 192.168.2.254 version 2: 10.0.1.0/255.255.255.0 router 192.168.7.254 metric 2 tag 0000 192.168.1.0/255.255.255.0 router 192.168.80.254 metric 2 tag 0000 192.168.2.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 192.168.7.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 192.168.14.0/255.255.255.0 router 192.168.7.254 metric 2 tag 0000 192.168.45.0/255.255.255.0 router 192.168.80.254 metric 2 tag 0000 192.168.80.0/255.255.255.0 router 0.0.0.0 metric 1 tag 0000 10.0.0.1/255.255.255.255 router 192.168.7.254 metric 2 tag 0000 111.11.117.0/255.255.255.0 router 192.168.80.254 metric 2 tag 0000
