Cisco ACI 5.2 - 15.2 DESIGN OPTIONS
Victor Mahdal
Manager / Team Lead / Network Cloud DC DevOps Engineer / Solution Architect
CISCO ACI 5.2 - DESIGN OPTIONS
Cisco ACI 5.2 brings us several features that might impact the design of ACI fabrics going forward.
Back to back Spines for multipod
As of ACI 5.2(3) we’re able to directly connect the Spines together, somewhat similar as the 2-site multi-site design.
This means we can get rid of the IPN switches going forward for new customers.
This will save a significant amount of money in these projects. This design is limited to two pods. If you need three pods, remote physical leafs or anything else that would require an IPN you can’t do back to back multi-pod. You can’t combine an IPN and a back to back multipod design.
As for the design it is recommended to create a full mesh of connections between the two pods as can be seen in the image below. However, this is not a hard requirement. You can do a square design when you’re constrained in the amount of fiber you have available between the locations. My advice would be to do a full mesh between the two pods if possible.
Please note that when I say full mesh I mean between the two pods and not within a pod. Spines in Pod1 do not connect to each other, same goes for Pod 2.
Something you might wonder about is whether it is possible to upgrade from a back to back design to a full IPN design. For example when you do get a third pod. The answer is yes. You can upgrade to a full IPN design. This does require a change window as the upgrade won’t be without downtime. You can also remove an existing IPN network in favor of the back to back design. To be fair I would not recommend you to do that if you already have an IPN. However, if your IPN is end of support or something you could consider moving to a back to back design to save money instead of buying new IPN switches.
BGP support for the IPN
If you still need an IPN for your environment, but you don’t want to use OSPF you can now use BGP for your IPN connections. You do need to use eBGP. iBGP is not supported in this design.
Aside from another routing protocol the IPN will remain the same here, so I don’t really have anything to add here.
Peer link between remote physical leafs
It appears that the theme for ACI 5.2 is connecting similar devices to each other. We’ve learned that we’re not allowed to connect spines directly to each other, which we can now do in a back-to-back multi-pod. And we’ve learned that we’re not allowed to connect leaf switches to each other. That, however, is exactly what we can do for remote physical leafs as of version 5.2.
By connecting remote physical leafs to each other we’re not dependent on the IPN switch anymore for traffic between orphaned ports on a single remote leaf pair. That way the availability is improved.
The image below shows the traffic flow between twp endpoints connected to remote leafs before ACI 5.2 and after 5.2
领英推荐
Remote APIC cluster
As of ACI 5.2 it is possible to manage an ACI fabric while the APIC cluster is not physically connected to it.?This way you can place your APIC cluster somewhere else. As far as I’ve been able to determine it still is not possible to use a APIC cluster to manage multiple ACI fabrics, so there is still a one-to-one relationship between APIC cluster and ACI fabric.
Furthermore this feature is only possible for greenfield fabrics. That means that you can’t up and move your existing APIC cluster for your existing ACI fabric to somewhere else. The APICs will be connected via an L3 network (IPN) to the Spine switches in this case.
Additional features
Endpoint learning toggle per subnet
Where we could disable endpoint learning for a full VRF or a single IP in prior versions of ACI, we can now disable it for a subnet. This gives us more flexibility in the configuration of endpoint learning. This is especially useful in subnets that are used for loadbalancers or active/active failover clusters.
PBR improvements
There is a list of PBR improvements in ACI 5.2:
This enables us to configure a PBR target without manually configuring its MAC address. Regular ARP will be used to resolve the MAC address belonging to the device. Especially in failover clusters this eases configuration.
We can now deploy PBR service graphs directly within an L3out
You can now use HTTP URI’s to track the availability of a service node in a PBR.
Another thing to note which is not really PBR, but service graph related is end of support for device packages. I don’t think anybody ever really used them, but if you do, keep that in mind before upgrading to 5.2.
Security features
Aside from the above features there are also some additional security features included in 5.2:
Please find more info at?Cisco ACI page