Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

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: 

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.

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.

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:


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

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

Google matched content

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Internal links

External links

Reference

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.

Syntax

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

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.

route executes its commands on routes to destinations.

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 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:

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.

Files

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



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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 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 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


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

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 to buy a cup of coffee for authors of this site

Disclaimer:

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