Cisco ACI – a Stretched Fabric That Actually Works
In mid-February a blog post on Cisco’s web site announced stretched ACI fabric (bonus points for not using marketing grammar but talking about a shipping product). Will it work better than other PowerPoint-based fabrics? You bet!
What’s the Big Deal?
Cisco’s ACI fabric uses distributed (per-switch) control plane with APIC controllers providing fabric configuration and management functionality. In that respect, the ACI fabric is no different from any other routed network, and we know that those work well in distributed environments.
But What about Stretched Subnets?
Even though you can use Cisco ACI to implement stretched subnets (and there was the mandatory mention of VM mobility in Cisco’s documentation), the fabric uses VXLAN-over-IP as the transport protocol, making the underlying transport network rock-solid. You cannot get a L2 forwarding loop in a pure L3 network.
Stretched subnets are as great idea as they ever were (there’s nothing you can do to fix a broken concept), but ACI’s handling of stretched subnets is better than almost anything else out there (including OTV).
ACI uses ARP proxies and anycast gateways on leaf switches, and something equivalent to VRF-based host routing to forward traffic toward IP endpoints. The traffic transported across the fabric is thus mostly unicast IP traffic (admittedly encapsulated in VXLAN envelopes), and we know that IP-based networks got pretty good at handling unicast IP traffic.
But There’s Split Brain Problem
True – and Cisco was quick to admit the problem exists (many vendors try to pretend you don’t have a problem because the redundant links between sites can never fail) and documented the split fabric scenario in their design guidelines:
- Controller cluster is split, and the minority part of the cluster goes into read-only mode;
- The fabric continues to forward traffic based on already-established policy rules;
- Leaf switches can detect new endpoints (assuming they’re covered with existing policy rules) and report them to the spine switches – both isolated fabrics thus continue to operate normally even under edge or core topology changes.
More Information
Start with Cisco ACI videos from NFD8 and NFD9, then watch the Multi-Pod and Multi-Site Fabrics part of the Leaf-and-Spine Fabric Architectures webinar, and the Cisco ACI Deep Dive webinar.
Disclosure: Cisco Systems was indirectly covering some of the costs of my attendance at the Network Field Day 9 event.
You'll probably be interested by the Lippis report about ACI: http://lippisreport.com/2015/03/lippis-report-223-an-open-approach-to-network-automation/
Unless I'm misunderstanding the current limitations, but the designs I've seen always show another device on a stick acting as a way to route between VXLANs.
The QFX5100 uses just the Trident II -- which is "known" (for varying values of "known") to NOT support VXLAN routing. The N9K leverages both the Trident II, as well as custom Cisco silicon -- the latter being specifically able to handle VXLAN routing.
That VXLAN routing leaf stick is required in standalone(nxos) mode if you are runing older nxos code. However, with new VXLAN-EVPN/Anycast-GW feature in code 7, you don't need that stick any more.
- the VM MAC/IP addresses are distributed in the fabric (and even inter-fabric), meaning that all leaf switches can proxy ARP
- the VM mobility is transparently supported
- now, "Nexus 9300 switches with the ALE ASIC offer the capability to route VXLAN overlay traffic at the leaf, unlike traditional Broadcom Trident II based platforms, which cannot VXLAN route the packet".
EVPN not supported in ACI mode yet. Expect support for EVPN in Q4
BTW up until now we really like ACI.
I just setup our second ACI pod.
Trident II can route VXLAN packets it requires a re-circulation the same as the Nexus 9300 which uses the NorthStar ASIC for the re-circ.
This was done with all GA code from Cisco.
https://www.youtube.com/watch?v=RLkryVvzFM0