May the source be with you,
but remember the KISS principle ;-)
Key Softpanorama Topics
|About||Contents||Top Updates||Top Visited|
|Bulletin||Selected Papers||Softpanorama Bookshelf||History|
|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:
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.
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.
- 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.
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:
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 ?
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 184.108.40.206 via 220.127.116.11 ?
A: route add net 18.104.22.168 22.214.171.124
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 126.96.36.199 via 188.8.131.52 ?
A: route delete net 184.108.40.206 220.127.116.11
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:
|Bulletin||Latest||Past week||Past month||
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!
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]
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:
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 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
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 : C++ Humor : ARE YOU A BBS ADDICT? : Object oriented programmers of all nations : C Humor : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : 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 : The Most Comprehensive Collection of Editor-related Humor : Microsoft plans to buy Catholic Church : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor : Best Russian Programmer Humor : Russian Musical Humor : The Perl Purity Test : Politically Incorrect Humor : GPL-related Humor : OFM Humor : IDS Humor : Real Programmers Humor : Scripting Humor : Web Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor :
The Last but not Least
|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: softpanorama.info (the fastest) and softpanorama.net.|
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: July 07, 2013