Date: Sat, 13 Jul 1996 22:17:59 -0700 (PDT) From: "JULIAN Elischer" <julian@ref.tfs.com> To: archie@whistle.com (Archie Cobbs) Cc: freebsd-hackers@freebsd.org Subject: Re: interfaces, routes, etc. Message-ID: <199607140517.WAA13311@ref.tfs.com> In-Reply-To: <199607132345.QAA00884@bubba.whistle.com> from "Archie Cobbs" at Jul 13, 96 04:45:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I'm finding some weird behavior in -current with regards to interface > numbering, aliases, automatically generated routes, ARP entries, etc. > > One specific example... > > - When you bring an EtherNet interface up and ping some addresses > on that network, you get automatically generated LINK layer routes > (ie, arp entries). However, when you bring the interface down > these routes do not automatically go away. > > [ I thought there was discussion about this before and agreement > that "automatically generated routes should be automatically > removed, and static routes should always be left alone." If so, > I'd be happy to produce a patch for review. ] > > One very weird but non-reproducible case involved an ethernet interface > that had been renumbered several times on the same class c network. > It got into a situation where "ifconfig" clearly showed the address > as a single number (and netstat showed sane settings as well), but > pinging *certain* addresses on the ethernet would cause transmitted > packets to have the old source ip address. > > In general, old alias addresses sometimes seem to "haunt" an interface > long after they have been deleted. I'm betting that this is a cached route.. the validity check for the rtentry checks that the interface still exists and that it is up, but I don't think it checks for the address still being valid.. check ether_output() in if_ethersubr.c. I think that whole section is a kludge and needs to be shot.. > > 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? > > In FreeBSD: > > - The local and remote addresses do not need be part of the > same network hmm didn't we figure out this was being done wrong by code inspection? > > - The local address can be 0.0.0.0, but not the remote address > > - It is possible to set aliases address pairs on a point-to-point > link which share the same destination, but not the same source > > I assume this is to be as flexible as possible for people trying > to do funny things like half routing, etc. > > However, I don't understand the third one above; you should be > able to have address pairs with the same source and different > destination addresses; this would apply nicely to NBMA (non-broadcast > multiple access) networks such as frame relay. > > My suggestions... > > - Automatically generated link layer routes get removed when an > interface is brought down. > > - 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 > > - Declare that any interface which has the POINTOPOINT but not the > BROADCAST flag set, and which allows multiple (alias) address > pairs, is by definition a NBMA network. > > > -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?199607140517.WAA13311>