man pages section 1M: System Administration Commands

in.routed(1M)

NAME

in.routed, routed- Network routing daemon

SYNOPSIS

/usr/sbin/in.routed

-s

-q

-t

-g

-S

-v

logfile

DESCRIPTION

in.routed is invoked at boot time to manage the network routing tables. The routing daemon uses a variant of the Xerox NS Routing Information Protocol in maintaining up-to-date kernel routing table entries.

In normal operation, in.routed listens on udp(7P) socket 520 (decimal) for routing information packets. If the host is an internetwork router, it periodically supplies copies of its routing tables to any directly connected hosts and networks.

When in.routed is started, it uses the SIOCGIFCONF ioctl(2) to find those directly connected interfaces configured into the system and marked "up" (the software loopback interface is ignored). If multiple interfaces are present, it is assumed the host will forward packets between networks. in.routed then transmits a request packet on each interface (using a broadcast packet if the interface supports it) and enters a loop, listening for request and response packets from other hosts.

For trusted routing, extended security attributes must be associated with a route along with the simple metric that indicates the number of hops to the destination. The additional security routing information ( SRI ) includes a sensitivity label range, and can include a CIPSO domain of interpretation, a RIPSO label, and a RIPSO error, and some additional keywords: ripso_only , cipso_only , and msix_only . The SRI combined with the simple metric is called the extended metric, or emetric.

For Trusted Solaris 7 and later systems, two additional types of packets are exchanged. The first one is sec_response , which is like the response packet but also carries the SRI for the routes. Similar to the response packet, the sec_response packet propagates a route while adjusting its metric and SRI one hop at a time. The SRI that is carried in sec_response packets cannot be propagated through non-Trusted Solaris gateways.

The second additional packet type is sec_t_response , which has the exact format as sec_response but with a different command number. The sec_t_response packets are used for tunneling. Every time a response is sent, a sec_response and a sec_t_response packet are also sent.

Tunneling can be set up for trusted routing between Trusted Solaris 7 and later gateways when non-Trusted Solaris gateways exist between the Trusted Solaris 7 and later gateways. For tunneling to work, all Trusted Solaris gateways must be running Trusted Solaris 2.5.1 or 7 or 8, and they must be using the extended in.routed(1M) for dynamic routing. Also, the non-Trusted Solaris gateways must be using the standard in.routed(1M) for dynamic routing. All gateways must be in the same Intranet. To forward SRI s through non-Trusted Solaris gateways to a target (sub)network, a Trusted Solaris system sends an unlabeled sec_t_response packet in a (sub)network directed broadcast to the target (sub)network on behalf of the non-Trusted Solaris gateway connected to that (sub)network. Trusted Solaris systems on the (sub)network can use the SRI to configure their routing tables correctly, and Trusted Solaris 7 gateways on that (sub)network can propagate the SRI to other (sub)networks. A machine that does tunneling is called the forwarding machine; any Trusted Solaris gateway can be a forwarding machine.

Tunneling is enabled by the existence of the file /etc/security/tsol/tunnel , and the target (sub)network addresses are obtained from this file. A Trusted Solaris gateway can be responsible for tunneling to more than one (sub)network. The file is composed of a series of lines, each in the following format:

broadcast_addr

A Trusted Solaris gateway can be responsible for tunneling to more than one (sub)network.

A Trusted Solaris system ignores a response packet if it is sent by another Trusted Solaris gateway, because in this case, sec_response packets should be used in place of response packets. A Trusted Solaris system processes a response packet if it is sent by a non-Trusted Solaris gateway. If tunneling is done on behalf of that non-Trusted Solaris gateway, it will process both the response packets sent by the non-Trusted Solaris gateway and the sec_response packets sent by a remote Trusted Solaris gateway on behalf of the non-Trusted Solaris gateway.

When a request packet is received, in.routed formulates a reply based on the information maintained in its internal tables. The response packet contains a list of known routes, each marked with a "hop count" metric (a count of 16, or greater, is considered "infinite"). The metric associated with each route returned, provides a metric relative to the sender.

sec_response and sec_t_response packets are formulated by AND ing the emetric of the route with the emetric derived from the outgoing interface. Before the response packet is sent, a sec_response and a sec_t_response packet are sent to the same destination with the same metric and additional SRI .

response , sec_response , and request packets received by in.routed are used to update the routing tables if one of the following conditions is satisfied:

No routing table entry exists for the destination network or host, and the metric indicates the destination is "reachable" (that is, the hop count is not infinite). For sec_response and sec-t_response packets, a destination is also unreachable if its SRI restricts all possible packets.
The source host of the packet is the same as the router in the existing routing table entry. That is, updated information is being received from the very internetwork router through which packets for the destination are being routed. The only exception occurs when in.routed is supposed to process both the response packet from a non-Trusted Solaris gateway and the sec_response packet tunneled on behalf of that non-Trusted Solaris gateway. In this situation, if both packets carry routing information for the same route, the SRI from the tunneled sec_response packet and the metric from the response packet are used.
The existing entry in the routing table has not been updated for some time (defined to be 90 seconds) and the route is at least as cost effective as the current route.
The new route describes a shorter route to the destination than the one currently stored in the routing tables; the metric of the new route is compared against the one stored in the table to decide this.

For sec_response and sec_t_response packets, the last rule above is changed to compare the SRI s as well as the metrics. One route is better than another if (a) its metric is smaller; and (b) its SRI is more relaxed than or equal to that of the other. Note that when comparing the SRI s of two routes, one route cannot always serve as a substitute for the other. For example, if the SRI s of two routes have different sensitivity labels, one SRI cannot be said to be more restrictive, because they restrict different sensitivity label ranges.

