15.8 The netconf File At the heart of our IP configuration is the file /etc/rc.config.d/netconf . This is where we configure our IP addresses, subnet masks, and static routes. We can also enable other routing daemons, the main one being gated , which is responsible for dynamic routing. We will configure dynamic routing in the next chapter. Here are the entries I added to /etc/rc.config.d/netconf , as well as the associated commands for the nodes in our example outlined in Figure 15-2: -
Node = hpeos001
root@hpeos001[] vi /etc/rc.config.d/netconf ... INTERFACE_NAME[0]="lan0" IP_ADDRESS[0]="192.168.0.67" SUBNET_MASK[0]="255.255.255.224" BROADCAST_ADDRESS[0]="" INTERFACE_STATE[0]="" DHCP_ENABLE[0]=0 ... ROUTE_DESTINATION[0]="net 192.168.0.32" ROUTE_MASK[0]="255.255.255.224" ROUTE_GATEWAY[0]="192.168.0.66" ROUTE_COUNT[0]="1" ROUTE_ARGS[0]="" /sbin/ifconfig lan0 192.168.0.67 netmask 255.255.255.224 /sbin/route add net 192.168.0.32 mask 255.255.255.224 192.168.0.66 1
-
Node = hpeos002
root@hpeos002[] vi /etc/rc.config.d/netconf ... INTERFACE_NAME[0]="lan0" IP_ADDRESS[0]="192.168.0.34" SUBNET_MASK[0]="255.255.255.224" BROADCAST_ADDRESS[0]="" INTERFACE_STATE[0]="" DHCP_ENABLE[0]=0 ... ROUTE_DESTINATION[0]="net 192.168.0.64" ROUTE_MASK[0]="255.255.255.224" ROUTE_GATEWAY[0]="192.168.0.33" ROUTE_COUNT[0]="1" ROUTE_ARGS[0]="" /sbin/ifconfig lan0 192.168.0.34 netmask 255.255.255.224 /sbin/route add net 192.168.0.64 mask 255.255.255.224 192.168.0.33 1
-
Node = hpeos003
root@hpeos003[] vi /etc/rc.config.d/netconf ... INTERFACE_NAME[0]="lan0" IP_ADDRESS[0]="192.168.0.33" SUBNET_MASK[0]="255.255.255.224" BROADCAST_ADDRESS[0]="" INTERFACE_STATE[0]="" DHCP_ENABLE[0]=0 INTERFACE_NAME[1]="lan1" IP_ADDRESS[1]="192.168.0.65" SUBNET_MASK[1]="255.255.255.224" BROADCAST_ADDRESS[1]="" INTERFACE_STATE[1]="" DHCP_ENABLE[1]=0 /sbin/ifconfig lan0 192.168.0.33 netmask 255.255.255.224 /sbin/ifconfig lan1 192.168.0.65 netmask 255.255.255.224
-
Node = hpeos004
root@hpeos004[] vi /etc/rc.config.d/netconf ... INTERFACE_NAME[0]="lan0" IP_ADDRESS[0]="192.168.0.35" SUBNET_MASK[0]="255.255.255.224" BROADCAST_ADDRESS[0]="" INTERFACE_STATE[0]="" DHCP_ENABLE[1]=0 INTERFACE_NAME[1]="lan1" IP_ADDRESS[1]="192.168.0.66" SUBNET_MASK[1]="255.255.255.224" BROADCAST_ADDRESS[1]="" INTERFACE_STATE[1]="" DHCP_ENABLE[1]=0 /sbin/ifconfig lan0 192.168.0.35 netmask 255.255.255.224 /sbin/ifconfig lan1 192.168.0.66 netmask 255.255.255.224
NOTE : Remember to change the IP address/hostname pairing in your host's lookup database as well, e.g., /etc/ hosts . The other thing to point out here is that I have specified the subnet mask in my netconf file. Be sure to update the netconf file on all affected nodes in the network. If you forget to update a particular node, it will have a network address fundamentally different from all other nodes and will not be able to communicate with them without further intervention. It is recommended that you reboot your system to ensure that all networking software is started up with the correct settings and in the correct order. I agree with the last part of that statement, but a reboot can take some time on larger servers; I would drop down to run-level 1 and then go back to my default run-level (run-level = 3 normally). If all goes well, I should be able to ping all hosts from all locations. If not, I need to spend time ensuring that all relevant configuration changes have taken place.
root@hpeos001[] # netstat -in Name Mtu Network Address Ipkts Opkts lan0 1500 192.168.0.64 192.168.0.67 1482 1441 lo0 4136 127.0.0.0 127.0.0.1 1306 1306 root@hpeos001[] # 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.67 192.168.0.67 UH 0 lan0 4136 192.168.0.64 192.168.0.67 U 2 lan0 1500 192.168.0.32 192.168.0.66 UG 0 lan0 0 127.0.0.0 127.0.0.1 U 0 lo0 0 root@hpeos001[] # ping hpeos002 64 3 PING hpeos002: 64 byte packets 64 bytes from 192.168.0.34: icmp_seq=0. time=1. ms 64 bytes from 192.168.0.34: icmp_seq=1. time=1. ms 64 bytes from 192.168.0.34: icmp_seq=2. time=1. ms ----hpeos002 PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 1/1/1 root@hpeos001[] #
The problem with static routes is that they are exactly that: static . If we refer back to Figure 15-2, we notice that we actually have two routes between both networks. Let's add both of them into the routing table on node hpeos001 :
root@hpeos001[] # route add net 192.168.0.32 192.168.0.65 1 add net 192.168.0.32: gateway 192.168.0.65 root@hpeos001[] # 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.67 192.168.0.67 UH 0 lan0 4136 192.168.0.64 192.168.0.67 U 2 lan0 1500 192.168.0.32 192.168.0.65 UG 0 lan0 0 192.168.0.32 192.168.0.66 UG 0 lan0 0 127.0.0.0 127.0.0.1 U 0 lo0 0 root@hpeos001[] #
And on node hpeos002 :
root@hpeos002[] # route add net 192.168.0.64 192.168.0.35 1 add net 192.168.0.64: gateway 192.168.0.35 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 192.168.0.64 192.168.0.35 UG 0 lan0 0 192.168.0.64 192.168.0.33 UG 0 lan0 0 root@hpeos002[] #
Two things to notice: -
The newly added route is the first in the list of gateway (UG) routes. -
I did not use the mask option to the route command, because this is not necessary when the destination network is using the same netmask as I am. If we now access one node from the other, we will use the first route that allows us to get to our distant network:
root@hpeos001[] # traceroute hpeos002 traceroute to hpeos002 (192.168.0.34), 30 hops max, 40 byte packets 1 hpeos003 (192.168.0.65) 1.027 ms 0.510 ms 0.514 ms 2 hpeos002 (192.168.0.34) 1.077 ms 0.828 ms 0.775 ms root@hpeos001[] #
As we can see, we are utilizing the route through node hpeos003 (192.168.0.65) because it is the first route in our routing table that allows us to access network 192.168.0.32. Let's now disable that route by simply removing that cable between hpeos003 and the hub/switch. Just to show you that all I have done is to remove the cable from node hpeos003 , here's the output from netstat “in :
root@hpeos003[] netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lan1* 1500 192.168.0.64 192.168.0.65 1060 0 1091 0 0 lan0 1500 192.168.0.32 192.168.0.33 1316 0 1051 0 4 lo0 4136 127.0.0.0 127.0.0.1 1220 0 1220 0 0 root@hpeos003[]
As you can see, the asterisks (*) signify that there is a problem with the link on lan1 . Now, if we are to try a traceroute again, we should find that it would not use the second route even though it is alive and well .
root@hpeos001[] # traceroute hpeos002 traceroute to hpeos002 (192.168.0.34), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * **** max ttl expired before reaching hpeos002 (192.168.0.34) root@hpeos001[] #
Simply replacing the cable resolved this problem. Remember, a static route is STATIC. The problem stems from the fact that these routes are seen as just that: routes . If they were seen as gateways, then the situation would be different. A command that we will look at in more detail later is ndd . Using the ndd command, we can extract information about network related kernel parameters. In this case, I am extracting the routing table. I have underlined the lines I am interested in:
root@hpeos002[] # ndd -get /dev/ip ip_ire_status IRE rfq stq addr mask src gateway mxfrg rtt  ref type flag 02740ec8 026dfc80 00000000 000.000.000.000 ffffffff 192.168.000.034 000.000.000.000 04136 00000 000 IRE_BROADCAST 0273e288 026dfc80 026dfd44 000.000.000.000 ffffffff 192.168.000.034 000.000.000.000 01500 00000 006 IRE_BROADCAST 026dad08 00000000 00000000 127.000.000.001 ffffffff 127.000.000.001 000.000.000.000 04136 01430 000 IRE_LOOPBACK 02740448 026dfc80 00000000 192.168.000.255 ffffffff 192.168.000.034 000.000.000.000 04136 00000 000 IRE_BROADCAST 0273ed08 026dfc80 026dfd44 192.168.000.255 ffffffff 192.168.000.034 000.000.000.000 01500 00000 006 IRE_BROADCAST 027400c8 026dfc80 00000000 192.168.000.032 ffffffff 192.168.000.034 000.000.000.000 04136 00000 000 IRE_BROADCAST 0273f0c8 026dfc80 026dfd44 192.168.000.032 ffffffff 192.168.000.034 000.000.000.000 01500 00000 006 IRE_BROADCAST 02c8f448 026dfc80 026dfd44 192.168.000.033 ffffffff 192.168.000.034 000.000.000.000 01500 00000 001 IRE_ROUTE 0273bec8 026dfc80 00000000 192.168.000.034 ffffffff 192.168.000.034 000.000.000.000 04136 01034 000 IRE_LOCAL 02d88d08 026dfc80 026dfd44 192.168.000.035 ffffffff 192.168.000.034 000.000.000.000 01500 00000 002 IRE_ROUTE 0273fd08 026dfc80 00000000 192.168.000.063 ffffffff 192.168.000.034 000.000.000.000 04136 00000 000 IRE_BROADCAST 0273f448 026dfc80 026dfd44 192.168.000.063 ffffffff 192.168.000.034 000.000.000.000 01500 00000 006 IRE_BROADCAST 027407c8 026dfc80 00000000 192.168.000.000 ffffffff 192.168.000.034 000.000.000.000 04136 00000 000 IRE_BROADCAST 0273e988 026dfc80 026dfd44 192.168.000.000 ffffffff 192.168.000.034 000.000.000.000 01500 00000 006 IRE_BROADCAST 02740b48 026dfc80 00000000 255.255.255.255 ffffffff 192.168.000.034 000.000.000.000 04136 00000 000 IRE_BROADCAST 0273e608 026dfc80 026dfd44 255.255.255.255 ffffffff 192.168.000.034 000.000.000.000 01500 00000 006 IRE_BROADCAST 02741288 00000000 026dfc80 192.168.000.032 ffffffe0 192.168.000.034 000.000.000.000 01500 00000 002 IRE_RESOLVER 02d5a7c8 00000000 00000000 192.168.000.064 ffffffe0 192.168.000.034 192.168.000.035 00000 00000 000 IRE_NET 0273e0c8 00000000 00000000 192.168.000.064 ffffffe0 192.168.000.034 192.168.000.033 00000 00000 000 IRE_NET 019b4ec8 00000000 00000000 127.000.000.000 ff000000 127.000.000.001 127.000.000.001 00000 00000 000 IRE_NET root@hpeos002[] #
These are the entries resulting from my route command. If they were marked as gateways, they would be probed every 3 minutes (by default), and if we don't get a response from a gateway, then it is marked as dead . We can see this by using the ndd command again:
root@hpeos002[] # ndd -get /dev/ip ip_ire_gw_probe 1 root@hpeos002[] #
This parameter means that we will probe gateways:
root@hpeos002[] # ndd -get /dev/ip ip_ire_gw_probe_interval 180000 root@hpeos002[] #
This parameter defines the time interval in milliseconds (3 minutes, in this case) when we probe gateways. The kernel will flush routing table entries of gateways every 20 minutes:
root@hpeos002[] # ndd -get /dev/ip ip_ire_flush_interval 1200000 root@hpeos002[] #
As expected, the routing daemon gated will update the routing table periodically. The kernel will still probe dead gateways in case they come back online. Gateways are managed by the routing daemon: gated . Manipulating the use of static routes will require you to get involved with the route command. This is the main reason that static routes are not so favored. Think about it this way. In this example, if the cable I was using had an intermittent problem, some connections would not be possible while the cable was faulting. Other connections would be okay when the cable was working normally. If we were to persist in using static routes, an administrator would have to manually maintain the relevant routing tables using the route command whenever a problem occurred. With the routing daemon gated , there is a good chance we would avoid any perceived disruption in service with the gated daemon dynamically updating routing tables automatically. As I mentioned previously, we discuss the routing daemon gated in the next chapter. Before moving on to RARP and DHCP, let me say a quick word on Proxy ARP. 15.8.1 Proxy ARP The terms Proxy ARP, promiscuous ARP, and the "ARP hack" all relate to the same thing. This software setting is supported by some routers. The idea is to make setting up static routes as simple as possible. A very simple example is shown in Figure 15-4. Figure 15-4. Proxy ARP. 
The important thing to not is the use of the route command; the nodes hpeos001 and hpeos003 appear to be our own default gateway . This means that when node hpeos002 wants to communicate with node hpeos001 , it will simply send the packet on its local network; a hop count of 0 means that you are your own router to that particular network. When the initial ARP broadcast request packet is sent on the local network, routerX will realize that the particular IP address in question doesn't actually reside on the local network but resides elsewhere. The router running the proxy ARP software will respond to the broadcast ARP request by supplying its own MAC address back to node hpeos002 . Subsequent communication will require routerX to receive the packets from hpeos002 destined for hpeos001 , look up a special routing table that tells which physical network hpeos001 is actually located on, and forward the packets to node hpeos001 . Packets returning from hpeos001 follow a similar route with routerX hiding the physical location of nodes from each other. When we think about the ARP cache on node hpeos002 , there will be two IP address (IP addresses for routerX and hpeos001 ) mapping onto a single MAC address. To a security administrator, this is very suspect. This looks like one machine is spoofing another, i.e., pretending to be another machine by mapping someone else's IP address to your MAC address. This is not a violation of the ARP protocol, but simply an exploitation of an assumption made by the ARP protocol; all responses are legitimate . Proxy ARP may seem like a useful solution, but it does not scale well because the tables of nodes and addresses maintained on routerX commonly have to be maintained manually and are, therefore, prone to errors and take time and energy to maintain. I don't have a router that supports proxy ARP to show you in operation. In my experience, it is not used extensively due to the perceived security problems; lots of network monitoring software will alert administrators if they see two disparate IP addresses mapping to the same MAC address (although this is possible with IP multiplexing and is a required feature for package IP addresses in Serviceguard). We have looked at applying an IP address to a node manually. Let us now look at setting up RARP and DHCP to allow nodes to acquire an IP address dynamically. | 