[rbridge] Shared VLAN learning: What is it and why should we care?

[J. R. Rivers]

More importantly is that sometimes R does reply to local ARPs and
sometimes it doesn't... as part of system vendor feature definitions.
Generally, I've always thought of ARP as a router/host function.  As the
lines blur between routers and switches, there have been many features
introduced into "switches" based on router functionality.

I'd argue that this is one great reason to leave ARP out of TRILL so
that any of these extensions can continue to work based on their
expectations of the underlying L2 network.

JR



> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler
> Sent: Monday, April 02, 2007 11:21 AM
> To: Radia Perlman
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> 
> Radia Perlman wrote:
> 
> > 
> > My question was -- how does R know *not* to respond to the
> > ARP? Or does sometimes R wind up forwarding between endnodes
> > in the same VLAN unnecessarily and we don't care because it's
> > not *incorrect*, it's just suboptimal?
> > 
> 
> I'm not sure what the relevant specs are, but my understanding
> has always been that a Proxy ARP only answers an ARP request
> if it is somehow between the requester and the machine it
> is proxying for.
> 
> My direct experience with this all relates to Cable Modems,
> so I haven't thought about corner cases where the "between"
> status might not be blatantly obvious. And in that case 
> flooding irrelevant packets from every home network upstream
> was not "suboptimal", it would have been a network killer.
> So luckily the distinction between the home network and
> the cable network was easily made.
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>