Table of Contents

1.0: Routing


  1.1: About Routing
  1.2: Routing Definitions
  1.2.1: A Note on ARP
  1.3: How Routing Starts Up
  1.4: IP addresses, Netmasks and Subnet
  

2.0: Debugging Routing
  2.1: ifconfig
  2.2:  netstat
  2.3: ping
  2.4: traceroute

3.0: Common How Tos
  3.1: How to Set a default router 
  3.2: How to Add Static Routes
  3.3: How to Use in.rdisc
  3.4: How to Use in.routed
  3.5: How to Force a Machine to Be a Router
  3.6: How to Force a SunOS Machine Not to Be a Router
  3.7: How to Force a Solaris Machine Not to Be a Router
  3.8: How to Set a Netmask under SunOS
  3.9: How to Set a Netmask under Solaris
  3.10: How to Subnet by Bit
  3.11: How to Protect a Gateway Machine
  3.12: How to Proxy ARP
  3.13: How to Delete ARP Entries
  

4.0: Some Frequently Asked Questions
  4.1: Miscellaneous Questions
  4.2: Basic Routing Problems
  4.3: in.routed Errors
  4.4: netmask Problems
  4.5: traceroute Problems
  4.6: arp Problems
  

5.0: Patches
  5.1: Routing Patches for SunOS
  5.2: Routing Patches for Solaris
  5.3: ARP Patches for SunOS
  

6.0: Known Bugs & RFEs
  6.1: Bugs
  6.2: RFEs
  

7.0: References
  7.1: Important man Pages
  7.2: Sunsolve Documents
  7.2.1: Infodocs
  7.2.2: SRDBs
  7.3: Sun Educational Services
  7.4: Solaris Documentation
  7.5: Third Party Documentation
  7.6: RFCs

9.0: Additional Support  

1.1 About Routing

This PSD documents a wide variety of information concerning routing as implemented in the SunOS and Solaris operating systems. It is intended as both an introduction to routing, and as a guide to the most common problems. Routing can be a very complex subject, and this PSD can really only skim the surface of it. If you are setting up a complex routing environment, you will probably also want to refer to the more complete references listed in Section 7.0. For this discussion of routing, an understanding is needed of various aspects of ROUTING, as well as NETMASKS. These are both covered below. Solaris in.routed supports RIPv1 ( rip version 1). RIPv2 is available in gated, gated is not SUPPORTED 

1.2: Routing Definitions

The ROUTING TABLE is a table maintained in the kernel that determines how packets are routed to other systems. A number of programs may add or delete routes from the routing tables, including route, ifconfig, in.routed and in.rdisc. The routing table consists of three types of routes: HOST ROUTES are checked first and define a route to just one host. NETWORK ROUTES are checked second and define a route to all the hosts on one network. DEFAULT ROUTES are used as a catch-all, when no host or network routes are found to a destination. They usually send to a more knowledgeable routing machine, which has a better chance of being able to find a host or network route to the destination. (see Section 3.1 for how to add a default static route as explained in Sections 3.3 and 3.4, default routes may also be used with in.routed and in.rdisc.) For a packet to get from your machine to its destination, it usually goes through a number of routers. Each of these routers decides what to do with the packet based on the set of rules listed above. Systems are configured to handle routing in one of two ways: With STATIC ROUTING, the tables in the kernel are defined when the system boots and do not change. The ROUTE command can also be used to manually add and remove static routes. (see Section 3.1 for how to add an automatic default route at boot time see Section 3.2 for how to use route to add static routes.) With DYNAMIC ROUTING, the tables in the kernel are updated by a ROUTING DAEMON as the network changes. SunOS and Solaris machines both provide IN.ROUTED to exchange routing information between hosts. in.routed depends upon RIP PACKETS to exchange this info. Solaris also provides IN.RDISC, which just manipulates default routes. in.rdisc depends upon ROUTER DISCOVERY PACKETS to gather this information. (see Sections 3.3 and 3.4 for how to run in.routed, and in.rdisc, respectively.) In addition, IFCONFIG will always add routes when interfaces are brought up. These routes will be to directly connected networks for most interfaces, though they will be to directly connected hosts for point-to-point interfaces. With regard to routing, machines are divided into two classes, routers and hosts: A machine with more than one interface is, by default, defined to be a ROUTER. If in.rdisc or in.routed are running, they will advertise routing information. In addition, the machine will automatically forward IP packets. (see Section 3.6 and 3.7 for how to force a multiple-interface machine not to be a router.) A machine with only one interface is a HOST. If in.rdisc or in.routed are running, the host will listen for routing information. Hosts do not advertise routing information. 

1.2.1: A Note on ARP 

This document also contains some information on ARP, the ADDRESS RESOLUTION PROTOCOL. ARP is the protocol which converts the IP address to an address appropriate to the hardware type (ie, Ethernet addresses on an ether network). After normal routing protocols have done their work, ARP springs in to action. It's what actually gets packets from one machine to another. Usually, you should not have to worry about ARP at all. Except in special setups, it should work totally transparently. 

1.3: How Routing Starts Up

Solaris and SunOS each have a specific order which they use to start up routing: If an /etc/defaultrouter file exists (see Section 3.1), only static routing will be used, and a static default route will be created to the machine listed in the defaultrouter file. If there is no /etc/defaultrouter file, and the machine is a router, both in.routed and in.rdisc will be started, and they will advertise routing information. SunOS machines will only start up in.routed, as in.rdisc is not available under SunOS. If there is no /etc/defaultrouter file, and the machine is a host, in.rdisc is initially started. If any machines on the same network advertise via Routing Discovery, in.rdisc will be used as the dynamic routing program if there are no machines advertising via Routing Discovery, in.rdisc will quickly quit. SunOS skips this step. Finally, if there is no /etc/defaultrouter file, and either the machine is running SunOS, or in.rdisc has failed, then in.routed is started. It will listen for other in.routed programs advertising via RIP packets. This is the default manner in which most out-of-the-box Suns will operate. 

1.4: IP addresses, Netmasks and Subnets

All IP ADDRESSES are divided into two portions: the NETWORK ADDRESS, and the HOST ADDRESS. The network portion of the IP address defines the level at which routing is done this means that all machines with the same network address are on the same network. For example, if we had the IP address a.b.c.d, we might learn that the network portion of that address was a.b, and the host portion of that address was c.d. In that case, all machines with the IP address a.b.*.* would be on the same network. We would typically see a route to the network a.b.0.0. By default, Internet IP addresses are divided into 3 Classes. Each of these ranges has a different portion of the IP address reserved as the network and host addresses. Class IP Range Network Host 

Class A 1.*.*.* to 127.*.*.* a b.c.d 

Class B 128.*.*.* to 191.*.*.* a.b c.d 

Class C 192.*.*.* to 223.*.*.* a.b.c d 

Multicast: Class D 224.0.0.0 to 239.255.255.255. 

Reserved: Class E 240.0.0.0 to 247.255.255.255 

Given the standard classes, a few typical network routes would be: 16.0.0.0 150.101.0.0 207.48.123.0 NETMASKS are a shorthand way to define what portion of an IP address is reserved for the network address. The netmask is a set of 1 and 0 bits set to 1 define the network portion of an IP address, while bits set to 0 define the host portion of an IP address. We can look at the example of a Class B network address. In the address a.b.c.d, the network portion is a.b and the host portion is c.d. This is equivalent to the netmask 255.255.0.0: 255.255.0.0 = 11111111.11111111.00000000.00000000 This means that the three classes of networks have the following three default Netmasks: Class IP Range Netmask Nodes/Network

 Class A 1.*.*.* to 127.*.*.* 255.0.0.0 16,777,215 

