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