I'm trying to change the default routing entry for IPv4 packets from one
IPIP tunnel device to another with rtnetlink (like 'ip route replace 0/0
dev NEWTUNL'). The change seems to succeed (i.e. the routing table
changes), but the packets go for a while (several seconds) to the old
tunnel. If I replace the default route between the two tunnel devices
frequently (couple of times per second) more or less all the outgoing
packets seem to be going to one device.
I first thought, that there might be some kind of minimal update delay on
route cache and tried to flush it by writing -1 or 0 to
/proc/sys/net/ipv4/route/flush. After setting the min_delay to 0 I was
apparently able to flush the cache immediately, but it didn't seem to have
any effect on the problem.
If I set the old tunnel device down for a short moment ('ip link set dev
OLD down ; ip link set dev OLD up') the routing goes (quite obviously, as
the old tunnel is unavailable) immediately to the new tunnel. This is,
however, not a good solution as the device is down for a while and
incoming encapsulated packets arriving to the old tunnel may (and actually
will) be lost.
How is the routing entry selected in this kind of situation and is there
a way to force the default route to immediately change the destination
interface?
The tunnels and the default route looked like this:
TUNLB: ip/ip remote 192.168.240.9 local any ttl 64
TUNLA: ip/ip remote 192.168.240.11 local any ttl 64
default dev TUNLA scope link
(switching this between TUNLA and TUNLB with RTM_NEWROUTE - NLM_F_REPLACE)
Simultaneously to this switching of the route I'm sending UDP packets to a
remote host and these packets should be tunnelled to the two end points of
the tunnels, but the change does not happen immediately after changing the
routing table entry.
--
Jouni Malinen
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
