07.01.08 @ 03:41 Andre Oppermann wrote:
Vadim Goncharov wrote:
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops
only. In multicast, next-hops are normally just interfaces.
Also the IETF MANET ad-hoc IP is going to need hooks there;
multicast in MANET needs to address its next-hops by their unicast
address, and encapsulate the traffic with a header. This is not true
link layer multicast -- although it might use link layer multicast to
leverage the hash filters in 802.11 MACs.
As regards getting ARP out of forwarding tables, this should have
happened a long time ago...
I'm not 100 % convinced of this...
I was, but I think there may still be a place for a cached arp pointer
in hte next hop route to the arp entry for that next hop.
I DO however thing that the arp stuff should nto be accessing its
data via the routing table.
Surely, routing table should contain a cached pointer to an entry in
L2 table (ARP in case of Ethernet), to not do double lookups. But still
separate those tables...
Locking hell over again. How do you remove an ARP entry without doing
a full walk over the entire routing table (some 250K entries for the
DFZ)? Make it rmlocks and be done with it.
Why a full walk, why such a dumb way? To remove an ARP entry for host
A.B.C.D in L2 table of form (A.B.C.D -> 00:01:02:03:04:05), it is enough
to do a (usual speed) routing lookup for host A.B.C.D and modify a one
pointer in it's rtentry to NULL or remove rtentry (if it's selected to be
implemented as cloned). Thus, when on regular forwarding (table read) a
routing lookup is done, we already have a FAST access - one pointer
dereference - for it's L2 table entry, be it ARP or any other L2 type
(which support becoming easily with separation of L2 and L3). And on every
modification of L2 table - which is RARE - do lookup with usual speed to
modify cached pointer. Compare it with a scheme where for EVERY forwarded
packet, there is a need for DOUBLE lookup - after a routing one, do
another in L2 table.
Current routing table implementation, with all disadvantages of combining
L2 and L3, have from the same combinig a one HUGE benefit - performance.
And never, ever, ever, ever even try to split L2 from L3 with losing that
performance - then it should be still never split, despite all
disadvantages, and you'll become an enemy of many, many users. Especially
while caching allows to do things reasonably fast.
--
WBR, Vadim Goncharov
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
