16.2 Router Discovery Protocol (RDP)

     

Although rare, some commercial routers use this simple protocol in order to advertise routes on connected interfaces. This protocol isn't really a routing protocol; it's simply a means whereby a default route can be inserted into a client's routing table. One useful feature is being managed by gated ; if the route fails, gated can update the routing table with a new advertised route automatically. Both hpeos003 and hpeos004 will operate in server mode while the other two machines will operate in client mode .

16.2.1 Router discovery: Server mode

As we mentioned at the beginning of this chapter, there is still a daemon called rdpd , which used to look after router advertisements. The daemon is still available (it is activated via /etc/rc.config.d/ netconf ), but its use is discouraged. If you read the man page for rdpd , it does mention that its capabilities have been subsumed by gated , and the rdpd daemon may disappear in future releases of HP-UX. Here is the gated configuration we will employ on nodes hpeos003 and hpeos004 to support Router Discovery:

 

 root@hpeos003[]  vi /etc/gated.conf  # #       This is an initial /etc/gated.conf file. #       Note that this file should be modified according #       to the routing topology. Refer to the sample #       configuration files in the "/usr/examples/gated" directory. #       See gated-config(4) for details. # @(#)B.11.11_LR # traceoptions "/var/adm/gated.trc" size 10M files 2 route; interfaces { interface all passive ; } ;   routerdiscovery server yes {     interface all maxadvinterval 30;     address all broadcast;     } ;     icmp {     traceoptions routerdiscovery ;     } ;   root@hpeos003[]  gdc checkconf  configuration file /etc/gated.conf checks out okay root@hpeos003[] 

I hope that the routerdiscovery definition needs little explaining except the maxadvinterval . This is simply the maximum time between sending advertisements. Advertisements are broadcast using a class-D multicast IP address of 224.0.0.1. In our example, we are broadcasting on all interfaces.

The icmp definition is simplicity itself. The only option we have with the ICMP protocol is to specify what type of packets we will trace. In this case, we are tracing Router Discovery packets. Once the configuration has been put in place on both hpeos003 and hpeos004 , we are almost ready to start the gated daemon. First, we need to ensure that the daemon is started after every reboot ( GATED=1 ) and that we disable static routes from inside the netconf file:

 

 root@hpeos003[]  vi /etc/rc.config.d/netconf  ...   #   ROUTE_DESTINATION[0]="default"   #   ROUTE_MASK[0]="255.255.255.0"   #   ROUTE_GATEWAY[0]="192.168.0.1"   #   ROUTE_COUNT[0]="1"   #   ROUTE_ARGS[0]="" Dynamic routing daemon configuration. See gated(1m) # # GATED:        Set to 1 to start gated daemon. # GATED_ARGS:   Arguments to the gated daemon.   GATED=1   GATED_ARGS="" # # Router Discover Protocol daemon configuration.  See rdpd(1m) # # RDPD:         Set to 1 to start rdpd daemon # RDPD=0 root@hpeos003[] 

To ensure that there is no conflict between our old static routes and gated , we should flush the current routing table. Be aware that this may cause problems for client machines using this node as a router. I am sure you will be testing this outside prime user hours.

 

 root@hpeos003[]  route -f  root@hpeos003[]  netstat -rn  Routing tables Destination           Gateway            Flags   Refs Interface  Pmtu 127.0.0.1             127.0.0.1          UH        0  lo0        4136 192.168.0.33          192.168.0.33       UH        0  lan0       4136 192.168.0.13          192.168.0.13       UH        0  lan0:1     4136 192.168.0.65          192.168.0.65       UH        0  lan902     4136 192.168.0.32          192.168.0.33       U         3  lan0       1500 192.168.0.64          192.168.0.65       U         2  lan902     1500 192.168.0.0           192.168.0.13       U         3  lan0:1     1500 root@hpeos003[] 

Now we can start gated :

 

 root@hpeos003[]  gdc start  gated started, pid 4933 root@hpeos003[] gated is running (pid 4933) root@hpeos003[]  ll /var/adm/gated.trc  -rw-r--r--   1 root       sys          17693 Nov 24 16:19 /var/adm/gated.trc root@hpeos003[] 

We can configure our clients now.

16.2.2 Router Discovery Protocol: Client mode

The client configuration is syntactically similar to the server configuration. The differences include the fact that we explicitly do not start the RIP protocol because it is unnecessary; RDP is going to supply us with a default route, which is going to be our exit point from this network. The other change is that we explicitly allow redirects. ICMP redirects are used to direct a client to a router if it becomes available. Essentially, that is all we are trying to achieve here, the best exit point for our clients:

 

 root@hpeos002[] #  vi /etc/gated.conf  # #       This is an initial /etc/gated.conf file. #       Note that this file should be modified according #       to the routing topology. Refer to the sample #       configuration files in the "/usr/examples/gated" directory. #       See gated-config(4) for details. # @(#)B.11.11_LR # traceoptions "/var/adm/gated.trc" size 10M files 2 route; interfaces { interface all passive ; } ;   rip no;     routerdiscovery client yes {     interface all broadcast;     } ;     icmp {     traceoptions routerdiscovery ;     } ;     redirect yes;   root@hpeos002[] # 