Class B 128.*.*.* to 191.*.*.* 255.255.0.0 65,535 

Class C 192.*.*.* to 223.*.*.* 255.255.255.0 255 

Thus, packets sent to 100.1.2.3 are routed at the level 100.0.0.0 (and all 16 million machines in the 100.*.*.* range should form one distinct network), while packets sent to 200.1.2.3 are routed at the level 200.1.2.0 (and all 255 machines in the 200.1.2.* range should form one distinct network). Often, the default Netmasks are not sufficient. You can further divide a network by defining a custom netmask. This is termed SUBNETTING. A custom netmask changes the definition of the network size, and also changes the level at which routing is done. For example, many people on Class A or B networks implement a netmask of 255.255.255.0, so that all routing is done to networks of 255 or less machines. Sections 3.8 and 3.9 explain how to set a custom netmask for SunOS and Solaris. 

 This netmasking is really done down at the bit level. These means that you can divide a network even further. An example of this is given down in Section 3.10. [Example Note: references to the network 150.101.*.* in this document should be understood to be entirely fictitious, and are only used for reasons of example.] Ip Addressing assignment notes: InterNic Pre-Reserved Private Network - see RFC 1918 proposes network numbers that are reserved for private use. ( networks not on the internet or behind a Firewall using NAT) 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 

It is unwise to create a private network with the same addressing as one assigned on the global internet. What Addresses NOT to use ? IP address is all zeros IP address of all ones A valid network number A valid subnet number loopback 127.x.x.x addresses reserved by the Network Information Center. ( 0.x.x.x, 128.0.x.x, 191.255.x.x, 129.0.0.x, 223.255.255.x ) Multicast 224.x.x.x (greater than 223.*.*.*) What is the meaning of N in x.x.x.x/N? N is the number of significant bits in a prefix. This is a compact notation. In the old days, you'd write 129.146.86.51, netmask 255.255.255.0. Nowadays, you can just say 129.146.86.51/24, because 24 bits of the address indicate the subnet. We no longer have class in IP addresses (as of Solaris 2.6), so this syntax fits better. Also this will be the PRIMARY way of saying things in IPv6. 2.0 Debugging Routing can be somewhat tricky because problems could exist anywhere between you and your destination machine. The following commands are helpful, because they can be used to isolate which machine is the one with incorrect information. The following understanding of routing is necessary to be able to fully debug your routing tables: For communication from host A to host B to work, there must be a route from A to B and there must be a route from B to A. If there is an intermediate machine, machine C, then there should be a route from A to B through C, and C must have a route to B. The reverse is true as well. There must be a route from B to A through C and also a route from C to A. Also, C must be configured to pass packets from one interface to another to allow routing. This is done via the ip_forwarding variable described in sections 3.6 and 3.7. When debugging routing, you must also know whether you are working with a host or a router, as they have very different characteristics. 

2.1: ifconfig 

It is always best to start investigating routing problems by making sure that your interfaces are set up correctly. By running ifconfig, you can see your current interface setup: # ifconfig -a lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 inet 127.0.0.1 netmask ff000000 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 150.101.16.28 netmask ffffff00 broadcast 150.101.16.255 ether 8:0:20:10:78:d When an interface is brought up, it automatically creates a route. This route will be to the local network for multipoint interfaces (ether, FDDI, TR, etc), or to a host for point-to-point interfaces (PPP). If your main interface (le0 in the above example) is not UP and RUNNING, clearly no routing will be occurring through it. If the interface is UP, you will also want to examine the inet and netmask entries of your main interface, and make sure they are set correctly. If the inet is set wrong, check your /etc/hostname.interfacename file (ie, hostname.le0) and your /etc/hosts file. If the netmask is set wrong, check your /etc/netmasks file (see Section 3.8 and Section 3.9 for correct netmask setup). 

2.2: netstat 

You can examine your current routing tables by running the command netstat, as follows: %%%% netstat -rn 

Routing Table: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 127.0.0.1 UH 0 581 lo0 150.101.16.0 150.101.16.28 U 3 935 le0 224.0.0.0 150.101.16.28 U 3 0 le0 default 150.101.16.3 UG 0 802 default 150.101.16.12 UG 0 854 By examining this table, and correlating it with your problems, you can sometimes figure out what is going on. For example, if some of my non-local packets were randomly getting lost, I might suspect that one of my two default routes was dropping packets. Some problems are even more obvious. For example, if the "default" entries were not present in the Routing Table above, I would probably find that I could route nowhere but 127.0.0.1, 150.101.16.0 and 224.0.0.0. (In actuality, 224.0.0.0 is a special multicast route, while 127.0.0.1 is a special localhost route they can both be ignored for basic discussions of routing, which would mean that I could really route only to the network 150.101.16.0.) 

2.3: ping 

If your problem is not obvious from examining 'ifconfig -a' and 'netstat -rn', the ping command can be very useful in diagnosing it further. Try running 'ping -s machine-with-no-route'. There are two possibilities. If you get some type of 'network unreachable' or 'host unreachable' error, this typically means that there is no route on your machine to the machine you are trying to ping. You will probably need to define a static route for that machine's network, or possibly a default route. Following are a few examples. Under SunOS, you'll just get the basic '... unreachable' errors: %%%% ping -s lab-manta PING lab-manta: 56 data bytes sendto: Network is unreachable ping: wrote 150.101.89.28 64 chars, ret=-1 At this point, you should return to looking at your 'netstat -r' table. You should find that there is no entry for the network you are trying to ping. Under Solaris, you will get some additional information. In the following example, I am again pinging lab-manta from psi: %%%% ping -s lab-manta PING lab-manta: 56 data bytes ICMP Host Unreachable from gateway psi (150.101.16.28) for icmp from psi (150.101.16.28) to lab-manta (150.101.89.28) The above message confirms very clearly that it is the gateway 'psi' that did not have the route, when I tried to ping from 'psi' to 'lab-manta'. Again, I would have to examine psi's routing tables at this point. In addition, Solaris can sometimes report back errors that remote machines are having: %%%% ping -s lab-manta PING lab-manta: 56 data bytes ICMP Host Unreachable from gateway softmtv716 (150.101.16.3) for icmp from psi (150.101.16.28) to lab-manta (150.101.89.28) In this case, it is the gateway 'softmtv716', which is one of my default routers, which does not have a path to the remote machines. If I investigate the routing tables on that machine, I will probably find that there is no route to the 150.101.89.0 subnet. The other possibility is that ping just reports packets being dropped: %%%% ping -s lab-manta PING lab-manta: 56 data bytes ^C ----lab-manta PING Statistics---- 7 packets transmitted, 0 packets received, 100%%%% packet loss First, you should verify that the remote machine is up. If it is, you likely have a routing problem. Usually, this means that routes do exist in routing tables, but something along the path just drops the packets. This usually occurs because a router is set up wrong, or because a machine is listed as a gateway, but is not configured to forward IP packets. The only way to diagnose this is to examine a map of your network, find all the IP addresses in between you and the machine that is not responding, and then ping them one at a time. For example, I might discover that to get to lab-manta, a packet first goes out of the Ethernet interface of psi, then into router-le0, then out of router-le1, then into lab-manta. In this case, I would ping first psi, then router-le0, then router-le1 then lab-manta. If router-le0 responded, but router-le1 did not, I would suspect that router was not passing packets correctly. (If you note such a problem, before examining the router, you should check the netmask on your local machine, via the ifconfig -a command. An incorrectly set netmask can cause the symptoms described above.) If you discover that a remote router or non-Sun machine is not passing packets, SunService is unable to provide further assistance in this routing matter. Sections 8.0 and 9.0 explain your alternatives. If you discover that a Sun machine is not passing packets, you should make sure that the procedures explained in Sections 3.6 and 3.7 have not been implemented on the remote machine, to prevent it from routing. Packets might also be dropped if there are not paths back to your machine. In the above example, packets might go from psi, to router, to lab-manta fine, and then run into problems on the return trip. If nothing else has proved fruitful, you could then examine lab-manta, and make sure it had a path to psi, through router, and then examine router, and make sure that it also had a path to psi. 2.3.1: ping -sRv ping is able to record routes for you. However, this is only of limited utility because (1) you will not get any results if packets are not being returned (2) there is a limit of 9 IP addresses -and- (3) this method depends upon source routing, which may be turned off on some machines, for security reasons. Still, if you find that routes are being done incorrectly, you might find it of some use. Here is an example of usage: %%%% ping -sRv lab-classic PING lab-classic: 56 data bytes 64 bytes from lab-classic (150.101.89.54): icmp_seq=0. time=7. ms IP options: <record route> softmtv703-bb (150.101.15.60), four-oh (150.101.89 .4), lab-classic (150.101.89.54), install-7 (150.101.89.25), four-oh-mrn (150.10 1.15.11), softmtv716 (150.101.16.3), psi (150.101.16.28), (End of record) ^C ----lab-classic PING Statistics---- 1 packets transmitted, 1 packets received, 0%%%% packet loss round-trip (ms) min/avg/max = 7/7/7 This was done on this network: 16.28---(16.0)---16.3/15.60---(15.0)---15.11/89.4---(89.0)---89.54 psi softmtv four-oh lab-classic Two things are of note here. First, the route we get returned is a round trip, to the machine and back. Second, whenever a packet hits a machine, ping -sRv records only the OUTGOING interface, not the incoming interface. That is, the first time a packet goes through softmtv, we see the address 15.60, not 16.3. It's also interesting to see that the route was not symmetric. The packet bounced off install-7 on the way back, which is a machine that it did not touch on the way in. Examining that type of things can point you towards possible errors in your routing. If ping -sRv gives you massively incomplete info, or no info, you should ignore it, as you're probably hitting one of the limitations described at the start of this section. 

