ifup, ifdown and why you should not use them

ifup - bring a network interface up
ifdown - take a network interface down

These commands were invented by some Linux distribution
(I don't really know which one) to configure network interfaces.

These commands can be typically found in startup scripts,
and also you may run them manually.

Their use in startup scripts presents problems, however.
There is no way of knowing how long ifup -a (up all interfaces)
will take to complete.

Surely, if you have just one, static IP, it will finish right away.
But not everyone has static addresses. Some people have
DHCP configured addresses, and ifup may wait until this address
is obtained. If your DHCP server box just gave the ghost,
this won't happen anytime soon.

There are many more scenarios when you cannot know how long
will it take to bring an interface up, and will it succeed
at all, ever. There are pppd interfaces which don't even exist
until pppd succeeds in contacting remote peer.
There are various VPN solutions (I used openvpn in the past)
which exhibit the same behavior.

Worse, if ifup configures ppp0 first and eth0 second, for example,
by the time ifup finished configuring eth0 using e.g. DHCP,
your ppp0 configuration may already be stale, because phone
connection snapped and needs restarting. And new IP address
on ppp0 may be different. And ifup has no way of knowing that!

The truth is, changes to network topology are *asynchronous*
in general case. ppp interfaces come and go, as do VPN.
Wireless network connections are also volatile.
Heck, even good old wired ethernet can go off and on -
you only need to go and play with your cable a bit.

Unless you have a single-homed machine with all storage
on NFS, you probably don't want to wait indefinitely
just because ifup -a tries to up eth0 and DHCP server is dead.


    But wait, how am I supposed to configure my network, then?

Treat appearance and disappearance of network interfaces
and links as asynchronous events. Whenever an interface
or link goes up or down, reconfigure network-related settings.

Since in general case these setting are quite complex and
interconnected, the solution which worked best for me was
a centralized script which can be simply told: "Hello!
You know, something is changed with network, please
look at it and configure it all again".

This script is rerun (typically without user interaction)
whenever there is a change in network topology.

I'll leave implementation details of this script for
admin or distribution manager, but broadly, the idea is
that script will analyze current state. This state may be
in static config files (for static IPs) or supplied by
respective daemons (pppd, dhcp, openvpn all have mechanisms
to save this data). Then the script configures the following:

* Logical link status (ip l set dev XXX up/down)
* IP addresses. Say, you may blindly assign static address
  to wired eth0, or use pppd-supplied IP (and DNS, etc)
  for ppp0, etc.
* /etc/resolv.conf (DNS from ppp0 is a prime example)
* Routing. "Aha, eth0 is down, but ppp0 is up! Route
  traffic thru ppp0!"
* Firewall configuration.
* Traffic shaping.

Note that in this scheme script does not wait for anything.
It is run when topology change has *already happened* and
all needed data is available. So it has a bounded
(short) execution time.

So instead of running ifup -a at startup, you just arrange
for this script to be run somewhere in startup sequence.
Instead of running ifup ppp0, just run pppd and let it do
its magic. When (and if) it will succeed, the script
will be run. With proper setup for kernel->userspace
notifications of link loss, or by running a process which
monitors link status, you can even arrange your computer
to properly react to plugging/unplugging of your wired
network.

One important detail is that you should avoid having
this script run twice in parallel. If ppp0 comes up,
you start script, and then ppp1 comes up, you should
either wait till it finishes, and then rerun it again
(because configuration is now stale), or just kill it,
and rerun. Running script second time while previous run
is not finished will likely lead to misconfiguration.

The mechanisms to ensure race-free execution are not
so hard, but out of the scope of this short memo.

Send comments, questions, explanations that I am
completely wrong to vda.linux@googlemail.com
--
vda