WEBVTT 1 00:00.000 --> 00:05.740 Wide area networks are a major part of our network. When we talk about our 2 00:05.740 --> 00:06.720 network architecture 3 00:06.720 --> 00:11.620 we'd said that there was a core block that would connect to a WAN block and 4 00:11.620 --> 00:12.880 unlike a lot of the 5 00:12.880 --> 00:17.920 other blocks the WAN block might consist of a couple of routers, sure in there 6 00:17.920 --> 00:19.200 and those are going 7 00:19.200 --> 00:23.760 to maybe full mesh connect back to our core but on the other side of that it's 8 00:23.760 --> 00:24.960 going to potentially 9 00:24.960 --> 00:30.560 feel like a big mess because the goal of our Wide Area Network is to connect us WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:24.960 --> 00:30.560 feel like a big mess because the goal of our Wide Area Network is to connect us 10 00:30.560 --> 00:32.640 to our remote 11 00:32.640 --> 00:37.590 sites and we might have a small handful of remote sites or we could have 12 00:37.590 --> 00:39.200 literally hundreds or 13 00:39.200 --> 00:44.070 thousands of remote locations. We're going to usually rely on a service 14 00:44.070 --> 00:45.440 provider or potentially 15 00:45.440 --> 00:51.400 multiple service providers to connect us from our what we might consider to be 16 00:51.400 --> 00:52.560 more of a local 17 00:52.560 --> 00:56.220 area network probably a headquarters location we're talking about high 18 00:56.220 --> 00:58.000 bandwidth, high reliable 19 00:58.000 --> 01:02.900 links but then going through a shared network a service provider network where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:58.000 --> 01:02.900 links but then going through a shared network a service provider network where 20 01:02.900 --> 01:03.840 they have lots of 21 01:03.840 --> 01:09.710 customers and connect out to all of these remote locations and so when we think 22 01:09.710 --> 01:10.640 about WANs 23 01:10.640 --> 01:16.340 especially traditionally and how we used to build them there have been a lot of 24 01:16.340 --> 01:18.080 downsides or maybe 25 01:18.080 --> 01:22.900 I should say just challenges with our Wide Area Network deployments. Again if 26 01:22.900 --> 01:24.560 we just have a few sites 27 01:24.560 --> 01:27.920 not that big of a deal but over the course of time we've seen that the more 28 01:27.920 --> 01:29.440 sites that we have the 29 01:29.440 --> 01:33.350 more challenging it can be. Now early on the challenge was I've got lots of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 01:29.440 --> 01:33.350 more challenging it can be. Now early on the challenge was I've got lots of 30 01:33.350 --> 01:35.040 point-to-point locations 31 01:35.040 --> 01:39.910 I have to manage this as a large routing domain and so maybe early on we had 32 01:39.910 --> 01:41.360 this point-to-point issue 33 01:41.360 --> 01:47.400 where I would get T1s and E1s these are point-to-point circuits T1 in some 34 01:47.400 --> 01:49.520 parts of the world E1 in other 35 01:49.520 --> 01:53.490 parts of the world and this again would just be point-to-point so if I have a 36 01:53.490 --> 01:54.560 router here and I have 37 01:54.560 --> 01:58.450 some kind of branch location over here branch one well that's well and good 38 01:58.450 --> 01:59.600 other than I'm going to 39 01:59.600 --> 02:05.010 have to have another one over here to branch two and we might still have a lot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 01:59.600 --> 02:05.010 have to have another one over here to branch two and we might still have a lot 40 02:05.010 --> 02:05.920 of these out in 41 02:05.920 --> 02:10.980 the network today for sure but at the same time we've gotten away largely from 42 02:10.980 --> 02:12.800 point-to-point it was 43 02:12.800 --> 02:17.440 a logistical nightmare to manage so many different point-to-point links manage 44 02:17.440 --> 02:19.440 my subnet usage manage 45 02:19.440 --> 02:24.100 the routing relationships and especially we usually have to worry about rout 46 02:24.100 --> 02:25.360 summarization and all 47 02:25.360 --> 02:30.780 of these things well these days we do tend to use a little bit more of a multip WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 47 02:25.360 --> 02:30.780 of these things well these days we do tend to use a little bit more of a multip 48 02:30.780 --> 02:32.000 oint topology 49 02:35.280 --> 02:41.990 so for example I might connect to an MPLS service provider and so I've got my 50 02:41.990 --> 02:43.040 headquarters location 51 02:43.040 --> 02:47.230 here I've got my two routers that would be part of that WAN block and then they 52 02:47.230 --> 02:48.640 're going to connect in 53 02:48.640 --> 02:55.070 maybe redundantly into this MPLS domain and then I can bring all of my branches 54 02:55.070 --> 02:57.040 into the MPLS cloud 55 02:58.640 --> 03:04.640 so rather than this being and requiring individual circuits from this router to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 02:58.640 --> 03:04.640 so rather than this being and requiring individual circuits from this router to 56 03:04.640 --> 03:05.520 this router and this 57 03:05.520 --> 03:09.420 router and this router and maybe even have to do it redundantly rather than 58 03:09.420 --> 03:10.720 doing that every router 59 03:10.720 --> 03:17.040 just has a single connection into a multipoint cloud this also allows me to 60 03:17.040 --> 03:19.280 perform site-to-site 61 03:19.280 --> 03:24.520 routing I can send traffic into the MPLS cloud and just have it come out rather 62 03:24.520 --> 03:25.280 than having to go 63 03:25.280 --> 03:31.240 through some kind of head end we're also going to see this from a DMVPN WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 63 03:25.280 --> 03:31.240 through some kind of head end we're also going to see this from a DMVPN 64 03:31.240 --> 03:33.440 perspective if I have an 65 03:33.440 --> 03:38.260 internet circuit well I might again have devices all connecting in all my 66 03:38.260 --> 03:39.680 branch offices to the 67 03:39.680 --> 03:44.300 internet but the internet is very insecure we wouldn't want to send business 68 03:44.300 --> 03:45.440 traffic directly 69 03:45.440 --> 03:53.920 over the internet instead I can build DMVPN which is dynamic multipoint VPN or 70 03:53.920 --> 03:54.480 some other 71 03:54.480 --> 03:59.000 multipoint VPN type of service something that's going to encrypt my traffic so 72 03:59.000 --> 03:59.920 this is still the 73 03:59.920 --> 04:04.220 internet but now I'm encrypting my traffic and sending it out I'll still have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 03:59.920 --> 04:04.220 internet but now I'm encrypting my traffic and sending it out I'll still have 74 04:04.220 --> 04:05.600 my head end locations 75 04:05.600 --> 04:12.580 down here but now I still maintain pretty much the exact same topology I can 76 04:12.580 --> 04:13.600 route and send 77 04:13.600 --> 04:17.810 traffic directly from one site to another without having to go through the head 78 04:17.810 --> 04:18.880 end I can manage my 79 04:18.880 --> 04:24.890 routing space a whole lot simpler in this regard and so the multipoint 80 04:24.890 --> 04:26.720 revolution I don't know maybe 81 04:26.720 --> 04:31.300 that's a strong word for it but using multipoint topologies in our wide area WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 04:26.720 --> 04:31.300 that's a strong word for it but using multipoint topologies in our wide area 82 04:31.300 --> 04:33.760 network is actually very 83 04:33.760 --> 04:38.050 useful and very helpful for us which is why we see so many of our wide area 84 04:38.050 --> 04:39.760 networks being built 85 04:39.760 --> 04:45.440 around this set of principles and especially leveraging MPLS and a multipoint 86 04:45.440 --> 04:46.560 VPN service across 87 04:46.560 --> 04:50.490 the internet so when we're looking at these services it is important to 88 04:50.490 --> 04:52.000 recognize that we have 89 04:52.000 --> 04:59.600 two very common technologies and I'll say tunnels I'll just say internet here 90 04:59.600 --> 05:00.400 so it's tunnels WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:59.600 --> 05:00.400 so it's tunnels 91 05:00.400 --> 05:04.330 over the internet what's the difference here why would we use one over the 92 05:04.330 --> 05:05.920 other or for that 93 05:05.920 --> 05:09.960 matter why might we use both of them and so when we're talking about MPLS we 94 05:09.960 --> 05:11.520 are talking about 95 05:11.520 --> 05:17.050 what's unfortunately usually a high cost we're talking about potentially 96 05:17.050 --> 05:18.560 hundreds and maybe even 97 05:18.560 --> 05:22.470 in some parts of the world potentially thousands of dollars a month on a per- 98 05:22.470 --> 05:23.440 site basis for these 99 05:23.440 --> 05:28.650 MPLS circuits very expensive in some parts of the world so high cost usually 100 05:28.650 --> 05:30.960 low bandwidth which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 05:28.650 --> 05:30.960 low bandwidth which is 101 05:30.960 --> 05:35.620 kind of interesting we were paying all this money and yet the bandwidth could 102 05:35.620 --> 05:37.360 be 10 megabits per 103 05:37.360 --> 05:43.160 second out to a remote location versus the internet being low cost internet 104 05:43.160 --> 05:44.640 circuits are relatively 105 05:44.640 --> 05:48.940 cheap maybe dozens or maybe a few hundred dollars a month and very high 106 05:48.940 --> 05:50.800 bandwidth internet is 107 05:50.800 --> 05:54.850 pretty easy to get a hundred or 200 megabits per second again depending on 108 05:54.850 --> 05:56.000 where in the world you 109 05:56.000 --> 06:01.150 you live now at this point the internet has MPLS completely beat it's better in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 05:56.000 --> 06:01.150 you live now at this point the internet has MPLS completely beat it's better in 110 06:01.150 --> 06:02.160 every way but there 111 06:02.160 --> 06:08.880 is one key difference and one reason why MPLS is used so heavily it is highly 112 06:08.880 --> 06:12.800 reliable and consistent 113 06:12.800 --> 06:21.700 whereas the internet this is very not reliable it's highly unreliable not just 114 06:21.700 --> 06:23.040 from the perspective 115 06:23.040 --> 06:26.860 that a lot of our internet service providers lack redundancy and so I might 116 06:26.860 --> 06:28.240 actually lose my internet 117 06:28.240 --> 06:32.540 connection more easily than an MPLS circuit which is built on very highly WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 117 06:28.240 --> 06:32.540 connection more easily than an MPLS circuit which is built on very highly 118 06:32.540 --> 06:34.400 redundant architectures but 119 06:34.400 --> 06:40.760 also just the fact that it's a lot of competition and contention one day the 120 06:40.760 --> 06:42.960 internet might be working fine 121 06:42.960 --> 06:47.890 and the next day it's not working so well or a lot of a lot of us experiences 122 06:47.890 --> 06:48.640 the internet's 123 06:48.640 --> 06:52.790 working great until I don't know about 3 pm in the afternoon and then all of 124 06:52.790 --> 06:54.080 the kids come home from 125 06:54.080 --> 06:58.990 school and they're jumping on and watching all of their high bandwidth YouTube 126 06:58.990 --> 07:00.960 videos and everybody WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 126 06:58.990 --> 07:00.960 videos and everybody 127 07:00.960 --> 07:04.920 in the neighborhood suffers business internet probably not going to suffer as 128 07:04.920 --> 07:06.160 much from that but we 129 07:06.160 --> 07:12.920 certainly are going to see spikes in activity more so than what we'd see on the 130 07:12.920 --> 07:14.320 MPLS side and so we 131 07:14.320 --> 07:19.750 really love for example throwing voice over IP onto MPLS circuits whereas bulk 132 07:19.750 --> 07:21.040 traffic that's not 133 07:21.040 --> 07:25.770 as time sensitive could go on to the internet but this is where we start to 134 07:25.770 --> 07:28.320 talk about our complexity 135 07:28.320 --> 07:32.710 because the reality is that if I said okay well are we going to use MPLS or the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 135 07:28.320 --> 07:32.710 because the reality is that if I said okay well are we going to use MPLS or the 136 07:32.710 --> 07:34.880 internet more often 137 07:34.880 --> 07:41.180 than not we're going to say hey why not both and both starts open up a little 138 07:41.180 --> 07:42.800 bit of an interesting 139 07:42.800 --> 07:47.800 world because when we look at these topologies down here I drew them side by 140 07:47.800 --> 07:49.200 side as if we had to 141 07:49.200 --> 07:56.270 choose one or the other but again we might say let's do MPLS and some kind of 142 07:56.270 --> 07:57.520 VPN circuit over the 143 07:57.520 --> 08:03.770 internet here's what this ends up looking like we have a single WAN block now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 143 07:57.520 --> 08:03.770 internet here's what this ends up looking like we have a single WAN block now 144 08:03.770 --> 08:05.520 at our headquarters 145 08:05.520 --> 08:13.120 location we have two clouds we have an MPLS cloud we have an internet cloud 146 08:13.120 --> 08:15.360 that we're going to 147 08:15.360 --> 08:20.100 assume has some kind of dynamic multi-point environment and so we're going to 148 08:20.100 --> 08:21.120 have redundant 149 08:21.120 --> 08:26.880 connections ideally to each one of these clouds and now when I have a site come 150 08:26.880 --> 08:27.760 online I'm going to 151 08:27.760 --> 08:33.390 want that site to have a leg in both circuits this is going to provide redund WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 151 08:27.760 --> 08:33.390 want that site to have a leg in both circuits this is going to provide redund 152 08:33.390 --> 08:36.160 ancy in case one of 153 08:36.160 --> 08:40.850 these circuits has an issue so maybe the internet is unreliable that day and it 154 08:40.850 --> 08:42.080 goes down well good 155 08:42.080 --> 08:47.170 news we have a path through MPLS and vice versa in case the MPLS circuit goes 156 08:47.170 --> 08:49.680 down now first glance this 157 08:49.680 --> 08:54.450 doesn't seem all that bad but we do have to consider a few things especially as 158 08:54.450 --> 08:55.840 it relates to our 159 08:55.840 --> 09:02.300 routing routing complexity starts to take off here we have a lot that we have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 159 08:55.840 --> 09:02.300 routing routing complexity starts to take off here we have a lot that we have 160 09:02.300 --> 09:03.360 to worry about 161 09:03.360 --> 09:09.020 as far as just making sure first of all that we have a converged layer three 162 09:09.020 --> 09:11.040 space second of all 163 09:11.040 --> 09:15.610 that we don't create routing loops need to make sure that if we're running 164 09:15.610 --> 09:17.280 multiple routing protocols 165 09:17.280 --> 09:21.610 which is typically how we might end up doing this we might have multiple 166 09:21.610 --> 09:23.360 protocols in play here 167 09:23.360 --> 09:26.980 and there's a few reasons for that but if we're redistributing between routing 168 09:26.980 --> 09:27.920 protocols then we need 169 09:27.920 --> 09:33.430 to make sure there's no routing loops we also have to worry about sharing our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 169 09:27.920 --> 09:33.430 to make sure there's no routing loops we also have to worry about sharing our 170 09:33.430 --> 09:36.480 routes with the service 171 09:36.480 --> 09:44.170 provider the reason for this is it's how multi or MPLS works if I have a route 172 09:44.170 --> 09:48.560 here that's the 10.1.1.0/24 subnet 173 09:48.560 --> 09:55.540 I have to share that route with MPLS the service provider and I might be an EIG 174 09:55.540 --> 09:57.840 RP shop I'm running EIGRP 175 09:57.840 --> 10:05.480 everywhere here and I can do whatever routing protocol I want through DMVPN but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 09:57.840 --> 10:05.480 everywhere here and I can do whatever routing protocol I want through DMVPN but 176 10:05.480 --> 10:06.720 the service provider 177 10:06.720 --> 10:11.450 might say okay that's great and all except we're going to require you to use BG 178 10:11.450 --> 10:13.200 P or maybe OSPF 179 10:13.200 --> 10:18.080 in some situations to exchange these routes I have to share this route with a 180 10:18.080 --> 10:18.800 completely different 181 10:18.800 --> 10:23.650 routing protocol than what I'm currently using I'm using EIGRP internally but 182 10:23.650 --> 10:24.480 now I have to share 183 10:24.480 --> 10:28.800 routes via BGP so I have to export the routes or I have to really redistribute 184 10:28.800 --> 10:29.600 the routes into a 185 10:29.600 --> 10:33.260 different routing protocol here on the other side I have to bring it in and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 10:29.600 --> 10:33.260 different routing protocol here on the other side I have to bring it in and 186 10:33.260 --> 10:34.640 redistribute it back 187 10:34.640 --> 10:38.980 into EIGRP and again this is where I need to make sure that I'm avoiding 188 10:38.980 --> 10:41.360 routing loops this also 189 10:41.360 --> 10:46.410 gets confused or complicated because what happens not if I have an outage an 190 10:46.410 --> 10:48.000 outage is okay relatively 191 10:48.000 --> 10:55.730 simple MPLS goes down everybody rerouts through the DMVPN circuit and it's one 192 10:55.730 --> 10:56.800 of those situations 193 10:56.800 --> 10:59.860 kind of like what we talked about with first-hop redundancy protocols where an 194 10:59.860 --> 11:01.520 outage is pretty easy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 194 10:59.860 --> 11:01.520 outage is pretty easy 195 11:01.520 --> 11:08.100 to detect and migrate or to deal with that's great what about performance 196 11:08.100 --> 11:12.160 problems what about if I have 197 11:13.520 --> 11:17.940 my voice over IP going through MPLS and that service provider is having some 198 11:17.940 --> 11:19.680 kind of issue that day 199 11:19.680 --> 11:25.150 and we have major degradation on our voice over IP calls well it'd be one thing 200 11:25.150 --> 11:26.560 if MPLS just went down 201 11:26.560 --> 11:30.950 all of our routing would converge through the internet circuit but can we very WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 201 11:26.560 --> 11:30.950 all of our routing would converge through the internet circuit but can we very 202 11:30.950 --> 11:32.000 simply go out and 203 11:32.000 --> 11:36.800 say hey we're having performance problems today we want to swing voice over IP 204 11:36.800 --> 11:37.360 through the internet 205 11:37.360 --> 11:41.540 because even though that's unreliable it'd be better than what we have in the 206 11:41.540 --> 11:42.800 moment and then once 207 11:42.800 --> 11:48.400 the problems are done we swing it back to MPLS this type of migration for 208 11:48.400 --> 11:50.880 basically saying I want 209 11:50.880 --> 11:55.580 specific applications to run out of specific wide area network circuits is very 210 11:55.580 --> 11:56.560 very difficult 211 11:56.560 --> 12:01.280 usually we're talking about deploying some kind of source-based routing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 211 11:56.560 --> 12:01.280 usually we're talking about deploying some kind of source-based routing 212 12:01.280 --> 12:03.520 otherwise known as policy 213 12:03.520 --> 12:08.320 based routing so we have to say we're going to deploy PBR into our environment 214 12:08.320 --> 12:08.960 are we going to 215 12:09.680 --> 12:13.490 manage this on a regular basis are we really going to say that the bulk of our 216 12:13.490 --> 12:14.560 data goes across the 217 12:14.560 --> 12:19.040 internet circuit but only voice over IP goes out MPLS are we putting all of the 218 12:19.040 --> 12:20.240 applications across 219 12:20.240 --> 12:24.300 one circuit until it goes down then we swing over to the other circuit so as we 220 12:24.300 --> 12:26.480 can see here either 221 12:26.480 --> 12:31.080 we have to almost choose we either have to choose between additional complexity WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 221 12:26.480 --> 12:31.080 we have to almost choose we either have to choose between additional complexity 222 12:31.080 --> 12:32.240 or we have to 223 12:32.240 --> 12:39.320 deal with inefficiencies because I might make a more simple environment but the 224 12:39.320 --> 12:40.640 reality is that because 225 12:40.640 --> 12:45.610 it's simple and I'm just using one circuit always and as it goes down that I'm 226 12:45.610 --> 12:46.960 being very inefficient 227 12:46.960 --> 12:51.250 and I'm not fully leveraging all of the bandwidth and all of the connectivity 228 12:51.250 --> 12:52.320 that I actually have 229 12:52.320 --> 12:59.520 available so this is where we were up until SDWAN software defined when became 230 12:59.520 --> 13:01.360 a thing because we had WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 230 12:59.520 --> 13:01.360 a thing because we had 231 13:01.360 --> 13:06.290 optimized a lot by moving to this multi-point architecture but it left a lot to 232 13:06.290 --> 13:07.440 be desired 233 13:07.440 --> 13:11.880 and as we see here we're going to want a solution which is building towards SD 234 13:11.880 --> 13:12.160 WAN 235 13:12.160 --> 13:16.910 which is going to reduce all of these complexities and solve some other pain 236 13:16.910 --> 13:18.240 points that I have with 237 13:18.240 --> 13:23.290 wide area networks and try to give me the most control that I can possibly have 238 13:23.290 --> 13:24.240 over my wide area 239 13:24.240 --> 13:25.600 networks.