Wide area networks are a major part of our network. When we talk about our
network architecture
we'd said that there was a core block that would connect to a WAN block and
unlike a lot of the
other blocks the WAN block might consist of a couple of routers, sure in there
and those are going
to maybe full mesh connect back to our core but on the other side of that it's
going to potentially
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
feel like a big mess because the goal of our Wide Area Network is to connect us
to our remote
sites and we might have a small handful of remote sites or we could have
literally hundreds or
thousands of remote locations. We're going to usually rely on a service
provider or potentially
multiple service providers to connect us from our what we might consider to be
more of a local
area network probably a headquarters location we're talking about high
bandwidth, high reliable
links but then going through a shared network a service provider network where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
links but then going through a shared network a service provider network where
they have lots of
customers and connect out to all of these remote locations and so when we think
about WANs
especially traditionally and how we used to build them there have been a lot of
downsides or maybe
I should say just challenges with our Wide Area Network deployments. Again if
we just have a few sites
not that big of a deal but over the course of time we've seen that the more
sites that we have the
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
more challenging it can be. Now early on the challenge was I've got lots of
point-to-point locations
I have to manage this as a large routing domain and so maybe early on we had
this point-to-point issue
where I would get T1s and E1s these are point-to-point circuits T1 in some
parts of the world E1 in other
parts of the world and this again would just be point-to-point so if I have a
router here and I have
some kind of branch location over here branch one well that's well and good
other than I'm going to
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
have to have another one over here to branch two and we might still have a lot
of these out in
the network today for sure but at the same time we've gotten away largely from
point-to-point it was
a logistical nightmare to manage so many different point-to-point links manage
my subnet usage manage
the routing relationships and especially we usually have to worry about rout
summarization and all
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
of these things well these days we do tend to use a little bit more of a multip
oint topology
so for example I might connect to an MPLS service provider and so I've got my
headquarters location
here I've got my two routers that would be part of that WAN block and then they
're going to connect in
maybe redundantly into this MPLS domain and then I can bring all of my branches
into the MPLS cloud
so rather than this being and requiring individual circuits from this router to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so rather than this being and requiring individual circuits from this router to
this router and this
router and this router and maybe even have to do it redundantly rather than
doing that every router
just has a single connection into a multipoint cloud this also allows me to
perform site-to-site
routing I can send traffic into the MPLS cloud and just have it come out rather
than having to go
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
through some kind of head end we're also going to see this from a DMVPN
perspective if I have an
internet circuit well I might again have devices all connecting in all my
branch offices to the
internet but the internet is very insecure we wouldn't want to send business
traffic directly
over the internet instead I can build DMVPN which is dynamic multipoint VPN or
some other
multipoint VPN type of service something that's going to encrypt my traffic so
this is still the
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
internet but now I'm encrypting my traffic and sending it out I'll still have
my head end locations
down here but now I still maintain pretty much the exact same topology I can
route and send
traffic directly from one site to another without having to go through the head
end I can manage my
routing space a whole lot simpler in this regard and so the multipoint
revolution I don't know maybe
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
that's a strong word for it but using multipoint topologies in our wide area
network is actually very
useful and very helpful for us which is why we see so many of our wide area
networks being built
around this set of principles and especially leveraging MPLS and a multipoint
VPN service across
the internet so when we're looking at these services it is important to
recognize that we have
two very common technologies and I'll say tunnels I'll just say internet here
so it's tunnels WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so it's tunnels
over the internet what's the difference here why would we use one over the
other or for that
matter why might we use both of them and so when we're talking about MPLS we
are talking about
what's unfortunately usually a high cost we're talking about potentially
hundreds and maybe even
in some parts of the world potentially thousands of dollars a month on a per-
site basis for these
MPLS circuits very expensive in some parts of the world so high cost usually
low bandwidth which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
low bandwidth which is
kind of interesting we were paying all this money and yet the bandwidth could
be 10 megabits per
second out to a remote location versus the internet being low cost internet
circuits are relatively
cheap maybe dozens or maybe a few hundred dollars a month and very high
bandwidth internet is
pretty easy to get a hundred or 200 megabits per second again depending on
where in the world you
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
you live now at this point the internet has MPLS completely beat it's better in
every way but there
is one key difference and one reason why MPLS is used so heavily it is highly
reliable and consistent
whereas the internet this is very not reliable it's highly unreliable not just
from the perspective
that a lot of our internet service providers lack redundancy and so I might
actually lose my internet
connection more easily than an MPLS circuit which is built on very highly WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
connection more easily than an MPLS circuit which is built on very highly
redundant architectures but
also just the fact that it's a lot of competition and contention one day the
internet might be working fine
and the next day it's not working so well or a lot of a lot of us experiences
the internet's
working great until I don't know about 3 pm in the afternoon and then all of
the kids come home from
school and they're jumping on and watching all of their high bandwidth YouTube
videos and everybody WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
videos and everybody
in the neighborhood suffers business internet probably not going to suffer as
much from that but we
certainly are going to see spikes in activity more so than what we'd see on the
MPLS side and so we
really love for example throwing voice over IP onto MPLS circuits whereas bulk
traffic that's not
as time sensitive could go on to the internet but this is where we start to
talk about our complexity
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
because the reality is that if I said okay well are we going to use MPLS or the
internet more often
than not we're going to say hey why not both and both starts open up a little
bit of an interesting
world because when we look at these topologies down here I drew them side by
side as if we had to
choose one or the other but again we might say let's do MPLS and some kind of
VPN circuit over the
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
internet here's what this ends up looking like we have a single WAN block now
at our headquarters
location we have two clouds we have an MPLS cloud we have an internet cloud
that we're going to
assume has some kind of dynamic multi-point environment and so we're going to
have redundant
connections ideally to each one of these clouds and now when I have a site come
online I'm going to
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
want that site to have a leg in both circuits this is going to provide redund
ancy in case one of
these circuits has an issue so maybe the internet is unreliable that day and it
goes down well good
news we have a path through MPLS and vice versa in case the MPLS circuit goes
down now first glance this
doesn't seem all that bad but we do have to consider a few things especially as
it relates to our
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
routing routing complexity starts to take off here we have a lot that we have
to worry about
as far as just making sure first of all that we have a converged layer three
space second of all
that we don't create routing loops need to make sure that if we're running
multiple routing protocols
which is typically how we might end up doing this we might have multiple
protocols in play here
and there's a few reasons for that but if we're redistributing between routing
protocols then we need
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
to make sure there's no routing loops we also have to worry about sharing our
routes with the service
provider the reason for this is it's how multi or MPLS works if I have a route
here that's the 10.1.1.0/24 subnet
I have to share that route with MPLS the service provider and I might be an EIG
RP shop I'm running EIGRP
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
everywhere here and I can do whatever routing protocol I want through DMVPN but
the service provider
might say okay that's great and all except we're going to require you to use BG
P or maybe OSPF
in some situations to exchange these routes I have to share this route with a
completely different
routing protocol than what I'm currently using I'm using EIGRP internally but
now I have to share
routes via BGP so I have to export the routes or I have to really redistribute
the routes into a
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
different routing protocol here on the other side I have to bring it in and
redistribute it back
into EIGRP and again this is where I need to make sure that I'm avoiding
routing loops this also
gets confused or complicated because what happens not if I have an outage an
outage is okay relatively
simple MPLS goes down everybody rerouts through the DMVPN circuit and it's one
of those situations
kind of like what we talked about with first-hop redundancy protocols where an
outage is pretty easy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
outage is pretty easy
to detect and migrate or to deal with that's great what about performance
problems what about if I have
my voice over IP going through MPLS and that service provider is having some
kind of issue that day
and we have major degradation on our voice over IP calls well it'd be one thing
if MPLS just went down
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
all of our routing would converge through the internet circuit but can we very
simply go out and
say hey we're having performance problems today we want to swing voice over IP
through the internet
because even though that's unreliable it'd be better than what we have in the
moment and then once
the problems are done we swing it back to MPLS this type of migration for
basically saying I want
specific applications to run out of specific wide area network circuits is very
very difficult
usually we're talking about deploying some kind of source-based routing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
usually we're talking about deploying some kind of source-based routing
otherwise known as policy
based routing so we have to say we're going to deploy PBR into our environment
are we going to
manage this on a regular basis are we really going to say that the bulk of our
data goes across the
internet circuit but only voice over IP goes out MPLS are we putting all of the
applications across
one circuit until it goes down then we swing over to the other circuit so as we
can see here either
we have to almost choose we either have to choose between additional complexity WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we have to almost choose we either have to choose between additional complexity
or we have to
deal with inefficiencies because I might make a more simple environment but the
reality is that because
it's simple and I'm just using one circuit always and as it goes down that I'm
being very inefficient
and I'm not fully leveraging all of the bandwidth and all of the connectivity
that I actually have
available so this is where we were up until SDWAN software defined when became
a thing because we had WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a thing because we had
optimized a lot by moving to this multi-point architecture but it left a lot to
be desired
and as we see here we're going to want a solution which is building towards SD
WAN
which is going to reduce all of these complexities and solve some other pain
points that I have with
wide area networks and try to give me the most control that I can possibly have
over my wide area
networks.