ENCOR - LISP and VXLAN

hey everyone happy wednesday thanks for joining us for another encore study group today we're going to be talking about lisp and vxlan and i know we're still trying very hard to get to the software to find access fabric operation it's what we've been trying to get to for a while now but we just got so many things to cover and really it's all about laying the groundwork for actually getting to the point that we can talk about fabric operation so as we look at today's agenda really again we're just going to be talking about lisp and vxlan and most of the conversation is going to be lisp lisp is definitely the larger cookie to try to consume if that's an analogy anywhere but either way we're going to be spending probably about three quarters of our time today on lisp and then at the end we'll definitely cover vxlan it's just you know vxlan is pretty straightforward it's a layer two tunneling mechanism so we'll give the information that we can on it and from there we'll have hopefully all be armed and equipped with the information that we need in order to finally again talk about software-defined access is fabric operation um moving forward so there's a lot to cover today we're going to dump jump right in but for those who are new or it's been a while since you've joined us thank you for coming this has been pre-recorded we're doing a youtube live session it's not live it's premiere i suppose but i'm in the chat right now ready to answer any questions i expect there to be some questions on lisp and vxlan so do not hesitate to chime into the chat ask whatever questions you want vxlan and list the reason we're covering these is because we're going through uh the whole software defined access section is for those who are studying for encore as you know sd access is a big part of this exam we need to be comfortable with the concepts and at the core of how sda operates we're running lisp we're running vxlan we have to have these protocols at a level we have to be at a certain level of comfort with these protocols in order to really pass the exam ultimately which is the goal so without further ado let's go ahead and jump in and we need to understand uh first and foremost that lisp was not designed for software-defined access neither was vxlan by the way they were designed to solve problems in different parts of the network and what we're going to find is cisco looked at those and said hey if we pluck lisp which you know cisco developed lisp so plucking list wasn't that big of a deal but we pluck lisp from the service provider space and we grab vxlan from the data center space we can really create something special with software-defined access a software-defined networking infrastructure for the campus environment and so again let's step into the service provider world here for a moment let's just think about i just drew a bunch of routers onto the screen here a lot of them connected or what have you but just imagine if you will that this is the internet uh probably not the entire internet i mean not certainly not that small but maybe it's an autonomous system somewhere bgp on as that's we've got a cluster of routers that the internet service provider has and let's think about this from a traditional routing perspective if i've got a subnet out here let's just call this subnet a and i have a packet arriving on this router destined for subnet a how do i get this packet across my internet service provider domain to the actual destination we need to get to this router right here and so the way we're going to do that is by exchanging routes everywhere we've got bgp running between autonomous systems we probably have it running within our autonomous system or we might have an igp or isis running or something along those lines just something that gets that traffic from the router on the left all the way to the router on the right now the way that we're going to do this is we're going to check our routing table and somewhere in this routing table we have a path to subnet a and so we're going to send that on to the next hop router that router is going to look up its routing table and it's going to see that it has a path to subnet a now in a lot of our networks we might be following a default route in some situations but in most service provider networks we're not able to rely on a default route the default route just sort of is the catch-all it points out towards the internet and for smackdab in the middle of the internet there isn't really a default route you know is it the service provider that's connected out that as number connection over there to the other bgp realm or is it is it that service right or is it this service provider at some point there really isn't a default route that we can fall back and rely on and so this is why it's so important that we have a route to network a and so we keep hopping and we check the writing table here and we see that we have a route to a and we forward it on to the final router which of course it's also got a routing table lookup to do even if a is directly attached which it might not be might just be downstream but either way we forward it on to the destination this is traditional networking and this works it works fine fine enough i suppose but not fine enough that we just want to leave it it's not working fine enough such that we didn't have to create something to fix some problems the biggest problem that we have here is that every single router in the path had to know what they had to know where subnet a lives and so that makes sense right i mean if i'm a router and i receive a packet and i don't know where the destination is i drop it but but there's a big flaw with this theory and that is that ultimately what i'm trying to get to is i'm trying to get to this router here on the right but in order to get to that router on the right i have to know where subnet a lives and not just subnet a i need to know where every subnet lives that i might potentially forward towards so on the internet that essentially amounts to the entire internet routing table which i boy i should have looked this up beforehand are we close we're on our way towards a billion routes is that right um i'll hopefully chime into the chat here if i'm wrong about that um somebody correct me if i'm wrong but either way we're we're looking at so many different routes on the internet one of our greatest tools for combating the sprawling growth of the internet routing table was aggregation right we would aggregate our routes such that okay well a i could i could maybe aggregate a through z maybe 26 or 32 probably a nicer binary number right a bunch of different subnets and i could summarize those essentially route aggregation i could summarize those into the routing core and so now i have fewer subnets that i am tracking except except unfortunately again a lot of us don't live in the service provider world so you might just have to take my word for this but what we're doing a lot of these days is we're actually doing disaggregation of routes we are relying and trusting on our routers being strong and beefy enough to be able to have the entire internet routing table to the point that we're actually taking some subnets and we're splitting them up and the reason we're splitting them up is for traffic engineering i might want for example if if i've got a subnet b hanging off of this it's going to sound silly to say this but i might want b to go around this way and so if i want b to go around that way then i need a route a pointing this way for subnet a and route b pointing this way and so in order the only way i can do that is if i have different routes which means that aggregating or summarizing all these routes together remember that a through z concept or i've got 26 or whatever however many subnets i have in there if a and b are in there together this isn't going to work i can't send traffic for one route this way in another route same route subset of that route that way it doesn't work i have one route at that point and this is why the internet service providers of the world have been segmenting off their or at least splitting up their aggregation and their summarization and so because we're no longer summarizing i mean you think that over time we'd be summarizing more and the writing table you'd be getting smaller it's actually quite the opposite the internet riding table continues to grow and it's a little bit out of control so cisco looked at this scenario and said okay this is not ideal and what but what can we do to fix it you know sometimes it takes just going to a whiteboard like this and saying all right if i could do whatever i wanted to make this work if i could go back in time 30 years and redefine how the internet works what would 30 years ago actually isn't far back enough anymore is it but either way we're going back in time we're trying to fix the internet what can we do in order to fix it and so the solution that cisco came up with was this concept of lisp so they created actually i'll make it green because green is good the locator identifier separation protocol or lisp the the idea that they came up with was to say okay really what we need to do is get to this routing locator over here i i'm using a term that i'll define here in a moment but this router really is what i'm trying to get to and so behind this is a subnet that i also need to get to but here's the thing something that all of these routers in the network already should know is how to get to this router that router is part of the igp or ibgp domain or whatever routing protocol i'm running they should be able to get to that and so if i'm sending a packet into this router and its destination is a and i send that packet onto the routers then they'll need to know where a lives but what if we package this up in a tunnel and instead of saying that my destination now is a that would be the inside of the tunnel my original packet says destination a but what if my tunnel's new destination is uh let's just call this like router 10 or something like that so now my destinations router 10. if my destination is router 10 and just let me erase this big green circle that i made if my destination is router 10 then what can i do whoops there we go then what i need to do is send that packet in but now at this point this router knows where router 10 is and so we're going to do something very similar except when we're looking up our routes we're really looking for router 10. we're not looking for subnet a anymore and so i send that on same thing they're going to look up for router 10. and this looks the same as what we just did before except think about how many routes that these routers now need to have these routes i'm sorry these routers now need to have as many routes essentially as there are routers in the network that's that's it i just need to know how to get to these routers for any subnets that they may own so the goal of lisp is to decrease the size of the routing tables in the service provider core this is why lisp was invented now the way lisp works is what we're going to be spending most of the rest of our time with but this is essentially the the gist of what lisp is trying to accomplish we're trying to bring packets in and encapsulate them into a tunnel and send them across a particular part of the internet now usually that part of the internet is going to be a bgp autonomous system or part of a service provider network it's not going to be the entire internet we can't scale lisp out to that extreme and neither would we want to by the way that's that that kind of eliminates the point of it the point of lisp is to take a domain a part of the internet again a bgp autonomous system in most cases run list in that domain and now all of a sudden we're talking about routers that maybe go from 500 million routes to what a few dozen routes i mean maybe even if it's hundreds of routes for all the all the different routers that we might have in our domain you're talking about such a huge decrease in the number of routes that now the money i have to spend on these routers goes down significantly i hope everyone's understanding that please chime in with the chat or into the chat if you don't uh for those who are watching this live but the the important part about this is the reduction of the routing table size for the routers that are in between this exact same concept is going to be used in software-defined access we've talked a little bit about that already and anytime we're using tunneling that concept of tunneling which used to just be like honestly tunneling was largely used other than ipsec tunnels and tunnels out to remote sites telling was mostly used for ccna labs and ccie labs we weren't really setting up tunnels inside of a campus fabric or campus network called back in the day five ten years ago but now all of our software-defined infrastructures are coming out of software-defined networking cisco's not the only one doing it this way every software-defined networking solution out there is building it on tunnels and part of the reason for that is because that way our underlay remember this overlay underlay concept the tunnels are part of the overlay but now the underlay it can be really dirt cheap networking gear for the most part we're just taking packets in looking up a small a route and a very small routing table relatively and just chucking on to the next hop that's all we need this device to do and so that that again it makes it less uh or it makes it more affordable really in the service provider core but it also just makes it so that the the routing table lookups are faster so it's going to speed up the amount of time that it takes for riders to process packets it's it's a fantastic solution again it doesn't scale out to the entire internet at once but it can scale out to an entire bgp autonomous system number whatever part of the internet we're dealing with at the time so here's how lisp works keep working on this diagram for a moment definition of terms here i called i kind of gave a spoiler earlier what we're doing in the lisb world is we're taking the locator id really the locator identification how to explain this um the locator identifier is li right and we're separating that from the locator and the identifier yeah i didn't explain that very well all right let's just do it this way the routing locator is going to be where my subnet lives my identifier this has always been my identifier if i look at my ip address that's how pretty much all policies are defined against me on the network if i log in with my pc it's they know who i am by based on my mac address this is one of the problems that cisco trustsec and ice tries to solve is identifying who you are not just based on your ip address right that's where we get scalable group tags and such but ultimately especially in traditional networking and pretty much everywhere my ip address still is my identifiers who i am which is why by the way coming into the network over here somebody's trying to send a packet to me and in lisp that doesn't change my identifier continues to be my ip address and specifically my subnet from a list perspective but now we introduce this concept of a locator a routing locator or an r-lock the routing locator is going to be an ip address that identifies where i live inside the network so now remember we talked about this concept of a destination ip address of router 10 this router 10 ip address is going to be my routing locator so now let's just say i don't know at this point 10.0.0.0.24 is the subnet and let's say that this router if we're in the internet right we should be using public ip addresses so let's just call this well i can't use 10 because i just you know tend to private range um we'll call this that's i really want to use 10 since it's router 10 why why did i call it rider 10. let's just call it 1.1.1.1 why in the world not okay 1.1.1.1 is the ipads which is by the way a pretty popular dns open dns style service these days so i can't even use 1-1-1 anymore anonymously but either way 1.1.1.1 is the ip address in our scenario here of router 10. so when that packet is going to come in we are going to somehow magically and again we'll explain this by the end but magically this router here on ingress is going to see okay wait you're destined for a a subnet a lives on 1.1.1.1 so i'm going to encapsulate that into a tunnel packet such that the destination is no longer 10. let's say it's just 10.0.0.1 that happens to be my ip address we're no longer destining this packet for 1001 we're destining it for 1.1.1.1 and again all the routers in my isp domain should know where one one one one is and whatever i and you know again i keep saying igp it could be eigrp it could be ospf it could be isis in a lot of cases it could again be ibgp but either way we've advertised out to all of these routers where 10 or 1.1.1.1 lives and so when i send my packet to the next top router it's going to look up do i have 1.1.1.1 hey i do and it forwards it on et cetera et cetera okay so routing locator and uh oh sorry um the term that we use to call this identifier is actually an endpoint identifier eid okay in the software defined access world we're going to find that the endpoint identifier actually identifies an endpoint in the lisp world for the most part my endpoint identifier is going to be the actual subnet as opposed to an actual ip address so in our example here the endpoint identifier would really be pointing to 10.0.0.0.24 rather than 10.0.0.1 which is what would happen again in sda world and the primary reason for that is not that we need to go into a whole lot of detail here but the reason for that is because in the lisp world subnets aren't going to be split around the network if this subnet is attached to this router i'm not probably going to have 10.0.0.1 hanging off of this router and 10.0.0.2 hanging off of this router in a software defined access fabric that's fair game because these edge devices in an sda fabric what are those those are layer 3 access switches so if i roam right if i wirelessly roam from one network closet to another just by connecting from you know from that access point now to to that access point i've now roamed from one network closet to another well now i've just done a layer two roam and so i was 1001 on that side now i'm 1001 on this side well in an sda world that's going to happen a lot but in a service provider world with lisp we're not we're not supporting clients being like migrating around we just we just want to support you know we want to track where the subnets live okay so we're getting rid of that uh 1002 can't exist out there it's again the routing locator and the endpoint identifier those are our two primary things we need to be thinking about okay uh what's next here oh yeah uh let's do let's do a few more terms here okay we have the concept of xtrs in the list world this stands for tunneling routers and we have two different the reason why it's x is because that's a variable we have two different types of well yeah yeah we'll just say two different types for now of tunneling routers we have an ingress tunneling router and we have an egress tunneling router so an itr and an etr in our example the itr is that first router whoops i can't spell itr that's ironic all right itr the packet is coming into the lisp domain because it's coming into the lisp domain this is an ingress operation so as we come into the domain and as we're about to be tunneled the ingress tunneling router is the one that initially places it into the tunnel meanwhile when i look up the routing locator and i find out okay that's where it's destined for i'm going to ford that off and this becomes the egress tunneling router this the etr is the router that pulls the tunnel packet in and de-encapsulates it so it encapsulates it and forwards it on to the rest of the i guess normal network but the non-list domain okay all right now we need to talk a little more detail about how all these routers magically know all of this information okay uh let me clear out pretty much all of it actually okay somewhere in this network let's just let's just make it a separate device we're going to have a router whose job it is to track all of the endpoint identifier and routing locator mappings the goal here is to track where all the subnets are in the network and we've got a lot of routing locators at this point let's just say all of these routers at the edge are routing locators that have subnets hanging off of them and so we've got to track where all of the subnets are how they're being um well yeah we need to track all of the subnets and where they live so remember keep in mind that we just said that we don't want to track all of the subnets on the internet routing table that will free up routers like these three in the middle to not need as many resources but the reality is that somebody in the network does need to have that information and that is this device right here this device is called a mapping server sometimes referred to the mapping server as the ms so i'll write that out here mapping server ms okay um now that i tight write that out like that i feel like it's just map server i'm checking my notes here uh i'm just going to go with map server it's one of those things where you call it the ms so much that you just don't even stop and think about what it stands for but i want to make sure that that's right oh yeah yeah there's in my notes it's the map server not mapping server all right good point being it's the ms right this map server is going to be tracking all the endpoint identifier to rlock mappings now that's great but how does it know how in the world does it know where all of these subnets live well the routers at the edge have to tell the map server when we have a subnet so what's going to happen is when a router comes online and it finds now again this is from a service provider perspective it operates a little bit differently in sda um but that's okay as we uh we'll cover that next week but our next session which is in two weeks but either way um when a subnet comes online so basically as i'm populating my routing table every entry in my routing table is a subnet and i need to register that information with the map server now there's a lot of different ways for the router to know where the map server is think about it from like a multicast perspective you got to figure out where your rendezvous point is there are ways of finding out automatically where this thing lives through dns and such but for the most part you know just just think about this as like manually configuring it so i might configure this router manually to say here is where your map server lives your map server lives at i don't know 2.3.4.5 random ip address i just invented so i know where my map server is i've got a bunch of routes in my routing table so i need to advertise all of these down to the map server the way we're going to do that is by sending a map register message this map register message more or less tells again the map server okay here's my routing locator id this is who i am and here's all of the information all the subnets that i have and we're going to get that from every single router that's out on the network within the lisp domain so this is at this point from an operation perspective we're considering this the etr the etr is essentially saying anybody who wants to attach to or send to any of these subnets send it to me i'll be the etr in that situation and i'll de-encapsulate the traffic and i'll forward it on okay so when a packet now arrives switch colors here so now a packet has arrived on a router and it is destined for one of the subnets again let's just call this subnet a is destined for subnet a now this router doesn't actually magically know where subnet a lives because again we've we're not running a routing protocol that tells it we're running a routing protocol that it knows i mean in its routing table it should have what do we say 2.3.4.5 we should know where 2.3.4.5 lives because we're running the igrp or ospf or what have you um but we don't necess but we we definitely don't know where subnet a lives at least on at the first packet i need to send a subnet a and so i'm going to send a map request message hold up i gotta scroll my notes down a little bit oh yeah yeah we're doing this a little bit out of order that's okay that's okay we're fine um we're going to send a map request map request i just skipped over some details on the tunnel i'm going to come back to the tunnel mechanism as part of lisp so this is fine it actually makes more sense to cover this first so we're going to send a map request to the map server and we're going to get back a map reply the map request included the information of hey i'm trying to reach subnet a and the map reply contains the routing locator for where subnet a lives now this is kind of interesting because it changes the model for the control plane operation first of all it moves all the control plane information the relevant control plane information right we're still running ospf for the underlay but as far as the overlay is concerned we're moving all of that off box the router here at the edge this itr at this point this is the ingress tunneling router the itr doesn't have all the information in today's like in a traditional network if we're running ospf and exchanging routes and everything and i get a packet in and i don't have a route i just assume well if i don't have a route then i don't know where to go i mean it's not an assumption that's the reality i get a packet in i don't have a route in my routing table therefore i drop the packet because i don't have a route but we changed the methodology here a little bit because in that methodology i have been pushed all of the information that the network has i've received all of my lsas if it's ospf i've received all of my route advertisements if it's eigrp i've really i've really received as what i'm trying to say i've received all of these routes and it's great that i'm where was i going with that i'm receiving they're pushing that information down to me so basically i'm just receiving a bunch of info that's in traditional networking in in this more modern way of doing things where we ex you know extract the information we put it onto the map server the map server now is the one that has all the information and when so when i get a packet and i need to know what to do with this packet i actually reach out and i pull that information down so it does a couple of things first of all it makes it as we've talked about so these routers here in the middle can focus on forwarding but even the routers at the edge they don't need to know all of the information they only need to know the information that they need at any given moment in time so yes there is a cache we're going to cache some amount of information i'm going to cache that a is attached to 2.3.4.5 and that's important because as packets continue to come in i don't want to like just forget that right if if i keep getting packets in destined for subnet a well i just i'm just going to store it locally i don't want to have to go to the map server every time it's going to overload the map server and it's going to overload me and it's going to delay my ability to respond and so as packets come in i'm going to send those packets referencing my local cache so the first step is not actually to do the map request the first step is to check the cache if i don't have anything in my cache that's when i check my map or i send a map request to the map server i hope that's making sense again as always chat's there ask your questions this is something that just takes a few times it's new it's a new way of doing it we're used to the control plane living on the box we're not used to this idea that there's a server out there that that's again in our case it's a router but we're calling it a server that serves up the information i'm like hey i need to know where subnet xyz lives i'll just send a map request out and i'll get a map reply back that's that's the idea of lisp um let's see here okay so this is where and i'll come back now to the tunneling mechanism so this is where the lisp data plane comes into play we don't need to know a whole lot about this but when we talk about lisp there are two elements there's the control plane operation which is exactly what we've said we're offloading all of the control plane information to the map server and we're going to go to the map server in order to get that information that triggered one other thing we have to come back and clarify that's okay lisp the the other component would be the data plane at the data plane we need to do this concept of tunneling so what tunnel mechanism are we using are we using gre are we using some other tunneling mechanism and the reality is that lisp brings with it its own tunneling mechanism so it has its own data plane uh operation it is uh what we call ip and ip so it's a it's going to be a packet that has you know the original packet here we'll call this the original packet we're going to strip off the ethernet header which is a very important thing to remember when we talk about vxlan later this will come back up we're going to strip off the ethernet packet so now our header so now we have an ip header and then we have whatever layer 4 header we have and then we have the layer 5 through 7 information here as our payload that's the original packet and then we have two things we're going to add a lisp shim header in here and we're going to add a new uh ip well hold up we're i'm running out of space here there we'll have to like this we're going to add a new udp header and an ip header and then of course ethernet whatever our layer two protocol is and not necessarily ethernet but whatever layer two as we go in front of that okay so this udp port is going to be a destination of 4341. you might need to know that on an exam so it's worth mentioning um we can do ipv4 or ipv6 so that's important we can do version 4 or we can do version 6 here okay checking my notes here what else is important um [Music] okay so the shim header the lisp header here this is going to include a virtual network identity are we going with vnid no we're going with um oh that's right it's called the instance id we're calling this the instance id the instance id is essentially a way to identify uh vrfs so if we have different networks different virtual networks we don't necessarily want to um well don't necessarily want to we absolutely do not want to share information with one vrf that doesn't belong with it so a multi-tenant environment is you know comes to mind but that's that's primarily what we're going to use for that if you look at vxlan later we'll see vnid is the identifier virtual network identifier instead of an instance id and it's basically the same thing it's just for network segmentation purposes um we're not going to use this if it's not a multi-tenant vrf based environment um and that's it that's it um importantly we do not use the data plane we do not use the lisp tunneling mechanism in software-defined access that's um that's why we're using we're gonna use vxlan instead and we'll talk about why later we actually already covered it a little bit it's that layer two layer three thing but this is layer three only we're not we're not sending layer two information we stripped the original ethernet header off assuming if it was ethernet when it came in it probably was but whatever layer two header information came in we stripped that off package that packet into again adding in ip header udp header and a lisp shim header all right um one other thing we need to cover really quickly and i apologize i really should have said this earlier it's a mistake there's one other component in all of this that we need to think about and that is the map resolver the reason i didn't bring this up is simply because the map resolver or the mr is usually usually it's the map server as well so in most unless we're scaling out and again from a if you're labbing this up you'll just make them the same device but if you are going to deploy this into a service provider space which is not the scope of the oncorn is not the scope of any conversation we're having here today if we're not scaling out then they can be the same device the only difference between the map server and the mappers not the only difference i shouldn't say like that the role of the map resolver is actually to receive the map requests again it's a scaling thing i received the map request which means that the map server actually pushes information down to the map resolver so effectively we're dividing our information up the map our responsibilities the map server receives all of the map register messages and so it's processing all of that and it's managing the database and the map resolver is handling all of the requests as they come in but again usually that's the same device usually it's the same router not necessarily in the service provider world but at least from an sda perspective it's going to be and from a um because that's going to be the the control plane node and from the encore perspective we're lab it up they'll be the same device but understand that there is a separation of responsibilities there um should have said that earlier okay we're 35 minutes we're about right on schedule here i would say we got just a little bit more to cover with lisp and i want to make sure yes okay so here we go so um what what am i trying to say here okay um next let me just i'll just clear all this off and orange okay yeah orange isn't a good color for this blue so now next what if what if i have and it shouldn't be what f this is always going to happen at some point what if i have a connection to a router that isn't part of the lisp domain so here's my lisp domain we're happily running lisp we've got our map server map resolver combo here the msmr uh that that's doing its thing we're taking packets in we're tunneling them across the the network but now all of a sudden i've got this connection to maybe a different service provider it's either way it's non-lisp it's not running list but doesn't know what lisp is what am i going to do with it um this in this case we create a new role and that is going to be the proxy xtr okay so pxtr the proxy ingress tunneling router proxy egress tunneling router just depends on whether traffic is coming into or out of the network but the pxtr is going to handle the relationship with routers outside of the domain for the most part a pxtr is going to operate exactly like an xtr the only difference really is we have to look at whether this is considered an well hold up real quick let me just make sure [Music] yeah um this the i guess that we'll cover a little bit of this with sda next week the difference is that the pxtr is not actually registering anything with the uh the map server okay so we've got some number of routes out here and probably a lot of routes you know i mean if this is the rest of the internet this is a pretty significant number of routes uh if we as we have a some kind of relationship here maybe there's a bgp relationship or maybe again in service writer world it's almost surely going to be a bgp relationship but it could be a grp it could be ospf or something along those lines um but either way we're not going to register uh we're not going to register those messages hold up real quick yeah okay my i'm getting a little bit mixed up here between um sda because sda has has two different kind of border nodes that they call them which essentially are these pxtr concepts um and so i want to make sure that i get the right information from a lisp service provider perspective okay itr is going to send it to the yeah so basically what's going to happen here is if i receive a packet oops if i receive a packet that's destined for something and i check in with the ms mr i send my map request and i don't get anything back it's basically going to send back what they call a negative map reply okay i'll write this out negative map reply the negative map reply is going to tell the ingress router so again this is the itr is going to tell the ingress tunneling router that hey i don't have an entry for this so you got to stop and think for a moment in a traditional environment if i don't have a route i'm going to drop that packet but in a in a lisp environment if i don't have that route i don't necessarily want to drop it because that route might exist somewhere it just might not be part of my lisp domain and if it's part of if it's uh not part of my lisp domain i'm going to forward it to one of the proxy xtrs or the yeah proxy i said that right so now at this point this is going to be a peter instead of a pitter i suppose proxy egress tunneling router i'm going to send that traffic to the p-e-t-r and the p-t p-e-t-r is going to at that point decide whether to drop it or not in other words it's running bgp it's got a bunch of routes and so maybe it does have a route outside of the lisp domain and maybe it does not by the way maybe it doesn't know exactly where it's supposed to go and so if it doesn't have a route at that point it will drop it but if it does have a route this essentially turns the pxtr the petr however you want to say it it essentially turns this into a default route because what's happening is as the traffic comes in if we don't have a destination for it we're simply going to send it to the pxtr that's exactly how a how a default route works as well all right [Music] all right so the only other thing i suppose is to think about the fact that now also we're getting traffic back in so if we were to pull this up say okay so traffic now is coming from the non-lisp domain and let's say it's landing on one of these uh pxtr so now this is a p-i-t-r and we're destined for you know something else out there i suppose like let's say subnet c is living off of here pitr is going to operate exactly like an itr at this point it will send the map request to the msmr and the msmr is going to respond back with a map reply telling it where c is remember it's responding with the routing locator the r lock and so now the pitr knows to send it over to the router to which c is attached okay [Music] moving on yeah i think that's it for a lisp so if you have any questions about any of that uh be sure to chime in again to the chat no no real surprise if we've got a lot of questions going with this lisp is kind of a new animal most of us don't have a whole lot of understanding of what exactly lisp is or what the problem is trying to solve but i think that's the key is if you at least keep in mind what the problem is trying to solve which is routing table explosion right and you know how we can solve that problem and we do it using tunnels and by tunneling out to the riding locators we can just send traffic through there and not have to worry about every router knowing where every subnet is that's the goal of lisp and so i keeping that in mind that'll really help us understand that and again walking through this scenario and this you know today this is really going to help us with our sda conversation next week because a lot of these same concepts are going to apply to sda this is again sda is using lisp under the hood at the control plane but then we're just we're not going to package it up with lisp in the we already erased it but the tunnel packet diagram that i drew earlier yeah i think that's the right word uh the diagram that i drew earlier that's for lisp not for sda all right so what are we doing with uh sda at the data plane and that is let me just go ahead and clear all of this actually there we go that would be vxlan we are finally ready to talk about vxlan we're at about almost 45 minutes that's almost exactly right we're here to talk about vxlan all right so as with lisp we need to step back and think about what problems vxlan was trying to solve by the way vxlan stands for the virtual extensible local area network now sometimes it's explained as if vxlan was meant to replace vlans you know vlan and vxlan vxlan the x is cool and new and so it's replacing it it's not saying that it's there to replace vxlans is not a good way of describing it because it makes it sound like it's roughly the same thing it's just you know vxlan has um more more space right we've got 24 bits which is 16 million different segments in vxlan and 16 million is a whole lot more than 4096 when we go from 12 bits and vlan to 22 bits in vxlan that that sounds like our 24 bits rather that sounds really great but that's not actually the value of a vxlan it's it's certainly a value it's not we're not simply replacing it in the exact same capacity all right what if what vxlan is essentially doing is as elevating if you will um the vlan concept so we had in the with the vlan concept we have 4096 ways of segmenting our network this is vlans vxlan takes those 4096 and equates them to a virtual network identifier or a vnid and so because we have 4096 vlans and they can be part of a single v ned well now all of a sudden we can have a second v nid and this vnid will have 4096 vlans and so now all of a sudden we see that oh well as i scale out these v-nets these v-nets each one has the capability of supporting an entire layer two domain entire layer two domain being all 4096 vlans so how is it doing this well these venis are essentially again we're segmenting the network and the way we're going to segment that network is by creating guess what another tunneled domain vxlan is not a network segmentation strictly speaking a protocol that was built for network segmentation yes that's part of it but vxlan is a tunneling mechanism and specifically excuse me it's a tunneling mechanism that maintains i'll write that out maintains that layer two information we talked about it with lisp when we encapsulated a packet in lisp and from a data plane perspective we scrapped the layer two information and with vxlan um first of all we're going to build this from an ethernet perspective vxlan was not built for like wide area networks and things like that so we're going to maintain the layer two info and specifically that's going to be the ethernet header that ethernet header will stay inside of the tunnel that i build to a remote device so let's see here so if we look at that from a from a diagramming perspective let's just do that now so remember before where am i going to draw this right here so let's say we've got the original payload that would be the layer 5 through layer 7 info so we've got the layer 4 info here a tcp udp whatever that is and then we have the ip address but from the original packet perspective again we're going to keep the ethernet header since we keep the ethernet header that is let's call this the original the entire original frame now it's a frame right because it's ethernet and from there now we're going to throw on a vxlan shim header and same thing with ud with lisp we're going to throw udp on it and we're going to throw ip in front of that and then assumedly another ethernet frame here so the key here is that because we're keeping the ethernet header intact we are now carrying layer two information with us across check this out across a layer three domain we're actually routing at ip this ip header allows us to route whatever's in here and what's in here happens to be a layer 2 frame so we're now routing layer 2 across the layer 3 domain now this one thing we have to keep in mind here is that and this is true with lisp as well but we need to think about mtu and so anytime we're adding on information adding on headers look at this for example like the original header for example because we've got the original ethernet header in there that that's no longer part of the 1500 right i mean the uh the 1500 bytes that we could support and so now we're adding on this ethernet header and this vxlan header and udp and another ip header and so this all amounts to usually 50 bytes of additional overhead but in some cases um with the embedded ethernet header here if we want to we can actually keep the vlan header intact and if we keep the vlan header intact then this actually becomes 54 bytes one misconception in the tunneling world is that you have to increase the mtu or the tunnels won't work and that's actually not true the tunnels operate at layer 3 and ip allows for fragmentation so if you mess this up good news is the network will work it'll fragment the tunnel pack it which isn't ideal and it'll send it across the network and it'll get refragmented and life is good and so this is why deploying tunnels in a lot of cases you might end up kind of messing up the deployment you'll never know about i mean that's the good and bad of fragmentation is it it makes up for your mistake but it doesn't tell you you're making a mistake until your router cpus are all spiking up high because it's spending all of its time fragmenting and defragmenting packets so we want to make sure that we do increase the mtu not for the perspective of the tunnel won't work but from the perspective of it will start fragmenting packets and um yeah i i'll i'll get off my soapbox on that there's it's actually a lot of it's interesting there's a lot of misinformation out there with how tunneling mtu works and so for you know yeah i'm not going to go into it now i don't have time to go into it but um what i'll challenge you with if you are studying for the encore is go if you've got a lab environment open up your lab environment build some tunnels just gre tunnels you know make tunnel interfaces and set the do not fragment bit on pings and send them through the tunnel you get onto those tunnels because the common scenario is get onto those tunnels and set them for 1476 um and you know from an mtu perspective but it doesn't work like you think it will so fit play with that and do yourself a favor and get a better understanding of how mtu works from a tunneling perspective either way we want to set our domain to be 54 or 50. incidentally by the way sda does not use the vlan header and so we only need to increase it by 50 bytes so it should be 1550 bytes at a minimum in our underlay and we can always just go higher we could just do 9000 and then life is rosy so but but increasing it by 50 bytes at a minimum for sda 54 if you're building your own vxlan network and intend to use the vlan tags okay so um the the that's essentially it from a vxlan perspective but i want to paint a picture here because the way vxlan is designed to work is it was really intended let me change colors here it was intended to work inside the data center and here's why for those who aren't familiar with the data center doesn't spend a lot of time inside the data center we have some challenges here that we don't have in other parts of the network for one we want layer two communications we talk a lot about how layer two communications is bad or are bad but layer two in the data center is important this allows us to do things like vmotion or more generically speaking my live migration it allows for storage communication we do a lot of uh iscsi and um maybe even some other protocols like nfs and sifs and such and we want that to be as much as possible at layer two we're also by the way doing jumbo frames as much as possible and jumbo frames usually is going to be a layer 2 concept as well but we're applying that to storage and vmotion because they are layer 2 and we these are heavy hitters on the campus network for the most part we upgrade our access layer switches to 10 gig because it makes us feel good but how often are we using more than 100 meg on our uplinks not not very often because most of our user traffic is just sending http messages out to the internet or what have you we're not doing a ton of data transfer out at the edge in the data center that's absolutely not true we are doing a ton of network traffic inside the data center and it has to be at layer two furthermore we have a lot of multi-tenant data centers multi-tenant i'll just say multi-tenant we think about cloud at this point if you have a cloud space and you're spinning up virtual machines for many different customers at once then you have to worry about keeping that network track traffic segmented and if we have a traditional infrastructure where we've got maybe a bunch of switches here we'll just draw two switches and we've got customer a and customer b here and customer a and customer b on this switch and okay from a layer 3 perspective we can definitely like carve out some vrf's and such and make sure our routing tables are split up and and that's great from a layer 3 perspective what about layer 2 and you know if this is just a trunked connection here in the middle and we're not even routing we're not even hitting our routers and worrying about vrfs how do we segment customer a from customer b well the best way to do that is with vlans and so we assign vlan 10 to customer a and vlan 20 to customer b or what have you and if you're a small internet server if you're a small um service provider a data center provider then this might work and and we've got 200 clients and each one of those clients has four or five vlans right then then okay so i only need a thousand vlans and i'm good but for large service providers can you imagine amazon being restricted to the 4096 vlans that's a problem in modern data centers because 4000 is way too few 4096 is almost too few for some large well i did it is it is too large or too few vlans for some enterprises um network segmentation we're segmenting our own networks and so as our service provider environment here just spins up we need more than four thousand what are we going to do and the solution up until this point is to segment with private vlans or you know again to have come up with some sophisticated mechanism so i know that um you know this router over here or this switch over here maybe it has vlan 10 assigned to customer c knowing that vlan 10 has been removed from the trunks that go over to the other switches or what have you and that means that i can't have a 10 over here i can only have c10 on this switch and a10 on that i mean it gets to be a nightmare how we split up our vlans and so vxlan was designed to solve a lot of these problems there are other problems with the data center that uh you know from an aggregation perspective data center pods and such scaling out at layer three um that i'm not gonna go into at this point but just understand that this layer two is so important that as we scaled our data centers out and we again we hit our limits and we needed to put layer three boundaries inside the data center that that kills our ability to do layer two you know if i if i've got two data center pods that are connected at layer and i need to do a vmotion from one physical server and one pod to a physical server in the other pod well that's just not going to work from a layer 2 perspective and likewise if i need to send storage attached storage between the two at layer 2 i don't have layer 2 it's layer 3. and so vxlan was developed to solve a lot of these problems for us this usually is going to go part and parcel with a leaf spine architecture this leaf spine architecture makes it so that i've got spine switches on one layer leaf switches on another layer we do not connect spines to spines we do not connect leaves to leaves and the way this is going to work is this becomes a layer 3 fabric inside you know between spines and leaves and because i'm connecting between spines and leaves here let me do it like this or show this this domain in here is going should should already start to look this already start to look a little bit familiar at least and really what i should do is draw it like this to include the spine switches this is an underlay and i'm going to start building my tunnels between my ax uh well leaf switches i'm going to start building my tunnels like this such that now i've got segmentation between my my neck or not between my access layer switches so i've got layer 3 segmentation between my layer 3 switches and so now i've got these tunnels built and spoiler alert these are vxlan tunnels and vxlan can carry layer 2 information which means that i can have a client on a on vlan 10 on this switch and here's the interesting thing i can have another client client b on a completely different vlan locally so i've got vlan 20 over here but because they're part of the same vxlan identifier that virtual network identifier which lives here i guess we never clarified that i apologize for that this v-nid which is a 24-bit valley yeah that's the right 24-bit value which gives us 16 million um vlans or v-nets vxlans there we go um because i've got these different vnids i can connect these two from a layer to perspective which means that now i have 4096 different segmentations per access layer switch or per leaf switch and so this is how the world of vxline is solving problems inside the data center it's really what it was designed to do i don't need to worry about layer 2 anymore because even if i have layer 3 pods i can build tunnels through those and leaf spine kind of gets rid of no it doesn't get rid of the idea of the pod but it certainly makes it less of a requirement that i move to pods my pods can be a lot larger with leaf spine the multi-tenancy not a concern anymore because i'm not going to run out of vlan ids i've got 4096 per switch basically and so i can handle that no problem and so it solves all these problems in the data center but cisco's paying attention to the x-lan and so when we looked at lisp and said okay that's great for the service provider that i'm doing layer 3 tunneling but then i look at my campus infrastructure and my campus infrastructure i need layer 2 tunneling because i need just the same reason i do layer two out to my access layer closets i need vlan 10 to live on every single one of my closets and maybe vlan 10 is a particular subnet or what have you now if i change that to a layer 3 design and i'm going to build tunnels between my access layer switches which is what software-defined access does if i'm going to do all that then i need a tunneling mechanism that can carry layer two information and so what we're gonna find next week as we walk through sda fabric operation is that we're going to leverage lisp all the things we talked about today from a lisp perspective at the control plane and then we're going to leverage vxlan to build the tunnels that will allow me to carry layer 2 information back and forth among my edge switches so that was a uh a lot quite a bit actually um from uh uh yeah lesbian vxlan there's there's always more there's always more to cover with these protocols there's certainly some more information that we could have talked about with lisp or vxlan but it's not the purpose of a one hour study session is to pump you full of all of the information uh certainly on cbd nuggets website uh i go into effect there's dedicated skills to each one of these to lisp and to vx land so quite a bit of content just dedicated to these two different protocols for those who have a cbt nugget subscription for those who don't if you're studying your way through the ocg there's plenty of information and that the official certification guide is what ocg stands for for those who are wondering um again this is what we need to understand from an encore perspective if our goal is to pass the ccnp and to get the encore i on route to getting this ecmp then this is plenty of information this will get you probably where most of the way where you need to go again with the goal not being lisp and vxlan because you're not likely to get a whole lot of questions on lisbon vxlan on the exam but with the goal being how does sda work because fair game to get asked about software-defined access on the encore so thank you very much for joining everybody for those who are watching live i'm going to stick around and the chat answer any questions that you may have over the next five or ten minutes so uh otherwise hope everyone has a great rest of your week we'll see you in two weeks for the next session which again is sda fabric operation until then [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] you

Channel: KishSquared

Views: 10,232

Rating: 4.9616613 out of 5

Keywords: ccnp, encor, cisco

Id: fKkcyZmKt3c

Length: 69min 28sec (4168 seconds)

Published: Wed Nov 18 2020