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.
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
GateD 3.6
For a long time, GateD was the prevalent routing engine of the research community and Internet test beds under the custody of the Merit GateD Consortium (http://www.gated.org).
It was first used to connect the original NFSNET and the emerging regional networks. At that point in time, the source code was basically free. Later, the Merit GateD Consortium changed the licensing and finally handed it over to NextHop. Over time, NextHop Technologies continued the development of the code base and made the product commercially available after adding significant improvements (http://www.nexthop.com). Unfortunately, NextHop removed all traces of the original Merit GateD Consortium 3.6 public release (GateD 3.6), including the manuals from the original http://www.gated.org repository, instead of maintaining the code as an open-research branch. In addition to the 3.6 public release, several 4.0.x development snapshots were made available to the public during the late days of the Consortium. This was alpha software with a lot of IPv6 and multicast stuff and did not compile on my test systems. Give it a try if you are a good and patient programmer. You can also find GateD 3.6.x binaries in most RPM Linux repositories. NextHop is in the business of selling source licenses to big companies such as Riverstone. Some of their customer's command-line interfaces (CLIs) still look a lot like GateD (a hierarchical and structured representation, as you will see) due to their heritage. The following list presents some useful details about the GateD 3.6 public software:
Version— GateD 3.6, Merit GateD Consortium public release, 1999.
Architecture— Modular routing engine, single daemon.
Resources— "Homeless and abandoned." Ask your favourite search engine for GateD 3.6 and retrieve gated-3-6.tar.gz together with the original postscript manual. Some documentation mirrors are still up as well. Due to unclear licensing, I cannot provide these at my repository.
Feature Description
The GateD public release supports RIPv1/v2, EGP, OSPFv2, BGP4, and RDP. There exists a great deal of inaccuracy as to which protocols the public version supports. Its syntax is structured and differs conceptually from what engineers are used to in Cisco IOS Software (several sections and layers of parentheses).
Installation of GateD 3.6
The following installation steps are rather straightforward, but they might assist those of you who are unfamiliar with UNIX installation procedures:
Get and extract source archive gated-3-6.tar.gz and the documentation gated.ps.
Use cd to access the GateD source directory.
Check configuration options: ./configure --help
Type: ./configure --enable-gii --disable-ripon --enable-rdisc
Type: make depend
Type: make
Type: make install
Check gated -h for options.
To fire up the daemon, type gated -f /etc/gated.cfg or use the gdc admin utility.
gated will not start if the config file has a syntax error.
Add the following entry to /etc/ services: gii 616/tcp
Access the GateD Interactive Interface (GII) by typing telnet localhost gii
Reliance on Service
gated relies on services of the UNIX kernel for the TCP/IP stack. These services include the following:
IP forwarding enabled.
Setting of UDP checksum for RIP on BSD (sysctl net.inet.udp.checksum = 1).
Optional SNMP support (via snmpd/smux).
Interfaces with the kernel to query interface status, routes, and timers.
Multicast support (for OSPFv2 and RIPv2).
On Linux, gated uses the netlink interface. Activate the kernel/user netlink socket under Network Options in the kernel configuration.
TIP
SIGINT causes the current state of all gated tasks, timers, protocols, and tables to be written to /usr/tmp/gated_dump or /var/tmp/gated_dump. GateD comes with several accompanying tools such as ospf_monitor, ripquery, and the gdc user interface.
Maturity, Scalability, and Stability of GateD 3.6
GateD 3.6 is a stable, scalable, and mature system but is no longer maintained. Nevertheless, it is suitable for production deployment, keeping in mind its current state of evolution and feature sets. It has proven its value as an Internet routing platform, especially for BGP, during years of stable operation. If you are looking for state-of-the-art supported code, talk to the folks at NextHop Technologies. Zebra/Quagga and GateD 3.6 are the routing packages used most frequently throughout this book. From now on, GateD will be used as an abbreviation for the "public GateD 3.6
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
