[rbridge] it's time to summarize things

[Joe Touch]

There are two ARP issues to be considered:

Proxy ARP, no - i.e., there should be no point at which an rbridge
preemptively replies to an incoming ARP with an ARP reply with its own
MAC address. Rbridge MAC addresses should never appear in external node
(host/router) ARP tables.

The optimization we discussed is based on snooping and reply via replay,
which could be called ARP Replay, i.e., to emit the ARP that the rbridge
thinks will be emitted from the ultimate destination, rather than to
broadcast the ARP throughout in search of that host. There are issues
with that procedure - notably, when nodes silently renumber, where that
replayed reply could be in error, which need to be considered, but
that's a later discussion.

I'm not aware ARP Replay being called Proxy ARP - is anyone else? Is
there a better name than ARP Replay?

Joe

Guillermo Ibáñez wrote:
> ARP Proxying by the Designated Rbridge was considered an acceptable 
> optimization,  right?
> GI
> Joe Touch wrote:
> 
>> Guillermo Ibáñez wrote:
>>  
>>
>>>> My understanding was that Rbridges would do ARP proxying and would 
>>>> forward ARP requests to other Rbridges. Am I still right?.
>>>>      
>>>>
>> Not proxying; they forward ARPs like all other L2 traffic. They don't
>> generate ARPs directed at their own L2 addresses in response to seeing
>> other ARPs (proxying).
>>
>> Joe
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://www.postel.org/mailman/listinfo/rbridge
>>  
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051216/304cfbe7/signature.bin