[rbridge] Max Network size

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Guillermo Ibáñez wrote:
> Guillermo Ibáñez wrote:
> 
> Joe Touch wrote:
> 
> 
>>Guillermo Ibáñez wrote:
>>...
>> 
>>
>>
>>>I agree with your view, except about ARP. 
>>>Is there any estimation on the ARP load expected on Rbridges as ARP 
>>>proxies and hosts in general (ARPs unsolved by proxies)?
>>>I wonder whether the Rbridges are the most suited devices to handle many 
>>>ARP requests. For big networks like this it might be worth to consider 
>>>the use of separate ARP servers distributed over the subnetwork instead 
>>>of ARP proxies at Rbridges.
>>>   
>>>
>>
>>I am anticipating that RBridges should handle ARPs via broadcast as a
>>default; we're looking into proxy-ARP based on knowledge of ingress
>>locations, to reduce ARP load. That solution would need to be fault
>>tolerant to loss of the proxy mechanism, whether distributed or at a server.
>>
>>Joe
>>
>> 
>>
> 
> Right. Default must always be ARP broadcast.  I understand that in this 
> case the frame is not encapsulated,  just forwarded by Rbridge.

All packets arriving at an egress are always encapsulated, including
ARPs. The only non-encapsulated packets inside an RBridge campus would
be RBridge control traffic, e.g., routing protocols and encapsulation
table setup.

>  ARP load is somewhat reduced in the core  by diffusing ARP to Rbridges 
> via a specific multicast address iso broadcast address . But still the 
> cost of local ARPs issued by each Rbridge at the ends may be significative.

Sure - ARPs not only flood the RBridge campus, but also the stubs that
attach. But that's a property of all L2 networks; broadcasts broadcast.

> I wonder if an ARP server/registrar approach can be foreseen as an 
> alternative or complementary strategy.  The Designated Rbridge registers 
> each host, when an ARP is received, at a (distributed) ARP server.

When an ARP reply is received, that can be done. But the first ARP to an
otherwise unknown host, which has silently attached to a stub at an
RBridge ingress, is unknown. The only way to find it is to flood.

> This 
> can help to enforce security (like preventing MAC spoofing) and  also 
> ensure ARP resolution in one step without broadcast. 

Correct the above if not correct, but assuming that there is no way to
secure ARP that doesn't modify ARP too.

> The point is to 
> distribute the load of ARP registry and queries between multiple ARP 
> servers. This may be based on IP hashing.

Sure, hashing will direct you to the right cache. But how does that
cache know what to reply? It can't unless IT floods; that's the catch-22.

Joe

> Regards
> Guillermo
> 
> 
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe5ChE5f5cImnZrsRAhYCAKCTK+bm/VtZ/7yGtU4Qi12pEC8B0QCfSJv0
Iv1gD4eJ7OyDsvTkRCB/ZXg=
=DzCO
-----END PGP SIGNATURE-----