1
00:00:00,000 --> 00:00:00,974

2
00:00:00,974 --> 00:00:04,383
[VIDEO LOGO]

3
00:00:04,383 --> 00:00:11,710

4
00:00:11,710 --> 00:00:15,150
So moving on to
Trouble Ticket 3.

5
00:00:15,150 --> 00:00:19,050
We're, once again, going
to be on IS-IS topology 1.

6
00:00:19,050 --> 00:00:26,160
And this time, our ticket is
R3 IS-IS neighborship to R1

7
00:00:26,160 --> 00:00:28,110
is currently down.

8
00:00:28,110 --> 00:00:30,630
So this time, we'll be
focusing on this segment

9
00:00:30,630 --> 00:00:33,780
between R1 and R3.

10
00:00:33,780 --> 00:00:35,790
So let's just jump
into the command line

11
00:00:35,790 --> 00:00:37,800
and start troubleshooting this.

12
00:00:37,800 --> 00:00:40,660
We'll start off
here on router 1.

13
00:00:40,660 --> 00:00:44,130
So let's go ahead and begin
with a show IS-IS neighbor

14
00:00:44,130 --> 00:00:46,230
just to verify the ticket.

15
00:00:46,230 --> 00:00:49,950
And we see here that our
connection to router 3 actually

16
00:00:49,950 --> 00:00:51,480
is not up.

17
00:00:51,480 --> 00:00:53,770
It's in an initState.

18
00:00:53,770 --> 00:00:57,090
So it shows up on
our neighbor list,

19
00:00:57,090 --> 00:01:01,170
but we're not actually
forming an adjacency.

20
00:01:01,170 --> 00:01:04,620
Let's take a more detailed
look at that interface.

21
00:01:04,620 --> 00:01:09,390
Let's say, show IS-IS
interface gig 0001.

22
00:01:09,390 --> 00:01:14,070
So looking over this, we see
that it is currently Enabled.

23
00:01:14,070 --> 00:01:18,220
We see that the Adjacency
Formation is actually Enabled,

24
00:01:18,220 --> 00:01:20,850
but it's not, of course,
forming the neighborship.

25
00:01:20,850 --> 00:01:22,140
We know this.

26
00:01:22,140 --> 00:01:25,290
We see that the Circuit
Type is Level-2-only.

27
00:01:25,290 --> 00:01:27,400
It's set to Point-to-Point.

28
00:01:27,400 --> 00:01:29,760
So so far, everything looks OK.

29
00:01:29,760 --> 00:01:33,180
Of course, our level 2
adjacency count is zero.

30
00:01:33,180 --> 00:01:36,620
And it should, of course,
have a neighborship.

31
00:01:36,620 --> 00:01:38,690
If we keep scrolling
down, we can

32
00:01:38,690 --> 00:01:41,720
see that the Protocol
State of CLNS is up.

33
00:01:41,720 --> 00:01:45,320
Our MTU is 1497.

34
00:01:45,320 --> 00:01:49,370
We can also see that IPv4
Unicast is Enabled as well

35
00:01:49,370 --> 00:01:51,800
as IPv6 Unicast.

36
00:01:51,800 --> 00:01:55,280
So again, just looking over
the basic parameters here,

37
00:01:55,280 --> 00:01:58,080
everything appears to be OK.

38
00:01:58,080 --> 00:02:01,360
Let's go take a look
at router 3 as well.

39
00:02:01,360 --> 00:02:06,420
So again, we'll do a show
IS-IS interface gig 0001.

40
00:02:06,420 --> 00:02:09,870
So we see here that the
interface is Enabled as well

41
00:02:09,870 --> 00:02:12,120
as the Adjacency Formation.

42
00:02:12,120 --> 00:02:15,780
We see that the Circuit Type
is Level-2 as it should be.

43
00:02:15,780 --> 00:02:20,080
The Media Type also
Point-to-Point as it should be.

44
00:02:20,080 --> 00:02:24,180
Of course, our Level-2
Adjacency Count is 0.

45
00:02:24,180 --> 00:02:29,010
And if we scroll down, we see
again, that the CLNS Protocol

46
00:02:29,010 --> 00:02:30,180
State is up.

47
00:02:30,180 --> 00:02:35,790
The MTU is 1453,
which is interesting

48
00:02:35,790 --> 00:02:40,320
because router 1 was 1497.

49
00:02:40,320 --> 00:02:44,830
We do see that IPv4 and
IPv6 are both enabled.

50
00:02:44,830 --> 00:02:47,490
So again, everything
else looks fine.

51
00:02:47,490 --> 00:02:52,590
But we do see something here
suspicious with that MTU.

52
00:02:52,590 --> 00:02:57,113
1453 is not the normal
default. So let's see

53
00:02:57,113 --> 00:02:58,530
if we can get any
more information

54
00:02:58,530 --> 00:03:00,930
about that out of a debug.

55
00:03:00,930 --> 00:03:04,550
Let's set up some
conditional debugging here.

56
00:03:04,550 --> 00:03:09,640
So we'll do a debug condition
being interface gigabit 0001,

57
00:03:09,640 --> 00:03:14,980
and then let's
debug CLNS packet.

58
00:03:14,980 --> 00:03:17,170
We'll go ahead and
turn off our debugging

59
00:03:17,170 --> 00:03:21,850
because the necessary
message has already shown up.

60
00:03:21,850 --> 00:03:27,280
Here on the debug, we can see
that we're sending that 1453,

