Cisco Accelerates SDN Strategy with Dynamic Fabric Automation
Cisco's Dynamic Fabric Automation integrates legacy physical networks with virtual devices. It's a sensible SDN strategy for a networking incumbent, but customers should wait until we know more about Insieme.
July 2, 2013
Note: The original version of this article indicated that VXLAN was used for tunnelling. As per Cisco's remarks in the comments section, Cisco is using a proprietary tagging encapsulation protocol. The article has been updated for accuracy and to express the author's views about proprietary protocols.
Cisco Systems' SDN strategy is taking shape via its announcement of Dynamic Fabric Automation. DFA is a data center fabric that uses an overlay network to provide orchestration, multitenancy and operational visibility. VMware, Juniper and Alcatel's Nuage also offer network overlays, but DFA has one significant difference: hardware integration in the physical network devices to support bare-metal servers or other physical devices.
DFA is orchestration software using a software network controller to manage a tunneling overlay network using a proprietary 24-bit tag in the Ethernet header to signal tunnel membership over the FabricPath-based fabric to an endpoint.
Cisco recommends using Nexus gear deployed in a Spine-and-Leaf configuration, though it's not required. This appears to be a workaround for the lack of entropy in the Ethernet header, which would cause poor load balancing in MLAG network designs common in today's networks.
Announced at Cisco Live in Orlando Florida, this is the first demonstration of Cisco's SDN strategy, which Cisco is calling "Application-Centric Infrastructure."
Tunnel Management
DFA uses Cisco's Data Center Network Manager (DCNM) as a network controller for the tunnel overlay and manages all the physical and software devices in the Unified Fabric as a distributed control plane. Note that Cisco disagrees with the use of the term "controller" to describe the DCNM. It calls it a Centralized Point of Management (CPoM). Cisco's reasoning is described in the comments section.
(click image for larger view)
DFA Architecture
Source: Greg Ferro
DFA works at the device level through an existing feature in NX-OS called Configuration Port Profiles. The DFA controller applies port profiles to logical ports in the Nexus 1000V switch on hypervisor platforms and to the physical leaf-node switches. In this way, both physical and virtual devices can connect using an overlay network.
[For more on port profiles on the Nexus platform, see "How To Configure Cisco Nexus 5500 Port Profiles."]
This control of the network edge, plus integration with cloud platforms such as OpenStack, provides the control for multitenant data centers. DFA enables multitenancy through the underlay network by managing all device configuration and by the use of proprietary overlay networking to isolate traffic.
The DCNM knows the location of endpoints and can graphically display the network slice of each tenant in the architecture, which simplifies troubleshooting and improves network visibility.
Cisco uses the misnomer of "Workload Aware Fabric Network" for this feature. The term implies that the network is adaptively handling traffic flows. In reality, the network controller knows the locations of servers and the network devices that are in the path.
The unified fabric is configured to support a distributed gateway where all leaf nodes share the gateway IP and MAC address for a given subnet. This enables transparent layer-2 functions across all the leaf nodes while also providing layer-3 routing at the network edge.
ARP traffic is terminated on each leaf and BUM traffic is significantly suppressed. Internally, the underlay uses /32 routing for each host to support dynamic L2 mobility at the edge of the network.
(click image for larger view)
DFA Endpoints
Source: Greg Ferro
It's not clear which specific Nexus devices support DFA today. As mentioned, Cisco recommends a Leaf/Spine design using an ECMP network core (FabricPath) between the spine and leaf nodes, which is only supported on specific switch models. DFA also uses iBGP to propagate some configuration data between elements of the tunnel fabric (although it's not yet clear what exactly this data is).
Cisco Plays To Its Strengths
It has been clear for some time that Cisco has not been leading Software Defined Networking technology and, to some extent, lost control of the SDN debate. It's trying to get it back. Cisco has started using a marketing term "Application-Centric Infrastructure" instead of "Software Defined Networking" and that message was consistently repeated at Cisco Live.
With DFA, Cisco is the only vendor today with a strategy to orchestrate physical tunnelling functions in network hardware (albeit with a proprietary mechanism with poor interoperability) with software network agents such as the Nexus 1000V.
This allows the deployment of overlay networks that connect both virtualized platforms such as OpenStack or VMware to non-virtualized devices and servers. Instead of supporting virtual workloads in a cloud platform like vCloud or OpenStack, Cisco can support any workload, anywhere.
This embracing of non-cloud systems will be attractive to many customers and attacks a weakness in existing software overlays such as Nicira, Contrail and Nuage that don't provide support for legacy network integration.
DFA looks to be a strong product that certainly meets customer needs, goes beyond competitive products and plays to Cisco's strengths integrating the physical and virtual networks.
Unfortunately, the choice of a non-standard and proprietary encapsulation is a significant drawback. While some customers may not be concerned about the use of proprietary technology, I recommend DFA be avoided because of it.
It's also clear that Cisco is betting a great deal on its Insieme project, which may offer a better solution for similar use cases. Cisco did not clearly explain Insieme at Cisco Live, so customers will have to wait for more information before making concrete plans.
About the Author
You May Also Like