atraso na exclusão da rota IP

Question

(Desculpas se este for o StackExchange errado para esta questão, mas parece haver alguma confusão em relação a direcionamento adequado de perguntas sobre redes IP )

Estou sendo forçado a aprender mais rápido para resolver um problema bloqueando meu "trabalho real". Recentemente eu fui ensinado a use ip route de route , que parece funcionar ... eventualmente. Ou seja, , estou repetidamente observando eventos como os seguintes:

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

(e, FWIW, estou correndo

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)

) Então, eu estou querendo saber, isso é aparente atraso na exclusão de uma rota normal?

1. Se sim, é normal em todos / na maioria dos casos, ou é mais provável devido a
   1. configuração do meu cliente (por exemplo, distro, kernel)?
   2. minha situação == tunelamento VPN? (detalhes do projeto aqui , detalhes de implementação here )
   3. meu uso de ip route ?
      1. Se o último, existe alguma ferramenta menos propensa a atrasos para obter e definir rotas IP?
2. Se não, há algo que eu possa fazer para reduzir a latência aparente? Eu pergunto porque a situação que estou tentando depurar é sensível : Estou tentando aprender mais sobre o que acontece quando conecto a VPN de passagem de túnel, que está causando a VPN que fornece túneis (através da qual a VPN que atravessa o túnel ... túneis :-) falha rapidamente.