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]"
