1
00:00:00,000 --> 00:00:03,984
[AUDIO LOGO]

2
00:00:03,984 --> 00:00:07,970

3
00:00:07,970 --> 00:00:10,250
So here's a potential problem.

4
00:00:10,250 --> 00:00:13,850
Imagine that we have some sort
of a failure in our network.

5
00:00:13,850 --> 00:00:16,640
Maybe a link goes down,
or a neighboring router

6
00:00:16,640 --> 00:00:20,150
goes down, and then, of
course, it comes back up.

7
00:00:20,150 --> 00:00:21,980
Now we had already
hyperconverged

8
00:00:21,980 --> 00:00:24,200
to a different or
alternate path.

9
00:00:24,200 --> 00:00:26,570
Might not be our
best path, but it's

10
00:00:26,570 --> 00:00:30,170
an alternate path that we can
use to get to our destinations,

11
00:00:30,170 --> 00:00:32,090
and that's been working fine.

12
00:00:32,090 --> 00:00:36,110
But now, when it
comes back up, our IGP

13
00:00:36,110 --> 00:00:39,080
converges, of course,
probably very quickly

14
00:00:39,080 --> 00:00:42,530
and maybe faster than LDP.

15
00:00:42,530 --> 00:00:47,840
Now we have a route going over
what's the potential best path,

16
00:00:47,840 --> 00:00:51,360
but there's no label
off that circuit.

17
00:00:51,360 --> 00:00:54,800
So now what we do is we're
going to forward the traffic

18
00:00:54,800 --> 00:00:59,540
unlabeled out that
interface based on the IGP.

19
00:00:59,540 --> 00:01:01,970
This is where we have a problem.

20
00:01:01,970 --> 00:01:04,760
Not so much if we're
just doing IP forwarding.

21
00:01:04,760 --> 00:01:07,190
Again, if we're just doing IP
forwarding while we're still

22
00:01:07,190 --> 00:01:11,180
forwarding traffic, but if we
have those additional services,

23
00:01:11,180 --> 00:01:14,210
those extra applications
like traffic engineering

24
00:01:14,210 --> 00:01:18,290
or layer 2 or layer
3 VPN, we're actually

25
00:01:18,290 --> 00:01:21,320
breaking the label switch
path, and that will then

26
00:01:21,320 --> 00:01:25,040
break the layer 2 layer
VPN the traffic engineering

27
00:01:25,040 --> 00:01:28,310
tunnel that traffic will now
be forwarded with no label,

28
00:01:28,310 --> 00:01:30,900
and that's going to
be a major problem.

29
00:01:30,900 --> 00:01:33,560
So in order to
prevent this, we can

30
00:01:33,560 --> 00:01:36,200
turn on IGP Synchronization.

31
00:01:36,200 --> 00:01:38,150
Let's go ahead and
jump in and take a look

32
00:01:38,150 --> 00:01:41,570
at the details of this feature.

33
00:01:41,570 --> 00:01:46,690
So IGP Synchronization
is used to prevent

34
00:01:46,690 --> 00:01:52,390
using an IGP learned path
from being used again

35
00:01:52,390 --> 00:01:56,860
until LDP has hyperconverged
on that interface.

36
00:01:56,860 --> 00:01:59,710
We don't want to start
forwarding traffic until we

37
00:01:59,710 --> 00:02:02,200
have a label, or
we can potentially

38
00:02:02,200 --> 00:02:04,390
break our label switch path.

39
00:02:04,390 --> 00:02:07,240
Again, the thought is
that we've switched over

40
00:02:07,240 --> 00:02:10,360
to an alternate path,
maybe not the best,

41
00:02:10,360 --> 00:02:13,480
but we're using that path, and
it's currently working fine.

42
00:02:13,480 --> 00:02:18,610
We don't want to switch back to
our best path or original path

43
00:02:18,610 --> 00:02:21,430
until it is completely
hyperconverged, including

44
00:02:21,430 --> 00:02:22,750
a label.

45
00:02:22,750 --> 00:02:26,320
Along that same
lines, it'll also

46
00:02:26,320 --> 00:02:31,660
prevent a link from being used
if the LDP session goes down.

47
00:02:31,660 --> 00:02:34,450
This would create the
exact same situation.

48
00:02:34,450 --> 00:02:37,420
If I lose my LDP
membership, then I'm

49
00:02:37,420 --> 00:02:41,270
going to lose all the labels,
and in a similar fashion,

50
00:02:41,270 --> 00:02:46,090
the circuit's up, so I would
still have my IGP path.

51
00:02:46,090 --> 00:02:48,640
Theoretically, routing
would say to use it,

52
00:02:48,640 --> 00:02:52,030
but IGP synchronization
will say no, don't use it

53
00:02:52,030 --> 00:02:53,950
because we don't have labels.

54
00:02:53,950 --> 00:02:58,170
Again, it would break
the label switch path.

55
00:02:58,170 --> 00:03:00,240
In case it's not
clear why we need

56
00:03:00,240 --> 00:03:03,690
this feature, the other
applications, traffic

57
00:03:03,690 --> 00:03:07,020
engineering, layer
2 VPN, layer 3 VPN,

58
00:03:07,020 --> 00:03:10,890
they don't know how
to work around this.

59
00:03:10,890 --> 00:03:14,370
Our IGP doesn't know
how to work around this.