2.4: traceroute

If you can't solve your routing problems by looking at the routing tables and interfaces, a useful program for helping solve the problem is traceroute. Solaris 2.7 software bundles the popular traceroute utility. Unfortunately, this program is not shipped with SunOS or Solaris prior to 2.7, and as a result is not supported by SunService. However, you can easily find a copy on the internet. The ftp site ftp.dfn.de contains traceroute under the /pub/tools directory. If you consult 'archie' or other searching programs, it is likely that you will be able to find a more local copy. Traceroute works by sending out a set of 3 UDP packets. These packets are initially given a Time-To-Live of 1 hop, which is then increased to 2 hops, then to 3, etc.... until the packets reach the remote machine. This has the effect of stepping through the routers leading towards a destination machine, one at a time. However, it also causes you to only see a unidirectional route, from your client to the destination machines. It's quite possible for routes to be different going from and to a machine, and traceroute will not standardly show this. For example, if packets followed the following path: --> C --> A B <-- D <-- A traceroute from A to B would show: A, C, B, while a traceroute from B to A would show: B, D, A. Only by doing both traceroutes could you be sure of understanding the full route to and from a machine. Once you have a copy of traceroute, you can run it to request the path to a machine as follows: # traceroute lab-classic traceroute to lab-classic (150.101.89.54), 30 hops max, 40 byte packets 1 rainbow-16 (150.101.16.12) 6 ms * 3 ms 2 four-oh-mrn (150.101.15.11) 3 ms * 3 ms 3 lab-classic (150.101.89.54) 10 ms 3 ms 3 ms Unlike ping, traceroute lists the INCOMING port of each machine. We can get a round trip path by running traceroute with the following options: # traceroute -g remote-machine local-machine For example, if I were logged in to psi, and wanted to know the round trip path to lab-classic, I would type: # traceroute -g lab-classic psi traceroute to psi (150.101.16.28), 30 hops max, 40 byte packets 1 softmtv716 (150.101.16.3) 13 ms * 2 ms 2 four-oh-mrn (150.101.15.11) 3 ms * 3 ms 3 lab-classic (150.101.89.54) 4 ms 4 ms 3 ms 4 install-7 (150.101.89.25) 3 ms * 3 ms 5 four-oh-mrn (150.101.15.11) 3 ms * 3 ms 6 softmtv716 (150.101.16.3) 3 ms * 6 ms 7 psi (150.101.16.28) 10 ms 9 ms 3 ms Again, we see that when the packets are headed to lab-classic, we just get the INCOMING port listed. Oddly enough, traceroute reports the same port on the way back. This is to avoid confusion. However, this round trip method again uses source routing, which could be a problem if some intervening machines disable source routing. If a round trip invocation of traceroute seems to give bizarre results, you should try running a traceroute in each direction, to be sure that you are seeing the correct results. Traceroute is more useful than ping -sRv because it will show us partial paths, even if our destination machine is unreachable. In addition, it will show more than 30 hops, while ping -sRv is limited to 9. For example, if I knew that packets were not getting to lab-manta, I could run traceroute: # traceroute lab-manta traceroute to lab-manta (150.101.89.28), 30 hops max, 40 byte packets 1 rainbow-16 (150.101.16.12) 6 ms * 3 ms 2 four-oh-mrn (150.101.15.11) 3 ms * 3 ms 3 * * * 4 * * * ... This would tell me that either four-oh is not passing packets, or the router beyond four-oh is not answering at all. I could then examine those machines for problems. 2.5: Running in.routed verbose and trace mode for debugging and logging Examples: in.routed -s -t in.routed -q -v /var/adm/rip.log See SunOS 5.6 in.routed(1M) man page -v Allows a logfile (whose name must be supplied) to be created showing the changes made to the routing tables with a timestamp. -t All packets sent or received are printed on standard output. 2.6 : Solaris 2.6 route debugging info For further info see the 2.6 route man page and answerbook. ------------------------- Route verbose mode example: # route -v add 10.0.0.0 192.168.21.57 -net -netmask 255.255.255.0 so_dst: inet 10.0.0.0; so_gate: inet 192.168.21.57; so_mask: inet 255.255.255.0; RTM_ADD: Add Route: len 124, pid: 0, seq 1, errno 0, flags:<UP,GATEWAY,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 10.0.0.0 brickwall 255.255.255.0 add net 10.0.0.0: gateway 129.151.21.57 ------------------------- Route monitor # route monitor got message of size 124 RTM_ADD: Add Route: len 124, pid: 20871, seq 1, errno 0, flags:<UP,GATEWAY,DONE,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 10.0.0.0 elvis 255.255.255.0 ------------------------- Route get # route get elvis route to: elvis destination: 192.168.21.0 mask: 255.255.255.0 interface: le0 flags: <UP,DONE> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 3.0 Common How Tos 

3.1: How to Set a defaultrouter 

