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>