 All right. Good morning, folks. Welcome to our presentation here. Let's get started. We'll talk about multi-tenant traffic visibility and why is it important in an open-stack environment, primarily for enterprises as customers move into the enterprise clouds, and also for the service providers and carriers, especially in NFVI architecture. I am Sesh, one of the product managers on the portfolio. Why traffic visibility? Why is it important? Primarily because network traffic doesn't lie. I mean, you can look at all the log data that you want, but traffic itself is the source of the truth. So we need that. Thank you, sir, for cheering me on. And modern data center and security tools rely on this traffic for analysis, right? I mean, logs are at point in time, but this gives you a lot more. You can peek into the traffic for inspection. And mobile operators, especially as they serve as subscribers, a lot of these subscribers need this traffic for analysis or providing better services for their customers, so they could also use this traffic for analysis. And finally, I mean, we don't want to say anything negative about log data. You still need that for alarms and events and so on, but we believe traffic augmented with log data will give you your entire picture into your network. And why do you need pervasive monitoring, right? And here are some use cases, increasing threats, right? You cannot secure what you cannot see. So logs may give you that data a little bit, but not the entire packet information that you want to capture and analyze. Next use case, you've got your distributed applications that have east-west traffic patterns, where these VMs are migrating across your entire infrastructure. How do you, as they propagate through this infrastructure, how do you visualize them, or how do you inspect that traffic? All these new blind spots, VXLAN, anybody using VXLAN here or looking at overlay technologies? There you go, how do you get your tools to be offloaded? They don't have to do the inspection. How can we help you with that as well? So these blind spots, they're optimized. They're optimized because those overlay technologies help you, but we also want to make sure the investments that you have preserved in your tools can still be applied for those new traffic patterns. And then finally, NFE. We are here at OpenStack Summit. There's a lot of NFE discussion. There's a lot of overlay discussions with SDN and OpenStack and KVM. And as you consider migrating to this infrastructure, you want to maintain your visibility across that spectrum as well. So again, the key drivers, security, application performance, as well as NFE monitoring for subscribers. These are the core tenants, what we would say, need visibility into that traffic. All right, so let's, if I can get this. OK, who deploys Gigamon? How many have you heard of Gigamon? All right, well, that's cool. That's great. So again, here's, you know, we are in a lot of these institutions that I won't read through them, but we are in the Fortune 100. All kinds of customer base here with all the verticals. So we've been deployed there. But these customers are now migrating over into the virtual infrastructure. Both VMWare environments, OpenStack environments and others, and they need this continuous visibility as they migrate to the next business infrastructure. But we're not doing this by ourselves, right? We are helping the tools optimize with the traffic that we provide them. We have our friends from Viabi here who also, and I'll walk through a demo with them, that we have integrated with their ecosystem as well to follow these tools. We also are working with RSA, the security analytics company, to get this traffic as well. So rich set of these tools. If you are a customer who recognize these tools, obviously you would need these packets to analyze them. Anybody recognize these tools in the environments that you have? That's cool. So finally, what are the challenges? Why did we get into this place? Why are we in the OpenStack Summit talking about this? Let's click through some use cases. If you have a typical server, your tier one server that is physical, you could span the traffic or tap the traffic and then inspect it. But if you virtualize that same server now with high consolidation ratios going anywhere from 10 to 100 per host, you get this kind of deployment where this east-west traffic is a blind spot. Nobody's inspecting that. How do you get that traffic to be to your tools for analysis? So this is where Gigamon fits in to solve that specific challenge. Again, security, application, and VNF monitoring, all of them who deploy this OpenStack infrastructure need that visibility. So here is how we have some of the customers have tried to address it. They might put these virtual probes on each of your hypervisors. Now, that's a good solution temporarily, but it takes up space on the host. It eats into your consolidation ratios. And if you want to put in the new tool to monitor that, that becomes a challenge. So a better approach is actually get one probe, or one virtual tap, if you will, in the hypervisor and get the traffic for all the tools that need it. So you only grab the traffic once from the virtual infrastructure and deliver to all your monitoring tools that need it. The other advantage of this is, as you scale to new infrastructures or new tools that need this, you just plug into the Gigamon infrastructure and they have that traffic readily available. So you don't have to go into the hypervisor and do anything there. So if you take it about a 1,000 foot level or 10,000 foot level, here's how it would look in a typical deployment. You deploy a gig of UVM. We're calling this a virtual tap, if you will, a Gigamon virtual machine that gets the traffic from the hypervisor and then routes it over your production network into your visibility fabric that can provide to the tools. So you're using your own production infrastructure for your traffic analysis as well. Now, some of the customers that we have spoken to also, let me build one more, are also physical. I mean, the database servers, for example, haven't migrated over to the virtual infrastructure. So it's not just within the hypervisor, but in some cases it could be a hypervisor to a database server that needs this visibility. Now, this is not a all virtual solution, even though you could deploy it. It is a combination of intelligence at the edge, get the traffic from the virtual hypervisor, and then also some traffic optimization on our hardware appliances so your tools get better visualization of the traffic. That's all great. So we've had the solution with VMware, ESX, NSX for a while, but over the last one year, we've been looking at OpenStack. As OpenStack has taken on, it's become pretty prevalent in the enterprise and service providers. How do you get this visibility? Some of the challenges with OpenStack itself is it's tenant-friendly, very tenant-friendly, in which case you as a tenant cannot go to your operator and say, give me port mirroring. Give me that traffic, because then that becomes a barrier to entry, in which case how do you get visibility? That's what we're trying to solve here. We looked at two use cases. We proposed TAP as a service. Anil here, our distinguished engineer from Gigamon. Wave, Anil. So he has a speech today. He has a discussion with a couple of the vendors today, later in the evening, to talk about TAP as a service as well. But while that's going on through the OpenStack community, we also were looking at what are the other options available. So we came up with an alternate approach called intelligence of the edge visibility, where you get the traffic right in the VM itself and then analyze it, while we still are investing in TAP as a service for it to be adopted in the community. Once we have that, you need an orchestration. How do you integrate with OpenStack itself? And that's where our centralized orchestration layer will integrate with OpenStack to configure these traffic policies. And then finally, that traffic, once it is captured from the virtual infrastructure, can be optimized by our visibility fabric nodes before delivering it to the tools. So it's an intelligence of the edge layer with a traffic optimization layer before the tool is inspected. So a holistic solution for scale, as well as reach. So here is how it works. I mean, obviously this is a TAP as a service. Again, Anil will talk about this today, the plan is to get into OpenStack as part of the end release, and hopefully you guys can listen into that speech. Quick plug for that, it's at 4.10 today. So I know a lot of people have stopped by our booth and asked about that, or you can talk to Anil after the session and talk to him as well. But while that is going on, here is what we are looking at, the intelligence of the edge and core. So here's a solution. It's a light footprint agent that sits in the target virtual machine. It could be packaged into your VM itself as part of a glance repository image, and every VM that gets spun up can have this agent in. It can do filtering and sampling as well. So you got the traffic at the edge. You can aggregate it into our virtual gigaview VM, which then can do the forwarding of the traffic to the physical infrastructure where the optimizations happen. So you can look for optimized traffic with SSL decryption. For example, GTP correlation for subscriber awareness. You can generate metadata out of that. You can optimize the traffic before the tools inspect it. So the tools are not burdened with all these optimizations. They're doing their best job and we can help them with that. So that's our solution today. It's available. It's GA right now. I'll walk through a quick demo of that as well. But before that, as we talked about it, this is a sense feeding the tools. The tools have to be on board on this. So we have two use cases. Sorry. Two use cases. One with RSA, who are a security analytics company, a vendor, obviously. They take this traffic and feed it in the security analytics infrastructure for securing the OpenStack private clouds. That's one use case. But the second important use case, probably most of you are also familiar, is the NFVI space, where you have a bunch of virtual network functions. Now how many of you are in the VNFs going into VNF environments? So this VNFs, where you actually have to need this monitoring solutions, you deploy this agent, aggregate the virtual traffic, and then deliver it to the tools. So that's where you get your visibility into your VNF. So as your P gateways or S gateways scale out, you can also deploy this as well. So a quick version. This is your before view, where as you virtualize all your VNF functions, like IMS or EPC, got all these blind spots now that you cannot inspect. But the new normal, after deploying the Gigamon solution, is now you got it covered. So you don't have any blind spots, and that'll help you get your full inspection with subscriber awareness if needed. So the before and the after picture of how the visibility can help your infrastructure. So the other advantage, obviously, also is as you roll out new services, you can use this infrastructure to inspect it before providing subscriber services as well. So I'm gonna walk through a demo here with our friends, Viavi, they're here. So if you wanna stop by and ask them how this integration work, we'll do that. So give me one second here. So here's a case where we have deployed a SIP application, a voice application, and put an agent in there to get the voice traffic over, aggregated it at the Gigaview VM virtual layer, orchestrated by the fabric manager for all these virtual policies, and then feeding it to the tools. That's the Viavi monitoring suite that looks at the traffic. All of you recognize this picture, this is Liberty with the SIP server and the SIP client, talking to the service, with the virtual traffic visibility node and an orchestration platform also in the same cloud, and also the Viavi set of tools that are inspecting this traffic. Here's a quick preview of the fabric manager, which is a centralized orchestration platform. It has integration with multiple clouds, VMware, ESX, NSX, and OpenStack, where you can define these traffic policies for inspecting the traffic. So here's a good example of where we're capturing SIP traffic with the capture rule of getting all the traffic over. A quick layout of where the ingress and where the destination tool is. There's a quick view of that. And then finally, we're gonna initiate some SIP traffic, generate a PN and SIPC traffic, and then we wanna inspect that and then deliver it to a tool. And here's the Viavi analyzer itself that is looking at the performance analyzer and then getting that traffic and inspecting it on the fly. So this way, as you look at any call drops or anything like that, you can monitor it through the Viavi application. And if you wanna double click a little bit deeper into that inspection, you got that as well. So this is a holistic system of capturing at the edge, delivering it to the tool, and all of it with gigamon orchestrating this infrastructure. That way, your call services can be inspected. So that's pretty much what I had with the demo. Let me go back and summarize some key benefits here. Again, as you consider migrating into this infrastructure, you're looking at maintaining compliance, security, and monitoring as you migrate over from the new infrastructure. You got your optimized monitoring tools themselves. You don't have to have probes. You can inspect it centrally and then forward it to the tools for analysis. Remote data centers. Most customers have a centralized code and a remote data center that you need to grab the traffic as well. So this also allows you to do that function. So if you have a remote open stack cloud that needs to forward traffic into a centralized open stack infrastructure, you got that. Multi-hypervisor support. A quick show of hands. How many of you use EMware and open stack in your deployments? Cool. So I guess either for new applications, greenfield, brownfield, but again, you got covered from both sides. And obviously we also have a thought leadership working with the open stack community as well. Again, just a quick plug for the tap of the service discussion. So if you want to attend that and get more details, more than welcome to do that. That's all I had. Thanks for your time. We're all here. So if you have any specific questions on how this can help, hang out and we'll talk more. Thank you very much. Appreciate your time.