From owner-freebsd-hackers Mon Apr 8 13:15:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23852 for hackers-outgoing; Mon, 8 Apr 1996 13:15:43 -0700 (PDT) Received: from bubba.tribe.com ([205.184.207.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA23847 for ; Mon, 8 Apr 1996 13:15:39 -0700 (PDT) Received: (from archie@localhost) by bubba.tribe.com (8.6.12/8.6.12) id NAA06876; Mon, 8 Apr 1996 13:15:36 -0700 From: Archie Cobbs Message-Id: <199604082015.NAA06876@bubba.tribe.com> Subject: Routing questions To: freebsd-hackers@freebsd.org Date: Mon, 8 Apr 1996 13:15:35 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello hackers... This discussion about how to handle routing entries when interfaces go up and down is central to some stuff I'm working on, so naturally it interests me greatly... we're considering FreeBSD for use in a commercial product. I've been working with 2.1-R so far and I suppose some of this has been fixed, but anyway... By the way, I know how to get around the problems stated below... I'm more trying to ask some higher level questions regarding the overall "policy" of how to manage the routing table, etc, when interfaces go up and down and/or change numbers. * * * Example one... suppose you do this: $ ifconfig ed0 192.0.0.2 $ route add default 192.0.0.1 $ ifconfig ed1 193.0.0.2 $ ping -c 1 193.0.0.5 So far, so good.. at this point an ARP route to 193.0.0.5 has appeared in the routing table. $ ifconfig ed1 down delete $ ping -c 1 193.0.0.5 ping: sendto: Network is down This can't be right, because I happen to know that it's also possible to get to 193.0.0.5 via the default route. But the ARP entry for 193.0.0.5 via interface ed1 was not removed from the routing table when the interface went down... This looks like a pretty clear cut case to me... at the least, any such *automatically* generated routes should be *automatically* removed when the interface goes down. Static routes, I believe, should never be automatically removed. Now on to the next issue... * * * Suppose I want to have a dial-on-demand PPP connection. OK so I setup the routes, run PPP, and PPP opens the interface and waits for a packet to be sent. The interface is initially numbered 10.1.1.1 -> 11.1.1.1. Result: Destination Gateway Flags Refs Use Netif Expire default 10.1.1.1 USc 0 0 tun0 10.1.1.1 127.0.0.1 UH 0 0 lo0 11.1.1.1 10.1.1.1 UH 1 0 tun0 Then a packet gets sent, so PPP opens dials the peer and negotiates the IP addresses. Oops, the server at the remote end wants us to use 12.1.1.1 -> 13.1.1.1 instead of what I had before. I have no choice. So I take my interface down ("ifconfig tun0 down delete"), and then bring it back up again, this time with the new IP addresses assigned by the server: 12.1.1.1 -> 13.1.1.1. Now a look at the routing table shows: Destination Gateway Flags Refs Use Netif Expire default 10.1.1.1 USc 0 0 tun0 10.1.1.1 127.0.0.1 UH 0 0 lo0 13.1.1.1 12.1.1.1 UH 0 0 tun0 First point: this looks like it shouldn't work, since now nowhere in the system is there an interface with the number 10.1.1.1. But sending a packet to an anonymous IP address does cause it to get sent through the tun0 interface. Moreover, it is assigned the source address 10.1.1.1 instead of 12.1.1.1 like it should. Oops. Next point: since the route to 10.1.1.1 via 127.0.0.1 was automatically generated by the first ifconfig, shouldn't it too be automatically removed when the interface is taken down? It is no longer the number of any local interface, up or down. And hey! what happened to the analogous local route for 12.1.1.1? * * * So anyway, my *real* question is: is there a document that states precisely what the policy is on the interaction between interface numbering, routing, ARP'ing, etc? Because if there were it seems the above problems wouldn't have happened... If not, does anyone else feel like there ought to be one? I'd offer to maintain the latest version if people are interested. On the other hand, if this is overkill.. could someone explain it to me? Thanks, -Archie ________________________________________________________________________ Archie L. Cobbs, archie@tribe.com * Tribe Computer Works, Inc.