Solaris route command

Route command manipulates the kernel routing tables. Routing is the process of forwarding a packet from one computer to another. It is based on the IP address in the IP packet header and netmask. But there are one additional  thing  involved -- so called host routing table. Traditional IPv4 routing can be summarized as "All routing decisions are make solely based on the destination of the packet." When a router looks at an IPv4 packet all it cares is the destination address in the header of the packet.  Only this information is used to make a decision on where to forward the packet. Traditional routing rely on a single routing table.  This table is searched each time routing decision should be made (in network speak the route is "looked up") sequentially from top to bottom and the longest match of the packet destination is made. This longest match determines the gateway to which we should forward the packet.

Route command implements so called static routing. We will discuss several topics here:

• Routing table
• Specifying default route with /etc/defaultrouter
• Making a routing entry permanent

Routing table

IP communication on Internet layer is actually is defined by two pretty simple rules:

• If the host tries to connect to a host which is the same network it just sends packet to the destination (direct routing).
• If the target host is on another network than host's own, then it forwards the packet to the router (indirect routing), if any.  It first try to find the suitable router in the routing table. If no router exists, the packet is simply discarded.

All OS that support TCP/IP maintains a special database called a routing table.  It can be populated statically or dynamically, using daemons that implement specific routing protocols. Often, for example for workstations,  only one router is defined. In this case it is called the default gateway and from the host’s point of view it outsources all the processing of "non-local" packets to this gateway. If there is no default gateway and the search of routing table doesn’t find an entry that matches the destination network address, the packet is discarded.

The routing table contains a list of networks that the host knows it can send packets to, and routers to which send the packets. These can be static routes, (entered by a system administrator), they can be default routes (a special static route to send unknown destination IP addresses to), or they can be dynamically discovered routes, found using a routing protocol.

In case of dynamic routing, routers talk to each other and share information about networks they are connected to. That sounds complex and it really is. As any additional complexity layer it also creates possibilities of misunderstanding. At the same time, dynamic routing takes the building of the routing table out of your hands and puts it into the hands of specific routing protocol. All you need to ensure is that  the routers are playing nicely with each other. See Routing for more details.

Route command as a specialized editor for routing table

The route command is essentially a custom editor for the kernel routing table. That means that you need to be root to use the command.  Like any editor it provides operations to insert record, delete record or modify record as well as the ability to view/print the record.

The syntax of the command is different from standard Unix convention where command has a set of option/value pairs. In deviation from this norm the route command contains a small build-in language for editing the routing table. In Solaris we have the following syntax

route [-fn] add | delete | get [net|host|default] [destination] [gateway]

In Linux the syntax is essentially the same but you need to specify keyword gw before the gateway entry, if any.  See Linux route command

With keywords add and delete the default for optional [net|host|default] troika is host. In other words net should be specified explicitly.

The most common command is to add route. Please remember that the result is change in the kernel table and as such it is wiped out by reboot. See below how to make those routes "permanent". Here are some examples that might help to learn the intricacies of the syntax: 

• Add a route:  route add net 128.50.3.0 bigbox ( you do need keyword net here)
  • Use the "route add net" command with the -netmask option to make the route command to take the netmask specified on the command line
    route add net 192.168.68.0 128.50.1.250 1 -netmask 255.255.255.192
• Add a default route: route add default 196.168.0.1
• Delete a route:  route delete net 128.50.3.0
• Display the route for a specified IP address (destination) :  route get 128.50.2.0
• Get routing reports continuously: route monitor
• Flush the routing table: route flush
• Add the multicast path for 224.0.0.0: route add 224.0.0.0 `uname -n` 0

Notes:

Netmask  is used to specify which part of the address is the network number part, and which is the host part. This is accomplished by a logical bitwise-AND between the Netmask and the IP address. The result specifies the network number.

• For hosts netmask is always 255.255.255.255.
• For Class C, the Netmask will always be 255.255.255.0;
• for Class B, the Netmask will always be 255.255.0.0; and so on.

Specifying default route with /etc/defaultrouter

As we already discussed there are two types of routing:

• Direct routing is used if the packet does not need to be forwarded, i.e. both the source and destination addresses have the same network number. In this case the packet is simply sent to destination as specified by the host part of IP address.
• Indirect routing is used when the network numbers of the source and destination do not match. This is the case where the packet must be forwarded by a node that supposedly knows how to reach the destination (a router). The simplest form of indirect routing is default routing. In this case any packet not suitable for direct routing is forwarded to the same router. This type of routing is often used for workstations and in cases where network segment has a single border router (choking point).

A default route is a route table entry that allows a host to define default routers to use if no other specific route is available. The default routers must be reliable. There is no need to define every reachable network. All indirectly connected packet destinations go to the default router.

A default router in Solaris is identified by entries in /etc/defaultrouter.  It contains hostname or IP address entries that correspond to one or more routers. Upon rebooting, existence of this file prevents the startup script (/etc/rc2.d/S69inet) from launching the in.routed and in.rdisc dynamic router processes. Default route table entries may also be added by the in.rdisc daemon.

