SD-WAN is going to use the concept of the Virtual Private Network or VPN.
However, if you're first learning about SD-WAN right now, you're probably
already thinking
about those IP Sectonals and the fact that, oh, maybe we're forming these
Virtual Private
Networks using the IP Sectonals like I do with, in between my computer and my
work,
when I go to a cafe and I log in over VPN.
Except it's not really that type of VPN.
In the SD-WAN world, specifically this solution, a VPN is very similar to the
concept of a VRF.
In fact, I would argue we should just call them VRFs.
So I'm not sure why we continue to call them VPNs other than the fact that it's
just how
the solution is going to call it that and we're all used to it by now.
But we really do need to think about them as VRFs, which are Layer 3 segment
ations.
So VRFs typically have the qualities of forming multiple routing tables.
They allow for multi-tenancy by segmenting among them and we have to place
Layer 3 interfaces
into a specific VRF.
Well, guess what?
All of that's going to apply to the VPN as well.
So specifically, we're going to use it for ideally three use cases here.
First of all, it's to segment the overlay and the underlay.
If we're actually configuring just outside of the SD-WAN world, an overlay
network, and
an underlay all in the same environment, maybe I want to configure some VX land
tunnels in
my data center, then it makes a whole lot of sense to place the overlay
connections,
the tunnel interfaces into one VRF, and the underlay connections or the
physical interfaces
into a different VRF.
It allows me to make sure that I am segmenting those two Layer 3 domains since
in theory they're
supposed to be completely disparate from one another.
Well, we're going to do the same thing with SD-WAN.
We're going to place our overlay networks into certain VPNs.
So we're going to have maybe what we might call a user space set of VPNs here,
whatever
VPNs we want to use, and the underlay is going to go into VPN zero.
Now again, be thinking along the lines of these being VRFs, but we're going to
assign
an ID a number to them rather than a name like we typically do on Cisco devices
when
we're configuring VRFs.
The second thing we're going to allow for is multi-tenancy.
Down many enterprise and corporate organizations aren't going to probably be
using multi-tenancy
a whole lot.
Maybe we'll have some kind of departmental breakdown that we might be
interested in
using for, but I will say this, most of the multi-tenancy is going to be used
by service
providers.
This is really important because even though we're studying this as part of the
enterprise
networking side of the Cisco world, Cisco participates very heavily in the
service provider space
and SD-WAN is a technology deployed by a lot of service providers as a service
to their
customers.
And so what by doing so, they would deploy the edge routers, they would build
out all
of the tunnels, and they would assign each customer a separate VPN.
So this feature is very important for service providers who want to deploy SD-W
AN solutions
for their customers.
Again, from a corporate enterprise perspective, if you work for one company and
you either
have an SD-WAN environment or you're considering it, you probably aren't going
to be worried
too much about multi-tenancy unless you have a very specific use case.
Now the last option, which we use even in non-SD-WAN environments is to break
out and
segment out our management network.
And that's exactly what we're going to do here in the SD-WAN space.
We are going to place the management network into VPN 512.
So we have two reserved VPN IDs, zero and 512, and we'll go over the range of
VPNs here
in a little bit.
But these are the three primary use cases for VPNs.
Again, if you don't work for a service provider, it's primarily going to be
figuring out what
VPN will use for our overlay network, making sure we are properly configuring
our underlay
network for VPN zero, and then likely using the management VPN for out of band
access
into our, especially our controller space.
So let's make this a little bit more visual.
I've got, let's say, an edge device here.
And I've got another edge device down here.
And maybe these are connecting in through a couple of different service
providers.
We have an MPLS service provider and we just have a backup internet circuit.
And so we have our connections here, which are physical connections.
Maybe it's an ethernet connection.
Maybe it's a serial connection, but either way, what we're going to find here
is that
these interfaces are going to belong to VPN zero.
So VPN zero again forms the underlay.
And that's very important for us to segment that out because that's a whole
layer three
world that we don't need to worry about sharing routes back and forth anymore
with MPLS.
We absolutely had to share routes back and forth.
We're not going to do that anymore because of that wonderful underlay versus
overlay
concept.
So these are now all part of VPN zero.
Meanwhile, I am likely going to connect in, let's say I choose VPN 10 for my
user space.
So VPN 10, this might look a little bit like a VLAN.
This is a layer three domain.
This is all of my VLANs because VRFs segment out layer three versus layer three
domains
rather than, you know, VLANs, which are doing it at the layer two level, very
similar concepts,
just at layer three versus layer two.
So I've got VLAN 10 up here.
I'm going to put my user space down here.
All right.
I said VLAN 10 VPN 10.
And then VPN 10 down here.
What this allows for me to do is to see my VPN information carried through the
network
via the IPsec tunnels.
So this is a very important concept as we start to make this diagram just ever
so slightly
more complicated.
What we're going to do is form our IPsec tunnels.
So this is IPsec.
And the IPsec tunnels are going to carry our VPN IDs via tags.
So when a packet arrives here, we know that, hey, this is VPN 10 information or
a packet,
a packet that belongs to VPN 10.
And we get forwarded into the layer three domain from there.
But what if these routers are not deployed by an end customer, maybe a
corporate or enterprise
network?
What if it is a service provider?
And at this point now, we decide to deploy a second customer off of this.
And so now we've got VPN 20 and VPN 20.
So do I need more IPsec tunnels?
And the answer is no, because these VPN IDs are part of a tagging system, I can
just send
my package through the IPsec tunnel properly tagged with a VPN ID.
So now same thing, I'm going to see that my VPN 20 traffic gets carried through
.
And then the packet is recognized as being part of VPN 20.
And it gets forwarded out a layer three interface that belongs to VPN 20.
So do notice that these interfaces must belong to their respective VPNs.
I'm not going to be in a way, trunking multiple VPNs downstream.
I have to physically separate them at that point.
Again, just like VRFs require on Cisco routers, where every interface must
belong to exactly
one VRF.
Now when I say every layer three interface must belong to a VRF or VPN, we're
talking
about layer three interfaces.
Those could be sub interfaces.
They could be SVIs.
They take a lot of different forms.
So it could be virtualized.
But every IP address, every layer three interface, virtual or otherwise, must
belong to a single
VRF and therefore VPN.
All right, so let's go ahead and talk about those VPN IDs.
So the range for VPN IDs, interestingly, when the solution first came out on
initialization,
only zero through 512 were allowed.
This is why zero is reserved for the underlay and 512 is reserved for the
management traffic.
Because of this, we were allowed to use five through 11 for our edge VPNs.
VPN.
Cool.
Except at some point, the solution expanded and we decided to allow five 13
through 65
30.
Be very careful.
65, 530, not 535.
We still have some reserved ones at the end.
65, 530.
So because of this, I'm sort of comma in there now, because of this, we can
also use 513
through 65, 530.
Also as edge VPNs.
So it creates a little bit of an odd range.
One to five 11, 513 and up to the max, but there's a reason for that and
helping to understand
the story of why is why I kind of explained it that way.
So again, VPN zero reserved VPN 512 reserved, all the other VPNs up to 65, 530
can be used
for our user space VPNs.