Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 07 Jan 2008 03:03:11 +0600
From:      "Vadim Goncharov" <vadim_nuclight@mail.ru>
To:        "Julian Elischer" <julian@elischer.org>, "Bruce M. Simpson" <bms@freebsd.org>
Cc:        arch@freebsd.org, Qing Li <qingli@freebsd.org>, Ivo Vachkov <ivo.vachkov@gmail.com>, Robert Watson <rwatson@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: resend: multiple routing table roadmap (format fix)
Message-ID:  <opt4i0rlz317d6mn@nuclight.avtf.net>
In-Reply-To: <4781197F.1000105@elischer.org>
References:  <4772F123.5030303@elischer.org>	<f85d6aa70712261728h331eadb8p205d350dc7fb7f4c@mail.gmail.com>	<477416CC.4090906@elischer.org>	<opt4c0imk24fjv08@nuclight.avtf.net>	<477D2EF3.2060909@elischer.org> <opt4g4kcis17d6mn@nuclight.avtf.net> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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...

-- 
WBR, Vadim Goncharov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opt4i0rlz317d6mn>