Advantages of default routing are:

• The /etc/defaultrouter file prevents additional routing daemons from starting.
  
• A default route approach is optimal when only one router is used to reach all indirectly connected destinations.
  
• A single default route entry results in a smaller routing table.
  
• Multiple default routers can be identified, which eliminate single points of failures within a network.
  
• A default route can run other routing protocols on the route.

Disadvantages of default routing:

• If the default router is down, there is no connectivity as the host does not learn about any alternative path that might exist.
  
• ICMP redirects occur if more than one router is available to a host.

Making a routing entry permanent

The result of the execution of route command are valid until other route command that modifies this entry or reboot. So reboot wipes all the static routes you defined using route command. To avoid this in older versions of Solaris you need to modify the startup script to include the necessary route commands in the script. 

Starting from Solaris 10 11/06 (that means from 2006) Sun provided a simpler and more elegant solution of  this important problem via option -p of the route command.

From the route(1M) man page:

-p  -- Make changes to the network route tables persistent across system restarts. The operation is applied to the network routing tables first and, if successful, is then applied to the list of saved routes used at system startup. In determining whether an operation was successful, a failure to add a route that already exists or to delete a route that is not in the routing table is ignored. Particular care should be taken when using host or network names in persistent routes, as network-based name resolution services are not available at the time routes are added at startup.

For solutions to a similar problem in Linux see Linux route command/Making_routing_entries_permanent

Currently, these routes are stored in /etc/inet/static_routes, but Sun doesn't guarantee it will stay there forever.

Quiz

Q1. Which command manipulates the routing table ?

 A: route

 Q2: Command to add a route to server1 via router1:

 A: route add host server1 router1

Q3. Which command will add a route to the network 128.251.0.0 via 128.144.1.254 ?

 A: route add net 128.251.0.0 128.144.1.254

Q4. Which command would delete a route to host server1 via router1 ?

 A: route delete host server1 router1

Q5. Which command will delete the route to the network 128.251.0.0 via 128.144.1.254 ?

 A: route delete net 128.251.0.0 128.144.1.254

Q6. Which command will remove all entries from the routing table ?

 A: route flush

Q7. Which command allows you to monitor the routing requests that are not getting resolved from the routing table ?

 A7: route monitor

Q8. Which script starts the in.named daemon ?

A:  Depend on the Unix version:

• /etc/init.d/inetsvc

NEWS CONTENTS

• 20110218 : Setting Persistent Static Routes on Solaris 10 by Justin Ellison ( 04/20/2009 , SysAdmin's Journey )

Old News ;-)

[Feb 18, 2011] Setting Persistent Static Routes on Solaris 10 by Justin Ellison

04/20/2009 | SysAdmin's Journey

It used to be that in order to add persistent static routes in Solaris, you had to whip up your own init script that manually ran 'route add'. Starting back in Solaris 10 11/06, Sun finally gave us a better way to do it.

From the route(1M) man page:

     -p

         Make changes to  the  network  route  tables  persistent
         across  system restarts. The operation is applied to the
         network routing tables first and, if successful, is then
         applied  to  the  list  of  saved  routes used at system
         startup. In determining whether an  operation  was  suc-
         cessful, a failure to add a route that already exists or
         to delete a route that is not in the  routing  table  is
         ignored. Particular care should be taken when using host
         or network names in persistent routes, as  network-based
         name  resolution  services are not available at the time
         routes are added at startup.

So, all you need to do to add a static route for 192.168.0.0/24 to be accessed via gateway 192.168.1.1 on each boot is this:

/usr/sbin/route -p add 192.168.0.0 192.168.1.1

Currently, these routes are stored in /etc/inet/static_routes, but Sun doesn't guarantee it will stay there.

I'm not sure I like being forced to use a command when I could just edit a config file, but it's a definite improvement!

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Internal links

• Unix Routing
• Subnetting and VLSM

External links

• Routing with Unix How to get your packets from point a to point b by Lance Spitzner
• Internetworking Technology Handbook - Routing Basics - Cisco Systems
• Cisco Router Configuration Tutorial
• Cisco router configuration tutorial

Reference

Only the superuser may modify the routing tables.

route [-fnvq] command [ [modifiers] args] route [-fnvq] add | delete [modifiers] destination gateway [args] route [-fnvq] change | get [modifiers] destination [ gateway [args]] route [-n] monitor [modifiers] route [-n] flush [modifiers]

Options

• -f Flush the routing tables of all gateway entries. If this is used in conjunction with one of the commands described above, route flushes the gateways before performing the command.
• -n Prevent attempts to print host and network names symbolically when reporting actions. This is useful, for example, when all name servers are down on your local net, and you need a route before you can contact the name server.
• -v (Verbose) Print additional details.
• -q Suppress all output.

Commands

route executes one of four commands on a route to a destination. Two additional commands operate globally on all rout- ing information. The six commands are:

