Date: Tue, 06 Apr 2004 13:58:50 +0200 From: Andre Oppermann <andre@freebsd.org> To: Anders Lowinger <anders.lowinger@packetfront.com> Cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? Message-ID: <40729B7A.2C984BD3@freebsd.org> References: <20040331005914.A6934@xorpc.icir.org> <40712A8F.9000704@packetfront.com> <40716208.808CF084@freebsd.org> <4072916D.101@packetfront.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Anders Lowinger wrote: > > > So far I haven't found any useful application of non-contignous > > mask in network applications. > > The only reason I've ever heard is when joining two separate subnets, > for example (sorry my cisco style, i'm a routing guy) > > interface ethernet 0 > ip address 192.168.0.0 mask 255.255.255.0 > > interface ethernet 1 > ip address 192.168.2.0 mask 255.255.255.0 > > if those are combined on one interface you could write > > interface ethernet 0 > ip address 192.168.0.0 mask 255.255.253.0 This is simply a supernet (aka classless) but *not* a non-contignous netmask. A non-contignous netmask would look like 255.254.255.0. > This is normally solved by secondaries (aliases) > > interface ethernet 0 > ip address 192.168.0.0 mask 255.255.255.0 > ip address 192.168.2.0 mask 255.255.255.0 secondary > > which gives the same functionality with contigious netmasks. Not really. With the your second example hosts on the network have to have different default gateways (192.168.0.1 and 192.168.2.1) depending in which network range they are. In your first example you just have one default gateway for all of them. However the netmask has to match on all hosts otherwise you run into all sorts of wierd trouble. > > Currently Luigi has teamed up with me to do the per-if > > ARP table stuff and the removal of cloning from the routing table. > > That alone will make network life in the kernel much easier. > > Sounds great! So, what is the goal? > Will the ARP functions generate host routes instead of the cloned routes? No. ARP will be completely removed from the routing table and become a link layer specific L3-L2 mapping hash list. In the routing table only the network entry to the interface will remain. > During forwarding to a nexthop with unknown L2/ARP entry, will you > trigger ARP? Of course, you have to. > We would really need an Mtrie for faster route lookups and combine the > forwarding lookup with the check for packets destined to the router/ > connected addresses. The scalability of many L3 interfaces today is not that > great. (caveeat, not 100% updated on the -current) The routing table would be cleaned up with these changes and lose all cloning functionality because it no longer needed (I removed the protocol cloning last year already). > I'll dig around, I have some old mtrie code I could try > to do some patches for.... If you have some you can post it, otherwise we have some other code ready in the closet. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40729B7A.2C984BD3>