0% found this document useful (0 votes)
103 views5 pages

IS-IS Troubleshooting

This document outlines common issues when using IS-IS routing and provides troubleshooting steps. It discusses configuration requirements for IS-IS including enabling it on interfaces and defining the area. Potential issues covered are address-family mismatches, MTU mismatches, incorrect area configurations, authentication mismatches, and metric style mismatches. Suggested show commands and packet captures are provided to troubleshoot routes not being installed in hardware or sub-optimal forwarding. Logs should be collected and engaging Arista support is recommended if issues persist.

Uploaded by

ChristopheProust
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
103 views5 pages

IS-IS Troubleshooting

This document outlines common issues when using IS-IS routing and provides troubleshooting steps. It discusses configuration requirements for IS-IS including enabling it on interfaces and defining the area. Potential issues covered are address-family mismatches, MTU mismatches, incorrect area configurations, authentication mismatches, and metric style mismatches. Suggested show commands and packet captures are provided to troubleshoot routes not being installed in hardware or sub-optimal forwarding. Logs should be collected and engaging Arista support is recommended if issues persist.

Uploaded by

ChristopheProust
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

IS-IS troubleshooting

eos.arista.com/is-is-troubleshooting

Andrey March 28, 2020

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.

1. Configure IS-IS routing instance on the router:

R1(config)#router isis <instance name> vrf <VRF name>

2. Define the current IS-IS area address and the system ID:

R1(config-router-isis)#net 49.0012.0000.0000.0001.00

3. Define is-type of the router, by default it is level-1-2:

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

5. Enable IS-IS on the specified interface:

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>

More about IS-IS configuration can be found in our configuration guide.


https://www.arista.com/en/um-eos/eos-is-is

IS-IS neighborship issues


When it comes to establishing neighborship between IS-IS routers, there could be several
reasons affecting the formation of adjacencies between neighbors.

Address-family configuration mismatch


IS-IS (non multi-topology mode) needs the same set of address-families [AF] to be enabled
on all routers in a network and on all interfaces in each router. This is because it uses a
single topology in the SPF and any gap for one AF in the topology will lead to blackholing of
traffic.

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:

Mar 12 00:15:58 R1 Rib: %ISIS-3-ISIS_HELLO_IGNORED: L1 LAN IIH Intf: et1, srcMAC:


50:72:0:ba:4b:4e, sysId: 0000.0000.0002: IIH len 1497 greater than mtu 997
Mar 12 00:15:59 R1 Rib: %ISIS-3-ISIS_HELLO_IGNORED: L2 LAN IIH Intf: et1, srcMAC:
50:72:0:ba:4b:4e, sysId: 0000.0000.0002: IIH len 1497 greater than mtu 997

IP subnet mismatch
Ensure that the IP-address on both ends belongs to the same subnet.

Level-1/Level-2 configuration and IS-IS area mismatch


Make sure the Level-1/Level-2 are configured as needed. For example, a Level-1 router
cannot form an adjacency with a Level-2 router. Level 1 routers can form adjacencies only if
they are in the same area. Level-2 routers can form adjacency even if their area doesn’t
match.

Unique system ID even though the areas are different


Although the IS-IS areas are different, ensure that the configured System ID still remains
unique. Otherwise, it might lead to an incorrect association of LSPs to an intermediate node.

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.

IS-IS metric style mismatch

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.

Routes learned by IS-IS, but not seen in hardware


1. Make sure that the same route is not learned via a different routing protocol with a better
(lower) AD value.

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.

Useful show commands:

#show isis neighbours


#show isis interface
#show isis database
#show isis database detail
#show isis database level-1 detail
#show isis database level-2 detail
#show ip route isis

Logs collection
For issues related to IS-IS, please collect the following data:

The output of the following commands:

#show tech-support ribd vrf all | no-more


#show tech-support extended isis | no-more (if multi-agent is configured)
#show agent logs | no-more
#show agent qtrace | no-more

4/5
Capturing IS-IS control packets
1. Directly on the kernel interface:

[admin@R1 ~]$bash tcpdump -nevi <ethernet> isis

2. Mirror the packets coming into the front panel to the CPU:

[admin@R1 ~]$bash tcpdump -nevi <mirror interface> isis

#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

You might also like