[rbridge] Max Network size

[Guillermo Ibáñez]

Guillermo Ibáñez wrote:

Joe Touch wrote:

>-----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.
>
>  
>
True. But this is the only case.

>>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.
>  
>
ARP query would be performed by the Designated Router (encapsulated 
query directed to the ARP server). I am not expert, but I guess the 
server can autenticate the DRs. I agree that a host may spoof  its MAC 
but security measures are possible both at the ARP server (the spoofed 
host is registered in same server) and at the DR (attacks and  behaviour 
will likely concentrate on a certain port of  DR)   

>  
>
>>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
>
>  
>
The caché knows the content because it is the unique both server and 
registrar for the IP addresses set. Prior to that query, upon first ARP 
issued  the host was registered by the DR at that caché, based on its 
hash(IP) . An ARP cache query from host would produce from DR two 
packets : a registration of originating host at ARP registrar and an ARP 
query of destination host at ARP server. 
Regards
Guillermo

>>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-----
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>