 Okay. So, welcome everyone. I'm Vanessa Little from VMware. This is Marcos Hernandez also from VMware and we're here to talk to you today about VMware integrated open stack with NSX policy redirection for NFV. I know we've listed this section as beginner but we do have a technical deep dive but I think we have a lot of time left in our presentation so if there's anything that you have questions about while we're in the middle of the demo please feel free to raise your hand and ask. When you do ask questions we appreciate if you could use the microphone so everyone could hear. Alright. So here's what I'd like to go over today. We'll go over the general concept of the demo and the workflow of what it is that we've built and we'd like to show you today. The various components that we've used in in our demo build. VMware vCloud NFV which uses VMware integrated open stack as a key component and VMware NSX. We'll go over the architecture of the design of the demo that we built and we'll go over the use cases and we'll do a live demo internet permitting and then we'll have a little time for Q&A at the end. So what we hope to achieve today and end to display is that we want to use VMware integrated open stack and favored in conjunction with NSX. Show of hands in the room how many of you have had your hands on an NSX deployment. Very good. That's excellent. And so we're also going to show that you can set up the applications, the networks, now the workloads using the VMware integrated open stack manager and how to how those configurations will propagate and spawn into various other components that you can use one single dashboard for configuration. Then we're going to show adding layer four to seven security services to this build and work with the NSX APIs. Using the NSX APIs to be able to configure policy-based redirection in this demo we use the four to gate, four to net firewall for an example. All right, this thing's killing me. And we'll show how that's configured with NSX manager to achieve that policy-based redirection and then we'll do a live demo. So the components in our stack today, the key component is vCloud NFV, show of hands, anyone who's even heard of this before. Pretty good. That's actually really good. So vCloud NFV is a suite of software all composed by VMware that we've built together and configured in a very specific reference architecture. And we've tuned it for specifically for NFV type workloads and it comes in two flavors. One uses vCloud director and the one that we've used today uses VMware integrated open stack. Now part of this whole suite of tools also includes our management and monitoring telemetry suite with vRealize operations, vRealize log insight and not on the slide is also vRealize network insights, formerly known as ARKIN, recently acquired by VMware. And so the VMware integrated open stack architecture, let's have the slide build here. Oops. So where did it go now? I'm having so much trouble with the clickers here. All right. So the VMware integrated open stack architecture, so what VMware has done is we've implemented vanilla open stack on top of the ESX hypervisor because as we all know, open stack doesn't really care about the hypervisor, it just needs it as a functional component. And so that's really the only difference. All of the APIs, all the northbound interfaces, even the horizon dashboard is all exactly identical to what you know and love with a few VMware logos thrown in. The advantages of doing this is that we get to use all of the existing VMware tools that already interact with our hypervisor for management, monitoring and telemetry, as well as fault tolerance, dynamic resource scheduling, et cetera, et cetera. You get to apply all of those extra tools on top of your open stack build. So that's the real key difference between the way VMware does it versus if you were to download it off the internet. VMware NSX, so this is the VMware SDN or software defined networking overlay that's used. So we've integrated NSX with the open stack build in order to leverage all of the different capabilities of NSX within your native open stack deployment. So in this demo, we demonstrate what we can do with NSX security and that we use the NetX suite of API libraries integrated with a third-party VNF, in this case, the 48 firewall, to be able to achieve policy-based routing and redirection. So this is really key for N of V environments, because in order to build a service graph, you don't want to have to have every package linearly go through each of your VNFs. You want them to only go to the VNFs where they need to go and where they belong, so that your network is efficient in scales accordingly. So this is what we're going to demonstrate to you today, that you can use the NSX policy-based redirection to point to the VNF that you need it to go to. And so the architecture of what we've built today, these are the technical specs. I'm not going to go over them in detail, but it just shows that we've built a number of VMs within a VMware deployment. We can make this deck readily available or help anyone who wants to stand this up in their own labs later on, just come see us after our lecture. And so the workflow of what we're going to show you today. First, we register for it as a security service with the NSX manager. So this is something that's NSX specific. When you want to onboard a new VNF onto it that has the NetX integrations, you register it with the NSX manager. Then we auto deploy the FortiGate VMX to all the hypervisors because it lives in the VMware kernel or it connects to the VMware kernel, it has to live on each one of the hypervisor instances. In this case, we use two physical servers and so it has to be deployed to both. Then the FortiGate VMX connects with the FortiGate VMX service manager and so this takes care of license verification and synchronization. So the FortiGate VMX manager is the master controller of all of your FortiGate policies and all of your security policies as we've defined them here. So that those policies and license verification then has to propagate to all the instances that have been deployed to the various hypervisors in your network. Finally, the redirection policy rules are updated and this pushes the FortiGate policy through your network. And then we have real-time updates of the object database. So this is really key because of the NetX integration with NSX. Any time you make a configuration within the NSX manager, it automatically propagates into the FortiGate VMX manager so that you don't have to configure all these things in two different interfaces. It unifies your dashboard into one management control plane. And finally the policy synchronization is pushed down to all the hypervisor instances as they're deployed across your network. And now Marcos is going to explain the demo build. Thank you, Vanessa. So like Vanessa said, we're going to try to spend the bulk of the presentation on the technical demo and more of a technical presentation and content. So in this demo environment, we have the usual components that you would require for vSphere operations. We have a vCenter that is managing three vSphere clusters. One for management, one for edge services, and one for compute. The compute cluster is where your OpenStack instances are going to land. When you boot instances using Nova, they will land on that specific cluster, which in this particular demo environment has two nodes. And this is also the cluster where we're going to put the VNF from Fortinet in this example. We also integrate with a number of other security vendors and next generation firewall vendors. Fortinet is one of our leading solutions and partners. So that's why we decided to include it here in this demo. So since we have two compute nodes in this compute cluster, we will need one VM from Fortinet, one VNF from Fortinet on each node in that cluster for a total of two. And then I'll explain later what happens inside of the kernel when NSX does redirection of the interest in traffic. The edge cluster is where your OpenStack routers will reside. When you create a neutron router in OpenStack using standard API calls, the NSX plugin will in turn instigate the creation of what is known as an NSX Edge Services Gateway. We support both centralized routing and distributed routing services in NSX, all consumable from the standard neutron API. And then in the management cluster, we have the vCenter, as I mentioned, we have the NSX control and management plane in the responsible for all the operations of NSX. And we also have the OpenStack control plane itself. This is where VIO resides. And in this build, we have VIO 3.0, which is seven VMs that make up that control plane and that can scale to the maximums of a single vCenter. That is a thousand hypervisors and however many VMs you can cram into that. So it's a very simple environment, but it's a representation of what you would see in production. Because when we do this with actual customer deployment, this is the distribution of clusters and configuration that we recommend as a best practice. We want functional clusters for management services. We want functional clusters for North-South routing services or bridging services because our plugin also supports an L2 bridge. And then we want your compute clusters, your payload clusters for the OpenStack instances to be separate. And those will be controlled by Nova Compute. So even though this is a demo environment that is using NSXI, it's just a micro representation of what you would see in very, very large environments with hundreds of hypervisors and thousands of VMs. So as part of the preparation and the prerequisites for doing NSX, we have to do something called host preparation. And this is nothing more than a kernel update. We take this compute node, which are going to be hosting my OpenStack instances, need to be prepared for NSX. And that is a kernel update that installs some, like I said, kernel updates that make all the distributed data plane services at NSX support possible. That includes VXLAN, VIP, or VXLAN kernel update for overlay networking, distributed firewall kernel update, which is used by neutral security groups to create East-West segmentation policy and micro segmentation from OpenStack. And we also have a distributed routing kernel module that allows for the hypervisor to become a router for the VMs hosted within that hypervisor. So this is host preparation. And this all has to be done prior to the VMware integrated OpenStack integration. And it's also a prerequisite for doing service redirection with any of our partners, including Fortinet. That is showing the representation of the cluster. There's also this notion of a transport zone. This is extremely critical. In NSX, a transport zone is a logical construct that defines the diameter of your logical networks and your secure, of your logical networks, not necessarily the security policies, but of your logical networks. So in the simplest form, a transport zone will include all the clusters that will be used in NSX services. So we have a management cluster. We have a net cluster and compute cluster. So potentially all these three clusters could be included. You don't necessarily need to include the management cluster because there are no live tenant VMs that will be running there. It's just control plane interactions. But you could do that if you want to protect that management cluster with micro segmentation policy. So that's completely up to you. But the edge cluster and the compute cluster need to be part of this notion of a transport zone. And that is what makes possible for NSX to exchange services across this element. Okay. So let's go ahead and jump over to the live demo because we have time to show what we've done here. And hopefully the internet connection will work. So we're going to log into vCenter and I'm going to show you a setup. Hopefully that's not an eye chart. While I do this and while I log, I just want to bring to your attention that we're working, what we're showing here is possible right now. It's a way that you would do service redirection in an NFV environment or a non-NFV environment using NSX and OpenStack today. There are some caveats though. The assumption here is that the cloud administrator has completely relinquished network and security controls from the tenant. The tenant is using OpenStack to launch VMs, interact with the computer and storage APIs, but network and security remain in the hands of the network and security teams. So what that means is that we're going to be doing some things in OpenStack for computer and storage services, but when it comes to network and security, that's going to be happening directly in NSX. And that is possible today. It's a way to consume advanced security services in an OpenStack deployment today. As you may or may not know, neutral security groups, which are the preferred way of doing implemented security in OpenStack, are only layer three, layer four, aware. So with neutral security groups, you can protect a network or a VM from talking on Port 80, for example. But there's no native way in OpenStack to actually determine that what's right in Port 80 is HTTP traffic. There's no visibility. So NSX does have a capability via third-party integration with Fortinet to discern application traffic and create policy to secure your application by looking at the actual layer five through seven traffic and for your in your east-west implementation. And if I could just interject here. Please. So this is really key in service provider NFV deployments because they're multi-tenant deployments and you don't want to have inter-tenant communication happening. You don't want to have one malicious tenant that's able to compromise other tenants. Using using this type of topology on an OpenStack environment, this is actually possible with normal neutron networking. This is not yet possible. Yeah. And the key word there is not yet possible. But it's going to be possible. We're very fortunate that we have here in the room two of our top leading neutron engineers. So I did and Gary are working. They're here. They're great contributors to a neutron community. So if you have some questions about the road map and the things that we're working on, they're the people that you need to talk to. And they've been working on an implementation that will elevate to neutron the consumption of these redirection services. And we are currently in the process of testing and validating the various use cases. So very soon, and this will be incorporated into VIO natively when you integrate it with NSX, very soon it will be possible. Everything that we're showing you today outside of OpenStack will be possible inside of OpenStack. So a tenant or a network and security admin will be able to consume redirection security policies without bypassing the API, which is a preferred way of doing a cloud. Right. If you're doing OpenStack, that should be your one and only entry point for your consumption. But there are some customers that want to do redirection today and they don't necessarily, they cannot wait for neutron to have all of these capabilities. So what we're showing is what's possible today. But I just want to point out something extremely important that we are absolutely working in promoting all these services and consumption to neutron. So you don't have to do it at the NSX layer. Hopefully that is clear. And I did in Gary here and they can share some more details of what we're working on. So again, that's kind of an eye chart, but these are the clusters that we were referencing earlier. We have an edge cluster for neutron routers, compute clusters for any instances, and then the management cluster and they have been prepared for NSX, compute and edge have. What we've done here under service deployment, okay, I better hurry up. Under service deployment, we have deployed the 40 net solution. So the 40 net solution has registered with NSX. And now NSX and 40 net are linked. So every time that I do something in NSX that is related to security policies that I want to redirect, the 40 net solution will actually fetch that information from NSX and two-way communication between the solutions will be possible. So let me walk you. We're going to leave NSX, this is the NSX UI. We're going to leave NSX for now. Excuse me. We're going to leave NSX and we're going to go to OpenStack. So let's go ahead and log into OpenStack and let me show you something very important here. In this particular demo, in this particular environment, I am not using Neutral Security Groups. Okay. Remember, all security operations are not happening in OpenStack. They're being controlled from NSX. So Neutral Security Groups do not apply. So what I've done is for the VMs that I want to put under the NSX solution and traffic, the traffic for those VMs redirect to the 40-net VNF, for those VMs, I have detached the Neutral Security Group from the VNIC of that VM. If you look at it, if we edit, for example, this web server, and I'll show you a topology in a minute, and we do edit security groups, you will see that there are no security groups attached to this particular VM. So again, very, very important, we're bypassing Neutral Security Groups all together and affecting security directly on NSX. This is possible only in Mitaka, to be able to create VMs that do not have a security group association. It was possible before Mitaka, but you have to do some massaging of the, with Neutral Ports and things like that. In Mitaka, Mitaka made it really, really easy to launch VMs with no security group association. So again, I'm repeating myself, but this is very important. We are bypassing the security in OpenStack and interacting directly with NSX. And the topology that we have in this environment is very simple. Let me show you just curve it here real quick. And you will see the topology here. So it's a two tier app that has a router connecting two networks, DBNet, where a DBVM has been created, and WebNet, where two web servers have been created. So a very, very simplistic, very, very easy to understand two tier app. Two web servers connecting to a router that connects to the backend database server. I've done this in purpose. I've named these VMs. The name that I've created for these VMs, for all three of them, have a common prefix of DMZ. Keep that in mind. Make a mental note of that, because later when we create the security and redirection policy, we're going to reference the VM name as our classification mechanism. Okay. So very simple to tier topology as seen from OpenStack. So two key points. No neutral security groups. This is like the fifth time I mentioned that. And meaning that all the security services are being controlled by the firewall team. So now I am going to impersonate the firewall team. I'm going to go back to NSX. And I am going to take you here to Service Composer. Service Composer is a utility in NSX that allows, implemented a wizard-based approach allows you to create security policies very, very easily. I have created a security group called virtual DMZ. And let's see what's in that security group. If I edit the security group, I will see here that, okay. No. No. Yay, live demos. Yeah. It's okay. I don't freak out anymore. It happens all the time. So in this security group, a security group in NSX is just a wrapper. It's a bubble that aggregates VMs. VMs enter and leave that security group based on a membership criteria. Okay. In this case, the membership criteria is the VM name. I'm saying, if a VM is created with a name that contains anywhere in that name, the DMZ, the letters DMZ, that VM will be associated with the security group. Right? Just like I can use VMs. I can use operating system names. I can use any attribute that describes that VM as seen by vCenter is fair gain to create a classification policy. Right now, there's no security policy. I'm just identifying which VMs will be subject to my security policy, and that is done with a security group and the membership criteria of that security group. The membership could also be static. I could statically assign VMs to that security group. But dynamic inclusion is more flexible because you don't have to, for environments where VMs appear and disappear, where VMs are created and destroyed, the action of these VMs, the fact or the mere act of these VMs coming and going, if you use dynamic membership means that you don't have to reconfigure your security policy every time a new VM is added. This is a very, very, very popular application with NSX, dynamic membership. And this is a policy language in NSX that allows you to create firewall policy that looks like your business. You can say, okay, this is my DMC security group. This is my web. This is my DV. I'm not creating policy based on IP addresses. So my security policy is going to look like my business. My security policy is not going to look like my network. When you look at a firewall today, it's a bunch of IPs, and if you don't have an Excel spreadsheet to translate what 10.10.10.1 is, you don't know what your security policy is. So that is a security group. So I have three VMs that satisfy that membership criteria. There they are. If I were to create a fourth, a fifth, a sixth one, they would be automatically added. As long as they satisfy, they meet the membership criteria for the dynamic conclusion. Okay? So those are my three VMs. Web one, web two, and my DV VM. Now let's move on to security policies. Security policies, I have one here called redirect DMC. Okay? Let's go ahead and edit this. A security policy is the security policy. What I'm doing is I'm taking the VMs that I already classified in a security group, and now I am going to apply a consistent security policy to them. And that security policy will control the entire life cycle, security life cycle of that app. So we have guest introspection services. I'm not using that in this example, but NSXF services that actually look into the guest and do guest-level protection. We're going to bypass that. You can create firewall rules in the distributed firewall. This is our east-west internal firewall. You can say, okay, this is how broad it's going to talk to test, or how my DMC is going to talk to the internet. You can do that with very broad and coarse firewall policies created in the firewall rules. But for the purpose of the demo, and because probably this is the first time that many of you see this, I kept it very simple. This is not a very realistic example. This is not how we see it in production. This is just for the purpose of the demo. If you notice here, there's something called network introspection services. Network introspection is where I create the redirection policy to the third-party VNF, in this case, Fortinet. And what I have here is an outbound and an inbound redirection policy where I am redirecting all the traffic to Fortinet. Basically the firewall in NSX is not being used. It's a bypass. I am redirecting everything to Fortinet. This is not, and I need to emphasize this, this is not the way, typically, that customers will do this. Typically, redirection will be of only a fraction of your traffic. You will only redirect high-risk traffic that you want to inspect. You only redirect a portion of the traffic. And then the security for the rest of the traffic is handled by the internal NSX firewall. We don't need to punt or redirect that to Fortinet. But here, for the purpose of the demo, I'm redirecting everything to Fortinet. So basically NSX is just a bump in the wire. Okay? So let's take a look at Fortinet now. So every single packet that is generated or received by the web VMs and the DVVMs will be redirected to Fortinet. So let's see what we can do here in Fortinet. So now I, and remember, I'm still the firewall guy, right? And I'm controlling the security policies. So in Fortinet, let's change the domain where we're operating. We have a domain called NSX. And here, under policy and objects, let me show you first addresses. There is, right there, a address group in Fortinet called virtual DMC. This was automatically synchronized with NSX when I created that first security group, where I put my DMC VMs. This happens with no intervention from the security operator. I create a security group in Fortinet. I create a redirection policy and that security group automatically appears on the Fortinet solution. And the three IP addresses for the three VMs in that security group are also automatically synchronized and reconciled. So we can see there the two web servers and the IP address for the database server. So this is one of the great, and this is in the workflow that Vanessa was describing. It was step number two, actually the last step in the integration process is constant two-way communication between Fortinet and NSX manager where all these objects are synchronized. So now Fortinet knows about the VMs. It knows about the IP addresses of those VMs in that security group. And with that group, I can create a policy just to keep it very, very simple so I don't have to mark around with like firewall rules because I don't think that would be like too interesting. What I've done is I've allowed everything through the Fortinet firewall. So let's take a step back. NSX is redirecting everything to Fortinet and Fortinet in the firewall is allowing everything in and out of the environment. So essentially I don't have any firewall rules. But I have enabled an anti-virus security policy for the inbound and outbound traffic. Okay? And again, this is not very realistic. Like I mentioned a few minutes ago, in a real deployment you would see a combination of east-west security rules of the NSX firewall, east-west security rules of the Fortinet or VNF firewall, and then maybe some additional introspection services like Network AV, IPS, IDS, it all depends on the capabilities of the VNF. But because this is a demo and I didn't want to overwhelm you with information, we kept it very simple and what we're going to be using in Fortinet is the AV engine. Okay, we're just looking at antivirus. Okay? So I'm no longer the security admin. I am now an irresponsible user in the DMC, right? And I am going to a website, again, very hard to read, but trust me when I tell you this, it's just a Wget. I'm just going to browse a website and download a file. And if you can read from where you're sitting, it's an iCar file. Who here is familiar with iCar? Yeah, it's Europe, so you guys invented it, right? So it's a file that looks and feels like a virus, but it's not a virus and it's used to test your antivirus policy. So I am going to fetch that file off of the internet right now. So let me go ahead and do that, right? So the file was downloaded, but if I explore the contents of that file, I can see that in a browser, this would be rendered better. It would be readable, but basically 40 net because it's in the path, identify that as a virus and basically rewrote or rewrite the HTML. And now when I render that file in my browser, I see a big warning that says, file blocked, you're downloading a virus. So this proves that, a number of things, right? This proves that is West protection and a protocol application layer is possible via netx integration with NSX and also possible with OpenStack, assuming of course that the end user of OpenStack is not in charge of the security life cycle of the app, right? Which is, by the way, a very, very common practice for with some enterprise OpenStack customers. They only expose certain API services to the application users but retain control of the network and security policies. When our engineering teams promotes to Neutron all this redirection capabilities, it will be possible to do everything from OpenStack. So at that point, the tenants will also be able to create their own redirection policies if the cloud admin allows them to do so, okay? So the last thing that we wanted to show was V-Rubs, right? A little bit of monitoring. Hopefully, network operations, monitoring troubleshooting is not an afterthought in your deployment and you're also taking into account that once you get an OpenStack cloud with all the services, you've got to monitor and troubleshoot it. So we have a solution with V-Realize operations and what we call a management pack that integrates services for NSX and OpenStack. So we don't have time to show you everything in V-Realize operations, but let me just pull one of the most useful dashboards that we, our customers use in V-Realize operations and this is the NSX object path. There used to be this notion that because NSX uses overlays and there was some concern, there were some concerns that network administrators would lose visibility by using overlays because I'm not using V-Lens anymore, I'm using something else, I don't see my network, I don't understand my topologies. So to address those concerns, we have a number of tools. There's one called V-Realize Network Insight which has been mentioned a few times throughout the day today and we have V-Realize operations. In this case, this particular dashboard is showing me the logical relationship. I'm gonna click on Web Server 1 and I'm also, and then, let me just select that and let me click on Database Server 2, okay? Database Server 1, I'm sorry, Database Server and Web Server 1. So I'm selecting two VMs and I wanna see the logical and physical relationship between those two VMs. So this particular map is showing me here and I'm sorry, I apologize, it's hard to see. It shows me the VM, it shows me the logical switch, AKA the network that that VM is connected to, it showed me the router that separates the Web VM from the Database VM, it showed me the networks on the other side and it also shows me the other endpoint. There's a little firewall icon there that if I were to expand would actually tell me which firewall rules are being applied to the traffic between those two VMs. So this is the logical view and relationship from an overlay NSX perspective. We also have a physical view, which is probably gonna, it's gonna show blank. This is a nested environment, so we cannot display real switches and routers, but V-RUPS also have an SNMP CDP LDP hook into the physical infrastructure and we are able to paint the physical topology separating these two VMs. Again, the caveat here is that this is a nested live environment, so there are no real switches, so we cannot display that. But this is just a little bit of a taste of what is possible with some of the tools that are provided by VMWare for day two operations and troubleshooting. So hopefully that's a good demo and I think we're gonna take questions now or? In a minute. So right before we skip the questions, so I just wanna make sure that we put this in the context of NFV. What we've shown here is a very simple use case where we had a virus pass through a certain server and it was caught by a redirect rule. If you think of this in an NFV context, previously you were able to do this policy-based redirection only at layer three. If it's coming from this IP on this port, then go this way. Now we can do it through layer four through seven so we can have more of a logical service graph built out based on hostname, IP, or origination, destination, protocol, or even a sample of the data payload can all be factors that determine where the packets are going. And this lets you build a lot more, you can have a very simple interface to build a very complex service graph which as we all know in the mobility space the service graphs can get pretty intense. By being able to do it like this with this tool, it makes a very simple logical and a graphical interface where you can actually see where your packets are going and how your network is physically laid out without having to sit there and examine every IP and net flow with a complex tool. So with that, any questions? And if you have questions please, if you can come up to the mic so we can get them. Ask a question, get a t-shirt. Any questions about NFV topologies in general? So the question was where is the Fortinet firewall in that logical diagram? And that's a great question. Yep, the Fortinet firewall in that diagram or in the topology, and I'll show it to you, is in the compute cluster. So, kind of read my mind, I was gonna show you that anyways. It's in the compute cluster. So I have a compute cluster here with two hosts, right? And this, under this resource group called ESXagent, I have one, two Fortinet VMs, one per host. So NSX in the kernel redirects the interest in traffic to this VMs. And those are the VMs that actually do, in the case of demo, the AV inspection, the antivirus inspection. We need, in our architecture, for the standalone NSX case, for the OpenStack use case, and for the NFV use case, it's always the same, it's always the same. We need one VNF, we need one next generation firewall per compute cluster. But it's only where your OpenStack instances are located. Right, and we do this at a cluster level. You don't have to do it across your entire OpenStack infrastructure, you can only do it on the clusters that are high risk, if you will. And that you want to, where you wanna see more of a protocol view of the east-west traffic. Yeah, and this integration with NSX is key. So when you think about traditional firewall topologies, your firewall sat kind of outside of your compute network, and all of your traffic had to hairpin through it, and then come back in. Because the firewall is integrated directly with a hypervisor kernel, and it exists on each physical host, that traffic doesn't go anywhere. It's validated directly on that host, right away. Absolutely, so hopefully that answers the question. Okay, the management console for all this is in the management, when I logged into this website, or into this console, configuration console, this is in the management cluster. I'm managing those VMs for Fortinet in the compute cluster. So one, the Fortinet VMs are in the data path. This view here is another VM that is not in the data path, it's just management plane. So that's the architecture. Any other question, comment? Okay, you want me to take that one? Yeah, sorry. So the question is, can I redirect traffic to a physical firewall instead of a logical or virtual firewall? The answer is no. I mean, right now, the redirection in the kernel is not a network redirection. And once you understand how netx redirection works, you will see why that is like it is. This redirection is not a network redirection. The packet that gets redirected or the redirection is not done based on destination IP, destination MAC, none of that. Actually, the redirection happens before the packet touches the software switch, in this case called virtual distributed switch, the software switch that exists inside of the hypervisor. It's not networkless, I should say. So because of that, and the redirection happens in the kernel, we're doing it to a service VM that is connected to that hypervisor. With that said, we are looking into solutions with our next generation firewalls, such as Palo Alto and Fortinet, to implement a redirection policy and a redirection strategy that actually sends that traffic to the physical firewall. What exists today, and this is true for all of our major third party firewall vendors that integrate into the kernel, into NSX with NETX. What is true today is that once you create a policy that applies to your virtual environment, all the solutions synchronize that policy with the physical environment. Palo Alto, for example, calls that notify groups. So when you create something that applies to a virtual firewall, they can take the exact same policy and apply to a physical, creating the illusion of single policy across virtual and physical, right? So and the same is true with Checkpoint and Fortinet. You can reconcile the security policy that you have in the virtual with the physical. So that creates that notion of single pane of management for the firewall and for the security policy. And it's also important to note that while you can't redirect to a physical firewall today using this type of configuration, if you just wanna do it with straight layer too, you absolutely can. Exactly. Network redirection as we've been doing for 20 years is still possible here. Just send it, send the IP packet to the next hop and then cross your fingers that that next hop will enforce whatever security policy in the service chain, right? Any other question? Okay, well thanks everybody for coming and feel free to sneak up front and collect your shirts. We don't have to take them all home and see either one of us if you have any questions after our talk. Thank you.