multiple routing tables review patch ready for simple testing.
Bruce M. Simpson
bms at FreeBSD.org
Wed Apr 30 17:56:10 UTC 2008
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.
More information about the freebsd-net