Multipod Layer 2 EPG Extension

[packet2020]

Hi All,

I am currently planning a migration from a legacy network to ACI and I have a question about how this can be achieved in a two data centre Multipod scenario.

We have two data centers with legacy switches that provide connectivity to various servers. The legacy switches are interconnected between data centres using a simple Layer 2 trunk.

We are implementing ACI Multipod across both data centres. The migration of servers to ACI which will be based on a common Layer 2 and then Layer 3 approach. The plan is the connect a pair of leaf switches in each pod to the legacy switches using VPCs, replicate the existing VLANs in ACI using a Network Centric Approach (1 VLAN = 1 BD + 1 EPG), and to then extend these VLANs to the legacy switches using EPG extensions using the existing VLAN IDs. In doing this, I'm concerned that I will either create a loop, or one of the VPCs will be spanning-tree blocked resulting in an inefficient Layer 2 path between sites. 

When extending a BD/EPG to the legacy data centre networks in this scenario, is the correct approach to then remove the associated VLAN from the legacy data centre interconnect to remove the redundant path thus preventing any loops? In doing this, can hosts that are associated to this VLAN that sit outside of the ACI fabric still communicate via the ACI IPN?

See below diagrams. There a a number of guides and whitepapers that detail migration options in a single data centre/single ACI pod scenario, but nothing that clearly details the above.

[Robert Burns]

The L2 interconnect (bewteen legacy switches) should be removed, thus eliminated any potential loop.  ACI does not participaite in STP, but it will FWD STP BPDUs, so if you had that L2 link between legacy, you certainly would expect some of those links to go into blocking state.  
With your only path available through ACI's IPN, each Pod would be able to reach the resources in the other Pod - including any hosts behind those legacy L2 Switches.  You would need to ensure the corresponding BDs are set for Flood mode for unknown unicast. 

What some customers might do, is configure an L3 link outside of the IPN, but understand that ACI will always prefer the IPN path over the external L3 connection for directly connected hosts.  For hosts a hope away from ACI, basic L3 cost pathing would apply.  

Robert

[packet2020]

Hi @Robert Burns 

Thank you for taking the time to reply. With what you stated above, does this also include the ability for hosts behind the L2 switches in each data centre to directly communicate via the IPN as per my second diagram? So in effect, the ACI IPN replaces the behavior of the legacy interconnect? Apologies if this is what you meant, I just wanted to confirm.

As you say, I plan to enable the required BDs to flood unknown unicast, however I'm not sure of the flooding behavior and if ACI will permit the above traffic flow.

[Robert Burns · Accepted solution]

Yes, as long as the EPG/VLAN is extended from both Pods to the Legacy networks, any hosts within them can reach the other side including those hosts directly connected, as well as those an L2 hop away.

Robert

[JackRiley]

Hi Rpbert, You mentioned removing the links between the external switches to ACI to prevent loops. I'm currently trying to enable L2 comms with an external gateway that is configured on an SWV pair of 4500s. If i add a port channel from each pod to the 4500, i will introduce that loop and one of the port channels will go into blocking anyway.

When there is a Single upstream logical switch will enabling unknown unicast flooding allow me to travers the IPN to discover the default gateway on the external Switch for an L2 EPG in the non-directly-connected pod?

Flow would have to be Pod2 > Pod1 > via portchannel > External Switch gateway. 

Portchannel is to Pod 1 and there is currently no port channel between Pod2 and the external switching. 

Hopefully this makes sense.

Thanks 

J