Monitoring a Juniper Contrail-Based Infrastructure


Dave Hegenbarth introduces the alliance partnership with Juniper Networks and describe the SevOne integration with Contrail.


Hi. I'm Dave Hegenbarth, Director of Systems Engineering for Global Strategic Partnerships at SevOne. Thanks for joining. The days of service providers and large enterprises buying rack after rack of specialized network computing storage, to launch a new service or application, are coming to an end. Our customers, and the market as a whole, are on a journey to software defined everything. Where network, compute, and storage, along with automation and orchestration, will allow them to innovate and deliver applications and services much quicker through a virtualized infrastructure.

At SevOne, we're committed to making that journey with our customers, and our technology partners, and provide complete performance visibility through the technology transition that is about to happen.

In this white board session, I'll introduce you to our alliance partnership with Juniper Networks and describe the integration of SevOne and Contrail. Let's go to the white board.

What I've drawn on the white board here is a deployment of software defined networks including the Contrail controllers. You'll see here that the controllers have a number of different parts and pieces. One of which is the API for north bound applications. This is our way to communicate to other applications that may want to be part of this software defined network. We also have the controllers coming down to the hypervisors. The hypervisors support the virtual machines that allow us to build virtual components through our virtual network.

Why do we do all this? It's to accelerate business applications and services for service providers across a network. Today, I'm going to describe just a high level how that's going to go on.

Let's say I have a guy who wants to build a new website. My guy over here, he's thinking up a website. He's going to need different components of this website spun up very quickly. Probably the first component we're going to need is a virtual firewall probably followed by, if we're going to be very secure, an IPS so we can do some packet inspection.

Then, because this website is going to be very popular, we'll probably put in a load balancer in case we need lots of web resources to deliver it. So we have our load balancer here. Behind that load balancer, obviously, are going to be the web sites. We have a number of servers that are serving up our website. We certainly have back end DBs. We have a number of servers that will be holding the back end database information for this website. And, maybe some more virtual servers to hold our web front end for the website.

We need this infrastructure and we need it very quickly. That's all part of the Contrail environment, to be able to spin up these resources to provide that quick response to business time for an application.

Where do these come from? These are actually all virtual instances. They are running off our virtual machines. They all have some virtual components sitting on top of that hypervisor. We've spun these guys up. Oh. We need some web servers. With a couple commands, we'll spin up some more resources. These will be VMs as well. Those guys will be what supports our databases and our web servers for this application.

We have some other parts and pieces of the network. We always have this layer 2 physical network. We have to be able to connect the hypervisors somewhere in the world. They have to be able to get places. We have and L2 and an L3 network. The great thing about the Contrail solution is that it uses just straight up IP. Each of these hypervisors will have a virtual router. They have the ability to spin up tunnels to each endpoint, allowing you to use your existing IP network, whether it's leaf-and-spine or a traditional access distribution and core network, the ability to build this service network or this service chain to deliver a website to the business very quickly.

We also have one last component I might mention. It's an edge gateway. We need these edge gateways like the MX to allow us to get to things that are not going to be virtualized in our infrastructure. We have to get to the outside world and internet access. We might even do some virtual storage. Or, we might even expand the virtual servers that drive this website into the cloud at AWS or Azure. Lastly, we have to be able to get to old legacy network gear, and other non-virtualized services we might have in the environment. The edge gateway allows us to do that.

Where does SevOne come into the equation? SevOne provides performance monitoring for this entire environment. If I draw the SevOne performance appliance solution up here, there are a number of different ways that we're going to provide visibility, performance visibility, of this software defined networking infrastructure. One is, we're going to tie into the APIs. Our tie into the API is very key because it allows us to do a couple of things. One, it allows us to give real time inventory. We have inventory of the applications and of the network virtualization services that we've spun up. We need to understand that those have come up and are important to our business immediately. Using the API from SevOne into the controller, we can understand the inventory and the topology of our software defined network, in real time. This might be my vision. Someone else might have a little different vision. They'll go about using the automation and orchestration to build whatever service chain helps them. SevOne needs to understand that topology and that new service chain in real time.

Lastly, we'll take typical traditional technologies, such as SNMP. Maybe we're going to just SNMP poll a particular firewall. This might be a Juniper Firefly virtual firewall. It could possibly be a firewall from another manufacturer, such as F5. Same thing for IPS and load balancers. They may be included, or they may be from another manufacturer. In that case, we're going to go ahead and use the SevOne technology we always have, in using something like SNMP, to get performance statistics out of these devices. It also might include logging from the IPS back into the SevOne solution. As traffic passes through, the IPS is generating logs and we're going to be able to grab performance metrics on those as well. We will also be taking flow data from the underlay network. The physical network is passing packets. It can use NetFlow to send us information about how those packets are traversing the network, the ports and protocols in use, and also the volume of traffic as it crosses our L2, L3 network.

You might say, "Hey. Contrail has some great performance statistics built into it". That is true. For the health of the original drawing I had, it's a great performance monitoring tool. How my VMs are spinning up, how many there are, and some of the usage statistics are definitely there. Where SevOne comes in, is the ability to build dash boards that combine not only those particular performance statistics, but also statistics polled or gathered in other metrics. I would put up my SevOne dash board. I might have a graph on firewalls followed by a graph on virtual connections in my load balancer. These values may be obtained via the API in some way. Or, they may be grabbed through SNMP polling. Or, again, if I had my IPS and I wanted some statistics from there, I have a graph that goes like this and this. I may get that from my logging data.

SevOne is committed to working with our partners to grab all of the performance information available in the infrastructure. Whether it comes from our legacy devices, or it comes from newly built service chains in a software defined environment, we're going to be able to give you a dash board view of the performance of the entire infrastructure.

Thank you for watching this white board session on the integration of SevOne and Juniper's Contrail software.