Date: Tue, 29 Apr 2008 13:42:03 -0700 From: Julian Elischer <julian@elischer.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Kevin Oberman <oberman@es.net> Subject: Re: multiple routing tables review patch ready for simple testing. Message-ID: <4817881B.7010409@elischer.org> In-Reply-To: <48178452.4050700@FreeBSD.org> References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M. Simpson wrote: > Julian Elischer wrote: >>> >>> A general purpose OS is a different beast as it has no physical >>> equivalent of the FIB. It may have multiple routing tables, though, to >>> I think setrib would be a term less likely to cause confusion then >>> setfib even though, in the case of your FreeBSD patches, it's really >>> both. >> If we need to change the terminology now is the time.. >> I asked for comments on terminology before and this is what we >> came up with.. but once it gets committed.... it gets set in stone. > > The kernel forwarding table is not a RIB. > > In the past some apps have tried to use it as one. They really shouldn't > do that. > > There are implementation constraints on the inter-process communication > involved (PRC_ATOMIC, etc) which make it inherently unsuitable as a > place for routing daemons to exchange routes, particularly when the > system is under load, or running near load limits, as would be the case > with a tightly engineered embedded system. > > I understand folk went down that road in the past, as a means to get > something up and running quickly as a working demo, or as a hangover > from the days when they were the only tools around, but it isn't the way > to build a comms infrastructure. > > These days general purpose OSes are getting closer to specialised comms > equipment in terms of what they can do, but more importantly, so are > people's expectations of them -- and thus people's concern about whether > or not it works tends to follow. > basically what I've implemented is similar to cisco VRF in nature. Interfaces are not however assigned to FIB instance. each FIB may contain entries for each interface, and by default they do, but you can delete teh entries associated with a particular interface from a particular FIB so that fib will never use that interface. An interface may however be present in entries from multiple FIBs in which case the INCOMING packets on that interface need to be disambiguated with respect to which FIB they belong to. This is a job for an outside entity (from the fibs). In this case a packet classifier such as pf or ipfw is ideal for the job. providing an outside mechanism for implementing whatever policy the admin wants to set up. I find it is convenient to envision each routing FIB as a routing plane, in a stack of such planes. Each plane may know about the same interfaces or different interfaces. When a packet enters a routing plane it is routed according to the internal rules of that plane. Irrespective of how other planes may act. Each plane can only route a packet to interfaces that are know about on that plane. Incoming packets on an interface don't know what plane to go to and must be told which to use by the external mechanism. It IS possible that an interface in the future might have a default plane, but I haven't implemented this. if you have several alias addresses on an interface it is possible that some FIBS know about some of them and others know about other addresses. New addresses when added are added to each FIB and whatever is adding them shoudl remove them from the ones that don't need it. This may change but it fits in with how the current code works and keeps the diff to a manageable size. (and it suits what I need for work where a route manager daemon knows to do this.) > cheers > BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4817881B.7010409>