ip route refresh

ip route refresh

[Luca Ferrari]

Hi,
I've noted on different system that when an ip route changes, the kernel keeps 
the old one in a cache (I suppose) for a while. For example, if in 
you /etc/hosts you have an entry:
192.168.1.201 fluca fluca
and ping fluca it will try to connect to 192.168.1.201.
Now if you change the address and immediatly reping it, it will try again the 
old host for a while. After a minute the system should be able to use the new 
address. This also applies to routes.
Is there a way to force a cache-clear, thus modifications are immediatly 
visible?

Thanks,
Luca

-- 
Luca Ferrari,
fluca1978@infinito.it

Re: ip route refresh

[Glynn Clements]

Luca Ferrari wrote:

> I've noted on different system that when an ip route changes, the kernel keeps 
> the old one in a cache (I suppose) for a while. For example, if in 
> you /etc/hosts you have an entry:
> 192.168.1.201 fluca fluca
> and ping fluca it will try to connect to 192.168.1.201.
> Now if you change the address and immediatly reping it, it will try again the 
> old host for a while. After a minute the system should be able to use the new 
> address. This also applies to routes.
> Is there a way to force a cache-clear, thus modifications are immediatly 
> visible?

1. What does this have to do with routing? Unless I'm misunderstanding
the above, this is a name-service issue.

2. Are you using nscd? If so, try "/etc/rc.d/init.d/nscd restart".

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: ip route refresh

[Luca Ferrari]

On Saturday 31 July 2004 00:34 Glynn Clements's cat walking on the keyboard  
wrote:

> Luca Ferrari wrote:
> > I've noted on different system that when an ip route changes, the kernel
> > keeps the old one in a cache (I suppose) for a while. For example, if in
> > you /etc/hosts you have an entry:
> > 192.168.1.201 fluca fluca
> > and ping fluca it will try to connect to 192.168.1.201.
> > Now if you change the address and immediatly reping it, it will try again
> > the old host for a while. After a minute the system should be able to use
> > the new address. This also applies to routes.
> > Is there a way to force a cache-clear, thus modifications are immediatly
> > visible?
>
> 1. What does this have to do with routing? Unless I'm misunderstanding
> the above, this is a name-service issue.
>

No, it's not, since I've experienced it also using direct addresses. I mean, 
if you ping 192.168.1.201 the packets will follow a particular way. If you 
change your kernel route (thru 'route') and try to ping immediately the same 
host, the pakets will try to reach the host with the same way (if it is still 
valid). 

> 2. Are you using nscd? If so, try "/etc/rc.d/init.d/nscd restart".

No, I'm not using it.

Thanks,
Luca

-- 
Luca Ferrari,
fluca1978@infinito.it

Re: ip route refresh

[urgrue]

> No, it's not, since I've experienced it also using direct addresses. I mean, 
> if you ping 192.168.1.201 the packets will follow a particular way. If you 
> change your kernel route (thru 'route') and try to ping immediately the same 
> host, the pakets will try to reach the host with the same way (if it is still 
> valid). 

Nevertheless these are two different mechanisms and two different "caches"
we're talking about. What route a packet takes is decided by a completely
different system as what IP an address maps to. iptables also has a kind of
"cache" but that doesn't mean it has anything to with /etc/hosts or routing.

For routes, try "ip route flush table cache" (this is from memory, but it
was something like that).

For name services, nscd is the only thing i can think of that might cause
the behaviour you described (/etc/hosts change not taking immediate effect).

Re: ip route refresh

[Ahsan Ali]

Can you give some specific examples?

I use linux extensively for routing and have never come across this.

Show us exactly what you're doing and the route tables when you do it.

-Ahsan

