Re: resend: multiple routing table roadmap (format fix)

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.

--
Andre

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: resend: multiple routing table roadmap (format fix)
    ... 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. ... As regards getting ARP out of forwarding tables, this should have happened a long time ago... ... Surely, routing table should contain a cached pointer to an entry in L2 table, to not do double lookups. ...
    (freebsd-arch)
  • Re: resend: multiple routing table roadmap (format fix)
    ... 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. ... As regards getting ARP out of forwarding tables, this should have happened a long time ago... ... Surely, routing table should contain a cached pointer to an entry in L2 table, to not do double lookups. ...
    (freebsd-net)
  • Re: resend: multiple routing table roadmap (format fix)
    ... 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. ... As regards getting ARP out of forwarding tables, this should have happened a long time ago... ...
    (freebsd-arch)
  • Re: resend: multiple routing table roadmap (format fix)
    ... 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. ... As regards getting ARP out of forwarding tables, this should have happened a long time ago... ...
    (freebsd-net)
  • Re: understand multicasting from the client/host perspective .
    ... multicast group. ... If the multicast mac is ... separate ARP mapping for each host involved. ... And you can't have an ARP ...
    (comp.dcom.sys.cisco)