[AUDIO LOGO]
So here's a potential problem.
Imagine that we have some sort of a failure in our network.
Maybe a link goes down, or a neighboring router
goes down, and then, of course, it comes back up.
Now we had already hyperconverged
to a different or alternate path.
Might not be our best path, but it's
an alternate path that we can use to get to our destinations,
and that's been working fine.
But now, when it comes back up, our IGP
converges, of course, probably very quickly
and maybe faster than LDP.
Now we have a route going over what's the potential best path,
but there's no label off that circuit.
So now what we do is we're going to forward the traffic
unlabeled out that interface based on the IGP.
This is where we have a problem.
Not so much if we're just doing IP forwarding.
Again, if we're just doing IP forwarding while we're still
forwarding traffic, but if we have those additional services,
those extra applications like traffic engineering
or layer 2 or layer 3 VPN, we're actually
breaking the label switch path, and that will then
break the layer 2 layer VPN the traffic engineering
tunnel that traffic will now be forwarded with no label,
and that's going to be a major problem.
So in order to prevent this, we can
turn on IGP Synchronization.
Let's go ahead and jump in and take a look
at the details of this feature.
So IGP Synchronization is used to prevent
using an IGP learned path from being used again
until LDP has hyperconverged on that interface.
We don't want to start forwarding traffic until we
have a label, or we can potentially
break our label switch path.
Again, the thought is that we've switched over
to an alternate path, maybe not the best,
but we're using that path, and it's currently working fine.
We don't want to switch back to our best path or original path
until it is completely hyperconverged, including
a label.
Along that same lines, it'll also
prevent a link from being used if the LDP session goes down.
This would create the exact same situation.
If I lose my LDP membership, then I'm
going to lose all the labels, and in a similar fashion,
the circuit's up, so I would still have my IGP path.
Theoretically, routing would say to use it,
but IGP synchronization will say no, don't use it
because we don't have labels.
Again, it would break the label switch path.
In case it's not clear why we need
this feature, the other applications, traffic
engineering, layer 2 VPN, layer 3 VPN,
they don't know how to work around this.
Our IGP doesn't know how to work around this.
Remember, we're still following the regular rules of routing.
So when our IGP says to use a path,
that's what we would try to do.
None of the applications know any better.
However, they suddenly lose all of their labels
which they need to function.
That's why this is so important that even though our IGP says
we have a path, we can't use it unless we have
valid labels for that path.
The best way to detect that is to see
if LDP is hyperconverged, that we have labels,
and that the LDP session is not down.
Now the way this works is that the IGP will only
advertise regular metrics once LDP is actually
synchronized on the link.
Now how does it know if it's synchronized?
Well, we have to have at least one LDP session
up on that interface.
Now again, LDP converges quickly,
so this will normally happen almost immediately.
So normally, this should not really
create any sort of a problem.
However, if needed, we can configure
a delay of up to 60 seconds if we need it
on a certain interface.
Now synchronization is only supported for OSPF and IS-IS,
which really makes a lot of sense
since these are the only two protocols that support traffic
engineering and, therefore, honestly,
about the only two protocols we generally use in our MPLS core.
This shouldn't really be a problem.
We're probably going to be using one of these two protocols
anyway.
All we have to do to enable this on both IOS XR and IOS XE
is turn on mpls ldp sync under the protocol configuration.
In other words, under OSPF or IS-IS configuration.
And in case you haven't picked up on the fact
yet that this is generally a good feature
and it's got a lot of advantages without really any downsides,
it is generally recommended that we use IGP Synchronization
in our environments.
In this video, we looked at IGP Synchronization.
The cool thing about this feature
is it prevents us from forwarding traffic over a link
that we've only hyperconverged our routing protocol
on but not LDP.
Therefore, we don't have any learned labels.
And if we started forwarding traffic,
we would be breaking the label switch path
for things like traffic engineering and VPNs.
And was cool is this prevents that from happening.
Now something else that can be very useful, especially
on routers with a large number of interfaces,
is a tool to help us actually enable LDP on our interfaces
along with our routing protocol, and that's exactly what
we're going to look at next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.