(Apologies if this is the wrong StackExchange for this question, but there does seem to be some confusion regarding appropriate targeting of IP networking questions)
I am being forced to learn more fast in order to solve a problem blocking my "real work." Recently I was taught to use ip route
instead of route
, which does seem to work ... eventually. I.e., I'm repeatedly observing events like the following:
me@client:~$ sudo ip route show
Thu Jan 22 23:47:36 EST 2015
0.0.0.0/1 via 10.144.0.13 dev ppp0 proto none metric 1
default via 192.168.1.1 dev eth0 proto static
10.144.0.1 dev ppp0 proto kernel scope link src 10.144.0.13
128.0.0.0/1 via 10.144.0.13 dev ppp0 proto none metric 1
134.67.15.30 via 10.8.0.5 dev tun0 proto none metric 1
me@client:~$ sudo ip route del 0.0.0.0/1 via 10.144.0.13
# note null response, so I'm assuming this worked. But ...
me@client:~$ date ; sudo ip route show
Thu Jan 22 23:47:54 EST 2015
# ... it's still there!
0.0.0.0/1 via 10.144.0.13 dev ppp0 proto none metric 1
default via 192.168.1.1 dev eth0 proto static
10.144.0.1 dev ppp0 proto kernel scope link src 10.144.0.13
128.0.0.0/1 via 10.144.0.13 dev ppp0 proto none metric 1
134.67.15.30 via 10.8.0.5 dev tun0 proto none metric 1
# But if I `ip route del` a second time, ...
me@client:~$ sudo ip route del 0.0.0.0/1 via 10.144.0.13
# ... again null response, but ...
me@client:~$ date ; sudo ip route show
Thu Jan 22 23:48:13 EST 2015
default via 192.168.1.1 dev eth0 proto static
10.144.0.1 dev ppp0 proto kernel scope link src 10.144.0.13
128.0.0.0/1 via 10.144.0.13 dev ppp0 proto none metric 1
134.67.15.30 via 10.8.0.5 dev tun0 proto none metric 1
# ... now '0.0.0.0/1 via 10.144.0.13' is gone
(and, FWIW, I'm running
me@client:~$ cat /etc/debian_version
jessie/sid
me@client:~$ uname -rv
3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13)
) So I'm wondering, is this apparent delay in deleting a route normal?
- If so, is it normal in all/most cases, or is it more likely due to
- If not, is there something I can do to reduce the apparent latency? I ask because the situation I'm trying to debug is time-sensitive: I'm trying to learn more about what happens when I connect the tunnel-traversing VPN, which is causing the tunnel-providing VPN (through which the tunnel-traversing VPN ... tunnels :-) to crash quickly.
blackhole
the route first? I think that delay in deletion might be normal, since the kernel needs to do a couple of things to tear it down. – Nils Jan 24 '15 at 21:52ip route
beip route blackhole 0.0.0.0/1 via 10.144.0.13
? @Nils: "I think that delay in deletion might be normal, since the kernel needs to do a couple of things to tear it down." That does seem reasonable. That being said, It Might Be Nice for the response to the command to be something likequeueing request to [whatever]
. – TomRoche Jan 26 '15 at 17:03route
works faster and better for your situation thanip route
, take the pragmatic approach. Personally, I've never come across route change delays such as the one you're describing, but then although I useip addr ...
, I've never usedip route ...
– roaima Jan 27 '15 at 0:39route
works faster and better for your situation thanip route
" I don't know that it does--do you?. If not: it might be worth checking, but 1. Given that the routes are "really in" the kernel, I can't see why these userspace applications would perform differently. 2. I'm a newbie, and frankly I find it very much easier syntactically to translate fromip route show
toip route <add|del>
than toroute
. – TomRoche Jan 27 '15 at 0:57ip route
was slow butroute
might be instantaneous. Having re-read the question and tried a few things here it seems to me that, for this use case,ip route
androute
act for me in the same manner and equally effectively. I do not see the no-op effect described. OTOH I don't have a PPP link to test against. – roaima Jan 27 '15 at 10:15