When we start up the clients, we expect them to receive an advertisement from all the routers on the network. If there are two advertisements for the same network, the kernel will choose one route (based on the preference of a route) and install it as the default route for the client. Should the default route fail, gated will remove the route from the routing table and update it from the next advertisement.

 

 root@hpeos002[] #  netstat -rn  Routing tables Destination           Gateway            Flags   Refs Interface  Pmtu 127.0.0.1             127.0.0.1          UH        0  lo0        4136 192.168.0.34          192.168.0.34       UH        0  lan0       4136 192.168.0.32          192.168.0.34       U         2  lan0       1500 127.0.0.0             127.0.0.1          U         0  lo0           0 root@hpeos002[] # root@hpeos002[] #  gdc start  gated started, pid 3086 root@hpeos002[] #  netstat -rn  Routing tables Destination           Gateway            Flags   Refs Interface  Pmtu 127.0.0.1             127.0.0.1          UH        0  lo0        4136 192.168.0.34          192.168.0.34       UH        0  lan0       4136 192.168.0.32          192.168.0.34       U         2  lan0       1500 127.0.0.0             127.0.0.1          U         0  lo0           0   default               192.168.0.33       UG        0  lan0          0   root@hpeos002[] # 

Assuming that all clients have been updated with a similar configuration, we should be able to contact our distant cousin hpeos001 :

 

 root@hpeos002[] #  traceroute hpeos001  traceroute: Warning: hpeos001 has multiple addresses; using 192.168.0.67 traceroute to hpeos001 (192.168.0.67), 30 hops max, 40 byte packets  1  hpeos004 (192.168.0.35)  2.556 ms  2.390 ms  1.636 ms  2  hpeos001 (192.168.0.67)  2.019 ms  2.825 ms  2.095 ms root@hpeos002[] # 

This all appears to be working fine. Now, we simply need to ensure that the dynamic component of this configuration works. We will simulate a LAN card failure. I will simply remove the cable from both network cards on node hpeos003 (you could use ifconfig lan0 unplumb ). We should see a new route appear in the routing table of node hpeos002 :

 

 ************************100 Mb/s LAN/9000 Networking**********************@#%   Timestamp            : Mon Nov 24 GMT 2003 23:34:19.511709   Process ID           : [ICS]              Subsystem        : BTLAN   User ID ( UID )      : -1                 Log Class        : ERROR   Device ID            : 0                  Path ID          : 0   Connection ID        : 0                  Log Instance     : 0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <7002>  10/100BASE-T driver detected bad cable connection between         the adapter in slot(Crd In#) 0 and the hub or switch.         btlan[ 0] [HP PCI 10/100Base-TX Core]         going Offline @ [0/0/0/0] [Cable Disconnected] 

Now if we look on node hpeos002 , we can see our new default route :

 

 root@hpeos002[] #  netstat -rn  Routing tables Destination           Gateway            Flags   Refs Interface  Pmtu 127.0.0.1             127.0.0.1          UH        0  lo0        4136 192.168.0.34          192.168.0.34       UH        0  lan0       4136 192.168.0.32          192.168.0.34       U         2  lan0       1500 127.0.0.0             127.0.0.1          U         0  lo0           0   default               192.168.0.35       UG        0  lan0          0   root@hpeos002[] # 

We can see this in the gated logfile:

 

 root@hpeos002[] #  more /var/adm/gated.trc  ... Nov 24 18:38:10 ICMP RECV 192.168.0.35 -> 192.168.0.63 type RouterAdvertisement(9) code (0) Nov 24 18:38:10 ICMP RECV       addresses 1 size 8 lifetime 1:30 Nov 24 18:38:10 ICMP RECV       router 192.168.0.35    preference 0 Nov 24 18:38:10 root@hpeos002[] # 

When the failure on node hpeos003 is recovered, we might think that our client(s) would go back to using node hpeos003 . They won't. When node hpeos003 comes back online, advertisements will be broadcast for the route via this node. However, the current route has the same preference because we didn't actually specify one; you can see a preference = 0 from the advertisement logged above. Where we have a configuration with a preferred route, we should make it explicit in the configuration of that server. Here, I am giving node hpeos003 a higher preference :

 

 root@hpeos003[]  vi /etc/gated.conf  # #       This is an initial /etc/gated.conf file. #       Note that this file should be modified according #       to the routing topology. Refer to the sample #       configuration files in the "/usr/examples/gated" directory. #       See gated-config(4) for details. # @(#)B.11.11_LR # traceoptions "/var/adm/gated.trc" size 10M files 2 route; routerdiscovery server yes {         interface all maxadvinterval 30;         address all broadcast   perference 10   ; } ; icmp {         traceoptions routerdiscovery; }; root@hpeos003[] 

It's probably a good idea to do the same on node hpeos004 to ensure that we explicitly set the preference for all routers. This configuration makes sense because node hpeos003 has the APA configuration in place, and I would prefer that my clients use the big fat pipe available via that node than the piece of wet string attached to node hpeos004 .

16.2.3 Conclusions on Router Discovery Protocol

RDP is a simple yet effective way of supplying a default route to a number of clients connected to a local network. It works well for small- to medium-size networks and can react quickly to failures in a specific route. It showcases the benefits of the dynamic routing daemon gated . With preferences, we can give clients a preferred exit point from the network, which is normally a high availability, high performance, secure network connection. The configuration is relatively simple to put in place and maintain. The only other thing to consider is to turn off the ICMP tracing of routerdiscovery packets because leaving it on will fill up the /var filesystems in the space of a day or so.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net