3

(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?

  1. If so, is it normal in all/most cases, or is it more likely due to
    1. my client's configuration (e.g., distro, kernel)?
    2. my situation==VPN tunneling? (design details here, implementation details here)
    3. my use of ip route?
      1. If the latter, is there some less-delay-prone tool for getting and setting IP routes?
  2. 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.
|improve this question
  • Perhaps you can 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:52
  • @Nils: "Perhaps you can blackhole the route first?" Gotta say, as a network newbie, I had never previously heard of null routes. So in this case would the ip route be ip 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 like queueing request to [whatever]. – TomRoche Jan 26 '15 at 17:03
  • 1
    Frankly, if route works faster and better for your situation than ip 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 use ip addr ..., I've never used ip route ... – roaima Jan 27 '15 at 0:39
  • @roaima: "if route works faster and better for your situation than ip 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 from ip route show to ip route <add|del> than to route. – TomRoche Jan 27 '15 at 0:57
  • Agreed, @TomRoche. I was following up on the original question (and the several related ones) where I had inferred that ip route was slow but route 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 and route 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.