|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|News||Routing||Recommended Links||Static Routing||Typical Operations||Making routing entries permanent|
|ip command||Linux ifconfig||netstat||Static Routing||Default Route||Suse static routes table|
|Policy Routing||Suse network configuration||Redhat Network Configuration||Traceroute||tcpdump||RIP Daemon|
|martian source||nmap||Horror Stories||Unix History||Humor||Etc|
Like in other Unixes, route is an entry in routing table specifying the target where Linux kernel sends IP packet based on it the destination address. Linux inherited set of classic Unix utilities such as route, netstat, ifconfig from GNU project and like other utilities from this project they have idiosyncrasies and extensions in comparison with POSIX utilities of the same name. For example, one difference between route command in Solaris and route in Linux is that you need keyword gw before specifying the gateway. Other then that two version are pretty compatible.
For basic info see Route command. Here we will discuss mainly Linux-specific issues.
Most Linux distributions support two types of routing:
... ... ...
B. Check for kernel compatibility (I think this is irrelevant. Also SLES 11 has different options. In both cases all the necessary options are enabled in stock kernel --NNB):
i. cd /usr/src/linux
ii. make menuconfig
iii. Follow: Networking -> Networking Options -> And make sure the following are selected:
- TCP/IP Networking
- IP: advanced router
- IP: Policy Routing
- IP: use netfilter MARK value as routing key
- IP: Choose IP: FIB lookup algorithm (FIB_HASH)
2. Create a new policy routing table for each interface:echo "1 corporate">> /etc/iproute2/rt_tables3. Provide IP info / gateway to the new corporate table.ip route add 192.168.0.0/24 dev eth0 src 192.168.0.99 table corporate ip route add default via 192.168.0.1 dev eth0 table corporate
4. Create IP rules to handle inbound / outbound traffic on this network.ip rule add from 192.168.0.99/32 table corporate ip rule add to 192.168.0.99/32 table corporate
netstat -r # with DNS names
netstat -rn # with IP addresses
route add -net 10.10.10.0/24 gw 192.168.0.1 route del -net 10.10.10.0/24 gw 192.168.0.1
route add -host 10.10.10.45 gw 192.168.0.1 route del -host 10.10.10.45 gw 192.168.0.1
You can also specify netmask and interface
route del -net 10.1.0.0 netmask 255.255.0.0 gw 10.2.0.1 eth0 route del -host 10.10.0.5 netmask 255.255.0.0 gw 10.2.0.1 eth0
route add default gw 192.168.0.1 route del default gw 192.168.0.1
You can also specify it in /etc/sysconfig/network
NETWORKING=yes NETWORKING_IPV6=no HOSTNAME=box17 GATEWAY=10.194.176.1
ip route flush
- You can also use ip command to manipulate routes in Linux.
- Routes added using route command exists until reboot. For Solaris you can add them permanently using option -p of the route command. In this case these routes are stored in /etc/inet/static_routes. Linux has no such capability.
In Solaris and other Unixes to make routing entry permanent you need to use -p option of the route command. That's it. Linux guys decided to reinvent the bicycle and that shows.
In Suse to make routing entries permanent you need to put them into a special table of static routes that will be read on boot. It is stored in /etc/sysconfig/network/route file. The file has the format of output of the route -rn command, so it's a pretty elegant approach. But only if you know about it ;-). See Suse static routes table for more details.
In Red Hat, Fedora, Centos, and Oracle Linux this issue is an over-engineered mess. There is no system wide table to store static route information. It is stored on interface basis. For each interface you need to define and maintain /etc/sysconfig/network-scripts/route-eth<number> (or other network interface) file. Such interface config file exists for each valid network interface card. For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file.
There are two formats acceptable in this file
We will start with the new format as it causes less allergy. It is available since Red Hat 8, I think. In this case the route-interface file has two types of directives: one for default router and the other for network/netmask directives. Here is an example from Centos deployment guide:
The following is a sample route-eth0 file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:There is also older, pretty stupid format that for compatibility is still accepted. You should never use it, but it might be useful to be aware about its existence:default 192.168.0.1 dev eth0 10.10.10.0/24 via 192.168.0.1 dev eth0 172.16.1.0/24 via 192.168.0.1 dev eth0
You can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards:ADDRESS0=X.X.X.X NETMASK0=X.X.X.X GATEWAY0=X.X.X.XWhere:
- ADDRESS0=X.X.X.X is the network number for the static route.
- NETMASK0=X.X.X.X is the netmask for the network number defined with ADDRESS0=X.X.X.X.
- GATEWAY0=X.X.X.X is the default gateway, or an IP address that can be used to reach ADDRESS0=X.X.X.X
The following is a sample route-eth0 file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.0.1 ADDRESS1=172.16.1.0 NETMASK1=255.255.255.0 GATEWAY1=192.168.0.1
Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0, ADDRESS1, ADDRESS2, and so on. --[That make deletion a labor intensive operation --NNB;-)]
Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=10.10.10.1
What's really funny is that this horrible way of specifying static routes was essentially a change from Suse-style that was used in Red Hat 7 (after all Suse is a Red Hat derivative). Yes, Red Hat 7 used to have a "normal" way to define static routes using /etc/sysconfig/static-routes table (Static Routes in Red Hat 8.0):
As of Red Hat 8.0, Red Hat has changed the way in which non-default static routes are initialized and added to the routing table on startup. Since this process is not documented, I've made a few notes here.
Traditionally, static routes were added in /etc/sysconfig/static-routes, in the form:iface type dest-addr netmask netmask gw gateway-addr ...
such as this example, taken from a real system:eth0 net 192.168.170.0 netmask 255.255.255.0 gw 192.168.168.1
This would cause the startup scripts to execute a command like thisroute add -type dest-addr netmask netmask gw gateway-addr ... iface
Notice the ellipsis at the end of the line there - this means that other options for the route add command can be specified in static-routes, which is particularly useful for specifying metrics - something that is quite common in moderately complex intranets. Other options, such as maximum segment size, initial window size and initial round-trip time, may also be useful.
In Red Hat 8.0, attempts to add interface-specific routes in static-routes will fail. Instead, static routes must be specified as multiple variables in multiple files in /etc/sysconfig/networking/devices. For example, a static route for the eth0 device must be specified in a file called eth0.route, like this:
No other variables are supported, although additional routes can be specified as ADDRESS1, NETMASK1, etc. Clearly, this means that metrics and other parameters cannot be set at this point.
Way to go, Red Hat. More complexity, with less functionality. . . Sigh . . .
Dr Nikolai Bezroukov
With the introduction of Redhat version 8 and continued into version 9, the /etc/sysconfig/static-routes file no longer seems to function correctly.
Linux static routes changed in 8.0 to a new format. Now you are to create a file in /etc/sysconfig/network-scripts for each Ethernet interface you wish to create static routes on.
The syntax for this file is different from the traditional route format used in /etc/sysconfig/static-routes . Redhat has yet to document the change on their web site as of June 2003.
Syntax based on a usenet post go to /etc/sysconfig/network-scripts, make a file called route-devicename (ex: route-eth0) and populate it with your static routes for that device so if you wanted to make a static route to the 192.168.0.0/24 network through 188.8.131.52 type:
192.168.0.0/24 via 184.108.40.206
Persistent static routes for ANY linux distribution
You may use this method to add static routes and it will work under any Linux distribution. However, it is considered by some a 'hack' or the 'ugly way'.
Edit your /etc/rc.local file and add your static routes using the route statement.
route add -net 10.10.98.0 netmask 255.255.255.0 gw 10.164.234.132 dev eth1
route add -net 10.164.234.96 netmask 255.255.255.252 gw 10.164.234.132 dev eth1
route add -net 10.164.234.112 netmask 255.255.255.240 gw 10.164.234.132 dev eth1
Force the old static-routes file to work under Redhat 9
Clear out the new /etc/sysconfig/network-scripts/ifup-routes script so that you can populate it with the original shell script from Redhat 7.x.
cat /dev/null > /etc/sysconfig/network-scripts/ifup-routes
type in the following (or copy and paste) not including the tilde lines:#!/bin/sh # adds static routes which go through device $1 if [ "$1" = "" ]; then echo "usage: $0
" exit 1 fi if [ ! -f /etc/sysconfig/static-routes ]; then exit 0 fi # note the trailing space in the grep gets rid of aliases grep "^$1 " /etc/sysconfig/static-routes | while read device args; do /sbin/route add -$args $device done grep "^any " /etc/sysconfig/static-routes | while read ignore type net netmask mask bogus dev ; do if [ "$dev" = "$1" ]; then /sbin/route add -$type $net $netmask $mask $dev fi done
Remember to use /etc/sysconfig/network for your default gateway
If you only intend to add one route, your default gateway, then you need not worry about the static routes file or using the route command. Simply add your default gateway in /etc/sysconfig/network.
ExampleNETWORKING=yes HOSTNAME="hostname.linux.org" GATEWAY="10.164.234.1" GATEWAYDEV="eth0" FORWARD_IPV4="yes"
Routing will be configured on routing devices, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients. However, if static routes are required they can be configured for each interface. This can be useful if you have multiple interfaces in different subnets. Use the route command to display the IP routing table.
Static route configuration is stored in a /etc/sysconfig/network-scripts/route-interface file. For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file. The route-interface file has two formats: IP command arguments and network/netmask directives.
IP Command Arguments FormatDefine a default gateway on the first line. This is only required if the default gateway is not set via DHCP:default X.X.X.X dev interfaceX.X.X.X is the IP address of the default gateway. The interface is the interface that is connected to, or can reach, the default gateway.
Define a static route. Each line is parsed as an individual route:X.X.X.X/X via X.X.X.X dev interfaceX.X.X.X/X is the network number and netmask for the static route. X.X.X.X and interface are the IP address and interface for the default gateway respectively. The X.X.X.X address does not have to be the default gateway IP address. In most cases, X.X.X.X will be an IP address in a different subnet, and interface will be the interface that is connected to, or can reach, that subnet. Add as many static routes as required.
The following is a sample route-eth0 file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:default 192.168.0.1 dev eth0 10.10.10.0/24 via 192.168.0.1 dev eth0 172.16.1.0/24 via 192.168.0.1 dev eth0Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:10.10.10.0/24 via 10.10.10.1 dev eth1
Duplicate Default GatewaysIf the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X" is a garbage.', where X.X.X.X is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.
Network/Netmask Directives FormatYou can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards:ADDRESS0=X.X.X.X NETMASK0=X.X.X.X GATEWAY0=X.X.X.X
The following is a sample route-eth0 file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:
- ADDRESS0=X.X.X.X is the network number for the static route.
- NETMASK0=X.X.X.X is the netmask for the network number defined with ADDRESS0=X.X.X.X .
- GATEWAY0=X.X.X.X is the default gateway, or an IP address that can be used to reach ADDRESS0=X.X.X.XADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.0.1 ADDRESS1=172.16.1.0 NETMASK1=255.255.255.0 GATEWAY1=192.168.0.1Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0, ADDRESS1, ADDRESS2, and so on.
Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=10.10.10.1DHCP should assign these settings automatically, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients.
I want SuSE to automatically remember some routes I always have to feed it when it restarts. How do I do that?
example:route add -net 220.127.116.11 gw 18.104.22.168 netmask 255.255.255.0 dev eth0In MS DOS I can just "route add -p" for persistant. man route didn't help much (I loathe man pages - the way they are written is overly geeky and 87% of the time I haven't got a clue what they're on about. And they are so DULL to read).
Any help greatly appreciated!
Yast -> Network Devices -> Network card -> Edit -> Routing
You can also edit /etc/sysconfig/network/routes if you prefer the CLI.
Gentoo Linux Wiki
What is a route
A route is a rule used by your kernel to determine how to get someplace on a network. This HOWTO covers IP routes (routes on an IP network) but there are other types of routable networks. Routes are stored in the Linux kernel are accessible for viewing and editing to users.
Viewing your routing table
The easiest way to view your routes is to use the command:/sbin/route -n
The table looks something like this:Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
The Destination is the network address for the routing entry, combined with the genmask (netmask) you can see what network is being routed to the Gateway listed. Please read the man page for route for more information on the meanings of these fields.
Adding a route
To add a route you must first know the network address of the network you wish to add, and the gateway to that network. In our case we are going to use the network 10.0.0.0 with a netmask of 255.255.255.0. We have a firewall on our network with an IP address of 192.168.1.50 that is the gateway to this 10.0.0.0 network.
To add the route manually we use the command:route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.1.50
Our route table now looks like this:Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 192.168.1.50 255.255.255.0 UG 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
As you can see the network 10.0.0.0 with a Genmask of 255.255.255.0 shows up with a gateway of 192.168.1.50. But how do we make sure this happens on boot?
On Mon, 2004-07-12 at 14:24, Ben Adams wrote:
> I have a server that uses the system default gateway for the vast
> majority of its traffic, but needs a different gateway for a handful of
> specific hosts. I want to establish specific routes for these hosts,
> which I would normally do from the command line like so:
> route add -host A.B.C.D gw X.X.X.X
> route add -host E.F.G.H gw X.X.X.X
> . . . etc . . .
> I could just tack these commands onto the end of rc.local (or some other
> such hack), but I know there's got to be something more elegant.
> What's the proper place to list these routes so that they will be
> applied to eth0 at boot?
It's not well documented, but you will see this if you read
Chris Kloiber, RHCT
Global Support Services
Red Hat, Inc.
Google matched content
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 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-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and 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 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: October 03, 2017