Re: multiple routing tables review patch ready for simple testing.
Bjoern A. Zeeb wrote: On Tue, 6 May 2008, Julian Elischer wrote: Hi, Bjoern A. Zeeb wrote: On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src So after looking at the patch a bit more again, could you add wrapper functions for those like you have done for the old KPI (rtrequest, rtrequest1, do you really want to do the extra work instructions? ... The defines will not give you a stable KPI and having that changed again if you are going with a prefix for each AF would be a pain if the _fib versions are going to change in the future. hmm fair enough... but let me outline my plans and thoughts so we can see if you still want this.. [ ... ] This all however is not ABI compatible so could not go back to 7.x and I want to check in an initial version that can go back to 7.x which sort of suggests to me that adding in_xxx functions is not really required, until I do the next step. 7.x will never get the next step. because the ABI is already set in stone for 7.x. I would make the in_xxx stubs in the next step in 8.x. after the MFC to 7.x of the ABI compat version. let me know what you think. Leaving aside any upcoming enhancement if what we have now is what is going into 7 and possibly 6 we should do the wrapper functions. The point is RELENG_7 will live for $(last release + 2 years) so I guess till 2011 or maybe later. No idea what would happen there in all that time. If people start adding support for other AFs we cannot say that the *_fib variants are not going to change so having the in_* stable sounds like a good thing for 6 and 7. Am I missing anything obvious? I don't mind if they are going to significantly change again in 8 a few weeks later. ok, check http://www.freebsd.org/~julian/mrt.diff /bz ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
On Tue, 6 May 2008, Julian Elischer wrote: Hi, Bjoern A. Zeeb wrote: On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src So after looking at the patch a bit more again, could you add wrapper functions for those like you have done for the old KPI (rtrequest, rtrequest1, do you really want to do the extra work instructions? ... The defines will not give you a stable KPI and having that changed again if you are going with a prefix for each AF would be a pain if the _fib versions are going to change in the future. hmm fair enough... but let me outline my plans and thoughts so we can see if you still want this.. [ ... ] This all however is not ABI compatible so could not go back to 7.x and I want to check in an initial version that can go back to 7.x which sort of suggests to me that adding in_xxx functions is not really required, until I do the next step. 7.x will never get the next step. because the ABI is already set in stone for 7.x. I would make the in_xxx stubs in the next step in 8.x. after the MFC to 7.x of the ABI compat version. let me know what you think. Leaving aside any upcoming enhancement if what we have now is what is going into 7 and possibly 6 we should do the wrapper functions. The point is RELENG_7 will live for $(last release + 2 years) so I guess till 2011 or maybe later. No idea what would happen there in all that time. If people start adding support for other AFs we cannot say that the *_fib variants are not going to change so having the in_* stable sounds like a good thing for 6 and 7. Am I missing anything obvious? I don't mind if they are going to significantly change again in 8 a few weeks later. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot/user/julian/routing/src
So after looking at the patch a bit more again, could you add wrapper
functions for those like you have done for the old KPI (rtrequest,
rtrequest1,
do you really want to do the extra work instructions?
..)?
+ * For now the protocol indepedent versions are the same as the AF_INET
ones
+ * but this will change.. just #define them at this time.
+ */
+#definein_rt_getifa(_a, _b)rt_getifa_fib(_a, _b)
+#definein_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c)
+#definein_rtalloc(_a, _b) rtalloc_fib(_a, _b)
+#define in_rtalloc1(_a, _b, _c, _d)rtalloc1_fib(_a, _b, _c, _d)
+#definein_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c)
+#definein_rtredirect(_a, _b, _c, _d, _e, _f) \
+ rtredirect_fib(_a, _b, _c, _d,
_e, _f)
+#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \
+ rtrequest_fib(_a, _b, _c, _d,
_e, _f,_g)
+#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b,
_c, _d)
+#define in_rt_check(_a, _b, _c, _d)rt_check_fib(_a, _b, _c,
_d)
The defines will not give you a stable KPI and having that changed again
if you are going with a prefix for each AF would be a pain if the _fib
versions
are going to change in the future.
hmm fair enough... but let me outline my plans and thoughts
so we can see if you still want this..
In order to get away from having every protocol (existing or not)
from preallocating N fib heads (currently it is done in protocol
independent code) the protocols themselves need to know if they are
allocating multiple FIBS and how many. For this reason,
the protocol versions will eventually know where their own
fibs are stored and act on them as needed, allowing them to be
dynamically allocated. (as many as needed).
The methods for each protocol family woudl be pointed to in the
domain structure, and the protocol independent versions would look
them up that way and call them..
so the domain structure would include:
struct domain {
[...]
*(struct rtentry *dom_rtalloc)(mumble);
[...]
};
(or whatever the syntax is (I always have to look it up)
in netinet we would declare
struct domain inet_domain = {
[...]
in_rtalloc,
[...]
];
A new function find_domain(family)
makes a method independent way to find the domain structure for
any given PF/AF.
So rtalloc_fib would be:
struct rtentry *
rtalloc_fib( struct route *ro, int fib)
{
struct domain *dp;
dp = find_domain(ro->ro_dst.sa_family)
if (dp)
return (*(dp->dom_rtalloc)(ro, fib));
return (NULL);
}
This all however is not ABI compatible so could not go back to 7.x
and I want to check in an initial version that can go back to 7.x
which sort of suggests to me that adding in_xxx functions is
not really required, until I do the next step.
7.x will never get the next step. because the ABI is already set
in stone for 7.x.
I would make the in_xxx stubs in the next step in 8.x.
after the MFC to 7.x of the ABI compat version.
let me know what you think.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src So after looking at the patch a bit more again, could you add wrapper functions for those like you have done for the old KPI (rtrequest, rtrequest1, ..)? + * For now the protocol indepedent versions are the same as the AF_INET ones + * but this will change.. just #define them at this time. + */ +#definein_rt_getifa(_a, _b)rt_getifa_fib(_a, _b) +#definein_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c) +#definein_rtalloc(_a, _b) rtalloc_fib(_a, _b) +#define in_rtalloc1(_a, _b, _c, _d)rtalloc1_fib(_a, _b, _c, _d) +#definein_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c) +#definein_rtredirect(_a, _b, _c, _d, _e, _f) \ + rtredirect_fib(_a, _b, _c, _d, _e, _f) +#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \ + rtrequest_fib(_a, _b, _c, _d, _e, _f,_g) +#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b, _c, _d) +#define in_rt_check(_a, _b, _c, _d)rt_check_fib(_a, _b, _c, _d) The defines will not give you a stable KPI and having that changed again if you are going with a prefix for each AF would be a pain if the _fib versions are going to change in the future. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, a kernel needs to be created with the option ROUTETABLES=N e.g. +optionsROUTETABLES=2 # max 16. 1 is back compatible. leaving this out will result in just a single routing table as per normal. the max is 16 but I have an artificial (even lower) at 8 but that may be gone by the time people try it :-) After reading through this thread and not looking at the patch again for the moment, where does this limit come from? Do you think this could be extended to more in the future? -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
John Hay wrote: You don't need to go to the kernel for this sort of thing unless you specifically need to implement route policy based on which interface(s) a packet came in on. Yes I know that. But in the world of adhoc wireless mesh networking there are very few non-linux people, so they basically call the shots and use the linux kernel features to the full. Not true. There's an awful lot going on behind closed doors in the MANET world, and from the sounds of the emanations, they might not be using Linux at all. In a sense I can understand them because their stuff also run on the small embedded stuff like the linksys wireless boxes and it needs to scale. The biggest adhoc olsr network is probably the Freifunk one that have more than 600 wireless nodes, mostly consisting of linksys boxes. The complexity of any system like that is still there, regardless of whether or not people choose to make it harder to debug code by prematurely pushing it into the kernel. On some boxes that are also connected to different kinds of networks, they run a different routing daemon into another fib and by setting the priorities on the fibs, they can decide which daemon's routes have the highest priority. And both routing daemons are happy because the other is not stomping on its feet. Yes, but this is largely to do with the fact that the Linux netlink socket allows daemons to coexist due to its use of a tag-length-value which captures that information, a different kettle of fish. The feature you describe is totally possible without adding complexity to Julian's current effort. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Julian Elischer wrote: OLSR is an overlay network Nope -- the express intention was that it could be used for basic IP connectivity, for mobile devices. In OLSR, every node is a potential IP forwarder unless it explicitly advertises itself as being unwilling to forward. and any machine that participated must have a split personality. First it must be able to think in terms of the basic local network, and it must be able to think in terms of the world from the perspective of the overlay. Applying routing policy gets more important at the border. The OLSR implementation in XORP is intended to give people a means of connectivity between MANET and non-MANET routing domains, by redistributing routes into the OLSR cloud. I daresay these capabilities will get more important, and relevant, to the MANET picture as time goes on, but it's best to leave them out of the operational picture for now, in my opinion. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Julian Elischer wrote: John Hay wrote: This confuses me The whole point of a FIB is to decide the *next* hop for a given input packet. So questions. 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? which ever one you select, using the policy of your choice. that's what policy routing is about. if you don't WANT policy based routing, dont turn it on. 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. the packet classifier selects a FIB which in turn implements a particular routing decision tree. In the degenerate case where a FIB has only one route then you are correct, but there are technical reasons why this is superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. no we are going to do the simple thing.. such enhancements can be done later if there is a call for it. We will just have a number of tables that you can associate a packet with at a number of points in its path. having another table as the 'default route' for a table (i.e. if you don't find something look in another table) is something that would be relatively easy to do, but I have not done it.hav Having been prodded to go look up OLSR i an say that this is exactly the kind of thing that multiple routing tables are useful for. OLSR is an overlay network and any machine that participated must have a split personality. First it must be able to think in terms of the basic local network, and it must be able to think in terms of the world from the perspective of the overlay. In this case you would set the overlay interfaces to work with FIB 1 so that packets are transported according to rules defined there and the application packets to the internet would be routed according to FIB 0 which would have entries for the overlay interfaces but not necessarily entries for the actual physical interfaces. (for example) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
John Hay wrote: This confuses me The whole point of a FIB is to decide the *next* hop for a given input packet. So questions. 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? which ever one you select, using the policy of your choice. that's what policy routing is about. if you don't WANT policy based routing, dont turn it on. 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. the packet classifier selects a FIB which in turn implements a particular routing decision tree. In the degenerate case where a FIB has only one route then you are correct, but there are technical reasons why this is superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. no we are going to do the simple thing.. such enhancements can be done later if there is a call for it. We will just have a number of tables that you can associate a packet with at a number of points in its path. having another table as the 'default route' for a table (i.e. if you don't find something look in another table) is something that would be relatively easy to do, but I have not done it. John ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
On Fri, May 02, 2008 at 04:44:20PM +0100, Bruce M. Simpson wrote: > John Hay wrote: > >The linux guys seems to have multiple fibs (or whatever they call them) > >which they can chain together by giving them different priorities. The > >effect seems to be that a packet will be matched through the highest > >priority fib to the lowest until a route match is found en then is used. > >Will something like that be possible? I came across that kind of use > >with the olsr guys. They let olsrd twiddle one of the higher priority > >fibs and then put fallback routes in a lower priority fib. That way > >olsrd can override a route (even the default route) and when olsrd > >exists and deltes all its routes, the original ones are still in the > >lower priority fib and will be used. > > > > XORP already does this without relying on any kernel support. > > Each routing protocol supplies an origin table of its own. The RIB makes > the decision on which route to plumb to the kernel based on > administrative distance. When xorp_olsr exits, its origin table is > removed, and the winning routes are recalculated. > > You don't need to go to the kernel for this sort of thing unless you > specifically need to implement route policy based on which interface(s) > a packet came in on. Yes I know that. But in the world of adhoc wireless mesh networking there are very few non-linux people, so they basically call the shots and use the linux kernel features to the full. To them it is unneeded complexity that the kernel already takes care of. :-/ In a sense I can understand them because their stuff also run on the small embedded stuff like the linksys wireless boxes and it needs to scale. The biggest adhoc olsr network is probably the Freifunk one that have more than 600 wireless nodes, mostly consisting of linksys boxes. On some boxes that are also connected to different kinds of networks, they run a different routing daemon into another fib and by setting the priorities on the fibs, they can decide which daemon's routes have the highest priority. And both routing daemons are happy because the other is not stomping on its feet. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
John Hay wrote: The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. XORP already does this without relying on any kernel support. Each routing protocol supplies an origin table of its own. The RIB makes the decision on which route to plumb to the kernel based on administrative distance. When xorp_olsr exits, its origin table is removed, and the winning routes are recalculated. You don't need to go to the kernel for this sort of thing unless you specifically need to implement route policy based on which interface(s) a packet came in on. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
> >This confuses me > > > >The whole point of a FIB is to decide the *next* hop for a > >given input packet. So questions. > >1) A packet arrives on an interface. If this interface is > > associated with more than one FIB, which FIB does it get > > given to? > > > > which ever one you select, using the policy of your choice. > > that's what policy routing is about. > if you don't WANT policy based routing, dont turn it on. > > > > >2) If that decision is taken by a a packet 'classifier', > > isn't it in effect doing the job of a FIB (deciding the > > next hop, which happens to be a local FIB)? Recall that > > basically a packet passes from a FIB to another FIB until > > it gets to its eventual destination. > > the packet classifier selects a FIB which in turn implements a > particular routing decision tree. > In the degenerate case where a FIB has only one route > then you are correct, but there are technical reasons why this is > superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
> Date: Wed, 30 Apr 2008 10:25:51 -0700 > From: Julian Elischer <[EMAIL PROTECTED]> > > Bruce M Simpson wrote: > > Julian Elischer wrote: > >> 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. > > > > Yes, there is no way the forwarding code alone can do this. > > > > It should not be expected to, and it's important to maintain a clean > > functional separation there, otherwise one ends up in the same quagmire > > which has been plaguing a lot of QoS research projects over the years > > (Where do I put this bit of the system?) > > > >> > >> 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. > > > > Absolutely. This has been the intent from the beginning. > > > > There is no "one size fits all" approach here. We could put a packet > > classifier into the kernel which works just fine for DOCSIS consumer > > distribution networks, but has absolutely no relevance to an ATM > > backbone (these are the two main flavours of access for folk in the UK). > > > >[...] > > >> It > >> IS possible that an interface in the future might have a default > >> plane, but I haven't implemented this. > > > > > This limitation seems fine for now. > [...] > > > > > >For SSM, the key (S,G) > > what's SSM? Source Specific Multicast. It is a scheme for finding the source of a multicast stream without the need for MSDP. It is intended for broadcasting (in the radio/TV sense) streams from a single source. It is not suitable for conferencing as it can't work with multiple sources. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpMdTx2slS7m.pgp Description: PGP signature
Re: multiple routing tables review patch ready for simple testing.
On Wed, 30 Apr 2008 18:56:07 BST "Bruce M. Simpson" <[EMAIL PROTECTED]> wrote: > > 2) If that decision is taken by a a packet 'classifier', > >isn't it in effect doing the job of a FIB (deciding the > >next hop, which happens to be a local FIB)? Recall that > >basically a packet passes from a FIB to another FIB until > >it gets to its eventual destination. > > > > Up until now, the BSD forwarding code always forwarded packets on the > basis of the destination address. > > In an IP environment this is totally reasonable. Most implementations > work on this basis -- ultimately, there is a fan-out to a collection of > tries which hold the prefix information, and there has to be a decision > about which trie(s) to use for resolving the next-hop. Linux iproute2 > works on this basis more or less. > > So the classifier is NOT doing the job of the FIB. Thanks for the explanation! I guess we look at it somewhat differently. You seem to imply that using anything other than destination address is not a FIB's job. While to me a FIB can use anything it wants for its forwarding decision. > > Wouldn't it make sense to treat each alias as on a separate > > logical interface? Then each logical interface belongs to > > exactly one FIB. On input you decide which logical inteface > > a packet arrived on by looking at its destination MAC > > address. That reduces confusion quite a bit, at least in my > > mind! What does doing more than this buy you? > > > > It doesn't buy anything because there is still no 1:1 mapping -- the > link-layer destination address maps to an ifp, and multiple aliases > exist on the ifp. > > You still need a classifier to look at other fields in the message and > decide, based on policy, which FIB is used for next-hop resolution. Hmm... a few years ago when we looked at this stuff in the context of hardware assisted forwarding that used more than just the destination ip address (probably you'd call it "policy based routing"), it was not clear to me at the time whether it made sense to separate such classification. We were looking at a function something like nexthop = lookup(protocol, src addr, dst addr, src port, dst port, ...) I suppose it makes sense to feed everything except the dst addr to a classifier when doing this in software (and may be even hardware but there you have different constraints). For us the entire "forwarding table/classifier" was really just a funky microprogram. That is, each microinstruction ate some bits of a packet and decided which next instruction to fetch and execute. It wasn't clear to me at the time which was better -- should it eat the dst addr first or last. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Bruce M Simpson wrote: Julian Elischer wrote: what's SSM? Source-specific multicast, where multicast flows (channels) are identified by both their original source address, and group address. Multicast addresses have no meaning on their own beyond the scope of a single link. I haven't changed any of that.. Basically I've kept clear of M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) or don;t define it at all in your config then you get what you had before and I shouldn't have broken anything. Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc topologies is Harder. It makes sense to steer clear of it for now. It can no doubt benefit from the hierarchy offered by multiple FIBs, but again, the policy routing mechanisms don't really exist just now, and things like PIM need changes to encompass it. They will need to come into existence for the model to work on a macro scale, for the same reason SSM was put on the table. I take it from this that you don't have any major complaints as far as what I've done. No problems here... I haven't tried testing. please please do.. just apply the patch to a regular source tree and compile.. :-) I would say though if we are going to be renaming rtalloc() and friends, that names should really change to be descriptive of what it does. It doesn't "allocate a route", it tries to look up a forwarding table entry, and returns a reference to it. It's important to not break source compatibility for 3rd party suppliers and users. (e.g. ironport, juniper, nokia, issilon, etc. etc.) they know about rtalloc... having said that I do plan on a pass over the code to rationalise some of the names that may have "evolved" during developement of the patch. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Bruce M. Simpson wrote: Bakul Shah wrote: 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? If you only have a single FIB, there is no issue here. If you have multiple FIBs, the decision gets made by the classifier. 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. Up until now, the BSD forwarding code always forwarded packets on the basis of the destination address. In an IP environment this is totally reasonable. Most implementations work on this basis -- ultimately, there is a fan-out to a collection of tries which hold the prefix information, and there has to be a decision about which trie(s) to use for resolving the next-hop. Linux iproute2 works on this basis more or less. So the classifier is NOT doing the job of the FIB. 3) When a local packets needs to be sent, which FIB gets it? Does setfib decides that? If there a default FIB? If you look at Julian's patch, he's added an option to the socket layer to control this. There is a default FIB which is used when no FIB tag exists. actually this ha changed in the latest code.. now all packets have a fib. as do all sockets and processes. If you do nothing those values are all 0 meaning FIB 0. I believe having to use pf/ipfw will slow things down a bit so the question is what does associating an interface with multiple FIBs buy you? You only need to pass through pf/ipfw if you wish to source-route packets, or need to apply a forwarding policy decision more complex than the destination field, which is all rtalloc() has historically supported. If there is any additional latency or slowdown, it's down to how good your matching algorithms are as you enter the classifier. Wouldn't it make sense to treat each alias as on a separate logical interface? Then each logical interface belongs to exactly one FIB. On input you decide which logical inteface a packet arrived on by looking at its destination MAC address. That reduces confusion quite a bit, at least in my mind! What does doing more than this buy you? It doesn't buy anything because there is still no 1:1 mapping -- the link-layer destination address maps to an ifp, and multiple aliases exist on the ifp. You still need a classifier to look at other fields in the message and decide, based on policy, which FIB is used for next-hop resolution. Tag switching systems avoid the issue by prepending a tag, but of course, what does a packet go through upon entry to an MPLS domain? You guessed it: A classifier. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Bakul Shah wrote: On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]> wrote: 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 confuses me The whole point of a FIB is to decide the *next* hop for a given input packet. So questions. 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? which ever one you select, using the policy of your choice. that's what policy routing is about. if you don't WANT policy based routing, dont turn it on. 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. the packet classifier selects a FIB which in turn implements a particular routing decision tree. In the degenerate case where a FIB has only one route then you are correct, but there are technical reasons why this is superior to just using a fwd rule in the firewall. 3) When a local packets needs to be sent, which FIB gets it? Does setfib decides that? If there a default FIB? the socket has a fib assocuated with it. it is inherrited from the process which has a fib associated with it, which it inherrited from its parent which probbaly used the setfib syscall. A process can also use the setfib socket option to make a socket with a different FIB to its own default fib. 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 believe having to use pf/ipfw will slow things down a bit so the question is what does associating an interface with multiple FIBs buy you? interfaces are not associated with FIBS on input. Just output.. i.e. a FIB knows about an interface or it doesn't. If it doesn't know about it it can't send an packets out that way can it? 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.) Wouldn't it make sense to treat each alias as on a separate logical interface? Then each logical interface belongs to exactly one FIB. On input you decide which logical inteface a packet arrived on by looking at its destination MAC address. That reduces confusion quite a bit, at least in my mind! What does doing more than this buy you? you are talking about vimage (for FreeBSD) or what cisco calls VRF. Stop thinking about receive interfaces... routing is only intersted in OUTGOING interfaces. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Julian Elischer wrote: what's SSM? Source-specific multicast, where multicast flows (channels) are identified by both their original source address, and group address. Multicast addresses have no meaning on their own beyond the scope of a single link. I haven't changed any of that.. Basically I've kept clear of M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) or don;t define it at all in your config then you get what you had before and I shouldn't have broken anything. Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc topologies is Harder. It makes sense to steer clear of it for now. It can no doubt benefit from the hierarchy offered by multiple FIBs, but again, the policy routing mechanisms don't really exist just now, and things like PIM need changes to encompass it. They will need to come into existence for the model to work on a macro scale, for the same reason SSM was put on the table. I take it from this that you don't have any major complaints as far as what I've done. No problems here... I haven't tried testing. I would say though if we are going to be renaming rtalloc() and friends, that names should really change to be descriptive of what it does. It doesn't "allocate a route", it tries to look up a forwarding table entry, and returns a reference to it. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Bruce M. Simpson wrote: Wouldn't it make sense to treat each alias as on a separate logical interface? Then each logical interface belongs to exactly one FIB. On input you decide which logical inteface a packet arrived on by looking at its destination MAC address. That reduces confusion quite a bit, at least in my mind! What does doing more than this buy you? It doesn't buy anything because there is still no 1:1 mapping -- the link-layer destination address maps to an ifp, and multiple aliases exist on the ifp. Let me qualify that further: You are talking about splitting network layer addresses onto their own logical interfaces, with the goal of having a 1:1 mapping for FIB resolution. This doesn't buy anything, because in IP, the previous hop never encodes the next-hop address it sends to -- it merely performs a lookup and forwards to you; your MAC address is the same for every IP address you have on the link, therefore it is not a unique identifier. UNLESS you use a separate MAC address for every IP alias which you add, in which case, you are merely pushing the mapping elsewhere in the stack; it actually adds more complexity in this case. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Bakul Shah wrote: 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? If you only have a single FIB, there is no issue here. If you have multiple FIBs, the decision gets made by the classifier. 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. Up until now, the BSD forwarding code always forwarded packets on the basis of the destination address. In an IP environment this is totally reasonable. Most implementations work on this basis -- ultimately, there is a fan-out to a collection of tries which hold the prefix information, and there has to be a decision about which trie(s) to use for resolving the next-hop. Linux iproute2 works on this basis more or less. So the classifier is NOT doing the job of the FIB. 3) When a local packets needs to be sent, which FIB gets it? Does setfib decides that? If there a default FIB? If you look at Julian's patch, he's added an option to the socket layer to control this. There is a default FIB which is used when no FIB tag exists. I believe having to use pf/ipfw will slow things down a bit so the question is what does associating an interface with multiple FIBs buy you? You only need to pass through pf/ipfw if you wish to source-route packets, or need to apply a forwarding policy decision more complex than the destination field, which is all rtalloc() has historically supported. If there is any additional latency or slowdown, it's down to how good your matching algorithms are as you enter the classifier. Wouldn't it make sense to treat each alias as on a separate logical interface? Then each logical interface belongs to exactly one FIB. On input you decide which logical inteface a packet arrived on by looking at its destination MAC address. That reduces confusion quite a bit, at least in my mind! What does doing more than this buy you? It doesn't buy anything because there is still no 1:1 mapping -- the link-layer destination address maps to an ifp, and multiple aliases exist on the ifp. You still need a classifier to look at other fields in the message and decide, based on policy, which FIB is used for next-hop resolution. Tag switching systems avoid the issue by prepending a tag, but of course, what does a packet go through upon entry to an MPLS domain? You guessed it: A classifier. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]> wrote: > > 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 confuses me The whole point of a FIB is to decide the *next* hop for a given input packet. So questions. 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. 3) When a local packets needs to be sent, which FIB gets it? Does setfib decides that? If there a default FIB? > 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 believe having to use pf/ipfw will slow things down a bit so the question is what does associating an interface with multiple FIBs buy you? > 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.) Wouldn't it make sense to treat each alias as on a separate logical interface? Then each logical interface belongs to exactly one FIB. On input you decide which logical inteface a packet arrived on by looking at its destination MAC address. That reduces confusion quite a bit, at least in my mind! What does doing more than this buy you? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Bruce M Simpson wrote: Julian Elischer wrote: 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. Yes, there is no way the forwarding code alone can do this. It should not be expected to, and it's important to maintain a clean functional separation there, otherwise one ends up in the same quagmire which has been plaguing a lot of QoS research projects over the years (Where do I put this bit of the system?) 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. Absolutely. This has been the intent from the beginning. There is no "one size fits all" approach here. We could put a packet classifier into the kernel which works just fine for DOCSIS consumer distribution networks, but has absolutely no relevance to an ATM backbone (these are the two main flavours of access for folk in the UK). [...] It IS possible that an interface in the future might have a default plane, but I haven't implemented this. This limitation seems fine for now. [...] For SSM, the key (S,G) what's SSM? [...] To summarize: For now, the limitations of the system should be documented so that users don't inadvertently configure local forwarding loops, even for unicast traffic; with multicast, the amplification effect of misconfiguration is inherently more damaging to a network. I'm not sure where I should add documentation. I haven't found the exact right place yet.. I have some notes but I haven't found a good place to put them cheers BMS P.S. I see you tweaked verify_path() to do the lookup in the numbered FIB. Cool. I should point out that for ad-hoc networks, the ability to turn off RPF/uRPF for multicast is needed as the routing domain is often NOT fully converged -- so the RPF checks normally present may discard legitimate traffic which hasn't been forwarded yet. An encapsulation is typically used to maintain forwarding state which is relevant to the particular topology in use. I haven't changed any of that.. Basically I've kept clear of M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) or don;t define it at all in your config then you get what you had before and I shouldn't have broken anything. I take it from this that you don't have any major complaints as far as what I've done. I'd like to get a few people to apply the diff and try it (more than just me for sure), and then I'd like to get it committed soon so that I can move on with it. I would like to get what is there now commited becasue it is a logical break before moving to more work. What is there is fully functional and consistent. and should be tested before more extensive changes occur so that we know where to look if there are problems. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
> Date: Tue, 29 Apr 2008 12:17:15 -0700 > From: Julian Elischer <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > Kevin Oberman wrote: > >> Date: Tue, 29 Apr 2008 00:44:18 -0700 > >> From: Julian Elischer <[EMAIL PROTECTED]> > >> Sender: [EMAIL PROTECTED] > >> > >> The patch can be found at > >> http://www.freebsd.org/~julian/mrt.diff > >> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) > >> > >> or source can be taken from perforce at: > >> //depot/user/julian/routing/src > >> > >> a kernel needs to be created with the option ROUTETABLES=N > >> > >> e.g. > >> +optionsROUTETABLES=2 # max 16. 1 is back > >> compatible. > >> > >> leaving this out will result in just a single routing table as per normal. > >> > >> the max is 16 but I have an artificial (even lower) at 8 but that may > >> be gone by the time people try it :-) > >> > >> I ws informed early in this project that kernel routing tables should > >> now be refered to as FIBs (forwarding Information base?). > >> > >> the new command "setfib" sets teh default fib for a process and all its > >> decendents > > > > I have been working with big routers in my day job for years and it's > > really frustrating to not have this sort of capability when I work with > > FreeBSD, but I don't expect a general purpose OS to ever have the > > routing capabilities of a dedicated router. > > > > I think this will really, really be nice for my needs, though. > > > > As terminology goes, I think you have it slightly off. > > > > Modern routers have two "classes" of tables to move packets between > > interfaces: the RIB Routing information base) and the FIB (Forwarding > > Information Base). A router has multiple RIBs, usually one for each > > network layer protocol (IPv4 and IPv6, both unicast and multicast) and > > added RIBs for policy based routes. They may be further broken up by the > > protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static, > > connected, ...) > > > > The RIBs exports data, as needed to a single FIB which is used by the > > ASICs (hardware forwarding engines) to do the actual forwarding of the > > packets. In a real router, the forwarding of almost all packets is done > > in hardware with no real involvement by the processor that determines the > > routes. (N.B. This is a gross simplification of what modern routers > > do or can do, but I don't want to send a book to the list.) > > > > 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. > > The way I see it the routing daemons (e.g. quagga) have the RIBS > and the kernel has FIBS because it doesn't really know the big picture. > > 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. On further review, I agree with you. The table in the kernel really is a FIB (or a logical equivalent), and not really a RIB, so I withdraw any objection to setfib. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpy7E8KvRlXJ.pgp Description: PGP signature
Re: multiple routing tables review patch ready for simple testing.
> Date: Tue, 29 Apr 2008 00:44:18 -0700 > From: Julian Elischer <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > The patch can be found at > http://www.freebsd.org/~julian/mrt.diff > (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) > > or source can be taken from perforce at: > //depot/user/julian/routing/src > > a kernel needs to be created with the option ROUTETABLES=N > > e.g. > +optionsROUTETABLES=2 # max 16. 1 is back > compatible. > > leaving this out will result in just a single routing table as per normal. > > the max is 16 but I have an artificial (even lower) at 8 but that may > be gone by the time people try it :-) > > I ws informed early in this project that kernel routing tables should > now be refered to as FIBs (forwarding Information base?). > > the new command "setfib" sets teh default fib for a process and all its > decendents I have been working with big routers in my day job for years and it's really frustrating to not have this sort of capability when I work with FreeBSD, but I don't expect a general purpose OS to ever have the routing capabilities of a dedicated router. I think this will really, really be nice for my needs, though. As terminology goes, I think you have it slightly off. Modern routers have two "classes" of tables to move packets between interfaces: the RIB Routing information base) and the FIB (Forwarding Information Base). A router has multiple RIBs, usually one for each network layer protocol (IPv4 and IPv6, both unicast and multicast) and added RIBs for policy based routes. They may be further broken up by the protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static, connected, ...) The RIBs exports data, as needed to a single FIB which is used by the ASICs (hardware forwarding engines) to do the actual forwarding of the packets. In a real router, the forwarding of almost all packets is done in hardware with no real involvement by the processor that determines the routes. (N.B. This is a gross simplification of what modern routers do or can do, but I don't want to send a book to the list.) 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpNlC61DpI7I.pgp Description: PGP signature
Re: multiple routing tables review patch ready for simple testing.
Julian Elischer wrote: 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. Yes, there is no way the forwarding code alone can do this. It should not be expected to, and it's important to maintain a clean functional separation there, otherwise one ends up in the same quagmire which has been plaguing a lot of QoS research projects over the years (Where do I put this bit of the system?) 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. Absolutely. This has been the intent from the beginning. There is no "one size fits all" approach here. We could put a packet classifier into the kernel which works just fine for DOCSIS consumer distribution networks, but has absolutely no relevance to an ATM backbone (these are the two main flavours of access for folk in the UK). 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. This limitation seems fine for now. Users can't be expected to configure the defaults "by default" if they aren't supported, so, if overall the VRF-like feature defaults to off, and there are big flashing bold letters saying "You must fully configure the forwarding plane mappings if you wish to use multiple FIBs", then that's fine by me. 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. In any event, for plain old IP forwarding, a node's endpoint addresses are used only as convenient ways of referring to physical links. To back up and give this some detailed background: For example, 192.0.2.1/24 might be configured on fxp0, and we receive a packet on another interface for 192.0.2.2. When resolving a route, the forwarding code needs to do a lookup to see from where 192.0.2.2 is reachable before the next-hop is resolved in the table. That happens on a per-FIB basis, when the patches are applied -- however the job of tagging input for which FIB is the job of the classifier. The problems with the above approach begin when an input interface resides in multiple virtual FIBs (no 1:1 mapping), or when you can't refer to it by an address (it has no address -- unnumbered point-to-point link, or addresses do not apply), or when you attempt to implement encapsulation (e.g. GRE, IPIP) in the forwarding layer. Then, you're reliant on each individual FIB having resolved next-hops correctly. The existing forwarding code already does some of this by forcing the ifp to be set for any route added to the table. This is done implicitly for routes which transit point-to-point interfaces. BSD has had some weaknesses in this area. It makes implementing things like VRRP particularly difficult, which is why the ifnet approach to CARP was used (the forwarding table gets to see a single ifp); it eliminates a level of possible recursion from that layer of the routing stack. With multicast, for example, next-hops can't be identified by IPv4 addresses alone. Every forwarding decision has potentially more than one result, and links are referred to by physical link (this could be an ifp, an interface index, a name, whatever), and where messages are forwarded is determined using a link-scope protocol such as IGMP. There, it's reasonable to expect that the user partitioned off the multicast forwarding planes into separate virtual FIBs, and that the appropriate rules in the classifier are configured. For SSM, the key (S,G) match has to happen in the input classifier, if one is going to route flows OK using the multiple FIB feature -- the multicast routing daemons have to be aware of it, 'cuz you can't run a separate instance of PIM for every set of flows -- PIM is greedy per-link, a !1:1 mapping problem exists, PIM has no way of telling separate instances apart (no hierarchy in the form of e.g. OSPF areas, and even OSPF won't let you put a link in more than
Re: multiple routing tables review patch ready for simple testing.
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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
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. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Kevin Oberman wrote: Date: Tue, 29 Apr 2008 00:44:18 -0700 From: Julian Elischer <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src a kernel needs to be created with the option ROUTETABLES=N e.g. +optionsROUTETABLES=2 # max 16. 1 is back compatible. leaving this out will result in just a single routing table as per normal. the max is 16 but I have an artificial (even lower) at 8 but that may be gone by the time people try it :-) I ws informed early in this project that kernel routing tables should now be refered to as FIBs (forwarding Information base?). the new command "setfib" sets teh default fib for a process and all its decendents I have been working with big routers in my day job for years and it's really frustrating to not have this sort of capability when I work with FreeBSD, but I don't expect a general purpose OS to ever have the routing capabilities of a dedicated router. I think this will really, really be nice for my needs, though. As terminology goes, I think you have it slightly off. Modern routers have two "classes" of tables to move packets between interfaces: the RIB Routing information base) and the FIB (Forwarding Information Base). A router has multiple RIBs, usually one for each network layer protocol (IPv4 and IPv6, both unicast and multicast) and added RIBs for policy based routes. They may be further broken up by the protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static, connected, ...) The RIBs exports data, as needed to a single FIB which is used by the ASICs (hardware forwarding engines) to do the actual forwarding of the packets. In a real router, the forwarding of almost all packets is done in hardware with no real involvement by the processor that determines the routes. (N.B. This is a gross simplification of what modern routers do or can do, but I don't want to send a book to the list.) 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. The way I see it the routing daemons (e.g. quagga) have the RIBS and the kernel has FIBS because it doesn't really know the big picture. 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. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
