[rbridge] Max Network size
touch at ISI.EDU
Fri May 6 08:43:29 PDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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
> 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.
> 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.
>>rbridge mailing list
>>rbridge at postel.org
> rbridge mailing list
> rbridge at postel.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rbridge