Stale route not flushed/updated

[Arnaud Lacombe]

Hi all,

I got a routing problem this afternoon with a soekris box running 5.0RC3.

A short description of the problem is that the kernel was re-using an
old local source IP address in an ICMP packet. Flushing routes and
recreating them solved the problem.

A longer description of the problem is the following: an interface on
the soekris has 4 IP address:

$ cat /etc/ifconfig.vr0
inet 172.16.0.1 netmask 0xffffff00
alias 172.16.1.1 netmask 0xffffff00
alias 172.16.2.1 netmask 0xffffff00
alias 172.16.3.1 netmask 0xffffff00

and 4 different routes associated:
route add 10.1.0.0/24 172.16.0.200
route add 10.1.1.0/24 172.16.0.200
route add 10.1.2.0/24 172.16.0.200
route add 10.1.3.0/24 172.16.0.200

as expected, the route to 10.1.3.1 picks 172.16.0.1 as the local source address:
# route get 10.1.3.1
route to: 10.1.3.1
destination: 10.1.3.0
mask: 255.255.255.0
gateway: 172.16.0.200
local addr: 172.16.0.1
interface: flags: <UP,GATEWAY,DONE,STATIC>

Now, if I clean-up the address on vr0:
# ifconfig vr0 delete 172.16.0.1
# ifconfig vr0 delete 172.16.1.1
# ifconfig vr0 delete 172.16.2.1

# ifconfig vr0
[...]
inet 172.16.3.1 netmask 0xffffff00 broadcast 172.16.3.255

I still have the old route entry pointing to 10.1.3.1:
# route get 10.1.3.1
route to: 10.1.3.1
destination: 10.1.3.0
mask: 255.255.255.0
gateway: 172.16.0.200
local addr: 172.16.0.1
interface: vr0 flags: <UP,GATEWAY,DONE,STATIC>

At this point, trying to ping 10.1.3.1 fails as expected:
# ping 10.1.3.1
PING 10.1.3.1 (10.1.3.1): 56 data bytes
ping: sendto: No route to host

However, if I change the netmask associated with 172.16.3.1 to a /22,
allowing the access to 172.16.0.200. Trying to ping 10.1.3.1 generates
an ICMP packet with the wrong source IP:

09:05:17.238201 IP 172.16.0.1 > 10.1.3.1: ICMP echo request, id 31459,
seq 5, length 64

The only point to recover from this situation is to flush the route to
10.1.3.0/24 and re-create it.

From my understanding, the route entry with 172.16.0.1 as a local
source to 10.1.3.0/24 should be flushed as soon as the interface no
longer have the IP address associated.

comments ?

- Arnaud

ps: btw, is there a way to tell the routing code to use a specific
source address depending of the destination network. In the above
setup, I'd like to have the 4 /22 (/24 currently, I know) using
172.16.0.200 as a gateway but picking different local source address
depending of the destination.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Arnaud Lacombe
Hi all,
I got a routing problem this afternoon with a soekris box running 5.0RC3.
A short description of the problem is that the kernel was re-using an
old local source IP address in an ICMP packet. Flushing routes and
recreating them solved the problem.
A longer description of the problem is the following: an interface on
$ cat /etc/ifconfig.vr0
inet 172.16.0.1 netmask 0xffffff00
alias 172.16.1.1 netmask 0xffffff00
alias 172.16.2.1 netmask 0xffffff00
alias 172.16.3.1 netmask 0xffffff00
route add 10.1.0.0/24 172.16.0.200
route add 10.1.1.0/24 172.16.0.200
route add 10.1.2.0/24 172.16.0.200
route add 10.1.3.0/24 172.16.0.200
# route get 10.1.3.1
route to: 10.1.3.1
destination: 10.1.3.0
mask: 255.255.255.0
gateway: 172.16.0.200
local addr: 172.16.0.1
interface: flags: <UP,GATEWAY,DONE,STATIC>
# ifconfig vr0 delete 172.16.0.1
# ifconfig vr0 delete 172.16.1.1
# ifconfig vr0 delete 172.16.2.1
# ifconfig vr0
[...]
inet 172.16.3.1 netmask 0xffffff00 broadcast 172.16.3.255
# route get 10.1.3.1
route to: 10.1.3.1
destination: 10.1.3.0
mask: 255.255.255.0
gateway: 172.16.0.200
local addr: 172.16.0.1
interface: vr0 flags: <UP,GATEWAY,DONE,STATIC>
# ping 10.1.3.1
PING 10.1.3.1 (10.1.3.1): 56 data bytes
ping: sendto: No route to host
However, if I change the netmask associated with 172.16.3.1 to a /22,
allowing the access to 172.16.0.200. Trying to ping 10.1.3.1 generates
09:05:17.238201 IP 172.16.0.1 > 10.1.3.1: ICMP echo request, id 31459,
seq 5, length 64
The only point to recover from this situation is to flush the route to
10.1.3.0/24 and re-create it.
From my understanding, the route entry with 172.16.0.1 as a local
source to 10.1.3.0/24 should be flushed as soon as the interface no
longer have the IP address associated.

The route entry should not be flushed, but its source should change.
This may work better with 'options IPSELSRC' than without.

Post by Arnaud Lacombe
ps: btw, is there a way to tell the routing code to use a specific
source address depending of the destination network. In the above
setup, I'd like to have the 4 /22 (/24 currently, I know) using
172.16.0.200 as a gateway but picking different local source address
depending of the destination.

Have you tried route add <destination> <gateway> -ifa <source> ? (This
will work worse with 'options IPSELSRC' than without; otherwise, I would
make IPSELSRC the default. I keep starting to fix that and getting
distracted.)

Dave