A linux route cache (flush) irregularity...

A linux route cache (flush) irregularity...

[Maciej Żenczykowski]

I can't seem to explain the following...
without there being some part/aspect of the route cache that 'ip route
flush cached' doesn't actually flush...
(ping output below slightly trimmed to make this log shorter)

This is on a 5.19.11-1rodete1-amd64 debian (or ubuntu?) based gLinux
kernel (I don't *think* there's any special gLinux hacks in it that
would be relevant though)
on a laptop connected via wifi to a cellular hotspot with 1460 mtu
path to the internet.

# ip route flush cached
# ip route show cached

# ping -c 1 -s $[1500-28] 8.8.8.8
From 10.0.0.200 icmp_seq=1 Frag needed and DF set (mtu = 1460)

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache expires 86396sec mtu 1460

# ping -c 1 -s $[1460-28] 8.8.8.8
76 bytes from 8.8.8.8: icmp_seq=1 ttl=113 (truncated)

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache expires 86390sec mtu 1460

# ping -c 1 -s $[1460-28] 1.1.1.1
1440 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=39.0 ms

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache expires 86381sec mtu 1460

# ip route flush cached
# ip route show cached

# ping -c 1 1.1.1.1
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=26.9 ms

# ping -c 1 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=50.0 ms

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache

Up until this spot I could explain everything, but why is there now an
entry for 8.8.8.8 but not 1.1.1.1?

The only explanation I can think of is that *some* part of the route
cache has actually remembered that a per-ip override for 8.8.8.8 needs
to be generated, but not for 1.1.1.1...

No, this doesn't really matter, but I'm the curious sort...
[side note: it also appears that 'ip route flush cached' and/or 'ip
route show cached' might be asynchronous...]

- Maciej