Freshly off the heels of what has been a top notch Cisco Live US experience, this Zigbit is going to highlight some of the initial concerns surrounding “The Network. Intuitive!”.
What is “The Network. Intuitive!”?
Before we can discuss the initial concerns of “The Network. Intuitive!” we must understand what “The Network. Intuitive!” is at a high level. A fellow #CiscoChampion, Justin Cohen, has put together a full blog post on “The Network. Intuitive!”. Justin’s blog post is titled “Cisco Announces The Network Intuitive”, which documents pretty much everything that is known so far. I highly recommend everyone read this post if you haven’t yet!
What is “The Network. Intuitive!”? – My own words
In my own worlds, “The Network. Intuitive!” is an intent driven approach for networking. The key to an intent driven approach is a policy or orchestration engine that enforces a policy or subset of policies based on the characteristics the environment, the network devices, and the end user devices maintain or have. These characteristics can be anything that is important to the business or just characteristics the business wants to apply a policy on.
With intent based networking, we care about the end state of the environment, the network devices, and the end user devices, and less about how it happens or how it is achieved, just that it is achieved. This decoupling of the how to accomplish a state versus validating the end state is achieved has a enormous number of benefits that our industry is just starting to scratch the surface on.
To achieve this intent based networking approach with “The Network. Intuitive!” Cisco has launched the Software-Defined Access or SD-Access. SD-Access includes a number of technologies and solutions, to include but not limited too: VXLAN, LISP, ISE (TrustSec), APIC-EM, DNA Center, and Network Data Platform (NDP).
Initial Concerns
The initial concerns with “The Network. Intuitive!” are twofold and are listed below
1. Reliance on Cisco TrustSec as a policy engine
2. Reliance on APIC-EM and its applications to be “The Brain”
1. Reliance on Cisco TrustSec as a policy engine
I’m a huge fan of Cisco Identity Services Engine (ISE). With that said the lack of customer adoption of TrustSec is a huge concern when Cisco is making TrustSec a core component of “The Network. Intuitive!”, or SD-Access. I spend between 50 – 75 percent of my time at my $dayjob deploying Cisco ISE over the last 3 years and I still have yet to see customers choose to implement TrustSec. This is not because we haven’t tried by any means. Some of the reasons why customers decided not to go with TrustSec:
TrustSec is not supported on their current Hardware:
When TrustSec is not supported on more than 50 percent of a customer’s network, it makes it a very hard sell and to implement TrustSec. If we are able to time this appropriately with their hardware refresh cycle then that is the best case scenario but is not a normal situation.
Application’s and User’s data flows are unknown:
One of the underlying issues with TrustSec, and ISE for that matter, is determining the application’s and user’s data flows. Most of today’s Network Infrastructure teams and Application Development teams just do not know what the applications actually need access too or what the users actually need access too. How can you implement an application policy when you do not know what that application is connecting too? How can you implement a user policy when you do not know what that user actually needs access too? Of course, we can potentially use a tool to determine this information but that is another cost, both time and money, that the customer would have to pay.
Limited Security Goals:
Finally, limiting security goals for an organization is another reason why TrustSec is not further investigated. When an organization’s security goal is focused on permitting company owned assets to connect to their network and denying non-company owned assets to connect to the network only, this limits the overall benefits of TrustSec. In this situation, it is more of a visibility tool than a micro-segmentation tool.
2. Reliance on APIC-EM and its applications to be “The Brain”
I like the idea of what APIC-EM has been marketed to do, but when actually deployed in the field it has left a number of less than positive experiences. With the launch of “The Network. Intuitive!” and SD-Access, it gives APIC-EM a second chance to shine and win the community over.
High and / or Increased resource requirements for APIC-EM:
Before this new initiative, the Virtual Appliance for APIC-EM required 64 GBs of memory….Sure to the huge enterprise customers and huge data center footprints of the world, 64 GBs of memory may not seem like a lot, but for the normal customer this is a huge resource requirement. With “The Network. Intuitive!”, the resource requirements have doubled, now requiring 128 GBs of memory for the Virtual APIC-EM appliance. I don’t believe customers are going to jump into this SD-Access bandwagon with resource requirements like this. Because of these resource requirements, I believe the push will end up being more focused towards the Physical APIC-EM offering than the Virtual Appliance.
Note: The new APIC-EM resource requirements were mentioned in a presentation but the APIC-EM data sheet has not been updated to reflect this change. If the resource requirements are not doubled then 64 GBs of memory is still a lot of memory for one system, for most organizations. I think it would be prudent for Cisco to come out with more reasonable options for the virtual APIC-EM appliances. Maybe 8 GBs, 16 GBs, and 32 GBs options?
The APIC-EM Apps:
There have been some mixed experiences with the APIC-EM Apps. This experience is from friends, colleagues, co-workers, customers, and first hand knowledge. The most utilized apps include Easy QoS, Plug-and-play (PnP), and Cisco Intelligent WAN (IWAN). Easy QoS has been the top app out of the three because it has functioned appropriately and as expected while the other two apps have failed to work more times than we can count, with the IWAN App taking the cake in this losing category.
The concern here is that the track record for APIC-EM Apps in real world situations has been very negative. With “The Network. Intuitive!”, the ‘brain’ behind SD-Access is DNA Center which is another App inside APIC-EM. How is DNA Center going to rank with these other Apps of APIC-EM? Is it going to blow away the past negative experiences or add to them? This is one of the biggest sticking points in terms of SD-Access and “The Network. Intuitive!”.
Summary
Putting these concerns aside, I honestly have a very optimistic view towards SD-Access. This isn’t something that is going to go away and Cisco isn’t the only company working towards or offering an intent based networking solution…I recommend everyone check out Apstra’s Intent Based Networking solution. I urge everyone to keep their minds open to intent based networking as I personally believe that intent base networking is going to revolutionize how we build networks of the future.
Stay tuned for future information as we dig deeper into the SD-Access solution and provide more real world context around intent based networking.
Resources:
- Cisco Announces The Network Intuitive – By #CiscoChampion Justin Cohen
- Industry Embraces Intent Based Networking – By Mansour Karam from www.Apstra.com
- Intent Based Networking: Use Cases CLUS17 – By Mansour Karam from www.packetpushers.net
Hey Michael,
Happy to clear a couple of things up for you:
Reliance on Cisco TrustSec as a policy engine – You actually can run it without TrustSec. You just lose the microsegmentation inside the VRF itself. You can still run it as a fabric and go crazy all day long.
Now let me explain further why I don’t think you should worry too much about the TrustSec part if you do deploy it:
– TrustSec is not supported on their current Hardware – That’s completely fine. That’s why you have SXP. I have customers with Juniper switches, Palo Alto Firewalls, etc all mixed in their environment and they decided to go Trustsec. Trustsec doesn’t require end-to-end inline tagging. In the customers that I had that were working on their aging infrastructure and they couldn’t rip and replace, we designed around it. Remember: TrustSec doesn’t only have to at the access layer or with 802.1x. You can tag upstream based on VLAN, static bindings, layer 3 interface, SXP, IP ARP bindings, local bindings through device tracking, and internal bindings.
In a situation where you have access layer that don’t support SGTs, you can fallback to methods like VLANs and dACLS and tag later upstream. For devices that don’t support SGTs in the middle like that shiny PAN firewall or Juniper core you might have, you can utilize SXP to piggyback the binding over that device so it’ll be retagged once that packet is back in a TrustSec cloud.
– Application’s and User’s data flows are unknown – Well… to be 100% fair, this could be the issue with ANY NAC you deploy if you’re trying to tag down to the port level. To me, there’s no difference here between this and trying to figure out how to craft your DACLs. When it down, you can always fall back to a blanket “permit” or “deny” instead of selecting specific ports to open up between groups.
– Limited Security Goals – Fair enough but in most cases with customers I deal with, they still want to prevent the east-west traffic for malware and it’s easy enough to say BYOD shouldn’t talk to production or guest shouldn’t take to production. You can craft your SGT policies as simply as that. SGTs and the TrustSec matrix is pretty much putty the same policies that you would write a DACL for except you’re removing the dependence on IP ACLs and trying to manage those.
In my experience, most of the misconceptions with Trustsec and SGTs tend to be an educational one. I had my head in the sand about Trustsec for awhile and I started really reading into it for my own studies that you know about. Once I started realizing the different ways you can deploy or architect around it and that there were a lot of flexible ways to deploy it, It grew on me greatly.
– High and / or Increased resource requirements for APIC-EM – I agree. It’s going to be a beefier server but before you go too far down the rabbit hole, I would ask you to wait until you play around with DNA Assurance which should be released later this year. I think you’ll see why there’s a need for the horsepower and the use cases for it.
-The APIC-EM Apps – PIC-EM was released and developed with some interesting use cases but the vision in mind was to eventually evolve to the DNA Center which is quite a bit different than your barebones APIC-EM. There’s a lot on the roadmap and they have some big dreams for this which from what I’ve seen demoed and played with, seems really awesome. Of course, with all new things, it takes time to develop and get these to market but I’m hoping it impresses you as much as it impressed me.