Date: Thu, 26 Oct 2000 11:10:05 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes Message-ID: <200010261810.LAA56409@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/10778; it has been noted by GNATS.
From: John Polstra <jdp@polstra.com>
To: freebsd-gnats-submit@freebsd.org
Cc: archie@freebsd.org, wollman@khavrinen.lcs.mit.edu,
fenner@research.att.com
Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes
Date: Thu, 26 Oct 2000 11:09:33 -0700 (PDT)
I have confirmed that the problem Archie described is real, and the
cause is as he describes it. The problem is easy to reproduce when
tunneling some routes through a VPN. In this case there is a default
route which points to the normal gateway, and there are some network
routes pointing to the VPN gateway. The the problem is reproduced
as follows:
- Communicating with a host 192.168.1.1 which is on the VPN.
The route for 192.168.1.0/24 sends the packets to the VPN
gateway.
- The VPN link goes down or is shut down.
- Packets destined for 192.168.1.1 now get routed to the default
gateway (which of course fails to deliver them to the right
place). Note that the ipforward_rt cache is (correctly) ignored
in this case because the route it points to is no longer up.
- ipforward_rt records that the route to 192.168.1.1 is via the
default gateway.
- The VPN link is brought back up.
- But packets for 192.168.1.1 still get sent to the default
gateway because of the cached route in ipforward_rt. If the
VPN gateway is a separate host from the default gateway and we
are communicating with only a single host on the VPN, this
situation can endure indefinitely.
Sending a packet to, say 192.168.1.2 replaces the bad ipforward_rt
entry and gets things working again.
One easy hack would be to ignore ipforward_rt if it is more than, say,
2 seconds old. This isn't a real fix, but it would at least limit the
duration of the damage. The performance penalty would be negligible
in real life.
The downside of implementing this hack is that it might prevent a
real fix from ever getting made.
John
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010261810.LAA56409>