Cisco Systems Application Centric Infrastructure (ACI) is the industry leading SDN platform according to Gartner, outpacing NSX by a factor of 2:1. ACI continues to accelerate past NSX by enabling Micro Segmentation and End-Point Granularity. In real world data centers, there are many simultaneous application delivery end points including VM’s from multiple hypervisors, bare-metal hosts, Linux containers, and layer 4 – 7 appliances that are both physical and virtual.
VMware recently published articles regarding this announcement and appear confused through inaccurately stating ACI capability. Juan Lage, a Principal Engineer at Cisco Systems provides an accurate and detailed description of our capabilities and addresses VMware’s obvious misunderstanding in his article below my introduction.
After reading Juan’s article below, the only thing left to say to VMware NSX is welcome to the “real world”
When we announced last month the 1.2 release of ACI (http://newsroom.cisco.com/press-release-content?articleId=1732204) we knew that we were bringing a lot of value to our customers, but we also knew that as a consequence, we are making it more complicated for competing offerings, and that there would be reactions to our announcement.
This is why VMware’s blog “VMware NSX and Split and Smear Micro-Segmentation”
(https://blogs.vmware.com/networkvirtualization/2016/01/vmware-nsx-and-split-and-smear-micro-segmentation.html ) did not come as a surprise.
The author of the blog attempts to prove that only VMware NSX can provide micro segmentation. Also, it appears the author suggests that you are not protected from “the bad” guys if you don’t have VMware’s Micro Segmentation.
It is an interesting post, but it has several statements that are inaccurate and a few ideas and exaggerations that are recurring in NSX’s marketing and that we certainly disagree with.
The first idea we must disagree with is about the scope of the vision of a Data Center. To speak of data center security where every security perimeter has a diameter of one by defending a solution that only works for vSphere is not arrogant: it is naïve. As much as some vendors may dislike it, there are endpoints that are not Virtual Machines. And yes, even a server running ESXi is one of those. How can the NSX Micro Segmentation approach provide any lateral movement protection for the vmkernel itself? … How can it do it for the management ports of the server where ESX is running on? Or for the physical filers that implement NFS shares?
And then of course, there are a good percentage of Virtual Machines that do not run on VMware.
The second idea we need to disagree with is the very definition of Micro Segmentation.
What is Micro Segmentation?
In our understanding and that of the customers and partners that we work with on a daily basis, Micro Segmentation is about having the possibility of setting up policies with endpoint granularity. Notice we use the word “endpoint” rather than “Virtual Machine” because again, there are things other than VMs running in every data center.
Can we settle for that simple definition? This is what our customers are asking for.
And they are asking for it because Micro Segmentation has many great use cases. It helps in minimizing the attack perimeter, complicating or even impeding lateral movement. It can also be useful to help in containing attacks, by quarantining endpoints and in facilitating remediation.
The author of the VMware blog makes the assumption that only NSX can implement security perimeters of one (one being a VM). This is not true. The Cisco ACI leaf switches can do per-Endpoint classification. We can definitely work with a perimeter of one for virtual and physical endpoints.
Cisco ACI provides Micro Segmentation on vSphere since June 2015 by using the Cisco Application Virtual Switch (AVS). Since December 2015 with the ACI 1.2 release, we also provide Micro Segmentation for Microsoft Hyper-V and for bare metal workloads. We have plans to also enable this functionality for Open vSwitch as well as extending it to using the native vSphere Distributed Switch (VDS) soon.
The author seems to be surprised or confused about how we can accomplish this using the VDS. We do agree that the VDS is a limited virtual switch compared to Open vSwitch or the Microsoft Virtual Switch. That is part of the reason why we developed and continue enhancing the Cisco AVS in the first place.
For instance, in Open vSwitch there’s the possibility of programming security rules using OpenFlow. The Microsoft Hyper-V vSwitch is also programmable using the Virtual Filtering Platform. Both these virtual switches offer this programmability in an open way, and both can use OpFlex (https://wiki.opendaylight.org/view/OpFlex:Opflex_Architecture) to be programmed.
But we can still work with the VDS to bring advantages to customers simplifying software lifecycle management by saving the customer from having to manage kernel modules on vSphere.
About firewalls and traffic “inspection”
The second biggest misconception seems to be the assumption that to provide micro segmentation in ACI, all traffic needs to be sent to a centralized firewall for “inspection”. We have already clarified that the ACI policy model can block traffic that is not conforming to policy without a firewall.
We also think there’s some exaggeration in the way the author talks about traffic “inspection” as it relates to NSX. The author is comparing a set of physical firewalls with the NSX Distributed Firewall and assuming the inspection capabilities are similar. Here we have an issue, because this leads to the perception that the NSX DFW capabilities are similar to those of a Cisco ASA, or a Palo Alto, Fortinet or Checkpoint firewall.
The word “firewall” and the term “traffic inspection” are not used with rigor in the blog. A firewall that only looks at L4 headers and keeps L4 connection state does not really “inspect” traffic. Or certainly not when it is being compared to a security device that actually may terminate connections to look at application level-threats, or that looks deep into the packet (i.e. beyond L4 packet headers) to detect for instance VoIP packets on HTTP, or block at URL-level. Next Generation Firewalls (NGFW) do that. NSX firewalls do not do that. Nor does the ACI fabric.
From what we know, the NSX Firewalls (both the ESG and DFW) implement something similar to Netfilter’s Connection Tracking (https://en.wikipedia.org/wiki/Netfilter). This basically keeps state of TCP flow sessions as you implement port-level filtering.
The ACI contract model also provides L4-port level security for east-west traffic. While the fabric does not keep TCP state, it also does not require the endpoints to dedicate any compute capacity to run a L4-port level packet filter.
Again, to compare a basic stateful packet filtering mechanism with the security provided by a Checkpoint, Cisco, Fortinet, or Palo Alto NextGen firewall only helps confusing customers and create wrong perceptions of security. The security teams must seriously evaluate if their requirements are adequately addressed by the NSX DFW compared to the advanced capabilities of available Next Generation Firewall (NGFW).
And the truth is that a Next Gen Firewall may well be required between certain applications tiers. After all, customers no longer use only L4-port level security at the perimeter. The security posture for East-West in certain application environments does not differ much from the North-South. Which leads to our final consideration.
Is Micro Segmentation all I need for Data Center Security?
Definitely not. And on this point, I am sure we are in agreement with other vendors including VMware.
Micro Segmentation helps in many ways. Increasing East-West security is one. But let’s say that you use NSX or ACI for allowing only HTTP between a set of endpoints: neither of the solutions can block URL-level attacks. Similarly, neither NSX nor ACI can natively block SQL inject attacks. And this is to name just two really basic examples.
To provide protection for modern attacks you need a NGFW that can really inspect traffic. To provide NGFW filtering for East-West traffic when using NSX, you are limited to using virtual editions of the supported vendors. This may be adequate for some scenarios, but it is expensive in compute resources and provides low per-host performance. What is the point of having 10GE capable servers when the NGFW will limit you to 1-2 Gbps while consuming a few vCPUs?
With ACI, NGFW and other advance network service devices can be inserted for both Perimeter and East-West traffic flows. Customers can choose to use NGFW virtual editions, or physical editions, or a combination of both. This way, access to high performance DB can go through hardware NGFW that can achieve multi-10Gbps, while a virtual NGFW is used for development environments for instance.
This is an area where ACI delivers a great advantage because of its flexibility and true multi-tenancy. By contrast, NSX limits customers to using virtual editions only, without any multi-tenancy support.
ACI helps in these scenarios using the same model when a NGFW, or an ADC, or an IPS/IDS is required for East-West or for North-South, whether using virtual or physical form factors: Service Graphs (http://blogs.cisco.com/datacenter/new-innovations-for-l4-7-network-services-integration-with-ciscos-aci-approach).
Final comments and conclusion
We welcome blogs like this one (https://blogs.vmware.com/networkvirtualization/2016/01/vmware-nsx-and-split-and-smear-micro-segmentation.html). They reflect misconceptions that may be shared across a large number of customers and partners and gives us the opportunity to clarify them.
The reality is that Cisco ACI does deliver Micro Segmentation for Microsoft, Bare Metal and vSphere Environments with endpoint granularity, and soon will do it for KVM as well. And the best part of it all is the fact that you can also run NSX Micro Segmentation on top of ACI. We are not putting limits to that.
The following table can help customers understanding when NSX and ACI are valid solutions for implementing Micro Segmentation in their environments.
The reality is also that Micro Segmentation is a great tool in the toolbox, but only one of many that are required in a Data Center Security strategy. ACI helps to insert and automate virtual and physical NGFW from many vendors, IPS/IDS systems and provides the foundation for automated security for the perimeter and for inside the perimeter, for single tenant and for multi tenant environments.
The reality is also that there is no one single product that can help customers be completely safe from “the bad” guys. But we are all here to work in getting better security, one step at a time.
Well said, Frank. Can you also link Juan’s article here like you’ve done for the NSX blog?
There is a lot of untruth in this blog. I guess that is to be expected when it is coming from Cisco. ACI is definitely not better than NSX. I don’t even see them as really competing products. ACI will one day be great, when it is ready for prime time, managing your physical network fabric. It will never be as good as NSX in securing a virtual environment no matter the hypervisor. With that statement I am clearly stating that the bottom graph is wrong. NSX supports multi-hypervisor. If Gartner actually ever stated ACI was better than NSX then it’s because they tested through Cisco powerpoint presentation and never actually tried to get it working live!
Hello Chris, thanks for your comment. It would be great if you can tell us what is untruth in the blog, we would love to correct it. But for that, it is important to be factual and while we appreciate all feedback (good and bad), your comment provides no data or facts that sustain your opinion. I still respect your opinion, but in general I don’t share it. I do agree that NSX and ACI are not always competing products.
Chris, we’ll be happy to POC any of the items in the blog and have many customers in production with ACI – the industry leading SDN platform in number of customers, production implementations, revenue, and scale. We would be interested in hearing detail however if you want to openly debate those items.
A scaling question: Many large enterprises have ten or twenty thousand applications, and still growing. And each of those applications may be further subdivided (web tier, application tier, database tier). Thus an enterprise could easily require a scale of ~50-100k microsegments.Yet the latest Verified Scalability Guide for Cisco ACI seems to indicate that the maximum number of End Point Groups is 15k, or maybe 21k. This would seem to be a serious limitation for deploying ACI in large-scale deployments, like an enterprise private cloud. Perhaps I’m misunderstanding something? Thanks for clarifying!
Hello Guglielmo,
thank you for your question. Scale always comes up in these cases. You know, 18 years ago I was attending a BGP training given by a Cisco-fellow-to-be. One of his first slides stated something like this: “In technology, there is only one real problem: scale”. I find this to be so true (and it is applicable to many things in life other than technology when you think about it).
About ACI and scale, we do make an effort to publish with every new release the “verified scalability guide” (something lacking from others in the industry I must add …). The latest for ACI is here:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/verified-scalability/b_Verified_Scalability_1_2_1x.html.
I know you have already seen it, I put the link here for others that may read it. 🙂
We will continue working to increase scale, but we think we are already well ahead of other SDN options in the marketplace.
There are indeed Enterprises that run a very large number of applications. But the first thing you also have to consider is that while an Enterprise may have thousands of applications, they not all necessarily run on the same infrastructure or even on the same data centre. Therefore, they don’t all need to be supported by a single fabric. This is the first way to scale: divide the problem into smaller problems.
In any case, looking at this in light of micro segmentation is going to require very careful consideration for certain. When you think about it, it’s not only because of scale. It is also because of policy, which is in my opinion the end goal (segmenting being a tool to achieve it). If you will create “micro segments” where before you had a larger single one segment, you need to also think of what policy you will enable between those. In my experience with customers at that scale level (and at much smaller scale too!), most often than not we do not know how to define the policy: what are the the application dependencies between all those thousands of apps? … That is a big challenge ahead! 🙂
And then there are environments and applications where it’s easier to define what policy you require. Much of the infrastructure security falls into this category. Certainly greenfield applications fall onto that as well, specially those designed to run in newer container-based infrastructure that map hand in hand to ACI Application Network Profiles. Those environments are perhaps the easiest to benefit from an automated approach to policy with ACI. So it is going to be a step by step approach.
I hope this helps?! 🙂 …
@Juan: Your description of “real world” is a good start for a discussion but in my opinion there are some inaccuracies.
1. You mentioned that a firewall that only looks at L4 headers and keeps L4 connection state does not really “inspect” traffic. Actualy Cisco taught about ”Layer 3/Layer 4 inspection” in IOS and ASA firewalls many times. Examples:
a)
http://tools.cisco.com/security/center/viewAMBAlert.x?alertId=30338
“Effective exploit prevention can also be provided by the Cisco ASA 5500 Series Adaptive Security Appliance, … using the following methods:
• Layer 3/Layer 4 inspection”
b)
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_protocol_cbac_fw/configuration/15-mt/sec-prot-cbac-fw-15-mt-book/sec-prot-email-insp.html
“TCP L4 inspection continues until the connection is closed.”
I agree that since Sourcefire acquisition the L7 inspection became reality but L4 inspection still aplies.
2. L4 FW is not NGFW but the L4 firewall with ALGs is better than ACLs. NSX firewall can at least offload a SYN flood denial of service attack. Do you agree?
3. You are right by saying that micro segmentation is not all-in-one security solution which meets all security needs. NSX firewall is not replacing the North-South security perimeter or NGFW. On the other hand NSX FW is not only about micro-segmentation. It combines identity based firewall, ALG support for Oracle, MS Windows etc., IP source guard, ARP spoofing, enhanced rules tracking, bandwidth stats for each rule and many other features. Flow monitoring capabilities totally surprised me comparing to ACI. Thus micro segmentation is one of features offered by NSX FW.
Guglielmo, there are many variations to scale and the type and use of EPG’s. Shared services models concatenate the use of individual EPG’s and many optimizations can be made. The scale numbers get tuned widely as customers determine the topology, use of EPG’s, and the depth of policy. Many implementations of policy reduce the rulesets required in traditional ACL’s and provide dramatically higher address and policy scale than those compared to traditional or merchant networks. We would be happy to address any of those with you if you want to reach out to us directly
Juan and Frank, Thank you for your thorough and thoughtful replies.
For many of the developers, the point of comparison is Amazon Virtual Private Clouds. That’s the API-driven networking to which they’ve grown accustomed.
While each VPC has its own limits, presumably the maximum total number of VPCs is so large that users can consider that pool practically limitless.
Thus for a private cloud, an ACI installation should be engineered to avoid API calls returning errors about insufficient resource. Hence the motivation for the question.
Thanks!
In five years everything will be containers. ACI correctly focuses on end-points while VMware clings to legacy VM revenue.
Chris allow me to rephrase your comment :
Just like yesterday when it was not just about Solaris or AIX and today when it’s not just about Windows or just about Linux in 5 years from now it won’t be just about VMware or just about containers. So the best approach is to have an architecture that is open and that allows for integrations from third parties. I think we are getting there with ACI.
This does appear contradictory, the same Andrew Lerner quoted in the blog states in their analysis of their magic quadrant:
“Although Cisco ACI is now generally available, we have observed very limited market adoption and estimate that there are fewer than 25 large-scale enterprise production ACI installations as of late March 2015. Enterprise clients continue to report that Cisco has difficulty producing production references for ACI deployments.”
http://www.gartner.com/technology/reprints.do?id=1-2F4M3ET&ct=150513&st=sb
Other outside sources also question these numbers:
https://www.sdxcentral.com/articles/news/enter-the-octagon-cisco-aci-vs-vmware-nsx/2015/11/
“By contrast, the 2015 Special Report: Network Virtualization in the Data Center cites NSX as the product that is most often being used or evaluated by customers with Cisco in second place. It’s the second year in a row that the SDxCentral NV survey has NSX at the top of its leaderboard.”
Best feed back is from our customers: http://www.networkworld.com/article/3016668/virtualization/tribune-media-rebuilds-it-from-the-ground-up-and-is-living-the-dream.html?nsdr=true
I agree Gilles, and I am glad that both vendors have happy customers. We too have customers with small deployments like the one mentioned on that link (an SDDC of 80 servers), and much larger as well, happily using ACI. Thanks for your comment! 🙂
Excellent Article Frank, provides clarity on the micro-segmentation differences.
Thanks!
The same Andrew Lerner quoted in the blog below place in their analysis of their magic quadrant:
“Although Cisco ACI is now generally available, we have observed very limited market adoption and estimate that there are fewer than 25 large-scale enterprise production ACI installations as of late March 2015. Enterprise clients continue to report that Cisco has difficulty producing production references for ACI deployments.”
Other outside sources also question these numbers:
https://www.sdxcentral.com/articles/news/enter-the-octagon-cisco-aci-vs-vmware-nsx/2015/11/
“By contrast, the 2015 Special Report: Network Virtualization in the Data Center cites NSX as the product that is most often being used or evaluated by customers with Cisco in second place. It’s the second year in a row that the SDxCentral NV survey has NSX at the top of its leaderboard.”
James – I’ll see your comments, and call with the following. Cisco is paying for the acquisition of Insieme between 2 and 3 times every 12 months. Can you share similar stats for Nicira / VMware? The following is from our financial report.
And our next-generation data center switching portfolio, which is our 3K, 9K, and ACI, is now at a $2 billion run rate with over $500 million in revenue this quarter, growing over 140% year over year, with sequential growth of 26%. This performance is much stronger than that of our competitors who claim they are outpacing and outperforming us.
http://www.thestreet.com/story/13365201/1/cisco-systems-csco-earnings-report-q1-2016-conference-call-transcript.html
D’Agostino -As stated by Gartner in their MQ report “Enterprise clients continue to report that Cisco has difficulty producing production references for ACI deployments.” I can tell you that we had over 5 times more customer in Oct 2015 than we had 12 months before that, and that NSX is the fastest growing product in our company’s history. Comparing your physical switching numbers to our software wouldn’t give an accurate view on actual production deployments – I have customers here in Africa with NSX running over 9Ks and I guarantee we both claim them as a customer :). Cisco’s challenge – as I see it – is that they have no choice but to link their SDN to specific hardware – so Hardware Dependent Software Defined Networking (HDSDN?), to quote Martin Casado “70% percent of our deployments are on 5Ks and 7Ks. NSX just treats the physical network as a back plane to pass packets. It could be IP over InfiniBand for all I care. As long as it has IP connectivity, we do everything on the edge in a distributed fashion. We can do things like L2, L3, load balancing, firewalling, all the mobility, all the security policy, all that stuff in a distributed fashion at the edge without affecting performance, and you can build your physical network how you want. That’s why if a customer has a Cisco 5K or 7K today I think they should seriously consider looking at NSX because the cost avoidance is material dollars.”
Coming back to the point on production deployments – even if you visit me here in Africa, I can take you to visit large scale production deployments.
Thanks James. Our numbers speak for themselves. You have a great idea however. I would love to come to Africa and do joint meetings with your customers.
Thank you for this post. I will be very happy to host you in Africa Frank and of course we are already working closely with our customers in Africa to help them address their real word DC security problems. Segmentation is a great start for good security but unfortunately not a complete strategy, it will be reckless for any information security professional to claim otherwise.
I am very glad there are customers using micro segmentation strategies in their virtualized data centers, this will help them to understand the value but also the limitations of a virtual segmentation only approach to security and sooner or later will realize that a wholistic strategy including purpose built hardware is indeed beneficial and also required to enable business while protecting against todays threat landscape.
Cisco VTS proves that a soft overlay decoupled from hardware is the right strategy. This is truely open and multi-vendor comparing to ACI. VTS can also be extended to Software Defined WAN. But because ACI is pushed the VTS solution is 1-2 years behind Nuage. Are there plans to decouple ACI from N9k or at least integrate VTS with ACI?
Hello Piotr, thanks for your comment. Cisco has solutions for different markets, but I believe that you have a miss understanding of VTS and its scope and how it is positioned with regards to ACI and SD-WAN offerings. I think you are not the only VMware employee confused in this sense. Feel free to reach out to me directly and I’d be happy to explain and clarify your doubts. 🙂
Hi Juan, I apprieciate your answer. No doubt these two products are positioned for different markets because their origins are different in terms of teams and approaches. ACI is focused on enterprise, a tight security integration, underlay & overlay management, should be the first choice, etc. My just personal statement is that these two incompatible products are built based not on a common cross-arch strategy but because of two silos strategies combined now as one.
Clear and to the point Frank, thanks.
@Juan: Your description of “real world” is a good start for a discussion but in my opinion there are some inaccuracies.
1. You mentioned that a firewall that only looks at L4 headers and keeps L4 connection state does not really “inspect” traffic. Actualy Cisco taught about ”Layer 3/Layer 4 inspection” in IOS and ASA firewalls many times. Examples:
a)
http://tools.cisco.com/security/center/viewAMBAlert.x?alertId=30338
“Effective exploit prevention can also be provided by the Cisco ASA 5500 Series Adaptive Security Appliance, … using the following methods:
• Layer 3/Layer 4 inspection”
b)
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_protocol_cbac_fw/configuration/15-mt/sec-prot-cbac-fw-15-mt-book/sec-prot-email-insp.html
“TCP L4 inspection continues until the connection is closed.”
I agree that since Sourcefire acquisition the L7 inspection became reality but L4 inspection still aplies.
2. L4 FW is not NGFW but the L4 firewall with ALGs is better than ACLs. NSX firewall can at least offload a SYN flood denial of service attack. Do you agree?
3. You are right by saying that micro segmentation is not all-in-one security solution which meets all security needs. NSX firewall is not replacing the North-South security perimeter or NGFW. On the other hand NSX FW is not only about micro-segmentation. It combines identity based firewall, ALG support for Oracle, MS Windows etc., IP source guard, ARP spoofing, enhanced rules tracking, bandwidth stats for each rule and many other features. Flow monitoring capabilities totally surprised me comparing to ACI. Thus micro segmentation is one of features offered by NSX FW.
Thank you again for commenting on our blog. And thanks for the links you bring up too, because they are actually quite explicit. See, the literature you point out from Cisco speaks very explicitly about “TCP L4 inspection”. I also hope you noticed that the links you talk about also speak of Cisco products that can inspect e-mail protocols for instance, something which, again, the NSX DFW currently does not do. I also want to clarify that Cisco has not been talking about app-level threat management and the need for app-level inspection (beyond L2-4 security) since the SourceFire acquisition, but way before that. And certainly we are not the only security vendor recognising the need for inspecting at the application layer. To your points: personally, I do not see how the NSX DFW can off load a SYN flood DoS, a firewall that can do that needs to proxy the TCP sessions, which is not the same thing as tracking them. Also, I am well aware of the ALG capabilities that are built into L4 firewalls. Then again, let’s not exaggerate by saying that it “supports Oracle and Microsoft Windows” … it’s not like it has ALG support for all MSFT or Oracle apps: only for MS-RCP and Oracle TNS, just like Linux netfilter. And this is good, it can open ephemeral ports also for FTP, like we do on the Cisco AVS, but let’s not confuse (1) inspecting the communication channel that an application uses with (2) inspecting the application traffic. In any case, to be very clear: our intention is not to criticise VMware NSX or its Distributed Firewall. We have a similar implementation with the Cisco AVS after all. The two issues that we have are the following: (1) on the VMware blog that we refer-to above, it is portrayed that ACI can not do micro segmentation without using expensive NGFW: that is simply NOT true. (2) another reading of the above mentioned VMware blog would be that the NSX DFW has “traffic inspection capabilities” that are comparable to a NGFW (since that is what is considered that would be used with ACI). This is an exaggeration. This leads customers into thinking that if they use NSX, they don’t need a firewall anymore which is not true. When a customer reads literature from Checkpoint, Cisco, Fortinet, Palo Alto and other security vendors, they read about how the firewall inspects application traffic. When they read the same terminology referred to NSX firewalls, many customers are misled into thinking that they are equivalent, and they are not. In summary: ACI can be used to do micro segmentation without requiring a NGFW. A NGFW may as well be advisable in order to provide app-level threat management in any case. ACI can dynamically insert a NGFW in the path between any two endpoints. Finally, our intention is not to de-merit NSX at all, but we do think when it comes to security, exaggeration has no place.
Thank you Juan. Excellent article!
I liked the real world practices/scenarios exhibits, makes a lot of sense to me as a tech guy. As well, nice to read an article that is backed-up with solid technical definitions and is free of unrealistic pretensions.
One comment, it would be great if it was possible to enlarge the images in this article to see them in a better shape.
Hi there every one, here every one is sharing these knowledge, so it’s good to read this website, and I used to
pay a visit this website daily.
NSX has its share of downsides, but I’m pretty clear on what it can and can’t do – and I mean for real, in a real world scenario, not roadmaps or theories. I am really struggling to get the same level of clarity around ACI.
>The author seems to be surprised or confused about how we can accomplish this using the VDS.
Perfect example right here. You take jabs at the author of the NSX blog for not understanding how you could meaningfully secure the VDS without the same level of kernel access that VMware has…. but you don’t actually explain how it works. Do *you* even know?
I am an architect for a VAR who sells both products and have no particular dog in this fight, but my customers are asking me how the heck ACI could accomplish this, and I can’t get a straight answer.