|
One important skill to develop with
Integrated IS-IS configuration and troubleshooting is to be able to
identify a problem resulting from mismatched interfaces in an NBMA
environment.
An example of a misconfiguration would be configuring one end of a
link, on router R2, to be specified as a point-to-point subinterface.The other end, router R4,
is to be used as a point-to-multipoint interface.
Issuing the
show clns neighbors on each
router shows a mismatch. R2, the point-to-point end router, shows the
adjacency as "up". R4, the multipoint end, shows the adjacency as
stuck in the "init" state. The misconfiguration results from the fact
that the two ends of the VC are set to different network types. The
point-to-point end sends serial IIH PDUs and the multipoint end sends
LAN IIH PDUs, so an adjacency cannot form.
The ISO standard defines a three-way handshake,
an agreement, for
initiating LAN adjacencies as follows:
- The adjacency starts in the "down"
state. The IS sends out LAN IIH PDUs, identifying itself.
- If a LAN IIH PDU is received, the
adjacency is installed in the init state. This router then sends out
an IIH PDU to the neighbor, including the SNPA of the neighbor in
the Hello packet. The neighbor does the same thing with the SNPA on
this router.
- The IS receives a second IIH from
the neighbor router with its own SNPA identified in the packet. On
receipt of this, the IS understands that the new neighbor knows of
its presence and therefore declares the adjacency "up".
According to the ISO standard, ISO
10589, this process is omitted for a point-to-point adjacency.
However, Cisco IOS implements the same three-way handshake by adding a
point-to-point adjacency state TLV, TLV 240, in the serial Hello PDUs.
In a similar manner to the LAN adjacency, the router checks for its
own SNPA in the neighbor's Hello PDU before declaring the adjacency
"up".
The result of the example mismatch depends on the IOS release. Prior
to release 12.1(1)T the results were as follows:
- R4, the multipoint router, receives the
point-to-point Hello PDU from R2 but treats it as a LAN Hello PDU
and puts the adjacency in the init state. R4 looks for its own SNPA
in the received Hello PDUs but never finds it. In a LAN Hello PDU
this would be identified in TLV 6 as IS Neighbors, but this TLV is
not present in a serial Hello PDU. Therefore, the adjacency remains
in the init state.
- R2, the point-to-point router, receives a LAN
Hello PDU and treats it as a point-to-point Hello PDU. It checks the
Hello PDU for a TLV 240, point-to-point adjacency state, and fails
to find one. For backward compatibility, or perhaps to allow the
link to be made to a non-Cisco IS-IS device, the router assumes this
is an ISO-specified point-to-point link. R2 ignores the Cisco
three-way handshake and allows the adjacency to establish, setting
it to "up".
Since Release 12.1(1)T the results are
as follows:
- R4, the multipoint router, receives the
point-to-point Hello PDU, realizes it is the wrong Hello type, and
installs the neighbor as an ES. R4 would show R2 in the
show clns neighbors
with protocol “ES-IS".
- R2, the point-to-point router, receives the LAN
Hello PDU, recognizes the mismatch, and ignores the neighbor. R4
would not appear at all in the
show clns neighbors
output of R2. A debug isis adj-packets
output shows the incoming LAN
IIH PDU and R2 declaring the mismatch.
|