All right, let's go and dive into this topology challenge.
So we want to decide a few things here.
First and foremost, what VPN will these be in?
This is really not a trick question.
It's just a matter of understanding that if we're going to directly attach our
edges together
and we're wanting to deploy T-Lock extensions across them, that means that they
're part
of the underlay.
And the underlay is always part of VPN zero.
So those links will be part of VPN zero now in a C edge or really just a modern
SD-WAN
edge deployment, which is running iOS, then VPN zero is going to simply be part
of the
default VRF.
So we don't need to worry about VRF configuration with these links.
We just need to get them configured and ensure we have some IP reachability to
start with.
Second question is which subnets need to be advertised in some way?
So we really need, again, from a routing perspective to look at these tunnels
and think
about things from an inbound perspective and from an outbound perspective.
Anytime it comes to routing for T-Lock extensions, especially when we have sub
nets on the back
end now that aren't just immediately known by the edge devices like over here,
then we're
going to need to think about the routing and the implications of inbound versus
outbound.
So for example, does edge 100 know where these two subnets live?
By default, the answer is no.
We have to make sure they're part of a routing protocol process or that they
are statically
configured.
And so first number two here, we're going to have to make sure that 10.250.0.0/
30 is
advertising some way as well as the 10.200.0.0/30.
But that's not it, is it?
I mean, we did say that we can assume the edges can ping one another on their
similarly attached
when interfaces, which means that edge 200 should be able to ping this
interface.
And that means that edge 200 knows where this 57.3.4.5 address is.
That's cool.
And edge 250 can ping this address.
So it knows where 10.1.1.10 is.
But does edge 200 know where 10.1.1.10 is?
And does edge 250 know where this 57.3.4.5 lives?
Now the last one might actually be OK because if edge 250 has a default route
and it already
happens to be pointing out this interface, then we're good to go.
And maybe that's just part of our routing protocol configuration.
However, if our default route is pointing elsewhere, like we see in our own lab
environment,
when we look at the fact that one of our edge devices has an internet
connection and we
don't want to use the internet connection natively in order to access this, we
want to
be able to go through edge 200 for specific reasons.
Well, at that point, we might need to make sure that we know where this is, at
least making
sure that we're using the correct link for this.
So usually what we have to do is we have to make, let's say 57.3.4.5 that this
needs to
be known by crisscross here.
It needs to be known by edge 250.
So edge 250 needs to know about this address.
Meanwhile, edge 100 needs to know about these original two subnets.
And then the last subnet would be this one down here.
So 10.1.1.10 needs to be known by up here, edge 200.
So we've got lots of ways to do that.
We could always do it statically.
We could take advantage of a dynamic routing protocol like BGP or maybe OSPF or
EIGRP if
those are already in place.
Next attack has decided to configure static routes over here on edge 100.
And well, okay, so we're asking what the full rods, including next hops will be
configured.
All right.
So we know the edge 100 needs these two subnets down here.
So we'll put three up here.
And we need to make sure we have the full route.
So 10.250.0.0.
If you wanted to say the subnet mask of 255.255.255.252 we could.
I'm just going to write slash 30 here.
That's fine.
Importantly, it's the next hop that matters.
So where is 10.250?
Well, 10.250, if we look at the arrow here, we're trying to reach this
interface for the
blue tunnel.
Which means that we want to go this way and use 50.1.1.3 as my next hop.
Meanwhile, I need to know where 10.200.0.0/30 is.
And if I'm trying to get to to for tunnel termination, I'm trying to get here
on edge
200.
Well, follow the purple path.
And I know I'm going through the Metro Ethernet link.
And so that's going to point to this address down here, 10.2.2.20.
Again, we've made the assumption here that 10.1.1.10 can reach 10.2.20.
We stated that assumption as part of this.
And so we can take for granted that we'll be able to reach the next hop.
And therefore, we'll be able to reach where the TLA extension is pointing us
towards.
Lastly, which route is missing on edge 200?
So this edge up here.
Or to have full reachability.
And what about edge 250?
All right.
So we got done saying that we needed these two routes as well.
We took care of these two routes via static.
But now we need to make sure that edge 250 knows where 57.3.4.5 is.
And so we would want to point to this router here, edge 200 from edge 250's
perspective.
And edge 200 needs to know where this subnet lives over here.
But again, follow the purple path here.
And we know that we've got to point down towards edge 250.
So we already identified the subnets.
It's just a matter of making sure we know what the next hop is.
We didn't provide the IP addressing on those links.
Just understand that we are trying to point towards edge 250 or edge 200
respectively.
So just depending on the route we're talking about.
So again, routing is a big part of TLA extensions.
We need to make sure that we are extending our routing connections across VPN
zero very
importantly.
And make sure that again, we think about it from an inbound and outbound
perspective.
It's not just can the edge device reach a particular IP address.
But can that remote edge, can it reach the edge that we're trying to form TLA
extension
based tunnels to once the routing is in place, then we can start to look at
configuration
of the TLA extensions themselves.
I hope this has been informative for you and I'd like to thank you for viewing.