BOSNOG @ 128 Technology, September 29, 2016.

the Boston network operators group met on September 29th 2016 to hear a presentation by tech startup 128 technologies the discussion is aimed at network engineers on the topic of rethinking from the ground up how routing is done in this presentation by one of 128 technologies founders Patrick Timmons you'll hear the problems they were trying to solve and the fundamentals of the solution they've brought to market as a result if you're in the Greater Boston area and would like to know more about the Boston network operators group take a look at Bosna go RG thank you for coming one of the Seven co-founders I didn't know Andy was going to be here as it turns out you know my beginnings of the story starts with Andy the Seven co-founders all came from another networking company based about five miles north of here we worked in the telecommunications industry we built an appliance that was used for securing and interconnecting voice and video over IP networks and around 2011 this picture was taken at our offices just up near the bedford line and then governor of Massachusetts deval Patrick came we were a big Massachusetts employer and so he was coming to press some flesh and kiss a babies and whatnot and I don't know if it was because Andy has some sort of latent desire to become a politician or if he was just drunk with power or swept up in the moment but he had two admonitions that day one was make routing great again the second let's build a firewall this was 2011 and so meanwhile two floors above where this picture was taken our engineering team who had built spent ten years building this hardware appliance for securing networks voice and video networks had been implored by our customer base to start looking at the then emerging NFV field like what can you guys do and we had invested tens of millions of dollars if not more building every one of our hardware platforms that scaled to you know fifty thousand eighty thousand one hundred and twenty thousand concurrent phone calls and they said build it in software we said ah can't be done can't be done they said come on build it in software all of our other vendors are moving to software and we said can't be done but two floors above while this picture was being taken our engineers were evaluating it and much to our surprise software running on commodity hardware not purpose-built hardware that cost tens of millions of dollars and years and years and years to to engineer commodity hardware and software were meeting or exceeding performance in just about every metric and it was at that moment that we knew that we were on the cusp of a revolution in networking and so yeah we went through with our plans and we built an NF via a software version of the platform that we had spent a long time building as as hardware but it started to beg the question well what's next what's next I mean yada yada yada the company was sold in the seven of us that founded this company got fed up working for the acquirers and so we put that knowledge to use and we started to look long and hard at IP routing we were voice and video guys predominantly and not all of us but the lion's share of us were voice and video guys for our career and so we looked at IP routing through a different lens than traditional data folks may and we looked at things as sessions like a phone call you pick up the phone and you dial some digits and you initiate a call and there's somebody else on the other end of that that receives the call there's a directionality to who initiates that telephone call but once it's established there's a symmetry you know you're talking to each other and that's sort of signaling that approach to session orientation via a signaled exchange was something that we was really percolating the background as we were moving forward towards our NFV plans and what's next after our previous company was sold and so we started to look at IP routing and this slide here just a disclaimer most of these are not my slides except for the one with Andy you know it just start out with a gag but so if I fumble through some of the builds and all that please just forgive me but this slide here represents the promise that RFC 1771 made in 1995 as the internet was starting to take off and the pundits at the IETF said mm-hmm we'll make a stateless routing network they'll have security at the endpoints everything will be stateless and so if there's any failure it get routed gets routed around it's very simple very easy of course you know BGP for had I don't know countless revisions I've never seen the IETF move so fast as they did when they were revising BGP for to account for things like classless routing versus classful routing and all that but anyway simple it was built to be simple but when you look at it and of course I'm preaching to the converted here but the reality is it's anything but and it's not stateless because in order to get the services that your end-users want to consume to work you have to put stuff in the way and the stuff that you have to put in the way our firewalls and load balancers and overlays and all a DPI or whatever all of these different middle boxes in fact you know we built a middle box in our last business I'm well-acquainted with middle boxes and so this is the reality it's not a simple stateless network the routing plane may have been stateless but there's state all over the place and you know Andy mentioned just coincidentally he and I didn't plan this or anything but he mentioned that if you could go back in time and tell the 1993 us what 2016 us is observing that you may have done things differently well I don't know if the time was right in 1993 to have a stateful routed network Cisco and other router vendors at the time were just doing everything they could to stay afloat and and make routers that were keeping up with the speeds and feeds that the the booming internet was demanding and it begat industries like firewalls and load balancers and other middleboxes but now just as we learned our lesson at our last business about how you can against all disbelief take these functions that were once the in the realm solely in the realm of purpose-built hardware and do it in software and so now not only did we decide when we founded this business to look at software based routing but we thought well what else I mean there are software routers out there right now but what else how could we design things differently how could we avoid this take our heads out of the ground and say you know routing isn't stateless look at this and so we have of we had a vision the seven of us two years and two months ago and it was for creating a secure vector routed Network and I'll explain later in the presentation what what I mean by secure vector routing but really it's all about getting packets from where they start to where they end in a predictable way in a scalable way and in a secure way meanwhile if we can get rid of the middle boxes along the way all the better and so I'm going to talk about some of the scale I'm going to talk about some of the simplification attributes of our platform and some of the secure attributes of the platform I don't have slides for all of these things you know I'll be happy to just be extemporaneous about it or whatever so our software was built from day one and my colleague Mike by who runs engineering this was this was his number one mission when he built our engineering team was to make something one software platform that scales from the smallest needs to the largest needs the way we did that the approach that we adopted was we looked at what a chassis based router looks like traditionally which has a control plane and various line cards that you insert and you you add to your chassis when you need more capacity we reinvented that as software and then we blew it up what am i what do I mean by that is we took the components that make up a chassis base router the line cards in the control plane and we developed each of them in software and then we allow you as a network designer network architect or network engineer to disperse those components in your network wherever you want it's not drag your packets to this chassis it's put the components of the chassis where the need is make everything a routed network make everything have everything be its own network segment and so we call these different components the line card it's a this thing right here that says slice that's a acronym software line card engine a slices of our software line card the control obviously is the control plane and we use these different icons you'll see sprinkled throughout the presentation to represent the control function the slice function or when we have our whole logo entire intact there that what we call a combo which is a portmanteau of the slice and control in one package and it was this distributed architecture where which allows us to scale from branch size you know running on these little nooks or nooks or whatever you however you pronounce it these little small micro micro form factor pcs running at our combo software all the way up to a data center where you can add as many line cards as you want to no it's not like a capacity the chassis that has capacity for eight line cards have 800 line cards 8000 line cards it's it's unfettered by any constraints imposed by hardware and so it's the scalability that is granted to us by virtue of the fact that it's software some photos of some of the equipment that we took in the lab over here earlier today there's a little guy over there it fits in fits in your briefcase it's a quad-core Atom processor the street price of that hardware is 150 bucks or something we take it out to demos and whatnot that we call our noisy cricket that's the men and black reference there is the little gun they gave Will Smith but the noisy crickets will do about a gigabit of traffic with today's software you know it's it's pretty beefy for $150 a little hardware platform and then we've got these 14 cores eons that we've got running at 40 gigabits all software and these like what are those I can't tell in the picture Lenovo or Dell or something I mean it's a couple thousand dollar piece of hardware getting 40 gigabits of traffic you know I learned on the packet pushers podcast while we were working here at this business that the the Cisco ASR 1000 series router I think it may have been their first 10 gig platform geared for enterprises it took them seven years to build and three acquisitions to design the silicon and you know we don't have any of those challenges anymore completely different now the game has totally changed and not only can we just take the packets up in software and decide where to route them and then fire them out but we can do interesting things to them in route - it's not like we're beholden to the decisions made when we put these Asics onto the motherboard and cast cast them aside so let's take a closer look this is a logical diagram that shows at the top our control function and here are the slices again I showed in the previous picture these two things can be cold resident in one logical software instance it's not like they're managed independently in fact like a chassis based router even if you cast these software instances of slices and controls strewn about your data center cast to the four winds you manage it like one logical router there's no logging in to a thousand CLI is to manage discrete entities all of these things are viewed through a single pane of glass single management instance single set of api's Netcom a single CLI single GUI all of that I also want to point out that this may smell a lot like open flow or something it's not open flow these packets don't come into these slices and then fly up to the the control for it to do some consultation and advise the the slice on how to do its routing or packet forwarding the control is really your policy engine it's where you decide how you define the services your network is bearing the properties that those services need to have and yes any of the traditional routing behavior of the BGP neighbors and communities and Confederations and all of that stuff gets provision here and all of that policy gets pushed down to these slices and these slices operate independently I mean they're operating based on policies they learn from the control but they effectively operate independently they have their own rib they have their own forwarding table they have their own instance of the of all of the policies that's been pushed down this is not an open flow like model I also want to point out while I'm here but this Fastlane here that's an homage to the 128th - you'll see references in our software in our marketing and everything to a different roadway like we have a service area and a fast lane it's just you know like that fun with it - but in the slice each one of these packet forwarding engines is where all of the heavy lifting is done so packets enter into the fast lane the fast lane is what's doing all of the you know your standard fare for packet processing it's doing all of your policing and your shaping and your deer dscp marking and your cueing and your scheduling and your transmission all of that happens in software in the slice the the slices communicate with each other over what we call the IP fabric there's no fabric backplane in a chassis anymore because you've dispersed these components now your IP network your layer 2 or layer 3 network between these slices becomes the fabric as it were and so we call that that network between these guys the fabric impact packets come in the slice determines based on the policy and its configuration where the best destination for that session resides it chooses its complementary slice it does some voodoo that I'll get cover in the next slide sends it off to its complement that slice takes that information it unravels it and it fires it off to the destination any questions so far okay so here's the session where data plane we call it so a lot of the magic that the 128 see we call 120 80 a lot of the magic that the 128 T router does is in the first packet that's received for a new session and again think of this through the rose-colored glasses of someone that's coming at this from a voice and video over IP background where every IP session that exists between a client and a server or two endpoints the two hosts looks like a session a bi-directional exchange of packets there's a request generally in a response with very few exceptions so the source transmits packets to the 128 T router the 128 T router says hey I've never seen this session before this is a first packet maybe it's a TCP syn maybe it's a UDP packet from some source IP and source port and desk type P the tuple is unique and it says hey this is something new the slice looks at its policy to figure out where to send it and again all of the policy is resident in every slice there's no open flow that packet is stays local to that slice it looks at its policies the policies can be based on current capacities of the links between it and its counterparts or the capacities of the counterparts themselves if they have some session thresholds that you've set it can look at the quality of the link between the two devices that it's proactively measuring using BFD and other techniques and it picks the best destination for that particular traffic it takes the original source and destination address is present the s and the D and it puts those into what we call the metadata first packet that we're just talking about the very first packet of a new session by the way that's it it takes the original source and desk and it packs them into this this header that's maybe anywhere variably between 40 and 50 bytes and it puts it into that metadata and then it assigns what we call 128 T specific Waypoint addresses just like a pilot when he's making a flight path between two cities has to decide on a series of waypoints control towers that is going to check-in that as it goes from its origin to its destination we adopted that same term Waypoint to describe the source IP address and the destination IP address of the routers themselves so we this slice here is going to select a source Waypoint and a destination Waypoint its chosen that the terminal 128 T complimentary router based on policy it picks its own Waypoint it picks the far end guys Waypoint and it does a double net it then sends the packet on its way the underlying network Ford's the packet to that destination Waypoint which is owned by that other slice that other slice unpacks the metadata and it does some some authentication checks it does integrity checks the way that the metadata isn't just source IP and destination IP and all of that there's there's other secret sauce in there to it unpacks that metadata it reconstitutes the original packet the TCP syn or UDP Datagram or whatever it may be and it fires it on to its destination exactly the same as it emit was emitted from the source so between here double NAT as it egress is it's as though nothing had happened yeah another source it sounds like I not sure i under understand your question hundred percent so you're saying if this guy picks yeah okay it is yeah I should have clarified it mean it picks a source IP port tuple and the source IP port tuple that way point and the destination IP port tuple the destination waypoint are unique are globally unique and so that five tuple of source IPS des type II source port desperate and transport protocol that unique five tuple represents effectively a session key I did uniquely identifying that session it wouldn't know it would always pick its own its own self correct there can be there can di you mean it once this guy receives it could he then fire it off to another 120 80 yeah potentially sure like this guy could pick his next top Waypoint and this guy could in turn pick a next top Waypoint as well in fact yes so just by way of example we've got a field engineer sales engineer that lives in Seattle and he has his own home office and we've got our own we're eating our dog food in the closet the IT closet in the corner of this building he's got one of those little Intel nooks running our software in his closet and one of our first experiments when we got all of this stuff working a year and some months ago was to do what I've just described now then we hired some guys in Japan and they said well hey we want to get onboard to one of the our Japanese field engineers took one of these nukes and put it in his lab and he relays packets to headquarters via our Seattle field engineer's home lab so Matt was mostly just a goof around with it because we like we like rolling our sleeves up and doing weird stuff yeah he could have come directly to us of course but ya know all of the traffic that we we generate out to the Internet or anywhere else for that matter from this building goes through our product and so you know there's a lot of important things that our people are working on here and so when someone needs to go make configuration changes on our router it's you know it's not like hey let's just go make some configuration changes and see what happens so it was easier just logistically for us to experiment with the fella in Seattle than it was for us to experiment with I wonder in a closet but it could have been just as easily the other way and basically the same thing happens in Reverse conceptually it's the same thing that happens in Reverse so the sin I showed in the previous I'd assume it's a TCP syn that goes from source to death that that server that receives the TCP syn generates a syn ACK fires it back the other way the slice that's there will insert reverse metadata or what we call reverse metadata just backward packet processing that basically does the exact same thing although there's no need to pick waypoints anymore those have already been selected for this session but the reverse metadata that goes from the the second slice in series to the first can include metrics on path performance and utility for example this this slice may be you know a small little form-factor guy that's running out of gas he could he could put on some active suppression to say hey you know no more traffic for a little while I gotta cool off but the metadata includes some stats and metrics and and other utilization data so that the next time a new packet comes to this original slice he can make a more informed decision about where to send the next traffic that arrives and so that's that's really the gist of how our packet processing engine works between the two slices it's a double net all of the decisions are made by the first slice they're abided by the second slice in line although this is not just taken at face value as I mentioned there's encryption and authentication and all sorts of other security functions that are that this slice can and will include as its forwarding packets over to its counterparts so he can do some integrity checking to make sure that it's not just some you know rogue agent firing packets at them and all of this this mucking around that we do with the packets is completely transparent to the source and the destination because it's all unwound before it leaves our fabric it it can be all one router the way that we've set it up today is as three separate routers but again it's just as much for our guys to just you know have something to play around with in their own labs they each have their own lab set up so that they're playing around with but yeah they could all be three slices within the same router absolutely I don't I neglected to mention that the choice of these waypoints ensures or enforces I should say some modicum of path symmetry just like the example I gave with the the pilot who puts out the flight plan says I'm gonna go from Logan to SFO via these this set of waypoints I'm gonna check in with it now the flight pant plan for this pilot may differ slightly from the flight plan of plan of another pilot you know they may take different approaches and all of that they're still going to check in at the same way points we couldn't guarantee that the first packet from the source to the destined packet from the source to the destinies this side of the slice or that side of the slice but these waypoints here and because the IP addresses are owned by the the routing elements ensure that we're going to see all of the packets symmetrically for both sides of the session the forward flow and the backward flow it was this enforcement of symmetry that really got us thinking that you know if we do this and we are seeing we're assured of seeing all of the packets in both directions of this IP session then we can start to do some interesting things and that was one of the the sort of what's the word I'm looking for it was one of the concepts that we had for eliminating all of the or as many as we can of the stateful devices that exist on today's networks the middle boxes oh okay a little box so as you guys know middle boxes are everywhere I read some white paper that was published in 2012 by some Berkeley students that said that the number of middle boxes on any given Enterprise is approaching if not exceeding the number of routers that are on those middle boxes on those networks and every one of these middle boxes requires subject matter expertise it requires management maintenance and all sorts of this periphery that makes these networks more complicated and you know you got VLANs you got q and q you've got tunneling you've got all sorts of stuff just to get packets to flow the way they want to go and our argument is that well our waypoints can be used to direct these packets where where they're going and if we can see both sides symmetrically of an IP session then why can't we load-balanced them why can't we act as a firewall why can't we do all of these gnats and seed carrier grade gnats and you know if we're seeing all of the packets for all of these sessions we can come up with some really cool analytics to show our end users on the behaviors of their network while we're at it and so we feel that by subsuming some of the functions that these middle boxes are are contributing to networking today and putting them arguably where they should be in the router you know Andy's flash back in time and build a night a router in 1993 that can load balanced and and be a firewall to today's technology makes it a reality I mean that the the behaviors of softer and the performance of off-the-shelf compute means that we can follow Gordon Moore's law and say every 18 months our routers are going to be twice as fast it's not going to take us seven years and three acquisitions to make something better just ride the curves and so that's that's the idea you get it yeah we don't have any individual licensing for load balancing and firewalling and all of that it's it's part it's part of the base package yeah so as I mentioned when a when a slice gets a packet in and it goes to its policy decision like what do I do with this you can tell it the capacities of all of the links on your network if you want you can tell it the capacities of all of the other slices that exist in the network you can apply administrative costs to and and course packets into specific in specific ways if you're so inclined but you're not beholden to that you can these these things can be configured to do whatever you want to do and if you want a load balance you want to send some this way and some that way that's fine what our fire approach to firewalling I think I get to it in a couple of slides if I don't then I'll talk about it off the cuff but I earlier mentioned that I would get to our topic of secure vector routing I'll dig in a little bit now our route policies that you define on the 128 T router are slightly different than you would get in a standard bgp routing table you know it's not like the wild and woolly days of 1995 internet where you have these massive routing tables of classful blocks that are exchanged and everybody knows about every other classful block the way that we do it at 128 T is you define policies from source source endpoint groups to destination services it's a service-oriented approach to describing routing and the way we've broken it down I our data model discussed the a data model we use to drive our router it's much longer conversation so I'll just set the table a little bit we describe our configuration either as top-down like you define the services that your network is gonna carry your web services your database services your voice services your video services conferencing whatever it may be you define the properties of those services the addresses and where the servers live the the thresholds for acceptability for traffic like no more than 1% packet loss or no more than 100 milliseconds latency whatever they may be you define your services in our data model top-down likewise bottom-up you define the actual components that you've your network is built from or your one 20:18 network is built from you define the slices you define the interfaces on those slices you define where the control functions live and then the combination of the service definitions and the network definitions are collapsed and wrapped with a big policy layer that you can define when those services get accessed and by whom the primary way that we partition our traffic sources is in what we call a tenant a tenant is a group of endpoints that all share some common properties and you define your services to exist logically within these tenants so by way of example in our office here as I mentioned we use our own product we have a few tenants just defined we have an engineering tenant where all of our developers machines exist and the engineering tenants the tenant for engineering has some services that have been defined for it our source code repository our QA test machines our documentation store all of these things are services that our engineering team has access to so they're defined within that tenant we also have another tenant that's defined here with a set of machines for our HR and Finance team and they have payroll information and they have a hiring plans and budgets and all of this stuff and the services for them are defined in that tenant now if I'm part of the engineering tenant I don't even know those services exist it's not like I I send a request to the finance server and I get rejected or I don't know what the user name and password and so I get unauthorized no route exists I can't get there there is no route and so my packets from my laptop as a member of the engineering tenant have no way to get through our network to those servers there's no security better than in accessibility and so by defining these tenants and the services within them and wrapping them up in the policies then you can address this this notion of network security in a very different way any questions okay I think I'm wrapping up here told I had limited amount of time I don't want to bore you guys I'm not going anywhere so if we have questions you can certainly ask me over a beer so we have we weren't targeting ourselves in any particular market I mean the routing market is really where what we're after but it's not like we're looking just at branch office or enterprise or a datacenter we're looking at everything anywhere a router exists and maybe some places where routers don't yet exist is where we're looking to put our product

Channel: Boston Network Operators Group

Views: 1,667

Keywords: bosnog, 128 technology, patrick timmons

Id: 4jUyfFCmN1s

Length: 37min 1sec (2221 seconds)

Published: Mon Oct 31 2016