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