SD-WAN Application Quality of Experience Innovations

my name is Aaron I'm a technical marketing engineer on Cisco's SD win product team I appreciate you guys let me talk to you guys for a little bit in ladies so this presentation we're going to focus a little bit on some of the new Sdn innovations that we have with regards to application quality of experience and then I've got a little bit of a treat one thing that was kind of snuck into the description but not so much into the title which is some of the new innovations we have in security particularly in umbrella security so talk a little bit about that first off Who am I so again my name is Aaron I'm a CIT in security I got it back in 2008 been doing deployment work for VPNs and remote access and unified communications I've done it all for a long time than been in the business for about 15 years or so I'm a Midwest boy I hail from Indianapolis Indiana it's where I still currently live so I'm one of the lucky ones that Cisco lets work remotely as part of the product team so again what are we going to talk about here today so application quality of experience at app qoe I kind of like to just flash this slide up here for a moment just to kind of lay the groundwork so to speak for app QE and what app QE is and how we define FQ Lee or application quality of experience so what is it it's it's basically a collection of tools or a collection of features that you guys can use within an SD LAN environment to improve overall application experience or improve overall application performance right so some of these little check marks whatever up on the screen will probably resonate with you you might know what some of them are some of them you may never heard of before and then a few of them we're gonna double click on here today the first of which will start off here with forward error correction so this is a bit of a deep dive technical presentation so hopefully if you get food few of you guys will get some get some good nuggets out of this but how many people here are familiar with redundant array of inexpensive disks raid I know there's a few storage guys I'm not a storage guy but I know right it had a lot of storage stuff in the previous days and whatnot but raid right so the idea behind raid is and I'll bring this into a you know connect these here in just a moment but the idea behind raid or redundant array of inexpensive disks is let's take raid 5 for example even though it's old we have three disks right 2 of those disks we're gonna put data on user data is gonna be stored on those disks the third disk is actually going to store information about the other two disks and the idea behind raid is that if one of those two disks one of the two user disks were to fail for some reason we can replace it with a blank hard drive or a blank disk and repair all of the lost data using that third disk so that third disk actually just stores a bunch of what you might call metadata about the other two disks that store information right so the idea behind raid is that we can recover from loss feck or forward error correction as we call it is essentially stealing a page from the storage guys playbook okay so what do we do here well with fact basically what we're doing is we're just like we would have a raid 5 with three hard drives we're grouping packets up into blocks of four packets ok so you can see here on the screen we've got two different blocks here right and block one here has four different packets inside it now we also have a fifth packet right so it's five packets in total but that fifth packet is what we call a parity packet and the idea behind it here is if for whatever reason I'm sending data across the LAN network right and one of my packets gets lost for some reason I can use that parity packet to recover that lost data all right so it's a lot like raid would do in a hard drive sense right we can recover a lost hard drive in this case we can recover a lost packet okay so it's a pretty cool feature right now a couple things to keep in mind here number one when would I actually use this I mean obviously yes I'm going to use it when there's some loss on the link and I want to recover some of that loss that totally sense but what's the actual use case for this well so number one what we're finding is there's a lot of customers out there that are deploying SD win and they might find themselves with some a couple remote branches out there in the middle of nowhere where there's really only one carrier that we can get out there and we can only bring in one come out of the internet circuit or one MPLS circuit okay so one of the premises behind us d win is that if you have multiple circuits we can load balanced across those circuits or we can you know correct for loss if one circuits lossy we can move traffic over to another circuit what happens if there's only one circuit this is where fat can step in right and help you overcome that loss on that single circuit right so you might find this out in the wild at those locations perhaps like at a bank for instance right you have a bank that has several thousand ATMs around the country you might only have one circuit to each one of those ATMs or perhaps even a you know an LTE connection or something to each one of those ATMs right I'm not going to have dual circuits to all my ATMs out there in the field this is something this is a feature this is a technology that you can couple with that single circuit to make sure that those critical applications that are running on the ATM don't incur any loss in the transit path make sense all right so a couple things about a couple additional things about fact number one it is dynamically invoked so where there's actually two methods two ways that you can you can turn it on one you can turn it on all the time the other method you could do use is dynamically so whenever the network or whenever the SDU in environment realizes that there's at least two percent loss we can turn it on all right now you don't want to go enabling this feature for every single application under the Sun because it is somewhat of a computational tax on the receiving router that has to reassemble some of the some of the packets that have been lost it's not a huge tax when we're talking maybe ten percent on the cpu 10-ish percent something like that but it is a tax right and depending on how many applications you're looking to rebuild it could be more and more and more you know depending on how much data that router is processing right now if you're a somewhat calm engineer one of the things that might be going through your mind right now is what happens about bursty flows okay this is all well and good you know when I've got nice little four byte or four packet streams you know and and the network's not all that busy in fact can do its job and you know so on and so forth but you know networks are typically bursty by nature right we got a big burst of traffic and then it goes dormant for a little while so for bursty streams there's a couple ways that we can solve that the first way that we can solve that with feck is to actually break those streams up a little bit right so if we've got ten people that are transmitting data all at one time so we have this big burst influx of data all of a sudden what we can do is for these four these four packet blocks here instead of just taking each packet sequentially for each flow what we'll do is we'll take one packet from let's say each each flow right so we'll take from flow number one we'll take a packet from flow number two we'll take a packet the flow number three we'll take a packet so on and so forth so the idea is each one of these four packet blocks is actually representative of multiple flows okay so if one packet is lost we're only impacting one users flow and hopefully we're reassembling or reconstructing that packet on the other end okay so that helps us kind of overcome some of the bursty nature's of network networking the other piece to this is if you have two circuits so if you do have two circuits right and you want to turn the feck on you can actually get some you know get some advantages with feck in that we can actually spread some of these for-for-for packet blocks out across two different circuits right that further help further help overcome that not only loss but overcome that bursty nature of networks all right so pretty pretty cool feature let me show you demo really quick here you can see what I'm talking about so first things first it's a pretty simple demo I've got a spiral traffic generator here I know this is somewhat maybe a little bit difficult for you guys to read so I'll read off what some of the values are here so you can you can see it for yourself or listen to me whatever you want to do but the idea here is what I'm going to do is I'm going to generate some traffic from a Spirent traffic generator to a receiver and this is going to go across to V edge routers that have feck enabled ok so initially I do not have feck enabled but I do have an impairment device sitting in the land that's interjecting 5% loss on the receive side and 5% loss on the transmit side so let me go ahead and fire up this traffic and I'll show you what I mean so go ahead start here now as soon as I do that you can immediately see we have some transmitted frames we have some received frames so on and so forth you can see we've got a lot of dropped frames right here and you can see right about 4.99 for 5.0 percent loss right so we've got 5% loss on this link ok feck is not enabled at this point but let's go ahead and enable FAQ so I'm gonna hop over here to my V manage I'm assuming you guys are you know some of you are at least somewhat familiar with the manage B manages our controller he manages our graphical user interface that we use to administer anything Sdn related so administration monitoring provisioning configuration everything rolls up through V managed here so this is that dashboard so what I'm going to do is I'm gonna head under the configuration menu under policies now real quick just to show you where you can activate this feature if I click on add policy here and I lost my window me make that a little bit smaller I'm gonna add a traffic data policy now again this is just to show you where you can add this but under QoS or under a custom policy here I can enable this feature now what's nice about this is I can select IP address ranges I can accept I can I can select user applications I can select an individual users so on and so forth I've got all sorts of match criteria that I can identify and then ultimately here under the actions tab I can accept plus it a bit I'm sorry can you come on plus it go yeah absolutely I'm sorry the help I'm old yeah all right no worries so ultimately once we've matched on whatever application whatever traffic stream that we're looking for here you can see under the match conditions we have a loss correction tab okay so if I click on that really quick here you see we've got a couple options we've got feck adaptive effect always and packet duplication all we're going to talk about packet duplication in just a moment here but feck adaptive in fact always remember FAC always like the name implies it's always going to be on for this particular application feck adaptive we're only going to kick it on when there's two percent loss in the network okay so I've already got a premade policy that I'm just going to activate here so we'll just activate this guy down here now as soon as I do this if I head back over to my RDP screen let me make this a little bit bigger so you guys can see because I can here now as soon as I do that you can immediately start to see the drop frame count is starting to tank a little bit starting to go back down to zero so right now it's at four point two I'm going to reset the counters just to make that go a little bit quicker as soon as I do that what you can see is we are still sending quite a bit of traffic into the network what you'll notice here is we no longer have dropped frames no longer have dropped traffic so fact is able to recover 5% of loss in both directions right pretty simple pretty you know nothing nothing special we use XOR as the algorithm right so whenever there's a lost packet or whenever there's a loss within the network it's a pretty simple equation right it's kind of like one plus two equals three if we lose 2/3 deduction we can figure out that one plus x equals three we can figure out what we lost right that's all effects doing for us so let's go ahead and stop this and we'll continue on here so the next feature that we have is pretty self-explanatory right two is always better than one right so if you have those applications out there on the network that need the the utmost amount of reliability the utmost amount of no loss right we have a feature called packet duplication and exactly as the name would imply that's exactly what we're doing if you have two circuits you can identify the application you can identify the you know the user or the stream the information that you want to duplicate and we will duplicate it across two separate links for you right and the idea is if we lose traffic off of one link we can pick it up off of the other link pretty simple right so interesting a couple interesting things to note about packet duplication number one as with feck as well that I didn't mention this but they are both protocol agnostic right so you can use it with TCP you can use it with UDP you can use it with ESP I mean in you know any kind of protocol that you want now the interesting thing here is packet duplication really has a use case when it comes to voice right now Mac you know effect you could make an argument either way because feck can also introduce a little bit of computational delay right and that may not be good for voice but packet duplication is one of those things that's absolutely you know we can duplicate that voice stream so if we have very high profile very important calls that need to go through we can duplicate that voice stream as long as we're using a reasonable codec that's not using up a whole bunch of bandwidth this is not going to be a huge tax on your network to duplicate that that call all right yes sir it's a very good question around thick we're producing an extra packet so your bandwidth increases that's great but it's only between the two V edges that's correct right so they on there's no on post computational overhead is small yeah so in Irbil yeah so we're talking and I don't know if I need to repeat the question but you know the question is if if the yeah all right then it won't repeat it the so the computational overhead effect is is it grows linearly based on the amount of packets at the the routers processing right so in our testing right so we had a like an ISR 4331 that we turned it on with we saw generally speaking with one percent loss we saw about an 8 to 10% CPU hit okay okay and that's when we were processing close to 30,000 packets I mean we had quite a bit of traffic going through that and it wasn't that big of a hit right so from a branch perspective 8 to 10 you're not gonna turn Vic on for everything that's exactly right exactly right from a branch I'm sorry go ahead so yeah you don't pick up for a subset of traffic you wouldn't recommend turning feck on for the entire link or the entire capacity because you are gonna burn CPU you're going to some processing latency so you don't need to be conservative like cost you I can only do it exactly traffic exactly yep yep so yeah just a just to kind of continue on that if you've got like a branch router eight to ten percent something like that but maybe somewhere at the head end like an aggregation router or something like that you definitely want to be careful about how to turn it on and probably make sure that you're not already running hot on CPU anyway I would say somewhere you know if you're somewhere 30 to 40 percent CPU and you turn it on you can expect another let's say 10 to 15 percent 20 percent yep add it on there you're still within that safe bounds of that router like no big deal but again so packet duplication as the name would imply pretty simple pretty easy you turn it on the same way in the same policy structure that I was just in this has very good merit for voice however as I said if you've got a high high profile call since feck can introduce computational overhead that means delay for a phone call you know kind of kind of hit or miss there right but packet duplication we're duplicating that that that stream whichever stream makes it to the remote router first wins the other strings discarded okay also keep in mind though that because we are duplicating this or duplicating bandwidth as well so you want to be careful here about turning it on for everything under the Sun right you said stream is it a stream or packet packet I'm so right yeah and so in this particular system we're dealing with you know links possibly different latencies correct how are you handling that alumni so basically what we do is we will evaluate all of the different circuits that you have available so first off let's say you have you have an intelligent routing policy that says voice should always prefer MPLS okay so we're always going to send that voice stream or those voice packets down MPLS we're then going to evaluate the other circuits to find out which ones have the lowest loss latency and jitter and we're going to choose the second best one mm-hm and then send the stream send the duplicate stream down that way so if MPLS were to encounter all the sudden just encounter a bunch of loss you've got it backed up even though perhaps the internet circuit was you know maybe you had a little bit more latency and it's going to get there a little bit later we at least have the packets and the call still up they call probably you know mosque or might you know who knows might drop a little bit I'm talking war of concern about out of order packets so let's say we have a link with 10 milliseconds as our latency yes we have another link that's a lot slower that's 50 milliseconds latency I drop one packet on the 10 millisecond link but it comes off cross the 50 millisecond link it's going to show up after yes a number of other packets have shown up on the 10 millisecond link and so you have to add a buffer right and so what does that buffer is that configurable is that something that we can the buffer is not configurable the we will reorder in the packets when they when when they come in so if we are missing packet 2 and you know in your example we'll wait for packet 2 to come in on on the on the secondary circuit reassemble the stream and send it on its way so but what is the maximum buffer like you figured that actually both sides lost it or something like that yeah so the the the actual buffer itself I like I said I don't know that it's tunable from a user perspective and actually you know what the more the more than I think about it you're probably we're actually not doing any buffering I'm sorry I stand corrected so first packet comes in we're gonna send that first packet immediately third fourth fifth packet comes in if there is a high amount of latency on this circuit we might have missed packet two for sure if there's 150 milliseconds on this link and there's 20 milliseconds on this link the idea behind this though is not to overcome latency this yeah yeah yeah and I'm just for the benefit of the group the idea behind this feature is not to overcome latency but to overcome loss okay so if you do have very high disparities between latency azan links that's actually a segue into the next feature which is tcp optimization where we can we can help optimize some of those some of those flows that are going across links that might have high latency or high delay values okay so the third that the third feature kind of on that note is if you look at a TCP network if you look at an overall network in general particularly tcp tcp is a rather old protocol it's not very well suited in today's networks it's it's somewhat it's we're reliable protocol but somewhat inefficient and how it uses bandwidth if you look at a typical it's called a line graph of a teeth how TCP uses bandwidth it'll start sending traffic as fast as it possibly can peek out the bandwidth right and then the line graph might look something like this because once it encounters loss it will drop off 50% and then it will ramp back up drop off 50% so on and so forth so this is what a hosts stream might look like as its sending traffic we you know mostly good networking guys in here probably know this that's not great that's not a great use of bandwidth that's actually a really aggressive way to overcome loss so one of the features that we're implementing to help or I'm sorry not to overcome loss but to overcome delay sensitive or delayed networks or latency ladened networks one of the features that we're bringing in to help correct for that is TCP optimization now this has always been within the Sdn framework right we've always had the cubic algorithm that you could turn on the problem was is cubic it was okay but chances are your network your network drivers your your your protocol stack within your laptop's had better optimization algorithms built into them and cubic didn't really buy you a whole lot right so we've updated it essentially right so we're now moving towards and we just recently introduced the DBR algorithm which is google's google's homegrown algorithm if you browse the Google website or you've browse to youtube.com you've been taking part in abbr exchange and you probably didn't even know it all right but the idea behind bbr is TCP in general had to wait on loss before it could correct for that congestion in other words TCP when it saw loss it assumed that there was congestion in the network right what bbr does is instead is it kind of watches the network right in other words our routers will actually step in in proxy in place of the end host and the our routers will watch these TCP flows watch these TCP sessions going on within the network and our routers will actually control kind of act like gatekeepers as to who's allowed to talk on the network at the time so the net effect of this is our routers will essentially provide a more efficient use in a more fair use of bandwidth okay so under normal circumstances if you just leave to their own demise you know leave networks to their own demise most computers will just start sending as fast as they can they'll go into that back off algorithm and I'll start looking like this again and that works to start acting you know you know some users don't get much bandwidth some users get a lot of bandwidth it's just not great the idea behind bbr is that these routers now step in in proxy to help make more efficient use of that bandwidth okay now I got a bit of a demo to show you what I mean by this so I'm gonna head back over to my RDP session here and don't hate me but I have an RDP window within an RDP window here I'm gonna make it as big as I possibly can though I'm gonna open this up here now what I've got here is a tool called iperf I'm sure you guys have all probably heard of VIPRE if you maybe even used I proof to to take a look at what kind of bandwidth you have available and how your hosts are using that bandwidth so what I want to do here is set up a transaction between a client and a server okay so I've got a PC here I've got a server sitting over in the data center and what I'm gonna do is establish an iperf session to that server and iperf is going to download traffic or download stuff off of that remote server in order to measure how much bandwidth that it's giving now the important thing about this is I'm going to actually set up twenty different simultaneous streams okay so the idea here is I want to mimic what 20 different users would look like if they're all the sudden hitting that server at the same time so to do that let me go ahead and kick this off so we'll run this just a few times if you I mean you can kind of ignore what it's doing here but you can see an important thing that I want to note here is if you look at some of the outputs here what you can see here is the sender the server in this case was able to send 200 kilobits of data 210 210 210 210 210 524 for this guy what I'm trying to get at here and we'll run this just a couple times while I'm talking what I'm trying to get out here is it's not entirely fair right some clients got more more bandwidth than other clients did write some some of them were fair some of them weren't some clients got tons more right so the idea behind bbr here again you can look at it here 315 315 210 117 you know right you can you can kind of kind of do the math the idea here is it's not fair so let's go ahead and turn on TCP optimization and watch and watch what happens to some of these numbers again the idea behind TCP optimization is that the routers will now become more of a gatekeeper into the network to prevent TCP from being so aggressive and allow a more fair and efficient use of that bandwidth so I'll go ahead and enable the TCP optimization policy real quick here refresh couple times there we go I'll hop back over to our screen here and let's rerun our test a couple times now again TCP optimization may or may not net you more bandwidth the idea though is that you are have more efficient use of that bandwidth so each user gets their fair share and we're gonna lower delay right we're gonna lower delay we're gonna lower latency here so what you can see here 3:14 for 419 314 314 314 314 419 my point is is much more distributed right not one clients getting 600k a bandwidth the other ones are getting 200 not one clients getting one mega bandwidth and the rest of them are getting 200 it's much more distributed in fact most of these guys have 314 with the exception of this guy right here which has 419 okay which just could be more of a product of you know he was the last guy to send traffic when nobody else was sending what happens when everybody's doing beabea like beabea overruns cubic majority the Internet today is running cubic yes so you Vantage of PBRs that you actually get to stomp on everybody else's traffic which I like yeah which is great because everybody needs to upgrade their systems and too bad if you don't sucks to be you yeah right yep we need to promote upgrading and refreshing in it and that system yep the challenge is going to be I don't at this point because you're terminating the TCP session and then reinitiating so you can change the windowing and correct I assume there's a bunch of other stuff going on as well in addition to the the VBR that's a middle box on the internet and that breaks a whole bunch of fundamental assumptions are you ready to cope with that adapt and keep adapting as time goes by I'm not sure what you mean by yourself you know we're looking at quick so now we're changing away from the fee by and large most of the traffic is already quick yes and so this feature is kind of less relevant sort of because quick automatically implements well if you using quick out of right you know it's a very fluid environment are you going to be flexible enough to change and catch up I like to think so yeah so yeah yeah so so when the teller was first acquired we you know we had the cubic algorithm so bbr has been something that's been on the roadmap now for about I don't know about a year or so so I guess it depends on your your definition of what quick is how quick we can how quick we can respond to the to the market when a new algorithm comes out yeah now as part of that acquisition as part of you know the overall evolution of this particular solution obviously now it's on is ours we have quite a bit more flexibility in what we can do with is ours and horsepower and whatnot so yeah I mean III I like to think that yes we can be quick to the market in it you know if the market were to shift again and if there's if there's some additional protocol some additional algorithm that we want to use absolutely it'll look I'm just I guess I'm flagging for the audience be careful with this because when you intercept the TCP session there are consequences somehow unexpected yeah whence it sad I understood just think that going and turning this on because you're actually putting a middle box in a TCP flow yeah there might be that's a very good point yeah it's a good point I mean it's it's it's a it's a lot like in the old days we used to do a TCP proxy and firewalls right so we can inspect that yeah and that's up not only a big overhead that you're putting on the on the on the router on the firewall whatever that's doing it but yeah in the case that those Indian hosts perhaps we're may be using a different protocol or perhaps we're using a different algorithm now we're interjecting ourselves in the middle of that I totally get your point and it's yeah it's it's definitely something yeah like who this video cook it and something guys yeah just a little caution yeah a little practical assumption yeah understood alright so let me wrap this up real quick final thing I want to show you is this is I want to shift gears here for a moment in the last couple minutes and talk a little bit about security okay so with most SD win conversations you're talking about commodity internet you're talking about getting rid of MPLS potentially some some guys are keeping it some guys are getting rid of it in so doing you can't have any SD LAN conversation nowadays without talking about security right I mean it's on top of mine for everybody now I flash this slide this slide may be familiar some of you might have even seen this slide and in other presentations and whatnot but I show this for those of you that that you know are interested we do have a full suite of security capabilities built into the router itself so fire well you know an advanced firewall intrusion detection prevention URL filtering amp threat grid all that fun stuff however we run into a situation where a customer may not necessarily have equipment sitting out at the remote branch that's capable of running all of this what happens to them right what happens to these guys that need need URL filtering out at the branch and for that what we're introducing is a new product called umbrella secure internet gateway or umbrella sick you guys are probably somewhat familiar with umbrella right with DNS redirection and command and control you know monitoring and that sort of thing same concept here we're still doing the whole DNS redirection board and now we're actually adding in cloud hosted firewall and cloud hosted web content filtering as well so the idea here is is that your branch routers instead of having to host all that security stuff on themselves they can offload it up into the cloud and let's Cisco take care of it so your branch routers are just going to build a VPN tunnel to the nearest cloud security gateway right and any direct internet access or any internet bound traffic is actually going to flow to the umbrella solution where it can be processed by a next-generation firewall it can be processed through a secure web gateway functionality right so we can check all the content that's coming through amp threat grid URL filtering you name it we can do it now this solution has three different components to it to be aware of first one is DNS layer security we already know about that one that that's inherent to umbrella right so we do DNS redirection we scrub those DNS requests make sure they're not going to anywhere malicious and then we can kill it right there if we pass this first check then we move on to a cloud delivered firewall right there's all sorts of stuff that you can configure with an umbrella and I don't know I'm running out of time here but I could show you that on within the within the firewall we can do port we can do protocol we can do IP address we can even do user right Active Directory user if you want to permit or deny them internet access once we pass the firewall check then we move into the secure web gateway where we can inspect HTTP traffic HTTP traffic we can unencrypted it pardon me we can unencrypted that excuse me unencrypted that traffic and process it we can process any content or any I should say web content within that traffic so if you have business policy that says you're not allowed to use Facebook gaming you can get to Facebook but I'm gonna like you're not gonna let you use Facebook gaming you can actually control that here from with an umbrella right and like I said your routers for any internet bound traffic they're just gonna forward that traffic through an encrypted tunnel up to umbrella process it through this stack here and as long as it passes that check it's good to go it'll be sent out to the Internet the return traffic will then come back through umbrella will make sure none of the returned traffic has anything malicious in it forward it right back down to the tunnel right back to the originating host the nice thing is again there's no additional burden that you're adding to the end to the to the question yes sir they delivered as a single product or they delivered as each separate licenses these are all delivered as a single product okay yeah yeah so this is going to come so basically your SD LAN subscription right so you'll have like a 250 megabit subscription license or whatever anything up to 500 megabit it's one megabit per user so if you have a 500 mega license you've got 500 user licenses for this kind of stuff wow that's complicated cool do you is okay right so that being said I think I'm a bit out of time here I've got a demo that I can show you here but I think you know a lot of you guys have probably already seen the Umbrella dashboard you you might already be familiar with but yeah it's much like a firewall I think we've all seen firewalls in here we know we know what rule processing looks like right just know that like I said you can you can inspect web content you can inspect all that web traffic including secure traffic through the umbrella service with no additional impact on the end router

Channel: Cisco

Views: 1,075

Keywords: TFD, TFD20, EN, Enterprise Networking, SD-WAN

Id: NRQ_JIX7hPY

Length: 33min 56sec (2036 seconds)

Published: Mon Nov 18 2019