1. add Add a route.
2. change Change aspects of a route (such as its gateway).
3. delete Delete a specific route.
4. flush Remove all gateway entries from the routing table.
5. get Lookup and display the route for a destination.
6. monitor Continuously report any changes to the routing infor- mation base, routing lookup misses, or suspected network partitionings.

The add, delete, and change commands have the following syntax:

route [ -fnvq ] add | delete [ -net | -host ] destination gateway [args]

or

route [ -fnvq ] change | get [ -net | -host ] destination gateway [args]

where destination is the destination host or network, and gateway is the next-hop intermediary through which packets should be routed.

Destinations

By default, a destination is looked up under the AF_INET address family or as an IPv4 address. All symbolic names specified for a destination or gateway are looked up first as a host name, using getipnodebyname(3SOCKET). If this lookup fails in the AF_INET case, getnetbyname(3SOCKET) is used to interpret the name as that of a network.

An optional modifier may be included on the command line before a destination, to force how route interprets a destination:

• -host Forces the destination to be interpreted as a host.
• -net Forces the destination to be interpreted as a network.
• -inet Forces the destination to be interpreted under the AF_INET address family or as an IPv4 address.
• -inet6 Forces the destination to be interpreted under the AF_INET6 address family or as an IPv6 address.

In the case of the AF_INET address family or an IPv4 address, routes to a particular host may be distinguished from those to a network by interpreting the Internet address specified as the destination. If the destination has a "local address part" of INADDR_ANY, or if the destination is the symbolic name of a network, then the route is assumed to be to a network; otherwise, it is presumed to be a route to a host.

If the destination is directly reachable by way of an interface requiring no intermediary system to act as a gateway, this can be indicated by including one of two optional modifiers after the destination:

• The -interface modifier
• a metric of 0 can be specified.

These modifiers are illustrated in the following alternative examples: example% route add default hostname -interface example% route add default hostname 0 hostname is the name or IP address associated with the net- work interface all packets should be sent over.

On a host with a single network interface, hostname is normally the same as the nodename returned by uname -n (see uname(1)).

In the above examples, the route does not refer to a gate- way, but rather to one of the machine's interfaces.

Destinations matching such a route are sent out on the interface identified by the gateway address. For interfaces using the ARP protocol, this type of route is used to specify all des- tinations are local. That is, a host should ARP for all addresses by adding a default route using one of the two commands listed above. With the AF_INET address family or an IPv4 address, the optional -netmask qualifier is intended to manually add sub- net routes with netmasks different from that of the implied network interface. The implicit network mask generated in the AF_INET case can be overridden by making sure this option, and an ensuing address parameter (to be interpreted as a network mask), follows the destination parameter. Alternatively, the length of the netmask may be supplied by appending a slash character and the length immediately after the destination. For example: example% route add 192.0.2.32/27 somegateway will create an IPv4 route to the destination 192.0.2.32 with a netmask of 255.255.255.224, and example% route add -inet6 3ffe::/16 somegateway will create an IPv6 route to the destination 33fe:: with a netmask of 16 one-bits followed by 112 zero-bits.

Routing Flags Routes have associated flags which influence operation of the protocols when sending to destinations matched by the routes. These flags may be set (or sometimes cleared) by including the following corresponding modifiers on the com- mand line:

• -cloning RTF_CLONING generates a new route on use -xresolve RTF_XRESOLVE emit mesg on use (for external lookup)
• -iface ~RTF_GATEWAY destination is directly reachable
• -static RTF_STATIC manually added route
• -nostatic ~RTF_STATIC pretend route added by kernel or daemon
• -reject RTF_REJECT emit an ICMP unreachable when matched
• -blackhole RTF_BLACKHOLE silently discard pkts (during updates)
• -proto1 RTF_PROTO1 set protocol specific routing flag #1
• -proto2 RTF_PROTO2 set protocol specific routing flag #2 -private RTF_PRIVATE do not adveritse this route

The optional modifiers -rtt, -rttvar, -sendpipe, -recvpipe, -mtu, -hopcount, -expire, and -ssthresh provide initial values to quantities maintained in the routing entry by transport level protocols, such as TCP. These may be indivi- dually locked either by preceding each modifier to be locked by the -lock meta-modifier, or by specifying that all ensuing metrics may be locked by the -lockrest meta- modifier.

The optional modifiers are defined as follows:

• -expire Lifetime for the entry. This optional modifier is not currently supported.
• -hopcount Maximum hop count. This optional modifier is not currently supported.
• -mtu Maximum MTU in bytes.
• -recvpipe Receive pipe size in bytes.
• -rtt Round trip time in microseconds.
• -rttvar Round trip time variance in microseconds.
• -sendpipe Send pipe size in bytes.
• -ssthresh Send pipe size threshold in bytes.

Some transport layer protocols may support only some of these metrics. In a change or add command where the destination and gateway are not sufficient to specify the route (for example, , when several interfaces have the same address), the -ifp or -ifa modifiers may be used to determine the interface or inter- face address.

Files

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July 28, 2019