Date: Mon, 15 Jul 1996 12:59:50 -0400 From: dennis@etinc.com (Dennis) To: Archie Cobbs <archie@whistle.com> Cc: hackers@freebsd.org Subject: Re: interfaces, routes, etc. Message-ID: <199607151659.MAA20029@etinc.com>
next in thread | raw e-mail | index | archive | help
A. Cobbs writes.... >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? It would be better if it meant "available", as it does with our driver. If a line goes down momentarily the upper layers should be informed, and the up flag is the only clean mechanism available. Packets should not be passed to a device that is not capable of passing them...which is what the up flag should mean. The running flag is a better mechanism for indicating whether a channel is administratively up or down....I've yet to figure out why you would care if an interface is running but administrativly not allowed to do anything. >> >> - 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. Then the POINTOPOINT flag shouldnt be on. NMBA is not PTP. If you want to model NMBA, fine, but dont degrade to meaning of one flag by adding another. You eithe model at NMBA or PTP, but not both simulaneously. The community generally does not model as NMBA because it is difficult to model effectively with existing routing protocols, and it has generally been determined that virtual PTP modelling works better and is more efficient. > >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. You're not understanding what it is. What you have is virtual PTP connections, not PTP with addressing, and not multi-point either. Without fully implemented discovery capability (like ARP on ethernet), you cant effectively use the single interface model without re-writing a lot of stuff. And the bottom line is that no one is using it, so you likely won't be very compatible if you do. >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. You can define it however you like, but you wont have a working product that will properly interface with the outside world. > >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. you didnt say that in your message. The confusion is that your flags are wrong. Its not PTP and its not multicast. You'll break lots of stuff if you do this. > >> 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 > Please dont do it with these flags....... >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). You'll be sorry to find out how many devices implement frame relay differently, and that you wont be able to talk to many devices. Unfortunately, what you should be doing is revamping aliasiing because aliasing in its present for is a terrible kludge. Now you're trying to extend the kludge in another inappropriate way. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD and LINUX
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607151659.MAA20029>