IETF doc proposes fix to stop descent into data centre 'address hell'

Proxy those MACs if you want manageable address tables, suggest Marvell and Huawei

Address tables in data centres can fill up really quickly, so researchers from Huawei and Marvell have offered up a proposal to make them smaller.

The purely-experimental RFC 7586 suggests that all hosts – including VMs – in an access domain be addressed through a proxy.

The problem the RFC looks at is how to get data from one VM to another, when the subnet the two machines are on span multiple L2/L3 boundaries.

As the RFC points out, if a VLAN or subnet has lots of hosts spanning different locations, and each access domain (for example different data centres) has hosts belonging to different VLANs, the address tables get very big, very fast.

Its example is an access switch with 40 physical servers, 100 VMs per server, 4,000 attached MAC addresses, and 200 hosts per VLAN, “this access switch's MAC address table potentially has 200 * 4,000 = 800,000 entries.”

Instead, the RFC proposes a Scalable Address Resolution Protocol (SARP), in which a SARP proxy sits in front of the access switch:

Even if they're on the same VLAN, hosts on either side of the boundary would use the SARP proxy's address rather than the host address. From the RFC:

SARP ascii art

IETF, last home of ASCII art - illustrating SARP

“The main idea of SARP is to represent all VMs (or hosts) under each access domain by the MAC address of their corresponding access node (or aggregation node). For example (Figure 1), when host A in the west site needs to communicate with host B, which is on the same VLAN but connected to a different access domain (east site), SARP requires host A to use the MAC address of SARP proxy 2, rather than the address of host B.”

That lets switches in each access domain stick to recording only those MAC addresses in its own domain, and the addresses of remote SARP domains.

The authors reckon the advantage of this is that the swtiches' filtering database (FDB) size is constrained no matter how many different data centres a VLAN might span.

The Register's networking desk will keenly watch the comments on this one, to see whether readers reckon it's workable. ®




Biting the hand that feeds IT © 1998–2018