Linux (both 2.0.x and 2.2.x), ifconfig, and routing tables

Richard Kaszeta (kaszeta@me.umn.edu)
Wed, 22 Sep 1999 17:02:09 -0500 (CDT)


I've discovered some differences between Linux's handling of the
routing table from other Unix and Unix-style OS's, and was wondering
if anyone could shed some light on things. It's not a bug, really,
just a bit of a misfeature.

I have a program I am working on (high availability/failover stuff),
that as part of it's operation does the following steps:

1. Brings down an interface with 'ifconfig interfacename down'.
2. Depending on circumstances, either brings the interface up with an
'ifconfig interfacename up', or changes it's IP address and then
brings it back up with 'ifconfig interfacename up'.

The problem I've run into is that whenever I do an 'ifconfig
interfacename down', the kernel automagically removes all the routing
table entries for that interface. If I bring the interface back up
with 'ifconfig interfacename up', I also have to run a bunch of route
commands to restore the routing table.

So the problem I have is that I need a way to either:

1. Get the kernel to leave the routing table intact when the interface
is brought down, or...
2. Find a way to save all the routing table entries involving the
interface I'm bringing down, and restore them after bringing the
interface back up?

Anyone know how do do either of these?

On every other Unix OS I've worked, an 'ifconfig interfacename down'
followed by an 'ifconfig interfacename up' restores things to their
initial state, and never changes the routing table.

For example, on one of my old SunOS boxes (with addresses remove to
protect the innocent):

# ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet xx.xx.106.62 netmask ffffff00 broadcast xx.xx.106.0
ether 8:0:20:23:1e:df
le1: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet xx.xx.196.1 netmask ffffff00 broadcast xx.xx.196.0
ether 8:0:20:23:1e:df
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
# netstat -r
Routing tables
Destination Gateway Flags Refcnt Use Interface
localhost localhost UH 17 26712 lo0
default mechex.router.umn.ed UG 16 50998 le1
xx.xx.106.0 meserv-le0 U 3 1501 le0
xx.xx.196.0 meserv U 2 27982 le1
# ifconfig le0 down
# netstat -r
Routing tables
Destination Gateway Flags Refcnt Use Interface
localhost localhost UH 16 26776 lo0
default mechex.router.umn.ed UG 18 51059 le1
xx.xx.106.0 meserv-le0 U 3 1501 le0
xx.xx.196.0 meserv U 2 27983 le1
# ifconfig le0 up
# netstat -r
Routing tables
Destination Gateway Flags Refcnt Use Interface
localhost localhost UH 16 26792 lo0
default mechex.router.umn.ed UG 18 51081 le1
xx.xx.106.0 meserv-le0 U 3 1501 le0
xx.xx.196.0 meserv U 2 27986 le1

So as you can see, the routing table is completely unaffected by the
'ifconfig' commands on the SunOS machine---it leaves the routes for
the deactivated interface intact even if the interface is down.

On linux (with 2.2.x kernel), I get the following:

bofh:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:E0:29:21:5A:54
inet addr:xx.xx.18.23 Bcast:xx.xx.18.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3424 errors:0 dropped:0 overruns:0 frame:0
TX packets:3106 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0xb400

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:34 errors:0 dropped:0 overruns:0 frame:0
TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

bofh:~# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
localnet * 255.255.255.0 U 0 0 0 eth0
default tc8x.router.umn 0.0.0.0 UG 0 0 0 eth0
bofh:~# ifconfig eth0 down
bofh:~# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
bofh:~# ifconfig eth0 up
bofh:~# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
localnet * 255.255.255.0 U 0 0 0 eth0

As you can see, the ifconfig command is removing my route table
entries, and the route table isn't restored by bringing the interface
back up. Thus necessitating that I store the routing table, which on
some of my stranger machines is non-trivial.

Ideas?

-- 
Richard W Kaszeta 			PhD. Candidate and Sysadmin
bofh@me.umn.edu				University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/