Date: Sun, 14 Jul 1996 14:50:38 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: dennis@etinc.com (dennis) Cc: hackers@freebsd.org Subject: Re: interfaces, routes, etc. Message-ID: <199607142150.OAA04134@bubba.whistle.com> In-Reply-To: <199607141623.MAA18495@etinc.com> from "dennis" at Jul 14, 96 12:23:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Dennis writes: > >> - Automatically generated link layer routes get removed when an > >> interface is brought down. > > This should depend on what you mean by "down". If the link is adminstratively > brought 'down", yes, but if on a PTP the line goes flakey for a few minutes > (because the telco is playing games, like ours does sometimes on a > saturday morning), it shouldnt affect the routes. If you're changing an addre > you should delete the old addresses explicitly. If the line goes flakey, that shouldn't affect the flags associated with the interface, the routes, or anything else, right? Just let the "best effort" property of IP packet transmission handle that case-- i.e., the packet get dropped by the physical layer, darn. The physical layer is not the concern of the kernel's anywhere above the device driver. In other words, my understanding is that the "UP" flag associated with an interface is always meant in the administrative sense... would you say the same? > >> Another question: > >> > >> - Exactly what is the netmask, as configured on a point-to-point > >> interface, used for? If anything, which address does it apply to, > >> the local or the remote one? > > This is something that should be fixed, as the routes are added at "host" > when you set up a PTP address pair, yet the netmask is set the the natural > mask of the local address, which is arguable wrong. The broadcast address > (if broadcasting is on) should also be the destinination address of the PTP, > not the broadcast address formulated using the netmask. Yes... this should be fixed! > >> - Allow NMBA type addressing on point-to-point links like this: > >> > >> tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 > >> inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > >> inet 1.1.1.1 --> 3.3.3.3 netmask 0xff000000 > >> inet 1.1.1.1 --> 4.4.4.4 netmask 0xff000000 > > Why would you want to alias like this on a PTP? This particular example is > very wrong, because the definition of a PTP link is one entity on each side > of the link. The above should be configured: It's not a point-to-point link, it's a NBMA link -- a type of link of which traditional point-to-point is an easily handled degenerate case. Think of NBMA as "point-to-point with link layer addressing". Frame relay is the motivating example here. Frame relay has the property that through a single physical interface exist multiple logical point-to-point channels (as you of course know). Each logical channel has a two byte link layer address called a DLCI. It also depends on what you mean by interface... The ET driver creates a new interface for each logical channel... a perfectly valid approach. But if you view the word "interface" as meaning something that corresponds uniquely to a single physical piece of hardware, then the ET approach doesn't work, and the other approach makes more sense, i.e., treating the interface as a single NBMA interface, with which are associated multiple point-to-point links. In addition, you would put the DLCI in the routing table just like ARP entries (link layer addresses for ethernet) are. > tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 > >> inet 1.1.1.1 --> 2.2.2.2 > > route add 3.3.3.3 2.2.2.2 > route add 4.4.4.4 2.2.2.2 That's not the same thing, since host 3.3.3.3 is not reachable via host 2.2.2.2 in my example. You must send to 3.3.3.3 directly using it's DLCI. > if you have multiple gateways on a PTP link the routing software has no > way of knowing what the gateway is for a particular packet, and you'll > break stuff that depends on such things. Why? What's so much more complicated about this: tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 inet 1.1.1.1 --> 3.3.3.3 netmask 0xff000000 inet 1.1.1.1 --> 4.4.4.4 netmask 0xff000000 than this?: tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 1.1.1.1 --> 3.3.3.3 netmask 0xff000000 tun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 1.1.1.1 --> 4.4.4.4 netmask 0xff000000 Your link layer addresses will get computed automatically a la ARP.. this solves the "multiple destinations on a single interface" problem (which is an old one, not a new one). -Archie ___________________________________________________________________________ Archie L. Cobbs, archie@whistle.com * Whistle Communications Corporation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607142150.OAA04134>