If you want to define a default router, so that you can send all of your non-local packets through one standard machine, simply create the file /etc/defaultrouter. It should have as its sole contents, the hostname or ipnumber of your router: %%%% cat /etc/defaultrouter router-1 or: 150.101.16.1 Note that any machine listed as a defaultrouter _must_ be on the same subnet as your machine and the name listed in /etc/hosts. On Solaris 2.4, and later, you can actually list multiple routers in the /etc/defaultrouter file, one default router per line: %%%% cat /etc/defaultrouter router-1 router-2 router-3 You also need to make sure that every name which appears in /etc/defaultrouter has an entry in your /etc/hosts file: %%%% cat /etc/hosts ... 150.101.16.1 router-1 150.101.16.2 router-2 150.101.16.3 router-3 After you have created /etc/defaultrouter, and made sure that any names listed in that file are also listed in /etc/hosts, you can reboot your machine. When it comes back up, it will automatically be routing through the defaultrouter that you have defined. If you have a simple network, or if you are just trying to get routing to work after your Sun machine is first installed, you probably want to set up a defaultrouter, as is described here. Section 4.1 gives some further advice on what type of routing to use. How does multiple default routes work? see SunSolve Infodoc 

INFODOC ID: 17516 

SYNOPSIS: How does multiple default routes work ( 2 static defaultrouter entries) ? Multiple default routes (wildcards) is a special case, they will be used in a round-robin fashion. Network connections will alternate between the default routers unless one is down, in which case it may take a few seconds to pick up the next default route. IREs( internal routing entries) are selected in a alternating fashion and that once selected, they are cached and the IRE entry is used for subsequent packets until it is flushed at ip_ire_flush_interval time (default 20 minutes) Multiple IRE entries are created by packets using the different default routes, which can be observed with " netstat -ra ". What happens if one of the default routers goes off-line? The TCP module on the gateway will attempt to resend the packet to that failed router based upon tcp_ip_notify_cinterval = 10 seconds (timeout value when TCP is performing an active open after which, TCP notifies IP to find a new route OR tcp_ip_notify_interval = 2 min (timeout value for an ESTABLISHED connection after which TCP notifies IP to find a new route. What happens if the default router looses the route? If the default router is up, and the route that it would use to forward the packet is not available and the router knows this, then the router should send back to your gateway an ICMP redirect, which should specify the IP address of one of your other default routers. 

3.2: How to Add Static Routes 

At any time, you can add static routes to your machine via the route command. The standard syntax for adding a network route is: route add net "remote-network-ip gateway-ip" 'hop-metric-count' On Solaris 2.6: route add -net "remote-network-ip gateway-ip" -netmask route add -host "host-ip local-intrf-ip" -interface remote-network-ip is the network you are adding a route to, gateway-ip is the ip address of the gateway that leads to that remote-network. hop-count is an integer which identifies the number of gateways that you must go through to get to the remote-network. A network that is directly connected to your machine would have a hop count of 0 (ie, the 150.101.16.0 net in the example below). A remote-network that is directly connected to a gateway-machine that is, in turn, on the same network as your machine would have a hop count of 1 (ie, the 150.101.17.0 net in the example below). Static routes are rarely added for remote-networks with a hop count greater than 1. One thing to note is that the metric is really not used except to differentiate between a "gateway" route (metric > 0) and an interface route (metric == 0)." Routes created with the route(1m) command play no part in the RIPv1 protocol .." For example, on the following network: YOUR-MACHINE---(150.101.16.0 NET)---ROUTER-1---(150.101.17.0 NET) You could execute the following command from your machine, in order to create a static route to the 150.101.17.0 net: route add net 150.101.17.0 150.101.16.1 1 (150.101.16.1 is the IP address of router-1) Solaris 2.6 example: route add -net 150.101.17.0 150.101.16.1 -netmask 255.255.255.0 The route command can also be used to add routes to remote machines. This is typically only done when using some type of point-to-point interface. The syntax is: route add host remote-machine-ip gateway-ip hop-count ie: route add host 150.101.17.100 150.101.16.1 1 Static routes are usually only used in conjunction with a /etc/defaultrouter. You might do so if you had a couple of networks which you did not want to go through your defaultrouter. In that case, you will probably want to make the routes permanent, by adding the route commands to the /etc/init.d/inetinit file. You can not use the above method to add static routes if you are running in.routed, as in.routed will automatically remove them after 90 seconds. If you are using in.routed, but want to include a few static routes, you can do this with the /etc/gateways file, explained in Section 3.4 below. 

3.3: How to Use in.rdisc 

The in.rdisc daemon is only available on Solaris machine it depends on multicasting, which is not present on older SunOS machines. If you do not have an /etc/defaultrouter file on a Solaris machine, any routing host will automatically bring up in.rdisc at boot time. As long as there is at least one router on the same network which advertises Router Discovery messages, in.rdisc will continue running. If nothing responds to the initial Router Discovery queries, in.rdisc on a routing host will automatically quit, and the rc files will fall through to in.routed. Solaris routers will also automatically bring up in.rdisc at boot time, if there is no /etc/defaultrouter file. They will not ever exit, but rather will advertise via Router Discovery messages. If you want in.rdisc to run, you should never have to do anything, other than delete the /etc/defaultrouter file, if it exists, and make sure that at least one Router Discovery compliant router exists on the same subnet as your machine. If you want to disable in.rdisc, you should simply rename it: %%%% mv /usr/sbin/in.rdisc /usr/sbin/rdisc.save In general, in.rdisc should only be run on routing hosts if your local network is relatively complex. 

3.4: How to Use in.routed

On a SunOS machine, in.routed will automatically be started if there is no /etc/defaultrouter file and in.rdisc failed to find any Router Discovery compliant routers on the local network. in.routed will automatically start on routers if there is no /etc/defaultrouter file, even if in.rdisc is running. in.routed supports RIPv1 only. You should not need to do anything, other than possibly deleting an /etc/defaultrouter file, in order to get in.routed to run. You can force in.routed to bring up standard network routes by putting entries for them into the file /etc/gateways. The standard format for that file is: net <remote-network-ip> gateway <gateway-ip> metric <hop-count> passive or: net <remote-network-ip> gateway <gateway-ip> metric <hop-count> active remote-network-ip, gateway-ip and hop-count are all described in Section 3.2. The keyword 'passive' should be used if you want the entry to be permanent.Passive gateways are maintained in the routing tables forever.Information regarding their existence is not included in any routing information transmitted. Active gateways are treated equally to network interfaces. The keyword 'active' should be used if you want in.routed to occasionally query the gateway host, and delete the route if it becomes inactive. Routing information is distributed to the gateway and if no routing information is received for a period of time,the associated route is deleted. An example of a gateway file follows: %%%% cat /etc/gateways net 150.101.17.0 gateway 150.101.16.1 metric 1 passive net 0.0.0.0 gateway 150.101.16.2 metric 1 passive The first line of this example is identical to the 'route add' command given in Section 3.2. It creates a route for the network 150.101.17.0 through the gateway machine 150.101.16.1. In the gateways file, the number 0.0.0.0 is a special number which means 'default route'. Thus, the second line creates a default route through the gateway machine 150.101.16.2. The gateways file may also be used to add routes to specific hosts, with the following syntax: host <remote-machine-ip> gateway <gateway-ip> metric <hop-count> passive Or: host <remote-machine-ip> gateway <gateway-ip> metric <hop-count> active Finally, the following directives may also be put in a gateways file: norip <interface> noripin <interface> noripout <interface> These prevent RIP (in.routed) packets from either going in or out of the specified interface (norip prevents packets from going either in or out). For example: %%%% cat /etc/gateways norip le1 The above would prevent RIP packets from going in or out of the le1 interface. This could be exceptionally helpful if you did not want your RIP info to be broadcast out of your le1 interface for security reasons. In general, routed should only be used on routing hosts if your local network is relatively complex. In addition, there must be machines on the local network which will correctly send out RIP packets if there are not, routed will fail to work correctly on a routing host. If you wish to disable in.routed, the best way to do this is by creating a defaultrouter file, as is described in Section 3.1. 

3.5: How To Force a Machine to Be a Router 

If your machine has at least two interfaces in addition to lo0, or if your machine has at least one point-to-point interface, it will automatically be set up as a router. Solaris 2.x: The IP layer will normally act as a router (forwarding datagrams that are not addressed to it, among other things) when the machine has two or more interfaces that are up. This behavior can be overridden by using ndd(1M) to set the /dev/ip variable, ip_forwarding. The value 0 means do not forward; the value 1 means forward. The initialization scripts (see /etc/init.d/inetinit) set this value at boot time based on the number of "up" interfaces, but will not turn on IP forwarding at all if the file /etc/notrouter exists. When the IP module is loaded, ip_forwarding is 0 and remains so if: only one non-DHCP-managed interface is up (the most common case) the file /etc/notrouter exists and DHCP does not say that IP forwarding is on the file /etc/defaultrouter exists and DHCP does not say IP forwarding is on Otherwise, ip_forwarding will be set to 1 . SunOS 4.x On a SunOS machine, you will want to adjust the /etc/rc.local file, to change the following line: in.routed echo 'running routing daemon.' To read: in.routed -s echo 'running routing daemon.' In order to insure that routed is in the "supplier" mode and routing information is being advertised. This is done for you automatically on Solaris machines if there are 2 up interfaces on bootup. ip_forwarding must be enabled to allow the system to forward packets between interfaces. to check on SunOS 4.x # echo "ip_forwarding/X" | adb -w /vmunix /dev/kmem on Solaris 2.x # ndd /dev/ip ip_forwarding 0 = don't forward, 1 = forwarding enabled 

3.6: How to Force a SunOS Machine Not to Be a Router 

If you do not want your multiple-interface SunOS machine to route packets, you will need to rebuild the kernel. In the file /sys/netinet/in_proto.c, change the following line: #define IPFORWARDING 0 to read: #define IPFORWARDING -1 Afterwards, config the kernel, remake it, and then install it. It may be useful to note, that on SunOS machines, IPFORWARDING can have three values: -1 Never forward IP packets 0 Don't forward, but change IPFORWARDING to 1 if there are two or more interfaces 1 Always forward IP packets 

3.7: How to Force a Solaris Machine Not to Be a Router 

If you do not want your multiple-interface machine, running Solaris 2.4 or lower, to route packets, you just need to make a small change to the file /etc/init.d/inetinit. Find the following two lines: numifs=`ifconfig -au grep inet wc -l` numptptifs=`ifconfig -au grep inet egrep -e '-->' wc -l` And immediately after them, insert the following: numifs=2 numptptifs=0 After the machine next reboots, it will not act as a router. If you are using Solaris 2.5 or greater, it's even easier to make your machine not route packets. Simply create an /etc/notrouter file: %% touch /etc/notrouter Afterwards, reboot the machine. It may be useful to note, that on Solaris machines, ip_forwarding can have three values: 0 Never Forward 1 Always Forward 2 Only forward when two or more interfaces are up The above steps result in the ndd /dev/ip ip_forwarding variable being changed from "1" to "0", which prevents routing. 

3.8: How to Set a Netmask under SunOS 

In order to include a permanent netmask on your SunOS machine, you must make an entry in the /etc/netmasks file, in the following format: network-address-without-zeroes netmask For example: %%%% cat /etc/netmasks 150.101 255.255.255.0 The above would subnet the class B network, 150.101.0.0, into 254 subnets, from 150.101.1.0 to 150.101.254.0. It is important to note that the entry in the left hand column must be the original base network number (ie # for a Class A, #.# for a Class B and #.#.# for a Class C), not the subnet. 

3.9: How to Set a Netmask under Solaris 

In order to include a permanent netmask on your Solaris machine, you must make an entry in the /etc/netmasks file, in the following format: network-address netmask For example: %%%% cat /etc/netmasks 150.101.0.0 255.255.255.0 The above would subnet the class B network, 150.101.0.0, into 254 subnets, from 150.101.1.0 to 150.101.254.0. In 2.5.1 and below, only one entry for the entire class network is allowed to support standard subnetting as specified in RFC-950 It is important to note that the entry in the left hand column must be the original base network number (ie #.0.0.0 for a Class A, #.#.0.0 for a Class B and #.#.#.0 for a Class C), not the subnet. The 2.6 kernel has changed to support VLSM. It is now possible to combine the RFC-950 and RFC-1519 form of subnet masks in the netmasks file. The network address should be the "SUBNETTED" address NOT the standard network number based on the hosts ip address. (see man page for netmasks) Here are a few examples: A host address 192.188.206.65 with a netmask of 255.255.255.224 /etc/netmasks 192.188.206.64 255.255.255.224 A host address 172.31.16.193 with a netmask of 255.255.255.192 /etc/netmasks 172.31.16.192 255.255.255.192 See section 3.10 to get a better understanding of how to subnet by bit. 

3.10: How to Subnet by Bit 

As was noted in Section 1.3, subnetting is actually done at the bit level. That is, all the bits that form the IP address are masked by the bits that form the Netmask, in order to generate the Network Address. Here's some examples of what a netmask looks like down at the bit level: 255.255.255.0 = 11111111.11111111.11111111.00000000 255.255.255.192 = 11111111.11111111.11111111.11000000 And here are a few examples of using the '192' netmask: IP Address Netmask Network Address ---------- ------- --------------- 150.101.16.90 255.255.255.192 150.101.16.64 150.101.16.150 255.255.255.192 150.101.16.128 Expanding out the first example should make this a bit more clear: 150.101.16.90 = 10010110.01100101.00010000.01011010 255.255.255.192 = 11111111.11111111.11111111.11000000 Network Address = 10010110.01100101.00010000.01000000 = 150.101.16.64 The resulting network number is 150.101.16.64 and the host address is 26. The only caveat is that RFC 917 states that it is illegal to have a subnet address that is all 0s or all 1s. This means that when you split your class C, you will lose the bottom set of IP addresses, and also the top set of IP addresses. Putting this all together, we can take a look at two examples. These examples both assume a Class C network (that is a network between 192.*.*.* and 223.*.*.*), which you wish to subnet. IP ADDRESS = any Class C NETMASK = 255.255.255.128 = 11111111.11111111.11111111.10000000 Subnet 1 = '0' Illegal because subnet is all 0s Subnet 2 = '1' Illegal because subnet is all 1s Clearly, using the 255.255.255.128 mask to subnet a Class C is useless. IP ADDRESS = any Class C NETMASK = 255.255.255.192 = 11111111.11111111.11111111.11000000 Subnet 1 = '00' Illegal because subnet is all 0s addresses x.x.x.0 to x.x.x.63 are wasted Subnet 2 = '01' network x.x.x.64, broadcast x.x.x.127 machines range from x.x.x.65 to x.x.x.126 Subnet 3 = '10' network x.x.x.128, broadcast x.x.x.191 machines range from x.x.x.129 to x.x.x.190 Subnet 4 = '11' Illegal because subnet is all 1s addresses x.x.x.192 to x.x.x.255 are wasted Thus, if you had a Class C that you wanted to divide into two subnets, you would use the 192 netmask described above, and end up with two ranges of 63 machines each. Now, the above all assumes that you own a Class C network, that is a network with an network address between 192.*.*.* and 223.*.*.*. Another common situation is the case where you are on a Class B network (ie 150.101.0.0), but you actually control a network equivalent in size to a Class C (ie 150.101.16.0), and you want to subnet further. Things work about the same as above, but you do not have to waste the top and bottom IP ranges. This is because the entire subnet, which is nine or more bits long, is not set to all 0s or all 1s in those cases only the last two digits are. So, if we were subnetting 150.101.16.0 further, using the 192 subnet, our table would look like this: IP ADDRESS = 150.101.16.0 (though any class B, further subnetted will work the same) NETMASK = 255.255.255.192 = 11111111.11111111.11111111.11000000 Subnet 1 = '00010000.00' network 150.101.16.0, broadcast 150.101.16.63 machines range from 150.101.16.1 to 150.101.16.62 Subnet 2 = '00010000.01' network 150.101.16.64, broadcast 150.101.16.127 machines range from 150.101.16.65 to 150.101.16.126 Subnet 3 = '00010000.10' network 150.101.16.128, broadcast 150.101.16.191 machines range from 150.101.16.129 to 150.101.16.190 Subnet 4 = '00010000.11' network 150.101.16.192, broadcast 150.101.16.255 machines range from 150.101.16.193 to 150.101.16.254 Subnetting by the bit can be a pretty complex process and SunService can not provide further assistance on initial configuration of this type. However, if you're trying to subnet at this small of a level, and don't totally understand how to do so, consult Section 8.0 and 9.0 for where you can get further assistance from within Sun. 

3.11: How to Protect a Gateway Machine 

Routing: --------------- You may find that you wish to keep a gateway machine from sending routing information via certain interfaces. This is usually done on a machine that acts as a firewall of some type. Assuming that you have a multiple interface machine that is advertising routing information (via in.routed and in.rdisc), you should do two things. First, totally turn off in.rdisc: %%%% mv /usr/sbin/in.rdisc /usr/sbin/rdisc.save Second, add norip lines to the /etc/gateways file for all interfaces that you do not want routing information to be sent through. For example, if le1 led to an external net, you would probably add the following entry: %%%% cat /etc/gateways norip le1 This type of setup should only be done on a firewall machine where you are trying to decrease your net connectivity. IP forwarding: --------------- For Security and network isolation. You can set ip_forwarding off and ip_strict_dst_multihoming on, if you are trying to prevent access to the other interfaces. "ndd /dev/ip ip_forwarding" Determines if the workstation will route packets. ex: ndd -set /dev/ip ip_forwarding 0 "ndd /dev/ip ip_strict_dst_multihoming" Determines whether to use Strict Destination Multihoming. If this variable is set to True, and ip_forwarding is turned off, then the machine will not except packets destined for a different interface. RFC112 ex: ndd -set /dev/ip ip_strict_dst_multihoming 0 also see: "ip_forward_directed_broadcasts" Determines whether to forward broadcasts directed to a specific net or subnet, if directly connected "ip_forward_src_routed" Determines whether to forward packets that are source routed,(packets which have a specific machine listed as part of route) 

3.12: How to Proxy Arp 

Proxy ARPing involves one machine answering ARP requests for another machine. This is most frequently done when a point-to-point interface (ie PPP) is being used. For example, imagine the following setup: ppp-machine psi 150.101.16.200---PPP LINK--ttya--150.101.16.28--le0--150.101.16.0 NETWORK 8:0:20:1:2:70 8:0:20:1:2:3 ^^^ether NA default route=psi In this example systems on le0 network would have problems, because systems on the le0 network and ppp link are not directly connected on the 150.101.16.0 network, 150.101.16.X will arp for 150.101.16.200 and not get a response. Using psi to proxy arp on behalf of the ppp-machine will allow the packets to be forwarded properly. The following command, run on psi, would allow that machine to proxy arp for ppp-machine: # arp -s ppp-machine 8:0:20:1:2:3 pub ^^^ ^^^^^^^^^^^^ ppp client hostname psi servers Ethernet Mac address Note that psi supplies its own Ethernet address, not ppp-machine's. This is because ARP should cause packets to go to psi, which is the only machine which actually can pass on packets to ppp-machine. (This command should also be put in the rc files if you wish it to be permanent.) Example: Create an executable file called /etc/rc2.d/S99proxyarp. This should have an arp entry for each of the clients , listing your server's Ethernet address: #!/bin/sh # # S99proxyarp script to force ip forwarding # and add published arp entries for point to point clients. ndd -set /dev/ip ip_forwarding 1 arp -s ppp-pc1 8:0:20:1:2:3 pub arp -s ppp-pc2 8:0:20:1:2:3 pub make it executable: # chmod +x /etc/rc2.d/S99proxyarp 

3.13: How to Remove ARP Entries in Solaris? 

You may determine that you need to remove arp entries. This could be done if a machine has changed ether addresses, and you must have access to it at once, or if a proxy arp has changed. You can delete a single ARP entry with the following command: # arp -d machine-name a simple way to clear a machine's entire ARP cache without rebooting, deleting entries manually or waiting for timeouts. # ifconfig le0 <IP> The above command ( = ifconfig down; ifconfig up) will delete all entries including static entries and published virtual interface entries. See srdb 11416 for arp time-out info. srdb 11416 what are the ARP values set by ndd? 4.0 Some Frequently Asked Questions 

4.1: Miscellaneous Questions 

QUESTION: Does Sun support gated? 

ANSWER: No. The public domain version of gated is available via several ftp sites, However, SunService can provide NO assistance with gated. 

Where to get GateD:              The GateD Consortium can be reached at: http://www.gated.org/ http://www.gated.org/new_web/code/code/gated-multi/code.html Sun offers this tar file strictly as a convenience, and offer no warranty, etc. ftp://playground.sun.com/pub/GateD/ 

QUESTION: What type of routing should I use? 

ANSWER: This depends on your overall network setup, and your goals. If your machine is on a simple unchanging network, that only has a few routers connecting it, it is best to just install one static default router. In addition, you _must_ use a static default router if you do not (or can not) propagate either Router Discovery or RIP messages within your network. The only deficit with this method is that you don't have a fallback if the primary router fails. This is not a problem in Solaris 2.4 and above, which allow multiple router entries in the defaultrouter file. Section 3.1 explains how to set up a default router. If you have a complex internal network, or a network that frequently changes, or you want to make sure that your machine has fallback opportunities if your primary router goes down, you should use one of the dynamic routing programs. If you have multiple routers which all support Router Discovery and are on a Solaris system, you will want to run in.rdisc. Otherwise, you'll want to run in.routed. Note that dynamic routing programs will not work unless you have already configured the machines on your network to send out either Router Discovery or RIP messages. Also, you should be aware that the dynamic routing protocols will introduce some limited level of additional traffic to your network. Sections 3.3 and 3.4 explain how to set up in.routed and in.rdisc. 

QUESTION: What routes are automatically set up? 

ANSWER: A few routes automatically get set up every time your machine is booted. First, all machines will always have a localhost route back to themselves: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 127.0.0.1 UH 0 591 lo0 This is standard and increases the efficiency of packets that a machine sends to itself. Second, Solaris machines have a special multicast route: 224.0.0.0 150.101.16.28 U 3 0 le0 Multicast routes are used by certain programs that broadcast to a group of machines rather than to the subnet in general. Finally, all machines will always set up one route for each of their interfaces. The route will be a simple one which says that all packets which go to the interface's network should be routed through the interface. For example, I have one interface, le0, with an IP address of 150.101.16.28. Since I use a netmask of 255.255.255.0, this means that my local network is 150.101.16.0, and the route looks like this: 150.101.16.0 150.101.16.28 U 3 951 le0 (It should be noted that machines which use point-to-point interfaces, such as PPP, will have slightly different routes consult the PPP Tip Sheet for more info on these.) 

QUESTION: Where did all these routes in my routing table come from? When I look at netstat -rn I see a lot of routes that I didn't add. 

ANSWER: As noted in the previous question and answer, you will get one for each interface is configured on bootup as well as for the loopback and multicast addresses. One of the following Sun routing daemons may have added them: in.routed in.rdisc GateD (or any other 3rd party, non-Sun supported routing daemon may add them) /etc/gateways may have routing table entries that get added They may have manually been entered on the command line ICMP redirects from routers can add them (look for the D flag in the netstat -rn output). They may have been added to some script (probably executed during bootup) somewhere on the system. Check for this by grep'ing for "route" in directories like /etc/rc2.d, /etc/rc3.d and so on. 

QUESTION: Why was ip_forwarding changed in 2.6 and above. 

ANSWER: ip_forwarding of 0 is now the default and the value 2 was removed to comply more strictly to RFC1122 (default MUST be to not forward packets) In 2.6, 2.7 if a defaultrouter is defined, then S69inet will set ip_forwarding off(0) unless DHCP has set IpFwdF. see 2.7 ip(7P) 

Bug references: 

Bug Id: 1113271 Synopsis: ip_forwarding should be configurable via /etc/system 

Bug Id: 4135171 Synopsis: 2.6 routing issue should be documented 

Bug Id: 4052347 Synopsis: Man page for ip needs updated for new ip_forwarding values in Solaris 2.6 To force ip_forwarding on, add the ndd change in the startup script. ndd -set /dev/ip ip_forwarding 1 The Netra implements a S99routing (/opt/netra/networking/routing/bin/boot.conf) that turns it on #!/bin/sh ndd -set /dev/ip ip_forwarding 1 ndd -set /dev/ip ip_forward_src_routed 0 --- 2.7 ip man page update: "...The IP layer will normally act as a router (forwarding datagrams that are not addressed to it, among other things) when the machine has two or more interfaces that are up. ... When the IP module is loaded, ip_forwarding is 0 and remains so if: o only one non-DHCP-managed interface is up (the most common case) o the file /etc/notrouter exists and DHCP does not say that IP forwarding is on o the file /etc/defaultrouter exists and DHCP does not say IP forwarding is on Otherwise, ip_forwarding will be set to 1." -

 4.2: Basic Routing Problems 

This sections outlines a very common routing problems. The techniques described in Section 2.0 will be needed to resolve more difficult routing problems. 

QUESTION: Why can I only ping machines on my subnet? 

ANSWER 1: You are using in.routed (this is how a machine ships by default), but are not propagating RIP packets on your network. You should define a default router, as described in Section 3.1. 

ANSWER 2: Your netmask is set incorrectly on the machine which can not ping. Sections 3.8 and 3.9 describe how to define a permanent custom netmask. 

ANSWER 3: You have a default router defined, but that machine is not forwarding the IP packets. If that router is a Sun machine, you should make sure that it has _not_ been modified as described in Section 3.6 or 3.7. If it is a non-Sun machine, SunService can not provide further assistance in resolving why it might not be forwarding IP packets. 

4.3: in.routed Errors 

QUESTION: Why does in.routed constantly generate the following error: "packet from unknown router, x.x.x.x" 

ANSWER: This occurs because your machine is receiving broadcast packets from a router that is on a different subnet. Since broadcast packets will not typically cross subnet boundaries, this usually means that you have machines from two subnets on the same physical wire. Often, this is a mistake if you see this error, and do not expect to have multiple networks on the same wire, you should track down the source machine (x.x.x.x), and fix its IP address. However, there are cases where this setup might be intentional, as outlined in RFC 1597. This would imply that you had several networks all using the same physical wire. Unfortunately, this is not currently supported correctly, as is described in Section 6.1. If you are on a SunOS machine, just install patch 100283 and this problem will go away. More information on this is contained in Section 5.1. Under Solaris, a fix for this issue is still pending. If the errors are too much, you should revert to using a default router, as described in Section 3.1, until the problem is corrected. 

QUESTION: Why does in.routed keep bringing my PPP interface up? 

ANSWER: in.routed automatically sends out RIP packets every 30 seconds. This will keep your PPP interface up. To prevent this, you can put the following entry in your /etc/gateways file: %%%% cat /etc/gateways norip ipdptp0 This will allow you to continue running in.routed, without have it keep your PPP interface constantly up. Another Tip Sheet exists for PPP which explains many routing problems associated with a PPP interface. 

4.4: netmask and broadcast Problems 

QUESTION: why is my netmasks entry being ignored? 

ANSWER 1: The network address listed in the netmasks file is a subnet instead of the base network. Remember that the network address should just be # if you are on a class A, #.# if you are on a class B, and #.#.# if you are on a class C. Section 1.3 has a listing of which IP addresses belong to which classes. A2: Although you have added the netmasks to /etc/netmasks, you have not put it in NIS. After NIS is brought up, your /etc/netmasks file is no longer consulted. Make sure to duplicate any netmasks entries in your NIS maps. 

QUESTION: Why do I get segmentation faults on boot after changing my netmasks file? 

ANSWER: This is a known bug in some Solaris systems. It is mentioned in Section 6.1. If you examine your /etc/netmasks file, you will find that it contains blank lines. Remove them, reboot, and your system will come up clean. 

QUESTION: Does Sun support variable-length subnetting, per RFC 1219? 

ANSWER: Solaris 2.6 or above supports VLSM and CIDR. Q1: Why can't I add a netmask for a remote subnet? 

QUESTION 2: If I add a netmask for a subnet not directly connected to my machine, it is ignored. Why? 

ANSWER: Sun systems only support netmasks for networks that are directly connected to a machine. This means that if you try and add a netmask for a network that is not directly connected to your machine, it will fail. If you want to route to a remote network which is subnetted, the correct method is to route to a machine that is directly connected to the subnetted network, and then allow that machine to route to the appropriate subnetwork. When RFC 1219 is implemented on Suns, this functionality may become available. 

QUESTION: How do I make SunOS 4.x limited broadcast all 1's like solaris2. 

ANSWER: Manually specify the broadcast, --------- example: # ifconfig le0 flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> inet 1207.48.123.87 netmask ffffff00 broadcast 207.48.123.0 ether 8:0:20:1a:f:83 # ifconfig le0 broadcast 129.151.21.255 # ifconfig le0 flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> inet 207.48.123.87 netmask ffffff00 broadcast 207.48.123.255 ether 8:0:20:1a:f:83 --------- Add a ifconfig line to /etc/rc.local to take effect on bootup. ... # set the netmask from NIS if running, or /etc/netmasks for all ether interfaces ifconfig -a netmask + broadcast + > /dev/null ifconfig le0 broadcast 207.48.123.255 

4.5: traceroute information and Problems 

Sun does not support the public domain traceroute package. New : Solaris 2.7 software bundles the popular traceroute utility. The traceroute utility is used to trace the route an IP packet follows to an Internet host. Traceroute uses the IP protocol ttl (time to live) field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path, and PORT_UNREACHABLE (or ECHO_REPLY) from the destination host. The traceroute utility starts sending probes with a ttl of 1, and increases by one until it gets to the intended host or has passed through a maximum number of intermediate hosts. The traceroute utility is especially useful for determining routing configuration problems and routing path failures. If a particular host is unreachable, the traceroute utility can be used to see what path the packet follows to the intended host and where possible failures occur. The traceroute utility also displays the round-trip time for each gateway along the path to the target host. This information can be useful for analyzing where traffic is slow between the two hosts. For more information, see TCP/IP and Data Communications Administration Guide. The below questions simply note some problems that we have run into with traceroute, and the simple steps that can be taken to correct them. Further problems or errors with traceroute should be directed to the traceroute author. 

QUESTION: Why does traceroute fail on every other packet, under Solaris: # traceroute psi traceroute to psi (150.101.16.28), 30 hops max, 40 byte packets 1 psi (150.101.16.28) 6 ms * 2 ms 

ANSWER: Solaris introduced a variable called 'ip_icmp_err_interval' which enforces a minimum time in between ICMP error messages. traceroute depends upon ICMP error messages, and tends to send them very fast. As a result, if ip_icmp_err_interval is set to the default value on a Solaris machine, traceroute's second packet will always get dropped, as shown above. You can disable this Solaris feature by adjusting the ndd variable: # ndd -set /dev/ip ip_icmp_err_interval 0 If you want this change to be permanent, you should add it to the file /etc/rc2.d/S69inet. However, since every single Solaris machine between you and your destination must change this variable, it is often more reasonable just to let every second packet get dropped, and not worry about it. 

4.6: arp Problems 

QUESTION: Why does arp fail with the following message: # arp -s system 0:8:20:1:2:3 pub "system: No such device or address" 

ANSWER: This occurs if you try and use arp to add a machine that is not on a local network. You may only arp entries for hosts on subnets that are directly connected to your machine. 5.0 Patches The following is the list of all of the routing related patches for 4.1.3, 4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having routing problems, installing the patches is a good place to start, especially if you recognize the general symptoms noted below. In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com. 

5.1: Routing Patches for SunOS 

100283 SunOS 4.1.1 4.1.2 4.1.3: in.routed mishandles gateways, multipl Fixes problems in the way that routed broadcasts some routes, and corrects an error in routing to machines with multiple interfaces on the same physical wire. 

5.2: Routing Patches for Solaris 

101318   SunOS 5.3: Jumbo patch for kernel (includes libc, lockd) 

104231   SunOS 5.3: in.routed patch 

101945   SunOS 5.4: jumbo patch for kernel 

104232   SunOS 5.4: in.routed patch 

103169   SunOS 5.5: arp,ip,udp,icmp driver and ifconfig fixes 

104234   SunOS 5.5: in.routed patch 

103630   SunOS 5.5.1: ip ifconfig arp udp icmp patch 

104236   SunOS 5.5.1: in.routed finds packet from unknown router 

104958   SunOS 5.5.1: usr/sbin/in.rdisc patch 

105786   SunOS 5.6: /kernel/drv/ip patch Resolve a large number of problems related to in.routed, and the kernel routing tables. Should be installed on all machines, but are an absolute necessity for routers. 

5.3: ARP Patches for SunOS 

100361 SunOS 4.1.1 4.1.2 4.1.3: server not responding due to limits of arp Corrects problems caused by the arp table being limited to 512 entries. Should be installed if you are hitting this limit. 6.0 Known Bugs And RFEs The following bugs & rfes reflect currently open issues with the routing software.

 6.1: Bugs 

1182386  in.routed finds packet from unknown router Sun's in.routed complains if it gets a broadcast from a router on a different network. This is in violation of RFC 1597. The following patches correct this: 

104022   SunOS 4.1.3: in.routed fixes 

104023   SunOS 4.1.3_U1: in.routed finds packet from unknown router 

104024   SunOS 4.1.4: in.routed finds packet from unknown router 

104231   SunOS 5.3: in.routed patch 

104232   SunOS 5.4: in.routed patch 

104234   SunOS 5.5: in.routed patch 

104236   SunOS 5.5.1: in.routed finds packet from unknown router 

104237   SunOS 5.5.1_x86: in.routed finds packet from unknown router\unformat 3002202 ifconfig core dumps when /etc/netmasks ends with blank line On Solaris 2.4, if you inadvertantly end your netmasks file with a blank line, ifconfig will coredump on the next boot you will need to bring your system down to single user mode in order to correct this problem. No patch will be made available for this in 2.4, but the problem has been corrected in 2.5 \unformat 

6.2: RFEs 

1061398 allow subnet specification in /etc/netmasks for OSPF2, RFC 1219 This RFE requests that the Sun routing programs be brought into accordance with RFC 1219, to allow Variable Length Subnet Masks (VLSM) and Classless Inter-Domain Routing (CIDR). VLSM pertains to routing within a network. Without VLSM, all subnets of a network must use the same mask. The mask need not be a conventional "even byte boundary" mask (ie 255.255.0.0 or 255.255.255.0) but the same mask must be used throughout the network. CIDR pertains to routing to other networks. Without CIDR, it is impossible to have routes to a subnet of another network. You can have a route to another network. But you cannot add a more specific route to a subnet of that other network. Bug/RFE 1061398 is addressed in Solaris 2.6. 

Outstanding routing protocol RFE's: 

Bug Id: 1047216 Synopsis: Would like gated incorporated into next O.S release 

Bug Id: 1168709 Synopsis: Request for support of OSPF (rfc1247) in Solaris 

Bug Id: 4075054 Synopsis: Solaris 2.6 doesn't deliver a routing deamon to support variable length subnet 7.0 References 

7.1: Important Man Pages 

arp in.rdisc (Solaris only) netmasks route routed routing 

7.2: Sunsolve Documents 

There are a number of Sunsolve documents concerning routing, subnetting and netmasks. The ones listed below are simply those which contain some amount of information which is not already in this document. 

7.2.1: Infodocs 

2176   Subnetting definition 

2180   Routing and delivery of datagrams 

7.2.2: SRDBs 

4713   ARP Thrashing in Large Bridged Networks 

5823   booting diskless client fails with ARP/RARP timeout 

5986   Subnetting 

7.3: Sun Educational Services 

[pending] 

7.4: Solaris Documentation

  [pending] 

7.5: Third Party Documentation _

TCP/IP Illustrated, Volume 1_, by W. Richard Stevens, published by Addison-Wesley Publishing Company, ISBN 0-201-63345-9 An excellent text explaining how the various TCP/IP protocols work. The chapters on arp, ping, traceroute, IP routing, dynamic routing, broadcasting and multicasting are all very useful in gaining an understanding of the way that the routing protocols work. _Internetworking With TCP/IP Volume 1_, by Douglas Comer Another book with good information on networking. 

7.6: RFCs  

RFC's are the internet-written documents that define the specifications of many common networking programs. They can be retrieved from nic.ddn.mil, in the /rfc directory. A very large number of RFCs describe routing over the internet. Included below are just some of the RFCs which most directly cover the topics described in this document. 917 Internet subnets Original specs for subnets and netmasks. 950 Internet Standard Subnetting Procedure Additional notes on subnetting. 1219 On the Assignment of Subnet Numbers Suggestions for additions to the subnet specs, which have not yet been incorporated by Sun. 1256 ICMP router discovery messages Specs for the Router discovery protocol, as implemented in in.rdisc. 

8.0: Supportability 

Sun is not responsible for the initial configuration of your network routing. In addition, we can not help resolve routing problems caused by your routers, bridges or other machines. SunService can help resolve problems where your Sun is not sending packets correctly to its next-hop router, or where one of your Sun's routing daemons is not responding correctly, but in such cases, the contact must be a system administrator who has a good understanding of the network layout, and its routing design. 

9.0: Additional Support 

For overall routing configuration, please contact your local SunService office for possible consulting offerings. Sun's Customer Relations organization can put you in touch with your local Sun Integration or Sales office.