[VIDEO LOGO]
So moving on to Trouble Ticket 3.
We're, once again, going to be on IS-IS topology 1.
And this time, our ticket is R3 IS-IS neighborship to R1
is currently down.
So this time, we'll be focusing on this segment
between R1 and R3.
So let's just jump into the command line
and start troubleshooting this.
We'll start off here on router 1.
So let's go ahead and begin with a show IS-IS neighbor
just to verify the ticket.
And we see here that our connection to router 3 actually
is not up.
It's in an initState.
So it shows up on our neighbor list,
but we're not actually forming an adjacency.
Let's take a more detailed look at that interface.
Let's say, show IS-IS interface gig 0001.
So looking over this, we see that it is currently Enabled.
We see that the Adjacency Formation is actually Enabled,
but it's not, of course, forming the neighborship.
We know this.
We see that the Circuit Type is Level-2-only.
It's set to Point-to-Point.
So so far, everything looks OK.
Of course, our level 2 adjacency count is zero.
And it should, of course, have a neighborship.
If we keep scrolling down, we can
see that the Protocol State of CLNS is up.
Our MTU is 1497.
We can also see that IPv4 Unicast is Enabled as well
as IPv6 Unicast.
So again, just looking over the basic parameters here,
everything appears to be OK.
Let's go take a look at router 3 as well.
So again, we'll do a show IS-IS interface gig 0001.
So we see here that the interface is Enabled as well
as the Adjacency Formation.
We see that the Circuit Type is Level-2 as it should be.
The Media Type also Point-to-Point as it should be.
Of course, our Level-2 Adjacency Count is 0.
And if we scroll down, we see again, that the CLNS Protocol
State is up.
The MTU is 1453, which is interesting
because router 1 was 1497.
We do see that IPv4 and IPv6 are both enabled.
So again, everything else looks fine.
But we do see something here suspicious with that MTU.
1453 is not the normal default. So let's see
if we can get any more information
about that out of a debug.
Let's set up some conditional debugging here.
So we'll do a debug condition being interface gigabit 0001,
and then let's debug CLNS packet.
We'll go ahead and turn off our debugging
because the necessary message has already shown up.
Here on the debug, we can see that we're sending that 1453,
but we're receiving the 1497.
So we can see right here on the debug
that the packet size is mismatching.
We could, of course, also see this in Wireshark.
So let's go take a look.
So if we look up in our Packet window,
we can see right away that the length of the packets coming
from the two different routers doesn't match.
The length is 1514, which is the standard size for an Ethernet
frame, and the other one is only 1470.
So we can already see a mismatch in the MTU here.
Of course, we can also see this in the Analysis window
where we see it's 1514 bytes on the wire.
And if we open up the IS-IS Hello,
we can actually see here the PDU length is 1497.
Now again, this is all a packet from router 1.
If we look at router 3, here we see
that it's 1470 bytes on the wire and the PDU length is 1453.
So router 1 is using default values and router 3 is not.
Now, of course, the problem here is
that in order for IS-IS to fully form an adjacency,
the MTU size on each router has to be the same.
And clearly, it's not.
So as we said, router 1 is using the default
and router 3 is not.
Clearly, of course, we could change them just so they match.
We have to just choose which one to change.
And again, since there's no reason here for the MTU
not to be set to the default, we'll
go ahead and change router 3 to be the default
MTU since, again, there's no reason for it to be smaller.
So let's jump back over to the command-line.
Let's do a show run for the interface gig 0001.
And we can actually see that the MTU
has been manually set to 1470.
So again, all we have to do to fix this
is change this back to the default.
We'll simply go into Configuration mode,
go into our gigabit interface, and simply say no MTU 1470,
commit our changes, and Exit configuration.
So if that fixed the problem, we should now have a neighborship.
Let's do our show IS-IS neighbor again.
And we can see that, in fact, we do have our neighborship up
with router 1.
So that verifies that we have solved
the problem in this ticket.
In this video, we saw an example of how if the MTU size does not
match between two devices, the IS-IS adjacency will not
actually form.
Now, what's interesting is we do still see each other's hellos.
So it was showing up on the neighbor list,
but it was in an initState, meaning it was still trying
to synchronize the database.
And we can't do that with that MTU mismatch.
So if you see the initState, one of the first things to check
would be that MTU.
I hope this has been informative for you,
and I'd like to thank you for viewing.