If two routes cannot be compared, both routes are kept in the routing table, because they represent two routes to the same destination although with different security characteristics; and both routes are needed.

When an update is applied, in.routed records the change in its internal tables and generates a sec_response packet and a response packet to all directly connected hosts and networks. in.routed waits a short period of time (no more than 30 seconds) before modifying the kernel's routing tables to allow possible unstable situations to settle.

In addition to processing incoming packets, in.routed also periodically checks the routing table entries. If an entry has not been updated for 3 minutes, the entry's metric is set to infinity and marked for deletion. Deletions are delayed an additional 60 seconds to insure the invalidation is propagated throughout the internet.

Hosts acting as internetwork routers gratuitously supply their routing tables every 30 seconds to all directly connected hosts and networks.

In addition to the facilities described above, in.routed supports the notion of "distant" passive and active gateways. When in.routed is started up, it reads the file gateways to find gateways which may not be identified using the SIOCGIFCONF ioctl . Gateways specified in this manner should be marked passive if they are not expected to exchange routing information, while gateways marked active should be willing to exchange routing information (that is, they should have a in.routed process running on the machine). 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. Routing information is distributed to the gateway and if no routing information is received for a period of time, the associated route is deleted.

The gateways is comprised of a series of lines, each in the following format:

 
< net | host> filename1 gateway filename2 metric value < passive | active >

The net or host keyword indicates if the route is to a network or specific host.

filename1 is the name of the destination network or host. This may be a symbolic name located in networks or hosts , or an Internet address specified in "dot" notation; see inet(3SOCKET) .

filename2 is the name or address of the gateway to which messages should be forwarded.

value is a metric indicating the hop count to the destination host or network.

The keyword passive or active indicates if the gateway should be treated as passive or active (as described above).

For both the passive and active gateway, the SRI s of their routes are obtained initially from their remote host template. For an active gateway, further routing information will be exchanged with this machine. If later a sec_response packet is received from the active gateway or a sec_t_response tunneled on its behalf is received, the initial SRI will be updated. If no sec_response packet is ever received for this active gateway, use of the initial SRI is continued. For a passive gateway, no further routing information will be exchanged; therefore, the initial SRI is continuously used.

in.routed must be started from the Trusted path at ADMIN_HIGH . It must inherit the net_mac_read , net_privaddr , net_broadcast , and sys_net_config privileges. If a log file is specified, in.routed must also inherit the file_mac_write privilege.

OPTIONS

-g: Is used on internetwork routers to offer a route to the ``default'' destination. This is typically used on a gateway to the Internet, or on a gateway that uses another routing protocol whose routes are not reported to other local routers.
-q: Is the opposite of the -s option.
-s: Forces in.routed to supply routing information whether it is acting as an internetwork router or not.
-S: If in.routed is not acting as an internetwork router it will, instead of entering the whole routing table in the kernel, only enter a default route for each internetwork router. This reduces the the memory requirements without losing any routing reliability.
-t: All packets sent or received are printed on standard output. In addition, in.routed will not divorce itself from the controlling terminal so that interrupts from the keyboard will kill the process. Any other argument supplied is interpreted as the name of the file in which in.routed 's actions should be logged. This log contains information about any changes to the routing tables and a history of recent messages sent and received which are related to the changed route.
-v: Allows a logfile (whose name must be supplied) to be created showing the changes made to the routing tables with a timestamp.

FILES

/etc/gateways: For distant gateways
/etc/networks: Associations of Internet Protocol network numbers with network names
/etc/hosts: Internet host table
/etc/security/tsolgateways: For trusted routing through listed gateways
/etc/security/tsol/tunnel: Tunneling information table for Trusted Solaris hosts

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

SUMMARY OF TRUSTED SOLARIS CHANGES

in.routed should be started at ADMIN_HIGH . It must inherit the net_mac_read , net_privaddr , net_broadcast , and sys_net_config privileges. If a log file is specified, in.routed must also inherit the file_mac_write privilege. Because trusted routing considers the security of the route along with the route's metric when making routing decisions, in.routed sends two additional types of response packets containing security information for routes: sec_response packets for communications with connected Trusted Solaris gateways, and sec_t_response packets for tunneling to Trusted Solaris gateways on the other side of non-Trusted Solaris gateways.

Trusted Solaris 8 Reference Manual

route(1M)

SunOS 5.8 Reference Manual

ioctl(2) , inet(3SOCKET) , attributes(5) , inet(7P) , udp(7P)

NOTES

The kernel's routing tables may not correspond to those of in.routed for short periods of time while processes that utilize existing routes exit; the only remedy for this is to place the routing process in the kernel.

in.routed should listen to intelligent interfaces, such as an IMP , and to error protocols, such as ICMP , to gather more information.

in.routed initially obtains a routing table by examining the interfaces configured on a machine and the gateways file. It then sends a request on all directly connected networks for more routing information. in.routed does not recognize or use any routing information already established on the machine prior to startup. With the exception of interface changes, in.routed does not see any routing table changes that have been done by other programs on the machine, for example, routes added, deleted or flushed by way of the route(1M) command. Therefore, these types of changes should not be done while in.routed is running. Rather, shut down in.routed , make the changes required, and then restart in.routed .

Trusted Solaris 8 Last Revised 30 Sep 1999