 Good morning. Oh boy the volume's up on this now Good morning again. Thanks for those of you who stayed over from our last session Welcome to those of you who are joining us for the first time this morning. My name is Gary. I'm gonna be your Guide through Cisco's topics today in our sponsored track session. We just finished up with Lou Tucker We've got our Cisco advanced networking session up now We have the morning break and then there will be two more sessions Before between the break and lunch, so I hope you can join us for that To save all of you a lot of time snapping pictures of the screens All of these slides Will be up on slide share it within a couple of days and and Shannon slides that are coming up in this presentation Are up there now, so feel free to not take pictures of the presentation screens So with that I'm gonna introduce our First presenter, so we do have two topics today in this session and McCormick Who is one of our technical leaders on the networking side is going to be doing her talk on? Thank you We're both we're both suffering sinus problems today And then Shannon is going to be up for the second half of the 40 minutes talking about IPv6 and apparently Shannon It's a real thing okay, so With that I'm gonna turn it over to Anne. Oh, and by the way as you leave Don't forget to grab your Cisco runs on open stack running socks, okay They'll be at that door out there as you're on your way out, so thank you for coming and it's all yours Okay, great testing. All right. I think I'm on Good morning. It's Wednesday at the open stack summit. Does anybody have any brain cells left? I'm hoping to have oh, okay I'm hoping to have just enough to get through this talk, so sir. I may need to call on you in the front row I hope you know something about VPP You're probably wondering about my wardrobe choice, so in the Boston area. We don't have much for history We have a historic sicko sign, so I bring you the famous gas sign The other reason why I'm wearing this shirt is because I was really hoping for a green screen behind me So that I could just be this weird floating head talking about geeky things, but we're just gonna have to go with it Cuz that didn't happen Good morning. My name is Anne McCormick. I'm a technical leader at Cisco. I work on metacloud deployments Imstick. Well, let me start with what metacloud is. We're an on-prem managed private cloud solution Managed meaning that metacloud goes in with their awesome ops team Installs their deployments and then continues to maintain them going forward for things like upgrades And what I do in particular at metacloud is to bring in Cisco technology into the open stack deployments Basically bringing in the power of Cisco networking into open stack So I should probably also mention what the heck I'm talking about. So fast data and packet processing virtual but for reals So how do we achieve fast data and packet processing on a virtualized platform? For that I give you vector packet processing VPP and For a quick overview What is VPP? It's basically open source optimized packet processing it can provide virtualized switching and routing for the layer 3 it supports cloud NFV and SDN deployments It can run on commodity CPUs and this is really important because basically that means Customers for their hardware assuming that the hardware supports DP DK VPP can run on it and optimize things VPP was initially developed by Cisco Donated to the Fido foundation the Linux foundation fast fast data IO project Fido includes other projects as well And my understanding is that some if not all of them have something to do with DP DK the data plane development kid and Cisco is still an active contributor to VPP So what does VPP do if you look at my handy dandy diagram here on the right? You can see that as packets come into the nick the DP DK. That is such a mouthful. I'm sorry. I'm trying DK press the process of the packets throws it into huge pages in the Linux kernel memory then the VPP stack comes along and Takes the packets out of huge out of the huge pages But what's important here is that it doesn't take them out individually It takes them out as a vector of packets meaning basically a whole chunk of them to be processed Simultaneously and what that does is it reduces context switching and it increases cash efficiency. So this is where the optimizations come in And I wanted to mention that VPP is modular. So as new protocol support is being added It's very easy to put it in and There's two existing stacks today One is networking VPP for the OpenStack integration OpenStack, which we all know and love OP NFV, which is open platforms for NFV basically open daylight. Those are the two existing stacks What's the status of VPP? Networking VPP, which as I mentioned is the OpenStack integration is currently on release 1704 Which gave us L3 support VX LAN GPE role-based access control and graceful restart The next release which is coming down the pike brings us security improvements things like remote group ID support It also brings us better L3 HA multiple routers and VRRP virtual routing redundancy protocol VPP will be included in popular distributions in the future and I was told to be vague here so there you go and Partners are as we speak adding support for new stacks. I'd love to tell you all about this But I'd have to kill you so let me move on to what I can tell you which is VPP is available now on MetaCloud deployments So let's talk about VPP on MetaCloud. What is it by us? It allows MetaCloud to take advantage of L3 fast packet processing In the case of MetaCloud We use the N9K and the ASR router as hardware platforms to Really speed things up But we use VPP for the packet processing and the use cases for VPP on MetaCloud are for NFV deployments high performance VPN and Media workloads if you think about it the time when you really need Optimized packet processing is when you've got a steady stream of things or a lot of things coming in in the case of media You can think of like streaming Netflix or something like that video and audio are particularly sensitive to delays and to jitter so it's important to get the data in get it buffered and For NFV your big data kind of deployments. It's very important to get things moving quickly Okay, so let's take a look at what this looks like in green. You can see a controller node Which is where we run our services and on the left. We've got our OBS stack that we know and love And what talks to that is the neutron server in the etsy D process I just want to mention etsy D is used by VPP in order to journal ports that are coming up So basically things that are in flight before the work is done. It gets journal in it at CD So it's it's kind of what it's kind of critical Then on the right on the controller you can see I think I showed this before but you've got the Nix you've got DPDk you've got the VPP stack and on top of that on in the case of the controller is the DHCP agent So any DNS requests and DHCP requests are going to be optimized by VPP Now let's take a look at the compute host in blue again We've got the OBS stack and that's for Nova compute and for the VPP agent in order to bring things up on the control plane Then we've got our optimized stack for the VM Traffic so basically the hungry VMs that are just waiting for all that data are going to be using VPP Oh, and I should mention we've got three VLANs a tenant VLAN. That's our data plane Service VLAN and an admin VLAN those two are control plane traffic So let's blow this up a little bit now We've got three controllers and three compute hosts as I mentioned the VLANs are terminated on the N9 case switch Which goes out to the ASR router out to the real world I wanted to mention on this slide in particular SED again because we run in a three node cluster for SED SED is used like a database for VPP So it's important that it has redundancy and by running in a cluster It uses the graft protocol to provide resiliency and redundancy So what did it take to get to production quality on MetaCloud? More than fits on a slide, but these are the highlights The first thing was to get to Liberty MetaCloud is currently running on Liberty. So we had to backport Another thing when we were first starting out we had to clean up VPP constructs For times when VMs are deleted or migrated a lot of state was being left behind I believe that's all been cleaned up now, but when we were starting that was something we needed to deal with Tuning the number of huge pages was something we needed to do to in order to allow multiple VMs to run and The huge pages are dedicated per VM. That was important When we when we first started security group support was not there so everything was open not great But that's fixed now We had to do a lot of thinking about high availability So things like process monitoring those Etcd services that I talked about are monitored by system D. So even though we've got multiple servers in the cluster We have process resiliency as well So that eventually if something goes down the controller itself or an etcd process, it'll come back up and join the cluster We've also got pacemaker for the VPP agent and the DNS mask process that DHCP agent I was talking about the reason for that is that if the DHCP agent moves we need the VPP agent to follow it So we use pacemaker for that logic Let's see. Oh and making VPP aware of all etcd nodes in the cluster. This was a big one Let me go back to the diagram here So even though there's multiple etcd processes Down on the compute host VPP only had the ability to talk to one of them And it did that through the controller IP address Which means that if that controller went away that particular one or that process that etcd process Even though the cluster was still running you were kind of dead in the water So we added support down in VPP in the plugin to be able to talk to each of the etcd nodes If there was a problem with one of them There was a problem with IPv6 subnet support that's since been fixed is my understanding Something that we hit recently was large core dump file size. I believe I heard numbers and like a terabyte That's huge a huge file completely unmanageable We fix this through config settings by putting fewer things into the core dump and Also recently we had a VM restart issue and the fix for that was upgrading to QEMU 2.6 Current limitations. I mentioned that there won't be support for remote Group IDs support there won't be support for remote group IDs until release 1707 this is a bit of a bummer for us because Because of the way that the system acts if there is a remote group ID When that happens all security group rules are ignored and so everything's open Kind of bad news. So we're looking forward to having that support We notice issues with live migration the VMs get stuck in a migrating state so we're looking forward to having that fixed and Scalability I mentioned this because VPP has never really been run in a huge deployment and as you know as things scale up Issues are sure to be found So finally I wanted to give you something pretty to look at Let's talk performance. These are numbers that were published by Red Hat this past February and What you're looking at here on the y-axis you've got throughput and measured in millions of packets per second And on the x-axis you've got number of flows and increasing complexity So if you look with 1,000 flows and simple complexity what I mean by that is the things that were varied in the testing We're like source IP address destination If you look the performance is pretty similar between OBS and VPP and I wanted to mention This is OBS with DPDK if we were comparing OBS proper like plain vanilla. No DPDK Support against VPP The changes the differences would be much more stark actually But let's go with what we have so at 1,000 flows The performance is pretty similar But what's cool about VPP is as the number of flows go up and the complexity increases So you start changing more variables like MAC addresses source and destination MAC addresses and things like that OBS starts to drop off But VPP actually remains steady and the reason for that is because of all of the optimizations that it's making so as things scale up We're looking pretty good there, and I think that's pretty cool So that's actually it for me if you haven't already Please visit the Cisco booth in the marketplace meet some cool people and talk about all the amazing stuff we're doing and with that I'm gonna hand things off to my partner in crime Shannon McFarland And we'll also have some time at the end and can come back up and you can take all kinds of photos of her answering Your incredibly difficult questions. So So we Yeah, we look forward to that. That's good. So we moved from a hard thing to a Bigger thing so Talking about the entire next generation internet protocol in 15 minutes is always a good time So we're gonna focus a little bit on kind of where things are with IPv6 from a deployment perspective specifically in the cloud My name is Shannon McFarland I work with Anne and many people in the group and work for Lou in the cloud computing area at at Cisco and since roughly 2002 I have range from full-time to Part-time in the IPv6 world and you can tell I have some affinity to it based upon my Twitter handle of IPv6 So that's the best way to get ahold of me is on Twitter or just hit me at McFarland at Cisco comm And we can talk about your IPv4 woes So from an IPv6 perspective if you've been under a rock for a period of time you kind of understand You know nothing about IPv6 and about this thing called IPv4 address start starvation or exhaustion But if you've if you've been alert at you know any point in your Career especially in the last 10 to 15 years you know that we're in trouble on publicly routable IPv4 address space So based upon the IANA exhaustion, which is the the governing body that assigns addressing to RIRs or Regional registries such as Aaron They exhausted their address space a long time ago each of the RIRs Are now in what they call the last call or or their last allocation pool and so these are Very very difficult things to get so if you are trying to expand your business into an area Where you're going to obtain publicly routable space directly from a registry instead of a service provider You're going to have to do a lot of work to justify that so for example today If you're wanting to go and grab an entire Slash-24 of routable space from an RIR You better have a really good reason and it's going to take you a long time to get that space so You know that that really is a driver towards IPv6 And there's a bunch of links here based upon the main IPv6 page for each of the RIRs that you can get to now what this has done is this has triggered kind of some Strange behavior in our market and it is address market Kind of exchange has has been created. There is no formal process if you will For you to go and acquire IPv4 routable address space from someone else So what your actual Obligation if you want to obtain someone else's routable space is that you would go to someone like Aaron and the selling party or the giving party in the case of Stanford that gave their address space away and You would go and say We as Cisco are obtaining this address space that used to be assigned to some other company And we basically do kind of an agreement around that exchange of information When that does not happen we do all kinds of dumb things Right because now if you're a service provider for example or an enterprise who has obtained v4 Spacing or address space from another entity and you have not done the good work of exchanging that record information From a registry such as Aaron What happens then is that you can be blamed for bad behavior from an address space that you now own So blacklisting that exists in various parts of the world You could be you know associated with address space behavior that literally You had nothing to do with and so this creates all kinds of strange stuff in this market But we see it happening. I mean just recently MIT sold a bunch of their address space and Amazon was one of the buyers We have people that are selling the address space back And we have people that are actually giving the space back Stanford being one of those And the ranging price for this depending on where you are in the world and how much space that you're actually buying can range from $5 an address Up to upwards of 14-15 dollars for each v4 routable address So a tremendous amount of money that's going in to basically You know stall the inevitable and this is around IPv6 That that is kind of helping us ease this burden So I go through all of that on the address exchange part simply to point out that you really don't need to do that IPv6 used to really suck to implement It has never been hard to get v6 addressing But it has been very hard to implement IPv6. So we're going to talk a little bit about What some of those strategies look like specifically in the cloud? So real quick I want to do one slide of what IPv6 is simply You know just to do a level set so IPv6 is 128 bits long versus 32 bits long versus in the IPv4 world So it's a significant step up an address space It's hexadecimal based and this one bullet point is the only reason I ever got into IPv6 Because I'm an IPX guy from way way back when and the pretty much the only joy I had back then was being able to create inventive names through hexadecimal So you know face bad Cafe all of these great things that you can do in a hexadecimal addressing space is really what drew me into IPv6 and here I stand So so that part of it is cool You also in here a bunch of really cool stuff with IPv6 and this really makes it into a very very valuable Protocol when we are looking at very massive scale type of addressing structures the ability to discover your neighbors and Discover resources on your own segment the ability for you to have stateless addressing This is incredibly powerful in the mobile marketplace where I don't want to carry something heavy weight like DHCP I just want something to come on the network Discover its own addressing and be able to get to where it needs to be and this is really really good in a first Responder environment where you've got to set something up quick You may not have all the equipment to provide a stateful means to providing addressing And so the stateless addressing model is very important Other things that we drop off and gain again very much like the VPP versus the OBS story that and was talking about is that? We are making Optimizations to the protocol as we embrace it so dropping off broadcast and moving all of the things that we used in Broadcast converting them over to a group-based messaging system such as multicast Is a very important asset there and we can tell Based upon the number of Routable addresses on the top versus the bottom that that we've got a fairly significant size increase in our allocation So when we look at IPv6 from a cloud context, there's a lot of things to consider I mean historically what we've had to deal with from an IPv6 perspective has been focused on Upgrading your your layer three components, right? So routers switches Getting all the way up to layer seven from a firewall and load balancing and deep packet inspectors Proxies those types of things have been what we've been focused on But when you start implementing stuff within the cloud context, there's a lot of dependencies on things that aren't pure routing switching So those things such as API endpoints. How does how do you represent through a load balancer your API endpoints? How do you talk to a database? Many many things that exist inside the cloud that are very protocol-dependent are things that you need to make sure Our IPv6 aware Some of the big ticket items that have nothing to do with the actual direct Implementation of the cloud as it relates to APIs and databases or how do you wrap your implementation of the cloud through? orchestration so if you are developing code or you are writing orchestration and Automation and you have some sort of protocol dependency there That's going to be a huge gap because the cloud components themselves may support IPv6 But if your automation that deploys that is not aware that a protocol such as IPv6 exists It's just a huge gap for you So what we have kind of led ourselves down the path to is simplifying the IPv6 implementation in the cloud And that focus has really been on the tenant facing support side versus the control plane So we're going to kind of jump over to what some of your options look like As it relates to deploying this in the cloud So the two common approaches that I talked to customers about is to dual-stack everything Or conditionally dual-stack these components. So let's kind of graphically take a look at this So on the left hand side is the dual-stack everything approach This simply is applying v6 everywhere you have IPv4 right no brainer, of course, right? But when you look from a cloud perspective that is pretty significant Because it's not just about again L3 through L7 constructs that you need to implement But it again it is okay Well, what happens if I can talk to a database or an API endpoint on two protocols and but something happens midstream to IPv4 Right someone makes a bone-headed route You know change and v4 blacks out but v6 is still there. What is it going to work? You know functionally is it going to work the way I expect it to? So there's a lot of research that you have to go through to ensure that these particular things work in all cases So the one on the left looks like the great approach But it's going to be a painful one for you unless you really really do a good job of kind of testing this out before you implement it Where the vast majority of customers are going especially in the enterprise is what we call the conditional dual stack environment And this is where they leave their control plane or their service tier alone their API endpoints their databases their automation to get the cloud in place They're leaving with v4 today But anything that faces or is consumed by the tenant is going to be a dual stack or an IPv6 only implementation And this is really what matters right because most of the time the tenant is coming and saying I want people to consume my Application regardless of the protocol they're using so please enable that functionality So my tenant facing environment to include access to the internet is really really where we want to focus our Implementation either in a dual stack or in a v6 only type of environment And so that's really where most of our folks are deploying Now when we look at IPv6 from an open stack perspective, we've got really strong support We've had some pretty good support since kilo, but it is matured and matured and matured And I'm proud to say kind of jumping to that last bullet point that there's people in this room And outside of this room from Cisco that have been really driving the IPv6 support model In each of our releases and some of those include all of the addressing structures that we have So we've got slack or stateless address auto configuration. We've got both models of DHCP And we also have IPv6 prefix delegation, which is super important, especially in the the service provider realm Now when I kind of parenthetically, you know say mostly there on the control plane components It does depend it depends on which databases you're using and which types of HA models Are you running pacemaker or VRRP or HSRP or keep alive D and which versions of those types of things? So when you start to glue your control components together You really need to do a good job of understanding what the IPv6 support model looks like and then Make a very conscientious decision on do you dual stack those or do you go ahead and kill v4 and just do v6? Because dual stack sounds amazing But again when you have two abilities to talk to one thing From a path perspective and one of them goes away. You can't absolutely see very odd behavior so some other things that are listed there security group LBAS support and and and so forth so You know wrapping up here the things that we want to kind of walk away from is IPv6 is here It's very strong in the open-sat community and if you don't have a plan for it, you're late And so if you it is never too late to do something about it But if you're if you're being shocked by the first time with IPv6 in the cloud and here today Then you should be concerned because it's going to take you a long time to get this running And you need to get moving on it pretty quick IPv6 with your standard L3 and L7 components is not your issue It is your developmental practices in the tooling Around how you implement IPv6 and how your applications work in that realm is really where you need to be focused Jumping down into here is again. You need to make a decision around whether you're going to do full control plane support Are all of your cloud components going to be v6 only or dual stacked or none of the above And from an application development perspective Do you write your applications to be protocol agnostic versus protocol aware? So the idea you know that you really want to go through in your application deployment is I don't care what the protocol is right Versus bolt-on IPv6 to all of your calls and so forth And so that's that's a conscientious decision that you have to go with The last part here is don't be paralyzed by the size of the job Start small start simple and start on the tenant facing side of your cloud And then just start piecing the components together and you'll end up with IPv6 before you know it All of the slides in in my particular case My deck there are probably 20 or 30 more slides that you'll want to get which are all the links to Deploying IPv6 inside of open stack And many many other things and I think there's some extra slides in there from and as well So you definitely want to get a copy of our decks Which are really kind of take you to that next level of depth that we have So I'm done with my part and if we want to take any questions I think we have a little bit of time. We have a few minutes for Q&A if Anybody's got a cue they've I don't even want to have to say it at that point. Yeah No So we did such a thorough job of two very very large complex Technologies in 15 minutes that you have no questions. That's amazing You're a lot better than I thought and Oh, no, I still got a mic on Nothing you may be able to go to break early. I'm impressed You know the one thing I'll say is it They haven't been all that spot-on with the coffee. So you might want to get yours get your line If there are no questions again all the slides are up on slide share for Shannon and now The rest of the slides for our other presenters will be up in a couple of days Thank you all for coming. We've got two more sessions after the morning break on NFV and container networking So come back for those On your way out stage right you can grab your Runs on open stack Running socks. Yeah, I know incredibly clever, right? Okay. Thank you very much. Thank you all for coming. We'll see you after the break