aci multisite intrasubnet unicast across sites steps

14.01 2020 | by massimiliano

---

aci multisite intrasubnet unicast across sites   1) First requirement before intrasubnet communication across sites can be achieved is to […]

aci multisite intrasubnet unicast across sites

 

1)

First requirement before intrasubnet communication across sites can be achieved is to complete the ARP exchange between source and destination endpoints

 

1a)

the endpoints are part of a bridge domain stretched across sites with BUM flooding enabled; the ARP request will reach the destination endpoints in remote sites, which will allow the remote leaf nodes to learn the site location of the source endpoint

 

1b)

as a consequence, the ARP unicast reply will be directly VXLAN encapsulated to the DP-ETEP address identifying the EP1 site, and one of the receiving spine nodes will perform the VNID and class-ID translation and send the frame toward the local leaf node to which EP1 is connected

 

1d)

the bridge domain associated with the IP subnet is stretched across sites with flooding disabled; the ARP broadcast requests cannot be flooded across sites, so you must be sure that they are encapsulated in the VXLAN unicast packet

 

 

STEPS:

 

2)

EP1 generates an ARP request for the EP2 IP address;

 

3)

the local leaf node inspects the ARP payload and determines the IP address of the target EP2. Assuming that no communication with EP2 has been initiated yet from the local leaf, EP2 is unknown, so the ARP request is encapsulated and sent toward the Proxy A anycast VTEP address;

 

4)

one of the local spine nodes receives the packet; it may not necessarily be one of the spine nodes connected to the intersite network, because the proxy VTEP function is enabled on all the local spine nodes.

In any case, the same information about remote endpoints is synchronized in the COOP database of all the local spine nodes; as a consequence, the receiving spine nodes knows the remote DP-ETEP address identifying the site to which EP2 is connected and can encapsulate the packet and send it internally to the site to be able to reach one of the local spine nodes connected to the intersite network;

 

5)

the receiving local spine node rewrites the source VTEP address as the local DP-ETEP A and sends the packet to the intersite network; operation is very important, because only the CP-ETEP and DP-ETEP addresses of the spine nodes should be seen in the external IP network;

 

6)

the VXLAN frame is received by one of the remote spine nodes, which translates the original VNID and class-ID values to locally significant ones and encapsulates the ARP request and sends it toward the local leaf nodes to which EP2 is connected;

 

7)

the leaf node receives the frame, decapsulates it, and learns the class-ID and site location information for remote endpoint EP1;

 

8)

the frame is then flooded to the local interfaces that are part of the bridge domain associated with the VNID and reaches EP2;

 

9) EP2 can reply with a unicast ARP response that is delivered to EP1 with the same sequence of steps (the only difference is that flooding is not enabled across sites);

 

 

STEPS from policies point of view:

 

 

10)

EP1 and EP2 are in the same EPG and bridge domain, and no microsegmentation is configured (and the EPG is not configured as isolated): In this case, no policy is applied, and EP1 can freely communicate with EP2

 

11)

EP1 and EP2 are in the same base EPG and bridge domain but associated with two micro-EPGs with a specific contract between them: In this case, at steady state the policy is always applied at ingress on the source leaf node

 

12)

EP1 and EP2 are in two different EPGs that are part of the same bridge domain: In this case, communication is dictated by the contract defined between them, and as in the previous case, at steady state the policy is always applied at ingress on the source leaf node