May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Solaris route command

News Routing Recommended Books Recommended Links Reference Static Routing Making a routing entry permanent Default Route
netstat Solaris ifconfig Typical Operations Subnetting and CIDR Solaris IP configuration Solaris ifconfig Solaris Snoop Packet Sniffer Network administration
Solaris Networking Suse network configuration Redhat Network Configuration Solaris Networking Tips Horror Stories Unix History Humor Etc

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

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

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: 


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.

Specifying default route with /etc/defaultrouter

As we already discussed there are two types of routing:

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:

Disadvantages of default routing:

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.


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 via ?

 A: route add net

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 via ?

 A: route delete net

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:

Top updates

Bulletin Latest Past week Past month
Google Search


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:


         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 to be accessed via gateway on each boot is this:

/usr/sbin/route -p add

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

Internal links

External links


route manually manipulates the network routing tables. These tables are normally maintained by the system routing daemon, such as in.routed(1M) and in.ripngd(1M). This utility supports a limited number of general options, but a rich command language. It enables the user to specify any arbitrary request that could be delivered by means of the programmatic interface discussed in route(7P). route uses a routing socket and the new message types RTM_ADD, RTM_DELETE, RTM_GET, and RTM_CHANGE.

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]



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]


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.

route executes its commands on routes to 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:

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:

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 somegateway will create an IPv4 route to the destination with a netmask of, 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:

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:

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.


/etc/defaultrouter list of default routers /etc/hosts list of host names and net addresses /etc/networks list of network names and addresses



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


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


Vol 26, No.1 (January, 2013) Object-Oriented Cult : Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks: The efficient markets hypothesis : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Vol 23, No.10 (October, 2011) An observation about corporate security departments : 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.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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

Copyright © 1996-2014 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: (the fastest) and


The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 19, 2014