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.
Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
TomRoche
  • 1,275
  • 3
  • 15
  • 29
  • 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](https://en.wikipedia.org/wiki/Null_route). 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 00: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 ` than to `route`. – TomRoche Jan 27 '15 at 00: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
  • Yes, you got the blackhole right. RTFM: `ip route flush` has an interesting entry: "rounds to flush the current routing table" sounds like there is indeed a delay involved. Perhaps you can monitor the actual delay with `ip monitor route` to shed some light on the problem. – Nils Feb 02 '15 at 12:46

0 Answers0