ip route refresh

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

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

> 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).

-
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

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

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

Re: ip route refresh

Are R1/R2 running VRRP or some routing protocol?

-Ahsan

On Mon, 2 Aug 2004 14:10:27 +0200, Luca Ferrari 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
>
-
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