On Sat, 31 Jul 2004 10:13:06 +0200, Luca Ferrari <fluca1978@infinito.it> wrote:
> On Saturday 31 July 2004 00:34 Glynn Clements's cat walking on the keyboard
> wrote:
> 
> > Luca Ferrari wrote:
> > > I've noted on different system that when an ip route changes, the kernel
> > > keeps the old one in a cache (I suppose) for a while. For example, if in
> > > you /etc/hosts you have an entry:
> > > 192.168.1.201 fluca fluca
> > > and ping fluca it will try to connect to 192.168.1.201.
> > > Now if you change the address and immediatly reping it, it will try again
> > > the old host for a while. After a minute the system should be able to use
> > > the new address. This also applies to routes.
> > > Is there a way to force a cache-clear, thus modifications are immediatly
> > > visible?
> >
> > 1. What does this have to do with routing? Unless I'm misunderstanding
> > the above, this is a name-service issue.
> >
> 
> No, it's not, since I've experienced it also using direct addresses. I mean,
> if you ping 192.168.1.201 the packets will follow a particular way. If you
> change your kernel route (thru 'route') and try to ping immediately the same
> host, the pakets will try to reach the host with the same way (if it is still
> valid).
> 
> > 2. Are you using nscd? If so, try "/etc/rc.d/init.d/nscd restart".
> 
> No, I'm not using it.
> 
> 
> 
> Thanks,
> Luca
> 
> --
> Luca Ferrari,
> fluca1978@infinito.it
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: ip route refresh

[Luca Ferrari]

On Sunday 01 August 2004 22:48 Ahsan Ali's cat walking on the keyboard  wrote:

> Can you give some specific examples?
>
> I use linux extensively for routing and have never come across this.
>
> Show us exactly what you're doing and the route tables when you do it.

Well, I've noticed it first when I changed my router policies. From a computer 
I was telnetting a remote host on another subnet. The subnet was reached thru 
a Linux gateway connected to two routers (call them R1 and R2). In a first 
test R2 was down, so all the traffic was traveling over R1. When R2 was up, 
the traffic to the above subnet was redirected to the R2 router (i.e., I 
changed the 'route' policy of the gateway). Nevertheless, for a couple of 
minutes the traffic was going over R1.
Another issue I've noticed was an error on the /etc/hosts (different machine): 
I wrongly wrote  the address of an host, thus pinging it was a real ping to 
another machine. I correct the entry and re-do ping, but it was still pinging 
the wrong host. After a minute everything was working fine, but immediately 
it was not. I believe it could be an arp cache problem, as you suggested me.
Thanks,
Luca
-- 
Luca Ferrari,
fluca1978@infinito.it

Re: ip route refresh

[Ahsan Ali]

Are R1/R2 running VRRP or some routing protocol?

-Ahsan

On Mon, 2 Aug 2004 14:10:27 +0200, Luca Ferrari <fluca1978@infinito.it> wrote:
> On Sunday 01 August 2004 22:48 Ahsan Ali's cat walking on the keyboard  wrote:
> 
> > Can you give some specific examples?
> >
> > I use linux extensively for routing and have never come across this.
> >
> > Show us exactly what you're doing and the route tables when you do it.
> 
> Well, I've noticed it first when I changed my router policies. From a computer
> I was telnetting a remote host on another subnet. The subnet was reached thru
> a Linux gateway connected to two routers (call them R1 and R2). In a first
> test R2 was down, so all the traffic was traveling over R1. When R2 was up,
> the traffic to the above subnet was redirected to the R2 router (i.e., I
> changed the 'route' policy of the gateway). Nevertheless, for a couple of
> minutes the traffic was going over R1.
> Another issue I've noticed was an error on the /etc/hosts (different machine):
> I wrongly wrote  the address of an host, thus pinging it was a real ping to
> another machine. I correct the entry and re-do ping, but it was still pinging
> the wrong host. After a minute everything was working fine, but immediately
> it was not. I believe it could be an arp cache problem, as you suggested me.
> 
> 
> Thanks,
> Luca
> --
> Luca Ferrari,
> fluca1978@infinito.it
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>