In a lot of cases, we are going to be focused on things from an organizational
perspective,
meaning that I have a single network.
I may be responsible for the network for my one organization and I have to
connect my
many organizational sites to one another.
But things change when we think about this from a service provider perspective,
because
at this point I have a multi-tenancy environment, which is a really fancy way
of saying that
I have many networks, not just a single one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I have many networks, not just a single one.
This is kind of a big deal because I need to make sure that these many networks
stay
separated from one another.
If I don't keep them separated, there we go.
If I don't keep them separated, then the traffic will start to inter-mix.
And we definitely don't want that if we've got many customers, those customers
are expecting
to not see their traffic get crossed over into one another.
And so built in to Cisco SD-WAN is the concept of multi-tenancy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so built in to Cisco SD-WAN is the concept of multi-tenancy.
And the way we build a multi-tenant environment is with VPNs.
Now, I don't know about you, but when I think about VPNs, I think about remote
connectivity
into my organization's network, maybe a site to site, kind of VPN.
That's not really what we mean by SD-WAN VPNs.
Instead, an SD-WAN VPN really more parallels a virtual routing and forwarding WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Instead, an SD-WAN VPN really more parallels a virtual routing and forwarding
instance
or a VRF.
A VRF is sort of like taking a layer 3 device and carving it up into multiple
layer 3 domains.
And this is heavily used with multi-tenancy to allow me to have multiple
routing tables
and basically a routing table per customer.
So let's take a look at a topology here.
Let's say that, again, think about it, things from a service provider.
I have a WAN Edge device here and I have a WAN Edge device here and I build out WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I have a WAN Edge device here and I have a WAN Edge device here and I build out
my service
provider network.
Maybe this is an MPLS domain.
And I'm going to make sure that I build my IPsec tunnel from WAN Edge to WAN
Edge here.
So that's great.
However, now because I'm a service provider, I actually have a customer A
network here
and a customer A network hanging off of this other WAN Edge.
But then from there, I also have a customer B network hanging off as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But then from there, I also have a customer B network hanging off as well.
Now as we can imagine, I don't want my customer B to be able to send traffic in
and number
one, go locally to another organization.
And number two, be able to forward across this IPsec tunnel and also end up
going into
the other organization.
That's a security breach from both customers' perspectives and we need to
prevent this no
matter what.
So here's what we're going to do. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here's what we're going to do.
We are going to embrace the concept of VPNs and so I'm going to say customer A,
let's
say, is going to use VPN 10 and customer VB.
We'll use VPN 20.
So we're using two different VPNs at this point.
What we do is we place these interfaces into their respective VPNs.
And again, the more we parallel this back to VRFs, the more this is going to
track.
Because this is exactly what we do for VRF configuration as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because this is exactly what we do for VRF configuration as well.
Furthermore, as traffic gets put into the same tunnel and yes, they do share
the tunnel,
they are going to be distinguished within the tunnel with the VPN identifiers.
In other words, we don't want to allow the router on the other side to receive
traffic and
say, hey, this packet just arrived is this part of a VPN?
Is it on VPN 10?
Is it on VPN 20?
We're going to know that because the traffic carries the VPN ID. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to know that because the traffic carries the VPN ID.
So it's no longer a question.
I know that this belongs to VPN 10.
And so I'm not even going to consider the routing table of customer B here
because that
would be part of VPN 20.
Now again, I do want to be clear that VPNs are very much a service provider
technology.
It's not something we're going to interact with a lot if I'm deploying SD WAN
myself.
So a lot of service providers I can go to and I can say, hey, I would like for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So a lot of service providers I can go to and I can say, hey, I would like for
you to manage
my VPN or my VPN, my SD WAN environment.
And maybe they even offer an SD WAN solution and their SD WAN solution is built
on Cisco SD
WAN.
And they're using VPNs because all of their customers are sharing all of their
WAN edge tunnels
because they deploy these routers, these WAN edges out to places that can then
connect
to multiple organizations.
So it makes sense from a service provider from a single organization
perspective, do we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
perspective, do we
still need to know this?
The answer is yes.
First of all, we need to understand the architecture because we're going to see
VPN configuration
when we're deploying SD WAN.
So we do need to choose a VPN to represent our organization even if we're only
going to
use a single one.
But there are also a few exceptions around VPNs that we need to be aware of,
especially as
it relates to the organization of VPN IDs.
So the full VPN range, interestingly, I say interestingly because it's actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the full VPN range, interestingly, I say interestingly because it's actually
kind
of interesting how this all comes together, but it ranges from zero to 65, 530.
Think comes next.
Usually we say 65, 535 because that's a full 16 bit number.
But SD WAN ends with 65, 530.
Don't ask me why.
It was maybe they just wanted a few at the end for the sake of reserving some
VPN IDs.
But the reason that that's interesting is because they actually do reserve a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But the reason that that's interesting is because they actually do reserve a
couple of other
IDs.
Specifically VPN zero, this is used for the underlay or maybe we should say the
WAN circuits.
So when we're looking at a router and we just said that we've got an interface
here in
this interface on the service side, this is going to be a VPN of let's say 10.
Well now I've got an IP address here on a circuit that goes to my MPLS provider WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well now I've got an IP address here on a circuit that goes to my MPLS provider
.
Well this interface is going to be in VPN zero because it's part of the under
lay.
And so I can't change that.
Furthermore, VPN 512 is also reserved.
And this is reserved for out of band management.
In other words, communications with our control plane and other devices.
So our V-bonds and our V-Smarts and everything out there is going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So our V-bonds and our V-Smarts and everything out there is going to
communicate using VPN 512.
And so this creates a rather interesting range of eligible VPN IDs.
Because if we think about it, we can't use zero.
So I'm going to start at one.
And I can't use 512 either.
And so I'm going to have to sort of comment here and say I can use 513 all the
way up to 65530.
Now why did this come about?
Well there's a little bit of history behind this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well there's a little bit of history behind this.
And long story short, the VPN range used to be historically zero to 512.
And so Cisco and Viptela at the time reserved the first and last VPN ID from
the range.
And so that was well and good other than it was always a 16 bit value.
And so we thought, well, why would we not use the full range, especially for
service providers,
that have more than 500 or so customers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that have more than 500 or so customers.
And so instead we extended we being Cisco extended the range out to the what
they consider
to be the max nearly the full 16 bit range.
But because of the way the architecture had been built, 0 and 512 had already
been reserved.
So that is why 0 and 512 of all VPN IDs are not eligible to be used.
So if you work for a single organization and you're just your own tenant, you WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if you work for a single organization and you're just your own tenant, you
can pick any
of these VPN IDs to use in your environment.
But if you're a service provider, you're going to find that you're going to be
using many
of these VPN IDs, each one representing one of your customers.
[BLANK_AUDIO]