RoutingA Second Look While we are talking about the gateway machine, it is an ideal time to take a further look at the intricacies of routing using Solaris. Routes are added to the routing table either statically or dynamically. Static ones are added by the system administrator, using the route command, which we will do later. Dynamic ones rely on a process maintaining the routing table on our behalf. The main protocols supported by Solaris are Router Information Protocol (RIP) and Router Discovery (RDISC). Normally, when a multi-interface machine boots, RDISC and RIP will be started by the programs /usr/sbin/in.rdisc and /usr/sbin/in.routed, respectively. They discover all the available routes and advertise these around the network. At the same time, any single-interface systems will be listening for the advertised routes. From here, both systems will build the routing table automatically. Similarly, if any routes need to be altered (for example, if a router fails and a different route then becomes the valid one), the new routes would be re-advertised and the routing table will be rebuilt accordingly. The second important part of this process is that IP forwarding is enabled by default on multi-interface systems. We'll see later in the section "Address Resolution" on page 271 how each interface contains the same Ethernet address, and that this is used to direct packets to a machine. Enabling IP forwarding means that if an interface receives a packet with the correct Ethernet address, but an IP address that matches the other network, it will simply forward the packet onto the correct interface. We can check that this is enabled using a command named ndd: indium# ndd -get /dev/ip ip_forwarding 1 indium# As with anything else, there are advantages and disadvantages to running RDISC/RIP. Some advantages are that the system administrator doesn't have to be concerned with ensuring that the routing table is up-to-date or whether a router fails since the routes will be maintained dynamically. Disadvantages are that in.rdisc is a potential security risk, and it can take a large amount of processing power from the server. The decision as to whether to run it is again a site-specific choice. As a general rule of thumb, if your network is small, doesn't have a complex layout, and is unlikely to change often, there is no real need for dynamic routing. On the other hand, if you have a complex network where routers are often changing (or failing!), it will probably be worthwhile running it. Our network is the formersmall and unlikely to change oftenso we will disable RDISC/RIP and add any routes we require manually. Disabling Router Discovery So, we know we don't want to enable router discovery, but how do we disable it? There are a number of different ways to do this. Let's look at some alternatives below. Creating a Default Router File The routing tables can contain an entry known as a "default route." As this suggests, it is the route taken by any packet that isn't destined for any other routes in the table. This is often used to connect to the outside world; in fact, we will use this ourselves in Chapter 13, "Connecting to the Internet." For this to work, the hostname or the IP address of the host is placed in a file named /etc/defaultrouter. When the system boots, it will set up the default route and stop both RDISC/RIP from been activated. Telling the System It Isn't a Router There are many reasons why a multi-interface machine should not forward packets across its network interfaces, often security related. To stop this from occurring, an empty file named /etc/notrouter is created. After the machine has been booted, ndd will show that IP forwarding has been disabled. Although we need this for our setup, the steps to carry this out would be as follows. After this task, the machine will be classed as a multihomed system; that is, a machine with multiple interfaces that doesn't forward packets between any networks it has configured. indium# touch /etc/notrouter <reboot the system> indium# ndd -get /dev/ip ip_forwarding 0 indium# Stopping the Binaries from Running If the system doesn't have a defaultrouter file set, but the system administrator still wants to use static routes, the best method for disabling RDISC/RIP is to rename the binaries as shown below so that they won't be started by any of the start-up scripts: indium# mv /usr/sbin/in.rdisc /usr/sbin/in.rdisc.disabled indium# mv /usr/sbin/in.routed /usr/sbin/in.routed.disabled indium# Which Method Should We Use? We'll use the last methodrenaming the binariesto stop RDISC/RIP from running. The reason for this is that we aren't ready to create the defaultrouter file at this point in the system build, since we will use this when we connect to the Internet later in the book. We said earlier that we will disable RDISC/RIP on the whole network. So, we'll run these commands on all the systems to ensure that we have a consistent setup, and add the change to our list of customization scripts that we'll build later. Manually Adding Static Routes First we'll add the routes manually until we are happy that they are correct, then we'll update the system files to ensure that this route is added every time the system boots. To achieve the correct results, we need to add a route from one network to the other on all the machines. Each network will connect to the other through the interface on indium. This means that all the systems connected to the 192.168.22.0 network will need the following route added: hydrogen# route add net 192.168.44.0 indium 0 hydrogen# While on all the systems connected to the 192.168.44.0 network, we'll add the following route: antimony# route add net 192.168.22.0 tin 0 antimony# After the route has been added, checking the routing table on (in this case) hydrogen should show something similar to that shown below: hydrogen# netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface ---------------- ---------------- ----- ----- ------ --------- 192.168.22.0 192.168.22.1 U 3 5 hme0 192.168.44.0 192.168.44.49 U 3 5 hme0 127.0.0.1 127.0.0.1 UH 0 2 lo0 hydrogen# While on antimony, the routing table would be as follows: antimony# netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface ---------------- ---------------- ----- ----- ------ --------- 192.168.22.0 192.168.22.50 U 3 5 hme0 192.168.44.0 192.168.44.51 U 3 5 hme0 127.0.0.1 127.0.0.1 UH 0 2 lo0 antimony# Now we can check that each subnet is visible from the other. We should be able to see, for example, hydrogen from antimony: hydrogen# ping antimony antimony is alive hydrogen# Again, we need to make the routes permanent across reboots. We could incorporate our changes into one of the standard networking start-up files, but we want to make sure the changes remain if we upgrade the operating system. The best way to do this is to create a specific start file in /etc/init.d, and then a link to this from /etc/rc2.d. The file below shows the one we have created for the 192.168.22.0 network: hydrogen# cat /etc/init.d/routes #!/bin/sh # # Create the required route to access 192.168.22.0 net # route add net 192.168.22.0 192.168.22.50 0 hydrogen# ln /etc/init.d/routes /etc/rc2.d/S99routes hydrogen# The files for the 192.168.44.0-networked systems will also be very similar, but instead will contain the route information that we added above. Again, these start-up scripts will become part of our standard customization build. | 