60
00:03:14,370 --> 00:03:17,470
Remember, we're still following
the regular rules of routing.

61
00:03:17,470 --> 00:03:20,490
So when our IGP
says to use a path,

62
00:03:20,490 --> 00:03:22,320
that's what we would try to do.

63
00:03:22,320 --> 00:03:24,580
None of the applications
know any better.

64
00:03:24,580 --> 00:03:27,870
However, they suddenly
lose all of their labels

65
00:03:27,870 --> 00:03:29,650
which they need to function.

66
00:03:29,650 --> 00:03:33,870
That's why this is so important
that even though our IGP says

67
00:03:33,870 --> 00:03:37,440
we have a path, we can't
use it unless we have

68
00:03:37,440 --> 00:03:40,110
valid labels for that path.

69
00:03:40,110 --> 00:03:42,990
The best way to
detect that is to see

70
00:03:42,990 --> 00:03:46,710
if LDP is hyperconverged,
that we have labels,

71
00:03:46,710 --> 00:03:49,770
and that the LDP
session is not down.

72
00:03:49,770 --> 00:03:54,780
Now the way this works
is that the IGP will only

73
00:03:54,780 --> 00:04:00,060
advertise regular metrics
once LDP is actually

74
00:04:00,060 --> 00:04:02,460
synchronized on the link.

75
00:04:02,460 --> 00:04:05,280
Now how does it know
if it's synchronized?

76
00:04:05,280 --> 00:04:10,980
Well, we have to have
at least one LDP session

77
00:04:10,980 --> 00:04:13,330
up on that interface.

78
00:04:13,330 --> 00:04:16,540
Now again, LDP
converges quickly,

79
00:04:16,540 --> 00:04:21,132
so this will normally
happen almost immediately.

80
00:04:21,132 --> 00:04:22,590
So normally, this
should not really

81
00:04:22,590 --> 00:04:24,700
create any sort of a problem.

82
00:04:24,700 --> 00:04:27,180
However, if needed,
we can configure

83
00:04:27,180 --> 00:04:31,890
a delay of up to 60
seconds if we need it

84
00:04:31,890 --> 00:04:35,130
on a certain interface.

85
00:04:35,130 --> 00:04:40,250
Now synchronization is only
supported for OSPF and IS-IS,

86
00:04:40,250 --> 00:04:42,770
which really makes
a lot of sense

87
00:04:42,770 --> 00:04:45,860
since these are the only two
protocols that support traffic

88
00:04:45,860 --> 00:04:48,530
engineering and,
therefore, honestly,

89
00:04:48,530 --> 00:04:53,120
about the only two protocols we
generally use in our MPLS core.

90
00:04:53,120 --> 00:04:55,280
This shouldn't
really be a problem.

91
00:04:55,280 --> 00:04:58,040
We're probably going to be
using one of these two protocols

92
00:04:58,040 --> 00:04:59,450
anyway.

93
00:04:59,450 --> 00:05:04,430
All we have to do to enable
this on both IOS XR and IOS XE

94
00:05:04,430 --> 00:05:10,380
is turn on mpls ldp sync under
the protocol configuration.

95
00:05:10,380 --> 00:05:15,410
In other words, under OSPF
or IS-IS configuration.

96
00:05:15,410 --> 00:05:17,330
And in case you haven't
picked up on the fact

97
00:05:17,330 --> 00:05:20,780
yet that this is
generally a good feature

98
00:05:20,780 --> 00:05:25,470
and it's got a lot of advantages
without really any downsides,

99
00:05:25,470 --> 00:05:30,830
it is generally recommended
that we use IGP Synchronization

100
00:05:30,830 --> 00:05:33,580
in our environments.

101
00:05:33,580 --> 00:05:37,750
In this video, we looked
at IGP Synchronization.

102
00:05:37,750 --> 00:05:39,730
The cool thing
about this feature

103
00:05:39,730 --> 00:05:44,020
is it prevents us from
forwarding traffic over a link

104
00:05:44,020 --> 00:05:46,960
that we've only hyperconverged
our routing protocol

105
00:05:46,960 --> 00:05:49,360
on but not LDP.

106
00:05:49,360 --> 00:05:52,340
Therefore, we don't
have any learned labels.

107
00:05:52,340 --> 00:05:54,340
And if we started
forwarding traffic,

108
00:05:54,340 --> 00:05:56,890
we would be breaking
the label switch path

109
00:05:56,890 --> 00:06:00,760
for things like traffic
engineering and VPNs.

110
00:06:00,760 --> 00:06:04,310
And was cool is this
prevents that from happening.

111
00:06:04,310 --> 00:06:07,780
Now something else that can
be very useful, especially

112
00:06:07,780 --> 00:06:10,900
on routers with a large
number of interfaces,

113
00:06:10,900 --> 00:06:16,210
is a tool to help us actually
enable LDP on our interfaces

114
00:06:16,210 --> 00:06:20,020
along with our routing protocol,
and that's exactly what

115
00:06:20,020 --> 00:06:21,680
we're going to look at next.

116
00:06:21,680 --> 00:06:25,090
Until then, I hope this has
been informative for you,

117
00:06:25,090 --> 00:06:28,170
and I'd like to thank
you for viewing.

118
00:06:28,170 --> 00:06:32,000