|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
|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 220.127.116.11 via 18.104.22.168 ?
A: route add net 22.214.171.124 126.96.36.199
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 188.8.131.52 via 184.108.40.206 ?
A: route delete net 220.127.116.11 18.104.22.168
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:
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!
Google matched content
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
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 in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
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
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
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
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
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
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org 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.
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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 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: September 12, 2017