61
00:03:27,280 --> 00:03:31,900
but we're receiving the 1497.

62
00:03:31,900 --> 00:03:34,270
So we can see right
here on the debug

63
00:03:34,270 --> 00:03:38,560
that the packet
size is mismatching.

64
00:03:38,560 --> 00:03:41,650
We could, of course, also
see this in Wireshark.

65
00:03:41,650 --> 00:03:44,180
So let's go take a look.

66
00:03:44,180 --> 00:03:46,630
So if we look up in
our Packet window,

67
00:03:46,630 --> 00:03:51,040
we can see right away that the
length of the packets coming

68
00:03:51,040 --> 00:03:54,550
from the two different
routers doesn't match.

69
00:03:54,550 --> 00:03:59,200
The length is 1514, which is the
standard size for an Ethernet

70
00:03:59,200 --> 00:04:04,210
frame, and the other
one is only 1470.

71
00:04:04,210 --> 00:04:08,380
So we can already see a
mismatch in the MTU here.

72
00:04:08,380 --> 00:04:11,800
Of course, we can also see
this in the Analysis window

73
00:04:11,800 --> 00:04:15,890
where we see it's 1514
bytes on the wire.

74
00:04:15,890 --> 00:04:18,589
And if we open up
the IS-IS Hello,

75
00:04:18,589 --> 00:04:23,900
we can actually see here
the PDU length is 1497.

76
00:04:23,900 --> 00:04:28,160
Now again, this is all
a packet from router 1.

77
00:04:28,160 --> 00:04:31,610
If we look at router
3, here we see

78
00:04:31,610 --> 00:04:38,970
that it's 1470 bytes on the
wire and the PDU length is 1453.

79
00:04:38,970 --> 00:04:45,030
So router 1 is using default
values and router 3 is not.

80
00:04:45,030 --> 00:04:47,390
Now, of course,
the problem here is

81
00:04:47,390 --> 00:04:51,350
that in order for IS-IS to
fully form an adjacency,

82
00:04:51,350 --> 00:04:56,250
the MTU size on each
router has to be the same.

83
00:04:56,250 --> 00:04:58,520
And clearly, it's not.

84
00:04:58,520 --> 00:05:01,850
So as we said, router
1 is using the default

85
00:05:01,850 --> 00:05:03,770
and router 3 is not.

86
00:05:03,770 --> 00:05:07,310
Clearly, of course, we could
change them just so they match.

87
00:05:07,310 --> 00:05:09,870
We have to just choose
which one to change.

88
00:05:09,870 --> 00:05:12,920
And again, since there's
no reason here for the MTU

89
00:05:12,920 --> 00:05:15,200
not to be set to
the default, we'll

90
00:05:15,200 --> 00:05:18,470
go ahead and change
router 3 to be the default

91
00:05:18,470 --> 00:05:23,330
MTU since, again, there's no
reason for it to be smaller.

92
00:05:23,330 --> 00:05:26,900
So let's jump back over
to the command-line.

93
00:05:26,900 --> 00:05:31,310
Let's do a show run for
the interface gig 0001.

94
00:05:31,310 --> 00:05:34,430
And we can actually
see that the MTU

95
00:05:34,430 --> 00:05:38,540
has been manually set to 1470.

96
00:05:38,540 --> 00:05:41,720
So again, all we have
to do to fix this

97
00:05:41,720 --> 00:05:44,840
is change this back
to the default.

98
00:05:44,840 --> 00:05:47,600
We'll simply go into
Configuration mode,

99
00:05:47,600 --> 00:05:55,640
go into our gigabit interface,
and simply say no MTU 1470,

100
00:05:55,640 --> 00:06:00,030
commit our changes,
and Exit configuration.

101
00:06:00,030 --> 00:06:03,230
So if that fixed the problem, we
should now have a neighborship.

102
00:06:03,230 --> 00:06:07,440
Let's do our show
IS-IS neighbor again.

103
00:06:07,440 --> 00:06:10,850
And we can see that, in fact,
we do have our neighborship up

104
00:06:10,850 --> 00:06:12,800
with router 1.

105
00:06:12,800 --> 00:06:15,290
So that verifies
that we have solved

106
00:06:15,290 --> 00:06:18,870
the problem in this ticket.

107
00:06:18,870 --> 00:06:25,230
In this video, we saw an example
of how if the MTU size does not

108
00:06:25,230 --> 00:06:30,180
match between two devices,
the IS-IS adjacency will not

109
00:06:30,180 --> 00:06:31,650
actually form.

110
00:06:31,650 --> 00:06:35,340
Now, what's interesting is we do
still see each other's hellos.

111
00:06:35,340 --> 00:06:39,210
So it was showing up
on the neighbor list,

112
00:06:39,210 --> 00:06:42,990
but it was in an initState,
meaning it was still trying

113
00:06:42,990 --> 00:06:44,940
to synchronize the database.

114
00:06:44,940 --> 00:06:48,580
And we can't do that
with that MTU mismatch.

115
00:06:48,580 --> 00:06:52,710
So if you see the initState,
one of the first things to check

116
00:06:52,710 --> 00:06:55,260
would be that MTU.

117
00:06:55,260 --> 00:06:57,480
I hope this has been
informative for you,

118
00:06:57,480 --> 00:07:00,620
and I'd like to thank
you for viewing.

119
00:07:00,620 --> 00:07:04,000