Date: Mon, 8 Apr 1996 13:15:35 -0700 (PDT) From: Archie Cobbs <archie@tribe.com> To: freebsd-hackers@freebsd.org Subject: Routing questions Message-ID: <199604082015.NAA06876@bubba.tribe.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604082015.NAA06876>