All right, let's have some fun here.
Let's go ahead and test our network connectivity
and make sure everything is in good shape
before we move on to more advanced configurations,
especially as it relates to our T-locks
and our T-lock extensions.
So at this point, we have a local area network in place,
ready to go 10.10.13.0/24.
First and foremost, I wanna make sure
that I can reach out to host on the other side of the network.
So I'm going to ping, for example, 10.10,
10 being VPN 10, and then let's say site 11.50
would be the Ubuntu host over there, and I can reach it.
And the reason I can reach it is because SD-WAN and OMP,
they're automatically advertising any attached route
into the network.
And because our route to extinguisher
and route targets are in place,
those routes went to the other side.
We can verify that here momentarily.
Let's just make sure that site 12 is reachable as well,
and indeed it is.
All right, so let's go ahead and take a look
at some routing tables here.
We'll start here with edge 13, we have to log back in.
And remember, if I do a show IP route,
we're not going to see that we've got a local route here
for 10.10.13.
We don't see that at all.
Instead, I'm going to see the locally attached routes,
as well as the static default route that we have
that points out towards the internet.
That's because this is the default VRF.
If I want to see the routes for a different VRF,
then I need to do a show IP route and specify the VRF,
VRF of 10.
And so remember, when we see an M here,
this little M means that it's something we learned via OMP.
So on edge 13 here, I see that I've learned about
site 11s subnet and site 12s subnet.
So that's great.
It also gives me the next top, but notice it's not the next top
from a network perspective.
It's the router ID that shows up in the routing table.
And then we use OMP mappings in order to figure out
how to get there.
So we're learning it from SD WAN.
So that's pretty cool that that shows up
in the routing table just as it is.
So let's go ahead and take a look at things
from another site's perspective.
Let's log into edge 11 one more time
and do a show IP route for that VRF 10.
And we do see that I am learning about 10.10.13.
Notice from two different routers here, edges 13 and 14
are both advertising this.
This is an interesting concept because if we think about it,
going outbound devices are probably going to be using--
by default, they're going to be using edge 13
because that's the default gateway.
So edge 13 is going to receive the traffic outbound
and send it out.
But return traffic might be a little bit asynchronous,
depending on how we do this advertisement.
Because edge 11 here that we're logged into,
it sees both of them as equal cost routes.
And so we might send the return traffic back to edge 14
and then it lands on our host.
So we're looking at the diagram up there.
It might go out edge 13 and then come in via edge 14.
Just something we have to think about when it comes
to routing rules.
We always have to consider what devices
see from a routing table perspective, both inbound and outbound.
So let's go ahead and check that VRRP redundancy.
We've said that VRRP is making it so that this dot 13 should
be picked up by dot 14 in the event of a failure.
So let's create a little bit of a failure here.
So I've got edge 13.
I'm going to come over to my Ubuntu host.
And we're going to do another ping.
In fact, let's just do the same ping to 10.10.12.50
because this is Linux.
It's just going to go forever.
And now we're going to come over to edge 13.
And we want to reload the system.
So I'm simply going to type reload and confirm
that I want to reload and down it goes.
So let's go take a look at our Ubuntu host here.
We see that-- oh, interesting.
We did lose a sequence number in there.
It looks like sequence number 35 didn't actually succeed
because basically we lost a ping.
But after that, it kept going.
So go check edge 13.
Edge 13 is definitely reloading, which means that edge 14--
look at this error message, or log message, I suppose.
Gigabit ethernet 3 is in the state,
a transition from-- it's over here--
back up to master, which means that if I do a show VRRP,
then we see that the state is in the master for Gigabit
ethernet 3.
So at this point, we have everything working how we wanted.
I have a subnet here at site 13.
Everybody else can see where the subnet lives.
I can see where those subnets live.
We can ping from host to host it among any of these sites
now, which is fantastic.
Furthermore, if edge 13 were to go down,
edge 14 picks up as the default gateway
and is able to move our traffic through the network.
But think about it from a WAN circuit perspective.
What happens if edge 13 loses its upstream connection?
And edge 13 continues to be the default gateway.
But now it's coming back online.
There we go.
We see edge 14 has now transitioned back to the backup state.
What happens if edge 13 loses its SD WAN connection?
What is going to happen?
Now, let's take a look at that.
So let's go ahead and get onto edge 13 here.
Boy, we've got a lot of messages.
Let's just get logged in.
Hopefully the messages start to clear out.
All right, very good.
So we know we already saw that edge 13 has come back online
and taken over as master because edge 14 became the backup.
That's great.
What happens if this upstream connection goes down?
So do a show IPInt Brief.
And we see that gig ethernet 1 is our connection
to the fake internet that we have.
Just keep getting more and more log messages.
I tell you what.
All right, so everything is trying to still establish here,
which is fine.
We want to make sure everything is well established
before we start doing additional tests.
So let's check in on our Ubuntu host here.
So we did see quite a few--
actually, we saw quite a bit of an outage
as edge 13 came back online because OMP hadn't finished
its information yet.
So we were using edge 13, but edge 13
didn't have any upstream connections.
But now we know that.
I think we probably already understand
what's going to happen here.
If I do a config dash t and I get onto my interface
for a gigabit ethernet 1 and I do a shutdown,
I am now losing my WAN connection.
So I'm going to say commit.
And now I have lost connection to my upstream SD WAN environment
and notice what happened with my Ubuntu host.
So if we have this wonderful redundant configuration,
why did we go down?
Well, what happened there?
Well, what happened was edge 13 is still online.
So VRRP says to still go to edge 13,
but it can't do anything about it.
So when we look at it from a--
where is my cursor?
There it is.
All right.
So host 10-- yeah, host 10-13 is using edge 13
as its default gateway.
If edge 13 goes down, it starts using edge 14.
And edge 14 can pass things upstream, which is great.
But what happens if edge 13 stays online but actually just
loses its upstream connection?
Well, now host 10-13 continues to use edge 13.
And edge 13 can't do anything with it.
And so the traffic's getting dropped.
So we have two options here.
We can use VRRP tracking to say, OK, well, we should go ahead
and basically turn down edge 13 as our VRRP master
and make edge 14 the VRRP master.
And that's something we could explore,
but we'd have to tune VRRP to make it work.
Or-- and this is going to be a better solution
within the greater conversation of SD-WAN and load
balancing and such--
what if I was able to form an SD-WAN tunnel through edge 14?
So this is now an IPsec tunnel that
allows me to take advantage of the MPLS cloud.
Because edge 13 only has the internet.
It doesn't have MPLS.
Well, this is exactly what we're going to start to explore.
I want to understand that this is a problem that
must be resolved.
If we don't resolve this problem,
yeah, we could maybe work around the connectivity issue.
But overall, our SD-WAN environment
is not going to be very efficient.
So we need to make sure that we can form a connection
across-- or via through--
going from edge 13 to edge 14 out to the MPLS cloud,
basically we want edge 13 to have a connection to the MPLS,
even though it doesn't have a physical connection to the MPLS.
So that's what we're going to be exploring moving forward.
Now it's a matter of making sure that our lab environments are
all caught up, configured for this, and ready to move forward.
And by the way, before we forget, we're going to come in here
and bring this--
let's see here.
We're going to do a no shutdown on this link and commit it
and make sure that our Ubuntu host comes back online
and is able to ping out to the rest of the network.