It’s time to talk (briefly!) about how NSX, DFA, and ACI handle Security. This blog series has already covered ARP, L2 forwarding and L3 forwarding, complete with many technical details. I’m hoping this blog will be a bit shorter, making easier on me doing the writing and you the reader. I intend to focus on where there’s something interesting to cover.
(Source: Wikipedia. Public domain.)
Prior blogs in this series:
- Practical SDN: L3 Forwarding in NSX, DFA, and ACI
- Practical SDN: L2 Forwarding in NSX, DFA, and ACI
- Practical SDN: NSX, DFA, and ACI, The All-Seeing Eye. See this first blog for a general disclaimer.
News!
Cisco seems to be adding content to the DFA page. Check out either http://www.cisco.com/go/dfa or its long form, http://www.cisco.com/en/US/solutions/ns340/ns517/ns224/ns945/dynamic_fabric_automation.html.
What’s new since the last time I looked is new Overview prose and the Product Support tab. The Product Support tab seems to be a bit of a work in progress, as some of the links go to rather stubby (unfinished) documents. Be that as it may, it’s great to see information and details starting to appear!
The Supported Software Releases document is quite useful, and answers some of my questions around device support and components of DFA. Cisco 7K, 6K, 55xx, and 1000v software releases and roles (Spine, Leaf, L2-only Leaf) are spelled out in this document. Good reading!
On another front, Cisco has announced A10 and Catbird as ACI partners. A10 for ADC/SLB, and Catbird for security.
Drilling Down on DFA
The graphics in DFA slideware have shown several platforms, and I have had some high level questions as to what each software package does for DFA.
DCNM 7.0(1) will manage the Spine-Leaf fabric, and use Prime NSC to control the 1000v switch(es). DCNM is sometimes referred to in DFA as the CPOM, the Central Point of Management.
Cisco Prime Network Services Controller 3.2 manages 1000v, VSG, Intercloud, ASA 1000v, CSR 1000v, VPX (NetScaler) — basically, the Cisco virtualized and cloud suite of products. The 3.2 release recently became available. For new features, see http://www.cisco.com/en/US/docs/net_mgmt/prime/network_services_controller/3.2/release-notes/Cisco_Prime_Network_Services_Controller_32_RelNotes.pdf
OpenStack for Cisco DFA 1.0 is in there for orchestration of virtaul workloads. It appears that at some point other platforms may also perform this role. Details are thin so far.
All this reinforces my impression: DFA is for those with “standard” (not legacy) Nexus hardware wishing for a more conventional and familiar approach. ACI seems to be a bit more about re-thinking the whole approach and trying to gain real abstraction, while dealing with a number of other customer wishes. (Like good telemetry tying the overlay network back to problems in the underlay physical network. Something one of the screen captures in the third Brad Hedlund link shows a form of, for NSX. Some of the original thinking in ACI may provide very powerful troubleshooting capabilities, however.)
Security and NSX
NSX for vSphere contains kernel based distributed firewalling capability. VMware is partnered with Palo Alto to enhance that capability with virtualized Palo Alto firewalling and central management GUI tool. See also:
- http://bradhedlund.com/2013/07/07/what-is-a-distributed-firewall/
- http://bradhedlund.com/2013/11/20/distributed-virtual-and-physical-routing-in-vmware-nsx-for-vsphere/
- http://bradhedlund.com/category/nsx/
In the first of these, Brad (@bradhedlund) notes that logical containers can be used. I read this as Object-Oriented Access Lists (speaking ASA / Cisco router-ese for a moment). The virtual firewall workload is distributed across the hypervisor hosts, acting like one giant firewall with central GUI for configuration. I’m not going to attempt to top Brad’s graphics here.
In the last of the above blogs (list of blogs about NSX), there are some nifty screen captures.
Security and DFA
You can build ACLs (access lists) in DCNM 6, and apply them to interfaces. Whether DCNM 7 will abstract that some, allow ACLs applied across a fabric, etc. remains to be seen. Prime NSC can configure VSG for 1000v on hypervisor hosts. I take that to be more or less the counterpart of what NSX distributed firewall does. (Ducking any quibbles about how many hypervisor hosts the distributed virtual switch spans, etc.).
DCNM 7 will apparently contain templates for edge, per-tenant, and other firewall use cases. It seems likely that DFA will leverage port profiles for a moderate level of abstraction. (See also Greg Ferro’s article at http://www.networkcomputing.com/data-center/cisco-accelerates-sdn-strategy-with-dyna/240157709).
My guess is that one can also use the VLAN / VRF capability to run traffic over to a physical firewall at the fabric edge.
Security and ACI
This could be a pretty big topic. I’ll refer you to the copious slideware that is now available for discussion of ACI policy. Or a later blog. Here’s the short version:
Groups of services are End Point Groups (EPG). Classic examples might be VLAN or VXLAN ID, IP address/subnet. Others at launch may include switch physical port, logical port (VM port group). And in the future DNS name or Layer 4 ports might be a factor. The point of an EPG is ideally to focus on the function and not the IP address. (I get that: the best feature of Cisco Security Group Tags is that I can enforce policy based on Security Group Tag, i.e. security group the user is in, and get out of the quagmire of ACLs based on seemingly random source IP addresses.)
Application Network Profiles are a group of EPGs and the policies for inbound/outbound communication allowed.
A contract specified what communication between EPGs is allowed, and how it behaves. They are formed of a filter (the standard example is “TCP port 80”, an action (“permit”), and a label. Actions include permit, deny, redirect, log, copy, and mark (DSCP). (Why does this remind me of OpenFlow?)
ACI is based on configuring intent, including these policy contracts stating which applications are allowed to talk, what QoS treatment they should receive, and any relevant service chaining (go to the virtual firewall, then the virtual Server Load Balancer / Application Delivery Controller, etc.).
I find myself thinking Object Oriented ACLs again, with bells and whistles (QoS bells and action whistles?). Since I consider the least fun part of implementing Cisco QoS to be building ACLs for classification and marking, tying together security and QoS with the same objects (EPGs and policies) sounds like a win!
Security and ACI: How It Actually Works!
Once again, I’ll give you the Lite version, and refer you to the slideware for the step-by-step pictures.
Let’s take a look at how enforcement happens in ACI (our Daily Dose of Detail!)
- When an endpoint connects, ACI pushes any relevant policies to the Leaf node (policies with the endpoint as source or destination).
- A packet from A to B arrives at a Leaf Switch. The Leaf switch looks up the source EPG for A and puts the source EPG ID into the packet.
- If the destination EPG is known, the policy is enforced. If the packet is forwarded, bits are set to indicate that policy has been enforced. This is called “opportunistic policy enforcement”.
- If the destination EPG was not known, the packet is sent instead to a forwarding proxy in the Spine.
- If the destination is known, the packet is forwarded to the Leaf node the destination is attached to.
- If the enforcement bits are not set, the destination Leaf node enforces the policy (using the source EPG ID; the destination EPG is known on the attached Leaf node).
Other Relevant Prior Blogs
- Thinking About NSX, DFA, and ACI
- Application Centric Networking After-Thoughts
- The Cisco ACI Launch, Part 2
- The Cisco / Insieme ACI Launch, Part 1
Twitter: @pjwelcher
Hiya,
Any thoughts on SGT usage with DFA ?
Haven’t seen anything so far. I’m guessing that SGT ACL enforcement might be a feature that will be added later, for both DFA and ACI. Good question!