When redhat said that it was now using /sbin/ip for doing the
network configuration, I was suprised that ifup-routes was not using
it too.
For some time now I have been using some modest changes to one of
the default redhat network configuration scripts that have been
working wonderfully well for me (since at least redhat 6.2)...
========8<------- cut ---------------------
--- /etc/sysconfig/network-scripts/fup-routes.orig Thu Feb 7 13:17:41 2002
+++ /etc/sysconfig/network-scripts/fup-routes Thu Jun 13 08:22:22 2002
@@ -19,8 +19,8 @@
#note the trailing space in the grep gets rid of aliases
grep "^$DEVICE[[:space:]]" /etc/sysconfig/static-routes | while read device args; do
- /sbin/route add -$args $device
+ /sbin/ip route replace $args
done
grep "^any[[:space:]]" /etc/sysconfig/static-routes | while read ignore args ; do
- /sbin/route add -$args
+ /sbin/ip route replace $args
done
========8<------- cut ---------------------
This simple change to use /sbin/ip to set static routes enables the
permanent configuration of much more powerful and complex routing
states.
For those that are not aware... since the 2.0.x kernels, /sbin/ip
is the new network configuration tool for linux, making
/sbin/ifconfig and /sbin/route quite trivial and obselete. It
comes with the iproute2 package (along with /sbin/tc), read all
about it in /usr/share/doc/iproute-*/* and the linux
advanced-routing howto. Very cool stuff.
The big implication with this change is that the format of
/etc/sysconfig/static-routes must also change - basically, it
requires a format where a line begins with "any " or "eth0 " (or
whatever, as usual), followed by what is needed to add to the begins
with "ip route replace ..." command to enable it. (Oops, the redhat
network configuration tools would also need some changes:)
Below here I give two examples where I am currently using this to
great effect. It works very well, never any problem (in fact, it
has solved them). At last it is possible to configure and use
things like multiple routing tables, source routing, multiple
default routes, route accounting ("labeled" routes and
/usr/sbin/rtacct), and so on.
One BIG potential advantage of changing the format of the
static-routes file for parsing to /sbin/ip is that the file can
be *dynamically* (re)created from a currently running routing
configuration... simply glob the output of "ip -o route show
table all", clean it up and filter out what isn't necessary (eg,
the "proto kernel" routes), add the initial "ifname ", and there
you have it... "service iproute save" (or "service static-routes
save", whatever).
A "ip route flush table cache" command would also be in good
order after setting or re-setting the routing table (and perhaps
also when interfaces come up and down).
Another thing that needs to be looked at to help complete the
ability to fully configure and preserve routing state, is ip policy
(a-la the "ip policy" command).
This could be done in a way very similar to ifup-routes (called
from ifup-post), static-routes (eg /etc/sysconfig/ip-policy), and
"service ip-policy save|load|stop". I've done this already... I
have some really good shell scripts and shell functions that
manipulate the output of "ip policy" to save, load and otherwise
manipulate routing policy states (which isn't always easy to do).
If there is interest, I'll be happy to dig these up and post them
here.
Also, IMHO /etc/sysconfig/static-routes is definitely the best place
to configure the static route (rather than in ifcfg-*, except where
this is inappropriate, eg, on dynamic ppp interfaces).
And while I am here... I use ip tunnels a lot. Unfortunately,
hotplug does not recognise tunl? devices as ones that it should
ignore... it can cause some grief. Can a tweak be made to
/etc/hotplug/blacklist to include "tunl" devices? Thanks. (I have
some /etc/sysconfig/network-script/*tunl? scripts to set them up for
me).
I am presenting my ideas in this forum so that these (simple!)
changes can be seriously considered for the next redhat release.
And I'm sure that others would like to know about these neat tricks
too :-)
(Yeah, not really bugs but I should probably bugzilla some of
this...)
Cheers
Tony
---*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=---
Tony Nugent <Tony@linuxworks.com.au>
LinuxWorks - Gold Coast Qld Australia
Two examples using /sbin/ip in ifup-routes
==========================================
First example is doing source-routing.
I have a server/router box with an isdn card in it. The isdn
interface is the default internet gateway via an ISP, while the
network itself owns 32 public ip addresses that are routed to it via
the isdn link. There is a mail and web server on one of their IP
address, this IP (in the DNS) also belongs to the same box.
With the default route of the box via the isdn interface, it has an
ISP-assigned (and owned) IP address. The mail server's IP address
is on another ethernet interface on that box... there is another
that connects it to a LAN behind it (masquerading).
A crude picture...
+---------------+
LAN===192.168.12.0/24-------+ eth0 |
(windows clients) | linux |
| (rh7.3) |
===203.100.4.32/27-------+ eth1 |
(currently no clients) | (server, |
| firewall) |
ISDN==139.130.62.0/24-------+ ippp0 |
(default route) | |
+---------------+
( ** all IPs are fictious!! ** )
The problem is that I want the box to talk to the internet with a
source IP of the address on the other (ethernet) interfaces
(203.100.4.34), rather than its "natural" one of 139.130.62.191.
(The LAN is composed of windows boxes, their traffic is NAT'ed).
Easy to do....
ip route replace default via 139.130.62.1 dev ippp0 src 203.100.4.34
It works nicely. It effectively forces the server to send packets
out of the isdn interface with a source address that belongs on the
eth1 interface (which currently has nothing hanging off it, although
another web server may soon be there). I can now totally firewall
the IP address on the ISDN device (which is only there for the local
link) for all incoming packets (except icmp etc), and not risk
making its public network services problematic.
With the change to ipfup-route, /etc/sysconfig/static-routes now has
something like this in it...
ippp0 default via 139.130.62.1 dev ippp0 src 203.100.4.34
It works like a charm to preserve the routing state through reboots.
The second example is on box that has two ethernet cards that are
connected to the same router (via two interfaces on that box).
This diagram essentially shows this (somewhat simplified)...
+----------+ +-----------+
| router +--- hub1, network1 ----+ dual-homed|
internet ----+ | | server |
| +----hub2, network2 ----+ |
+----------+ +-----------+
So there is a multiple default route, which can be created with the
following command...
ip route replace default \
nexthop via 203.222.1.1 dev eth1 \
nexthop via 203.222.2.1 dev eth2
This is what I have in the static-routes file to do this...
eth0 default via 203.222.1.1 dev eth0
eth1 default via 203.222.2.1 dev eth1
any default nexthop via 203.222.1.1 dev eth0 nexthop via 203.222.2.1 dev eth1
Note that if one of the interfaces fails to come up, a default route
will still exist. For example, at bootup eth0 comes up with a
default route and the "any" route will fail because eth1 is not up
yet. When eth1 comes up, the default route is first changed to that
interface, then the "any" route will successed after that (but only
if eth0 is up) to add the multiple default route.
This sort of (re)configuration has been a blessing on several occasions.
[end]
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
