When we have a topology with let's say three different edges here and each one
of our edges has a locally attached subnet we'll just call this subnets A
and B and C and we know that we'll just have a single transport in here that
we're forming these tunnels through the transport mechanism and by default it's
going to form these tunnels in full mesh and what we need to think about here is
how OMP running on the controller is going to forward these paths, this
pathing information about these different subnets. For example this edge
over here advertises let's just give these some site IDs we'll call this site
1, site 2, and site 3 and edges 1, 2, and 3 accordingly as well and so edge 3
says that I've got access to subnet A but it doesn't just say I've got access
to subnet A it specifically is saying this about a specific T-lock. So we also
have T-locks here let's call them T1 and T2 even though there's two connections
coming into each of these they are all coming in on a single T-lock and we'll
call it T-lock 3 here on site 3 or edge 3. So we know that subnet A is
accessible via T-lock 3 and then that information gets reflected down to the
other edges. So what do the other edges know? Well they know that site I guess
that's subnet C over here how about that so we know that subnet C is accessible
via T-lock 3 and same with site 2 up here we know that C is accessible via
T-lock 3. So that's all in good but what happens if one of these links goes down?
For example let's say that this connection between sites A and C or
sites 1 and 3 I suppose what happens if this link goes down? If we're used to
something like EIGRP or OSPF then we would say or look at this and assume
that well we'll just forward up to site 2 and site 2 will forward it down to
site 3 because that's how failover works with these routing protocols. But that's
not how this is going to work because we're not running EIGRP and we're not
running OSPF we're running OMP and the information I have is the information I
have. There is no failover kind of protocol or routine that we go through
to try to find a backup path. Instead because edge 1 here knows that I don't
have access to T-lock number 3 that I cannot access subnet C even though in
theory we have a way around it. So there is a solution to this to make our
topology a little bit more resilient to failures such as this and it's going to
require us to explore the concept of deploying T-lock action statements. What
we're going to do is we're going to configure OMP in such a way that we
provide routes that have two different pieces of information. So a route is now
let's say it's for subnet C it's going to not just have the T-lock remember we
advertised a T-lock like this instead we're going to call this an ultimate
T-lock. Now sometimes the word ultimate in English we say that to mean that
something is awesome or super but in this case the word ultimate actually
means final or last and so we're saying that this T-lock number 3 is the last
hop it's where I'm trying to go. But we're also going to define what Cisco
calls an intermediate T-lock. The word intermediate means something in the
middle and so in our case we might take this information and not only advertise
T-lock 3 as the ultimate location or ultimate T-lock I suppose but we can
also advertise T-lock number 2 up here as being the intermediate T-lock. Kind of
interesting. Now when this information gets propagated down over here to site
1 we're including this information so yes we have access to subnet C it's
accessible via T-lock 3 as the ultimate and T-lock 2 as the intermediate. So
we're passing two T-locks down and as we might imagine that's going to make this
a little more resilient to failure. So now we know of two different paths the
question is which one of these do we actually want to use? We might assume
that we're going to go straight to the ultimate location or the ultimate T-lock
T3 and then if we have to we'll use this indirect intermediate backup path. And
okay fine that is certainly an option but Cisco wants us to configure
this explicitly. So we're going to have to configure T-lock action with an
option and we have a few different options at play. First of all is strict
and strict is the default option and we're just going to say that if we have
it configured as strict that we're going to use the intermediate only. Now right
away we're going to notice that our focus on with these options has to do
with how we treat the intermediate path. It's kind of interesting because we
might expect that the ultimate would win out over pretty much any other
option and yet the reason why it doesn't is because what we're going out of our
way to configure is the intermediate T-lock. We already had the ultimate T-lock
down here with the original configuration so now we're saying that
hey I'm going to include additional information and now I need to know how
to treat that additional information. If I configure T-lock action to be strict
that means that we're going to treat this intermediate option as the only
option to the point that if this link goes down for any reason and this link
is still online that we would not be able to use that link because I have to
use the intermediate if I'm using the strict option. For the most part we're
probably going to look at one of three other options. The first of which is
primary and the next of which is backup. So as the names imply these are kind of
opposites of each other. If we're going to use primary we're going to use the
intermediate first and then we'll fail over to the ultimate. Backup is quite the
opposite. I'm going to start with the ultimate and then I'm going to fail back
to the intermediate. Now this backup option should catch our eye. This is
exactly what I just said is probably going to be our assumed default option
except we'd be wrong because strict is the default option here. But the idea
that we would start by sending straight to the ultimate T-lock and then we'll
use the intermediate T-lock if we desire it. Whereas primary is saying hey let's
just send to the intermediate which is what we said we'd do with strict. However
if there is a failure then I will use the ultimate connection directly. So
again as I already pointed out but it's worth noting again the word primary and
backup are in relation or relative relative to our intermediate T-lock. So
I'm describing the intermediate T-locks role here. In this case the intermediate
T-locks role is the primary. We start with intermediate and we fall back to
ultimate if needed. Same with backup. My intermediary or intermediate is the is
the backup link. I'm only going to use it if the ultimate link goes down. So again
this options are relative to the intermediate T-lock and that's a very
important part of all this. Now I mentioned that there's four options. If
it's use only one or use both but in failover fashion the only other option
really is to say let's just use both. The fourth option is ECMP which stands
for equal cost multi-pathing. That means that we're just going to load balance
both via load balancing. So we're going to be able to send traffic out
both paths and we got to be really careful with this because if we're
sending one directly to the site and then we're sending other flows bouncing
off another site it's going to create inconsistency when it comes to latency
and jitter and whatnot. But it would be on a flow per flow basis and so at
least packets within the flow won't be arriving out of order by taking
different paths. Now there is a special case that we need to talk about here
where OMP is going to need to get a little more involved than just handing
out multiple T-locks in a route and that has to do with the possibility of using
our primary option here. Because let's just draw this down here, running out of
room and some spaces, but let's say that we're using primary. So I'm trying to use
this T-lock here as the intermediate, this T-lock over here as the ultimate,
but I chose primary which again relative to the intermediate T-lock means I'm
going to send up to this edge via the intermediate T-lock which will then get
forwarded down. Alright so that's well and good I do have this connection down
here that I could use but I'm not using it because I wanted to use this primary
path. So the question is what happens if this link goes down? This would be an
indirect failure and it's an indirect failure that this edge will have no way
of detecting. We're not running any kind of keep-alives through both of these
paths. So at this point the controller is going to actually have to get involved.
When the controller gets the report that this link is down from this edge
it's going to know that this edge down here is supposed to be using that path.
And so it'll send an OMP update to allow this edge to recognize that we're in a
failover scenario. Which again as we said means that we'll fail over to using the
ultimate path and it will get redirected this direction. So again indirect
failures are nothing that edges can detect on their own. They're going to
need to be told that via OMP and fortunately OMP does the job there. So
the question we might ask in all of this is okay why isn't this the default
option? Why don't we just have backup paths for everything? And the reality is
that we already do because we looked at a single circuit or a single transport
type of scenario and in the real world we usually have two if not three or more
transport mechanisms. And so usually if two things to think about. First of all
let's again draw a quick topology up here. So if I have a single circuit that
all of these are connected to, what are the scenarios where one of these
connections goes down but I still have a connection through the same circuit to
the other one and they have a connection as well? Meaning that this
site didn't just lose its internet access it specifically lost the ability
to communicate to this other site while maintaining the ability to connect to
other sites. This scenario doesn't happen very often and so the
failover scenario isn't common. But here's the other thing we just said well
why wouldn't we want to have backup paths? And again we do because on top of
that we also have another transport mechanism and in theory all of these
sites are connected through that transport or you know WAN circuit
whatever it is MPLS let's say. And so we have to look at it from the perspective
of we already have failover through other circuits and this type of failure
scenario isn't very common. However if we find that we in production networks have
this problem where links are going down and maybe there's a very specific reason
why these links are going down and we do have backup paths through other sites
then we would absolutely want to configure this type of policy in order
to make sure that we stay online as much as possible. So again this isn't a
default configuration on purpose but it is sort of that corner case scenario
that we need to be aware of as far as how exactly we'd go about configuring it
using the TLOC action statements. So with that let's go and jump into our
configuration and see how this works.