Alright, so in order to verify what's happening here, we want to make sure that
our hosts
can ping one another, but again, we have to keep in mind that a VPN is a very
hard dividing
line.
So when we want to ping, we can't be pinging between hosts 10-11 and 20-11
because they're
in two completely different VPNs or VRFs, and without it doing any kind of
leaking of
routes, which we usually don't want to do, then these two hosts would not be
able to
reach one another, nor should they be able to reach one another, but we built
this out
to securely establish that we don't want VPN 10 devices and 20 devices
interacting.
That especially applies for a service provider, and we are deploying for
multiple customers.
Now what if we're not a service provider?
Would we still use VPNs?
Probably not, however, a lot of larger organizations occasionally will have
isolated networks.
Maybe that's to keep the network secure, maybe it's intended to be an off-the-
internet type
of network or something along those lines.
It could be medical, like sensitive information.
Those kinds of situations do exist at which point we'd want to use a different
VPN, but
just keep in mind, as soon as we create a new VPN, it's not just creating a new
network
environment.
That would be like a VLAN or a new subnet, but we're truly creating a brand new
layer
three environment.
So, what we're going to do here instead of trying to communicate between hosts
at the same site,
is we're going to try to leverage our SD-WAN.
Remember, our SD-WAN is in here, and it's working hard.
It's got all these IPsec tunnels.
Everything is in place to allow data plane communication, but the question is,
is our
control plane working?
What about the sharing of routes?
Because remember, even though these two links are both in VPN 10, they are two
different
subnets.
So, we've got 10.10.11 here, so VPN 10 site 11, and then we've got .50, so this
is the
IP address for this host.
And then this host down here is 10.10.12.50, and they're both /24s.
So that means that these are on two completely different subnets, and if they
're on two
different subnets, that should mean that there's going to need require some
routing,
or something along those lines.
So, the question is, should we expect this ping to work?
Should I be able to ping from host 10-11 to host 10-12?
And for that matter, should I be able to ping from host 20-11 to 20-12, because
those would
be also to hosts that are at different locations and different subnets, but
within the same
VPN?
Well, we've had a lot of setup time.
Let's actually go take a look at the terminal and see what happens.
So let's go ahead and jump onto the terminal for our first host.
We're up here.
We've got the diagram right up above.
So again, 10-11, right here, host 10-11, and we're pinging over to 10-12.
So I'm going to say ping 10.10.12, and they all end in .50, so that should be
hopefully
easy to remember.
And look at that.
We're getting pings.
So we set this up as saying, well, at least I was kind of leading us on a
little bit there
to say, hey, is it going to work?
And the answer in the end is, yeah, yep, it's working.
We can check VPN 20 as well.
So host 10-12.
I'm going to ping to the host in VPN 20, so that'd be 10.20.
Which one are we pinging to from 2011?
Oh, yeah.
We've got this host name, I think, is wrong.
Or maybe I just logged into the wrong one.
Oh, I did.
Oh, we're on this one right now.
So never mind.
This is why the host names matter.
All right, so let's go ahead and log into these other ones.
So that would be 9,003 in 9,004.
Oh, that didn't work.
9,007.
All right, there we go.
20-11.
That looks a little bit better.
All right, so now we're on 20-11.
Let's go ahead and ping 10.20.12, not 12, but .50.
All right, and yes, we can ping.
All right, so a little bit of confusion on my end, as far as which host is
which.
And by the way, remember Ubuntu machines or Linux machines in general, they don
't stop
pinging, so you got to hit Control C. But yeah, we see that the pings are
working.
So what's going on?
Why are the pings actually functioning?
Well there's a really good reason for this.
And let's go back to the diagram here just to confirm that we know what's going
on.
So as we said, we are pinging from one subnet to a completely different subnet.
And normally that requires routing.
Now if it's one device and they're both hanging off of the same router, then it
would technically
be routing, but it would actually see that connection as a different routing
table entry
point.
And so when we have multiple routers involved, well that's great and all except
now they
have no idea what's attached to the other side, so they need to communicate in
theory.
And we know in SD-WAN they aren't directly communicating now that the control
plane.
So where are they getting these routes and how?
Well remember our good friend overlay management protocol or OMP.
This is that routing protocol that's sort of like BGP in a lot of ways.
And it's running up here on those v smarts or really what we refer to as the
controllers
and the modern Cisco use case.
So that v smart is up there.
We'll just call it v smart for now.
The v smart is up there processing routes.
So when edge 11 sees this subnet 10 dot 10 dot 11 dot zero slash 24 as the sub
net is
known, it advertises this to the v smart via OMP.
Well guess what edge 12 is going to do?
It's going to do the same thing.
It's advertising its subnet up to v smart via OMP.
And technically they're each advertising two subnets.
The v smart is VRF or VPN aware.
It knows that we're sharing a route for VPN 10 and a route for VPN 20 from both
edges.
So what's the v smart going to do at that point?
Well it turns around and actually advertises back down to the other side the
routes that
we learned.
So we kind of crisscross here and the routes that get advertised to v smart one
way get
advertised down to the other locations.
So this is why we're able to ping.
But it does raise an interesting question.
If we in theory have received routes on these edge devices, we've received them
from OMP.
Shouldn't there be an entry in the routing table?
All right.
Well in theory as long as all this is holding true, then we should expect to
see routes
in the routing table.
Let's go ahead and go see if that's the case.
So now we want to look at edge 11 and edge 12 and see what their routing tables
look
like.
Now we believe that we've got somewhere around here.
There it is edge 11.
It's going long back in.
And now I can do a show IP route.
Now this looks kind of interesting.
I do a show IP route.
I see connected and local routes which is basically just the connected subnet
as well
as the /32 that belongs to my interface is the local.
But I'm not seeing any advertised routes.
Why would that be?
Well we got to put our Cisco routing hats on now and think about the fact that
this
is going to give me the routing table for the default VRF.
Not for VRF 10 and not for VRF 20.
So let's do a show IP route with VRF 10 as the tag.
Now we get a different looking routing table.
How about that?
We're not just seeing both interfaces as the only things that are there.
Instead we're actually seeing just one interface and one subnet.
10.10.11.11 is the only interface edge 11 has in VPN 10.
And for that matter it's the only subnet that's attached as well.
So that would be the subnet that it's going to advertise to vSmart.
And then lo and behold we have a subnet that was advertised via this little m.
What's the little m?
I'll look right up here and it is our friend omp.
So just as we were hoping to see and expecting to see the fact that I can ping
from one host
at one site to a host in the same VRF or same VPN in the other site means that
we are exchanging
routes.
But we never configured anything.
We never configured it to work that way.
So VPN 10 is getting routes.
VPN 20 is getting routes.
We've got the route from the other side.
And if we were to look at edge 12 we would see the same thing.
So why are they getting routes?
So there's VPN 10 and there's VPN 20.
So we do see an omp route on all four of our routing tables.
Edge 11 is two routing tables and edge 12's routing tables.
Again why are we seeing routes?
Which means looking at edge 12 VPN 20 that'd be gig four here it actually says
that gig
four.
This connected subnet is going to get automatically advertised into omp.
Not all subnets and not all routing protocols are going to get natively
transported into
omp.
But Cisco does us the favor of saying hey if you've got a connected route you
probably
want to advertise that to the rest of the SD-WAN environment.
Now maybe we do and maybe we don't.
We'll get into the details of routing later on.
But for right now we understand that this is all working.
We do have our edge VPNs working between sites 11 and 12.
Haven't done site 13 yet.
But between sites 11 and 12 everything is working because omp has done us that
immense
favor of advertising the connected routes.
So that is why everything is working and everything came up in our ability to
ping from
one side to the other.
And so now it's just a matter of extending our build out here not only into
your own lab
but then in the next skill we'll want to take a look at that last remaining
site where
we have two routers connecting into the environment.
[BLANK_AUDIO]