Jason: Hi, everyone. My name is Jason Baudreau. I’m joined today by Himanshu Gupta, Product Manager for Data Center Networking at Cisco Systems. Also joining us today is David Femino, Senior Solutions Engineer here at NetBrain.
Today we’re going to be introducing a partnership between NetBrain and Cisco to discuss how a joint solution is helping network teams achieve better agility, both for deploying network services, that’s with Cisco ACI, and also for day-to-day network operations like troubleshooting. And today we’re extremely excited about this partnership and unique solution that it delivers.
Before we move on. I want to mention a few things. First, if you have any comments or questions throughout the webinar, please use the Q&A window of your WebEx. We’re here live to answer those questions for you. So please keep those coming in.
And second, this session is being recorded. And we’ll be sure to share this recording with everybody who’s registered for the webinar over the next couple of days.
I’d like to start by setting the stage a bit. Let’s start by looking at major trends impacting the data center and how network teams are being impacted. Trends like cloud computing, social media, and mobile adoption are pushing traditional data centers to their limits. And each one of these is representing a huge strain on that data center and on the network.
So this stress is driving demand for more agility, which is to say that businesses are looking for their data center to evolve at the speed of the software – to meet the demands of the applications.
And if you look at server and storage virtualization over the last decade, you’ll see that this trend towards agility and agile deployments is not new. The network is simply the last piece of this puzzle. And this makes sense because, in many ways, the network is the hardest nut to crack in this problem.
So what’s happening is when a new application needs to be provisioned, the traditional network becomes a bottleneck. The servers and the storage, they can be spun up potentially in minutes, only to wait for network teams to install and provision network devices, which can take weeks. So it’s this bottleneck that has been the primary driver for software-defined networking, right?
And as a leader in software-defined networking, Cisco ACI is fundamentally changing the landscape of that data center. Perhaps the most important thing Cisco ACI does is separate the control plane from the forwarding plane, resulting in centralized management, and this reduces provisioning times and provides more granular control of the environment.
In a traditional network, it can take hours to reconfigure access lists and routing policies across the affected area. But with Cisco ACI, the entire network will be managed by a single logical controller, and changes made to the network will be made much faster, leaving virtually no room for error.
So as you’ll hear from Himanshu from Cisco in just a minute, this new centralized controller also introduces orchestration. So helping to automate both basic and advanced network functions, such as provisioning systems and applications, routing decisions, and even security elements of the network.
And ultimately, this is about delivering services faster to the business through rapid provisioning. The network becomes more responsive to the needs of the application and basically gets out of that bottleneck, fundamentally.
To tell you more about the benefits of Cisco ACI, I’d like to introduce Himanshu Gupta, again, Cisco’s Product Manager for Data Center Networking. Himanshu.
Himanshu: Thanks, Jason. Hello. This is Himanshu Gupta, I’m a product manager with Cisco’s Data Center Networking Business Unit. And I work in Code Technology Alliances for our flagship product, Cisco ACI, and Cisco declaration analytics engine.
Today, I’ll be talking about the inherent vision of Cisco ACI, while briefly touching on Cisco ACI architecture and the operational challenges that NetBrain and Cisco ACI team are helping you solve. So let’s get started.
Okay, so looking at Cisco ACI, we set out with a mission. And that mission was the primary thing we needed to deliver from a networking perspective was app agility. We wanted to be able to provide customers a network that is able to keep up with the pace of modern business demand, while not sacrificing security for agility and vice versa.
In order to achieve that vision, there were three foundational elements that we had to build. In our current data centers, we have 30 years of building complexity running our networks. We have things like IP and spanning tree protocols that we used to duct tape and Band-Aid, every problem thrown at the networking industry.
And this has created a network that is inherently complex, risky, hard-to-manage, and slow to change. We had to simplify that down. The first thing we did was look at how we should think about the network and the deployment of the network. In ACI, we call that our policy model, which is basically the management or operational model behind ACI.
Rather than looking at network constructs and forwarding constructs and all other things, we looked at the baseline. That is, I need to connect this group of objects to this other group of objects under some rules. And those rules are basically some sort of policy that I need to enforce. This policy can range from compliance, security, governance, risk, or service level agreements, and can be imposed by anything from a load balancer to a firewall. This is our operation model that we delivered through the ACI policy model.
Below that, we built ACI from the ground up to be a data center network delivered as a system. And while this sounds intuitive, it’s not the way networks have been built in the past. In the past, networks were designed as independent, disparate boxes that were properly configured manually on a command line. It would operate a system until something went wrong.
But we built ACI from the ground up comprising the hardware, the operating system on that hardware, and the API exposure of that operating system to the control system. That is, take all of the switching in the data center and deliver that as a single resource.
So when you’re deploying an application on an ACI network, you’re deploying it on a data center network, rather than configuring switch by switch. Finally, underneath that, the baseline of everything that allows ACI to centrally provision that simplification of that app agility is building automation and programmability inherently into the ground up of that system.
We designed the architecture to be full of network resources automated by a control system and exposed upwards by an outbound API so that it could be plugged into a high level of automation systems like OpenStack, UCF Direct, and/or any other competitive solution.
And that, in a nutshell, is what we are doing with Cisco ACI. So to simplify for you guys, if you want to know the easiest way to understand ACI, and for the people who are familiar with Cisco UCS, is that Cisco ACI is basically Cisco UCS for the network.
Ten years ago, Cisco UCS borrowed a concept from the cell carrier network. Cell carriers made phones as a stateless networking device that received their identity and network configuration from a SIM card. UCS put that concept and created pools of stateless server resources that receives the identity or configuration via service profiles, similar to mobile getting its identity from a SIM card.
And ACI took that to the network by building a pool of network resources, configured and managed by a logical identity provider known as the application profile. A UCS service provider is analogous to an ACI application profile. And the UCS server is analogous to an ACI switch, particular theme concepts that we applied into a network and we applied it to a network. And this is what generated the success of ACI, making it a leading SDN solution in the market today.
Our vision for Cisco ACI is scale, security, and full visibility. The big picture goal, and what we can deliver today, is the ability to take the ecosystem that creates an application. An application is not just a virtual machine. It is a virtual machine, a physical machine, Linux containers, and associated connectivity and policy requirements, delivering on mobility for not only the application, but also the associated application policy across multiple data centers and public clouds, while maintaining visibility into the application health and the tenant residing on the infrastructure, thus drastically reducing troubleshooting time while providing a seamless user experience while delivering excellent commitment.
So, this is, in a nutshell, the intent of what Cisco ACI is and Cisco ACI stands for. So now I give you a very, very quick glimpse into the Cisco ACI architecture. So a typical spines list topology, all leaves connect to spines. No spine leaf connects to each other, everything like bare metal DB servers, external edge networks, physical machines, virtual machines, firewalls, load balancer, routers, connect to the leaves.
APIC, which is a fabric management console, is also connected to one of the leaves. Another fail-safe. Once the configuration is pushed to be APIC, even if the APIC goes down, it does not impact the fabric.
Next, let me go through the detail of what we are doing, NetBrain and Cisco ACI teams, and what value we are trying to provide to you guys. So with any new technology, it brings new challenges. So we acknowledge that. People for 30 years that are in this industry has been working in a network-centric mindset. So there is a knowledge gap. There is a learning curve. There is a skill gap.
The Cisco ACI team and NetBrain joined forces to bridge that knowledge gap, to help our users transition to an application-centric mindset. And that is something we have introduced several features in a joint solution that are targeted at this problem statement. The second is a lack of intuitive visibility.
We acknowledge that a typical Cisco ACI deployment is where a Cisco ACI fabric is working in tandem with a lot of legacy infrastructure. And that inherently brings a little challenge for the people who are not used to working in that heterogeneous environment. So in a single console, visibility is something that Cisco ACI and NetBrain have been able to provide to our joint users so that they can easily understand their deployment and extract the full benefit of it from day one.
Finally, troubleshooting complexity. We have taken advantage of inherent capabilities of NetBrain that are targeted at troubleshooting, not only a new problem, but recurring problems as well. And this is something, again, where we have a built-in solution. And this is something we will be talking about in our demo and on a future slide. So I’ll pass the ball back to Jason to talk about use cases. And then David can talk about the demo, as well. Thanks.
Jason: Thanks, Himanshu. That’s a great overview of the benefits of Cisco ACI. I’m sure on the call we have a mix of people at different phases of their ACI journey from research and evaluation to deployment and operations of the new infrastructure.
We’ve talked with many of you at Cisco Live this past year back in June. And over the next 20 or 30 minutes or so, we’re going to talk about how those of you who already have Cisco ACI deployed can improve on-boarding and operations for the technology. And for those of you perhaps just starting to evaluate Cisco ACI, I hope this discussion helps address many of the concerns you may have regarding this fundamental shift in networking strategy.
First, let’s take a look at how this joint solution works. The NetBrain solution for Cisco ACI integrates NetBrain’s discovery and modeling engine with the APIC Controller through REST API. This allows NetBrain to discover and map the ACI environment. Of course, NetBrain also discovers a map to the traditional network environment using the traditional methods of SSH and Telnet and SNMP.
So this unique integration project provides three benefits. First, teams can map the new heterogeneous infrastructure, their legacy infrastructure, and the new Cisco ACI environment in a consistent and familiar context.
Second, teams can map application flows end-to-end across the infrastructure and understand the mapping between ACI overlay and underlay architecture.
And last, mapping and run book automation technology can be used to drive automation for troubleshooting the abstract and dynamic nature of the hybrid environment largely driven through Cisco ACI.
So we’ll take a look at each of these benefits in turn. It’s worth mentioning that even with Cisco ACI, a network is still a network. The fundamentals of routing and switching don’t change. We’ve talked with many joint customers. And we found that the ability to manage the new heterogeneous infrastructure in a consistent and familiar way is very, very important.
That’s why we built a solution that allows you to map the entire network infrastructure in a single map context, as I mentioned. That map context then becomes the user interface for virtually any operational task. And we’re going to talk about some examples of that a little bit later on.
And so if I’m going to say something like a map can be a user interface for network operations, the network map needs to give you actionable information for any task. And teams need better access to all their data. Usually, that data is delivered through many separate tools, right? Each one of them is extremely valuable. But often, that value is hard to derive, often not as valuable as those tools could be.
The best expression of this challenge is the strip I found here of this NOC guy. We see it was easier for him to set up an assembly line for all these apps and consoles to review all his critical data. I kind of chuckled when I came across this a few weeks ago.
The way I think of this challenge is as data islands. This is when the information you need across different tools is isolated behind a login or maybe a tool that you’re not so familiar with using. And that can make it very difficult to access, particularly when you need it.
So the critical thing behind these tools is the data. And if that data is not right at your fingertips, then it’s going to be very difficult when you need it most. So each of these tools is valuable, your ticketing system, your monitoring solution, your security and event management solution. And of course, the APIC controller itself, that Himanshu discussed.
So for many of those tools, you just need to be able to use them more effectively. So the way NetBrain can solve this is through integration with all of your existing tools. We call this using the map as a single pane of glass.
Now, how many times has a vendor promised a single pane of glass? This promise is usually followed by a big screen full of dashboards, right? And I’ve never seen this approach work very well. So there’s usually an eye roll when the term single pane of glass is used.
So NetBrain takes a very different approach in two ways. First, we don’t promise all the data in a single pane of glass. It’s just too much information. Instead, we strive to make that data accessible through a single pane of glass, which means at your fingertips. And second, we believe a network map is the most intuitive context for all that data. That’s why we see this map as the user interface, like I mentioned.
So data from any one of these tools can be turned on and off, sort of dynamically, with what we call data views. Each tool can have several data views. For example, maybe performance data from SolarWinds, your open tickets from ServiceNow, or your design data from the APIC controller itself, all this displayed in the context of the device or the interface on a network map.
To show us how the NetBrain and Cisco joint solution gives teams visibility into their heterogeneous environments with quick access to all their critical data, I’d like to introduce David Femino, a Senior Solutions Engineer here at NetBrain. David.
David: Thanks, Jason. The NetBrain and Cisco ACI joint solution lets you seamlessly visualize and manage your data center where Cisco ACI is working in tandem with legacy networks. Let’s see how that works. As Jason mentioned, NetBrain discovers the ACI devices from the API controller and creates a unified work space, including both ACI and traditional device data, that represents your entire network.
So here we’ll open up the NetBrain network pane and see how that is broken down. So I can look at my physical network: my routers, switches, firewalls, etc. And then I can also switch to my Cisco ACI view. Now, NetBrain has broken down Cisco ACI into three different views, a fabric pod view, a tenant view, and an application-centric view.
In today’s webinar. We will review all three of these views. But let’s first start with the fabric pod view. So here I have all of my pod information. The pod that we’re using today has two spines, two leaves, and one APIC controller.
When I click on any of the devices within that pod, NetBrain’s system is automatically generating a context map. This context map is created to make it easy for a network engineer to be able to view the relevant information that is important to them. In this example, the fabric pod view context map is showing me the physical connectivity between all of my devices, spine, leaves, and APIC controllers.
If I go back to the network pane, I can also see various node details – properties, chassis information, fabric extender information, interfaces, and so forth. Each of these screens is also searchable so I can find the information that I need very quickly and very easily with the search functionality.
So let’s go back to the map. So this is not just a static diagram that is going to show me just the physical connectivity. This is a NetBrain dynamic map, which means that we can apply layers of information with data views.
The first example I want to show is infrastructure information. So with the click of a button, I’m able to highlight the VTEP IP addresses, BGP information, and so forth. I can also highlight other information such as maintenance – model number, serial number, and firmware.
Now, not only is this providing information for our ACI infrastructure, but I can also add my legacy devices, as well. So in this example, I want to add a few firewalls and routers. And as you can see, when I added these new devices to my map, they also have maintenance information. Maintenance information in this example is being pulled from SNMP and CLI on my traditional devices, and then once again from the APIC controller for my ACI infrastructure.
In addition, I can also view information that I’ve integrated with third-party systems. In this example, I have ServiceNow integrated with NetBrain. And I’m able to see the devices that have open incidents associated with them, as well as the incident information rather quickly.
Now let’s take a look at the tenant view. Go back to the network pane, switch to tenant view. Now your network is broken down by tenant and VRF. And the VRF we’re interested here is Prod.
Now because this is a different type of node, we get different types of context maps generated for us by the system. We have an overlay map and the underlay map. The overlay map is now going to show us the different tenant VRF and endpoint relationships.
So here we have the VRF, the bridge domains, and the different endpoints associated with it. Now just like the fabric pod view, I can also apply data views on top of it. So here I want to apply the network design data view. And this is going to highlight the different endpoint groups on my various endpoints, as well as layer two and layer three out information.
If we go back to the underlay map, that’s going to show me the underlying network devices and the interfaces configured for this VRF. This helps users quickly locate logical structures, then drill down to the corresponding components.
In an effort to maintain a consistent way of viewing information, we can also apply that same network design data view to this underlay map. By clicking the button, I can also see that I have the different endpoint groups and layer three and layer two out devices. Now back to you, Jason.
Jason: Thanks, David. As I mentioned earlier, even with Cisco ACI, a network is still a network. So it’s refreshing to see how NetBrain can restore that familiar aspect of network management with both ACI and on ACI devices mapped and managed in that familiar context.
While it’s true that a network is still a network, we can’t ignore the impact that this high degree of policy orchestration and abstraction has on network operations teams. There is still a very real learning curve that comes along with this transition to an application-centric mindset.
Operations teams will need to embrace change to successfully take over an ACI environment. Just as a network must evolve to the needs of the app, teams will need to adapt to an app-centric mindset.
With Cisco ACI, the boundary between the app and the network is more blurred than ever. Network teams need to decode this relationship between the network overlay and underlay architectures, to see the relationship between application concepts like endpoint groups and contracts and the underlying architecture, like switches and interfaces.
So in many ways, the app and network worlds do collide. To give us a look at an application-centric view of the network, how overlay and underlay structures are mapped, David Femino will give us another demo.
David: Thanks. Now, let’s explore the application-centric view. The application-centric view will help users make the transition from a network-centric approach to an application-centric approach in managing their data center network.
So we’ll go back to the network pane. And here we can see a list of all of our applications. Now, in this example, what better way to look at the dependencies of our NetBrain system? So I want to look for NetBrain Prod, and I can search for that. You may have hundreds of applications and being able to search through them very quickly is going to help out a lot.
All right, so when I found my Prod application, I have two context maps. We can see here that we have a logical structure context map, as well as the underlay map. So let’s take a look at the logical structure map first. When I open up this logical structure map, I’m going to see the three endpoint groups underneath the applications for web, database, and application.
There are several contracts to find between these endpoint groups, as well, including external firewalls. So I have a contract between app and DB, web and app, and then also a firewall to web. When I switch back to the underlay map, I’m also going to be able to see the network devices and the interfaces automatically filtered to the ones carrying the traffic for this application.
In a typical ACI deployment, a customer may have tens or hundreds of applications deployed on top of the single fabric. So without such capabilities to quickly narrow down and locate these devices, it could be very time-consuming. Back to you, Jason.
Jason: Thanks, David. We think this type of visibility and logical mapping will give network teams a big leg up as they transition to this application-centric approach to network management.
Last up, we’re going to talk about troubleshooting. One of the key challenges operations teams face when adopting a new technology like Cisco ACI can be what it takes to troubleshoot it when things go wrong.
That complexity is driven by two things. One, the learning curve we discussed and transitioning to an application-centric mindset. And two, by the constant network change Cisco ACI introduces with policy orchestration. The old methods of troubleshooting, whether it manual or with traditional tools, they’re no longer going to cut it in such a dynamic environment.
When I talk about troubleshooting, I often like to start with this slide. I think most of you would probably agree in the effort to reduce mean time to repair, the repair is actually the relatively easy part. It’s what we call the MTTI that takes the vast majority of the time.
So what’s MTTI? I think of two ways. It’s the meantime to identify the root cause of the problem. In other words, it’s the troubleshooting time. But, of course, just as often it’s the meantime to innocence, right? Of course, the network is guilty until proven innocent.
But the burden of troubleshooting is still going to fall on the network team. And then they must somehow prove it’s not the network to the rest of the teams like the application team.
Here’s a common scenario. An application is slow. And fingers are being pointed to the network team to troubleshoot it. Well, this common challenge actually gets a lot more complex with these dynamic hybrid environments. There can be hundreds of applications running across the data center for any given application. The question is, what is the network dependency?
In other words, what are the endpoints of the app? Which ports do they connect to? What devices are in the traffic path? How is that contract to find? With an infrastructure as dynamic as Cisco ACI, it can be extremely difficult to answer these questions.
To show us how the NetBrain solution for Cisco ACI can decode and provide end-to-end mapping and apply automation for troubleshooting, David will give us one more demo. David.
David: Thanks again, Jason. Now let’s take a look at how NetBrain can be used to support typical troubleshooting scenarios for ACI fabric. Let’s imagine a user calls up and they’re having issues with an application. And many times the only information they can give is the IP address of the web server. So we can use NetBrain’s path functionality to map out all of the devices along that path.
So in this example, we’re going to use the user’s gateway device as the source and then the IP address of the web server as a destination. We’re also going to use TCP port 80 because we’re only concerned about the web traffic.
So I’m going to create the path. And NetBrain is going hop by hop determining the next device along the way. And as you can see, we start off with our traditional devices and then come into the ACI fabric, all the way to the web server.
We will also able to detect information from different device types. So in this case, this firewall is permitting traffic on ACL 100. And the load balancer also has a virtual IP translation.
So let’s zoom out a little bit. And now what we want to do is just take a quick snapshot of the overall health of our devices on this map. So I’m going to run our overall health monitor and see at a quick high-level glance that everything is green. So I know that my devices are online and relatively healthy. So what could the issue be?
Remember, I mentioned the virtual IP translation. Well, let’s take this IP address and put it into our application-centric pane. So I’m going to search for that device, the 10.90.253.10. And NetBrain was able to identify the web server and it also provides me with the two context maps, the logical structure and the underlay map.
In this example, I’m going to use the underlay map to really pinpoint my underlying devices. I’m going to run the overall health monitor here, as well, just to get a quick snapshot to see if all of my devices are, in fact, online and relatively healthy.
When I click on the overall health monitor, I can see that the web server has no issues. But the app server is down. So to the user, the web server was having issues. But in reality, it was the underlying app server.
So NetBrain cannot only be used to understand ACI fabric structure and support interactive troubleshooting, it can also be used in triggered mode and perform fully automated diagnostic procedures in real time without human intervention.
So as an example, when the APIC controller detects an interface status event, it will send out a notification via REST API. So let’s imagine that I shut down port 1/35, right? NetBrain can listen for this event notification and immediately trigger the generation of a map.
So what it’s going to do is create a map, run a sequence of customizable diagnostic steps in a predefined run book, and save all the results with a map. To access that map. I’m going to go into the NetBrain system automation manager and the map is going to be created for me.
So when I open up that map, I can see a run book with two steps already executed. First, is the overall health monitor, so I can view the result here. And I can see that my spine and leaves are healthy. Okay, so that wasn’t the cause of this notification event.
Later, we also executed the show interface command. And what this is going to highlight now is the device where the event occurred, and also what the triggering event was. So in this case, Ethernet 1/35 is down. Beneath the device, we also have the show interface table. And I can scroll down to 1/35 and see that it is admin down. That was the cause of the issue. We not only are able to view the diagnostics, but we can also save them for future reference. Back to you, Jason.
Jason: Thanks, David. This really brings that topic of agility that we started with full circle. It’s not just enough to bring agility to network provisioning. Operations teams need to be agile in the way they respond to application issues.
And David’s demo really gives a sense of how much time can be spared during a potential outage. The last part of David’s demo was relatively quick. So I want to take a moment to recap how powerful that last part can be, that API trigger diagnosis from APIC.
This can be powerful, particularly for those times when you’re trying to troubleshoot intermittent issues, where there’s a problem there one minute, and it’s gone by the time you’re trying to troubleshoot it.
NetBrain can integrate into your existing troubleshooting workflow right at the beginning before tier one even has a chance to respond. This is achieved through further integration with your event management solutions. That can be APIC as David demoed, but also your monitoring or Incident Management Solutions.
This enables what we call just-in-time automation to trigger a diagnosis at the moment to that event. This will arm first-responders teams with a rich set of information they can assess immediately for those intermittent problems.
So on that note, we’ll wrap up the planned presentation for today’s webinar. I want to thank everybody on the call, again, for joining us today. We’ll be here to answer some questions for you for a little while longer. So please keep them coming in the chat window along the way, the Q&A window, I should say.
In many cases, we’ll answer those questions allowed over the phone line. So for the benefit basically of everybody on the call to hear the answers to those questions. So please feel free to stick around for a few more minutes. Otherwise, please have a great day. And thanks again for joining.