Static Routes

Setting a default static route is so easy you’ll invite your mom and dad to watch. This sets a default route from a workstation to the local Internet gateway:

# ip route add default via

Deleting a default route is just as easy:

# ip route del default

Deleting a route is a more routine task than some of you hardbitten old network admins may realize. DSL users have long been accustomed to having a dialup modem as a backup when (not if) the DSL went down. The default route leftover from the DSL interface must be deleted to get a connection with the modem. If you don’t, the modem will connect, but no bits will flow over the wire, so the user is left sitting there sad, mystified, and possibly cursing.

On workstations there is usually a default route that is either assigned statically in /etc/network/interfaces on Debian, /etc/sysconfig/network-scripts/ifcfg-ethX on Red Hat and Fedora, or via DHCP.

You may change an existing route, instead of deleting it then adding a new one:

# ip route chg default via

Setting up NAT (network address translation) (define) is done this way — map an internal address to an external public IP:

# ip route add nat via

iproute2 does not have the flexibility of iptables for configuring NAT — it only permits one-to-one address mapping. But if your needs are very simple, it’s a nice alternative to iptables.

Simple load-balancing across multiple interfaces is done like this, with the nexthop argument marking this as a multipath route:

#ip route add default scope global nexthop via dev eth0

nexthop via dev eth1

nexthop via dev eth2

You may add the weight parameter if you want to give preference to one path, like this:

#ip route add default scope global nexthop via dev eth0 weight 1

nexthop via dev eth1 weight 2

Because of caching, this may or may not actually have any noticeable effect. The fun bit is if you have the luxury of multiple Internet service providers, this gives automatic failover if one of them goes down. If you do get multiple providers for fault tolerance be sure they connect to different backbones; if they both rely on UUNet, for example, and UUNet horks up a big hairball, you don’t gain anything.

Another way to do this is to alternate the path that each successive packet takes:

# ip route add equalize default

nexthop via dev eth0

nexthop via dev eth0

What if the two links carry traffic at different speeds? Suppose the first one is twice as fast as the second. This is where using the weight parameter makes sense; set the first link to send twice as many packets as the second:

# ip route add equalize default

nexthop via dev eth0 weight 2

nexthop via dev eth0 weight 1

via Tunnels, Routes and Rules: They’re Easier with iproute2 –