IS-IS Troubleshooting
IS-IS Troubleshooting
eos.arista.com/is-is-troubleshooting
Contents [hide]
Objective
Configuration
IS-IS neighborship issues
Address-family configuration mismatch
MTU mismatch
IP subnet mismatch
Level-1/Level-2 configuration and IS-IS area mismatch
Unique system ID even though the areas are different
Authentication mismatch
IS-IS metric style mismatch
Routes learned by IS-IS, but not seen in hardware
Sub-optimal forwarding
Logs collection
Capturing IS-IS control packets
Objective
The objective of this article is to outline the common issues faced when using IS-IS and
provide troubleshooting commands which could be helpful.
Configuration
To enable IS-IS on a router we need to use the commands below.
2. Define the current IS-IS area address and the system ID:
R1(config-router-isis)#net 49.0012.0000.0000.0001.00
R1(config-router-isis)#is-type ?
level-1 Act as a station router only
level-1-2 Act as both a station router and an area router
level-2-only Act as an area router only
1/5
4. Define the address-family for which you want to enable IS-IS:
R1(config-router-isis)#address-family ?
ipv4 IPv4 related
ipv6 IPv6 related
R1(config)#interface Ethernet1
R1(config-if-Et1)#isis enable <instance name>
R1(config)#interface Loopback 0
R1(config-if-Lo1)#isis enable <instance name>
2/5
MTU mismatch
When IS-IS enabled on an interface the router starts originating hellos to detect direct
neighbors, these hellos are padded up to the maximum transmission unit of the outgoing
interface which is rationally the value that the neighbor router will accept, so if there is MTU
mismatch these hellos will get dropped by the router who has lower MTU, it’s fine to happen
at such early stage before reaching the LSP exchange stage.
In this case, the switch with a lower MTU value will be logging messages:
IP subnet mismatch
Ensure that the IP-address on both ends belongs to the same subnet.
Authentication mismatch
3/5
Make sure the passwords and the authentication mechanism (clear text or MD5) are the
same on both the ends of the neighbors.
Ensure IS-IS metric style wide is used on both the devices. This is default and the only
supported style on Arista devices. Other vendors may have metric style narrow as a default.
2. Make sure filtering is not applied. Inbound filtering doesn’t prevent an LSP from being
installed in the database but it does prevent an LSP from being installed in the routing table.
If this is configured, the route won’t be installed in the hardware.
3. It is also possible that a Level-1 prefix is not copied into a Level-2 database due to
filtering, if this is the case, the route won’t be seen in the database and won’t be installed in
the hardware.
Sub-optimal forwarding
If you are seeing sub-optimal forwarding to reach a destination from a Level-1 router, then
make sure to configure route leaking correctly such that the forwarding is always optimal as
the level 1 router will now install and prefer the specific route for the destination prefix
instead of the default route towards its exit Level-1/2 router inside the area.
Logs collection
For issues related to IS-IS, please collect the following data:
4/5
Capturing IS-IS control packets
1. Directly on the kernel interface:
2. Mirror the packets coming into the front panel to the CPU:
#2 is used to isolate issues with the pipeline between the front panel port to the CPU kernel
port. It might be that the packet hits the front panel port, but gets dropped in the pipeline
towards the CPU. In such cases, #2 might help.
If the issues aren’t resolved even after performing the above checks, please engage Arista
TAC by sending an email to [email protected].
5/5