IS-IS on Cisco IOS: NET Address, Levels and Configuration

IS-IS is the link-state protocol of choice in large service-provider backbones and is increasingly found in data-center underlays, but its OSI heritage makes the first configuration feel alien: routers are named by a NET address instead of a router-id, and areas work through levels rather than OSPF-style area types. This guide demystifies IS-IS on Cisco IOS - the NET address, level operation, and the four commands that get a backbone adjacency up.

Understanding the NET Address

Every IS-IS router has a Network Entity Title (NET) - an OSI address that identifies the router itself:

49.0001.1921.6800.0001.00

Reading it right to left: the last two hex digits (00) are the NSEL (always 00 on a router); the preceding 12 digits (1921.6800.0001) are the 6-byte system ID, unique across the domain and often derived from a loopback IP (192.168.0.1 = 1921.6800.0001 in dotted-hex); everything left of the system ID (49.0001) is the area ID - 49 is the private AFI (the OSI equivalent of RFC1918 space) and 0001 the area number. Routers in the same area share the area ID; system IDs must be unique domain-wide.

The rules that trip people up are mechanical rather than conceptual:

• The NET is not an IP address. It is an NSAP with the NSEL set to 00. It identifies a router, not an interface, and there is exactly one per IS-IS process.
• System ID is 6 bytes. It must be unique across the entire IS-IS domain - not just within an area - and the usual convention is to derive it from the loopback: 10.0.0.1 becomes 0100.0000.0001, 192.168.0.1 becomes 1921.6800.0001. Each octet is written as three decimal-looking digits and the groups of four hex digits are separated by dots.
• The area ID is 1 to 13 bytes and must be identical on every router in the same level-1 area. 49 is the private AFI, so 49.0001 is the OSI equivalent of a private area number.
• Total NET length is fixed per router, and all routers in the same area must use the same area-ID length. Mixing 49.0001 and 49.0001.0001 on the same wire produces an adjacency that never comes up.
• The NSEL is always 00. A NET that does not end in .00 is not a NET, and IOS will reject it.
• The number of hex digits must be even within each group, so 49.1 is invalid while 49.0001 is fine.

Changing the NET on a live router is disruptive: the router re-originates its link-state packets under a new system ID, its neighbours see a new device, and adjacencies re-form. Treat the NET as an addressing plan decision rather than a tuning knob.

Levels: IS-IS Areas Without Area Types

IS-IS has two levels instead of OSPF's area zoo: level 1 (intra-area, like OSPF inside an area) and level 2 (the backbone between areas). A router can be L1, L2, or L1/L2 (the default, acting as an area border). Unlike OSPF, all routers speak the same protocol on the same wire - levels are a property of the adjacency, not the area number.

What that means in practice is a short set of adjacency rules:

An L1/L2 router therefore keeps two separate link-state databases and runs two independent SPF calculations. Level-1 routes stay inside the area; the L2 database carries the inter-area topology. This is why a pure L2 backbone is the standard service-provider design - and why is-type level-2-only is the setting you will see on almost every core router in the wild.

Basic Configuration

R1(config)# router isis
R1(config-router)# net 49.0001.1921.6800.0001.00
R1(config-router)# is-type level-2
R1(config-router)# metric-style wide
R1(config-router)# log-adjacency-changes
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip address 192.168.120.5 255.255.255.0
R1(config-if)# ip router isis
R1(config-if)# isis circuit-type level-2-only

The four process-level essentials: net assigns the NET (process level, not per interface); is-type level-2-only is the ISP default for backbone routers (L1/L2 by default); metric-style wide enables modern 32-bit metrics; log-adjacency-changes records flaps. Then ip router isis activates the protocol on each interface - unlike OSPF there is no network statement, interfaces are enabled directly, and their subnet automatically enters the LSDB.

Two of those deserve a longer note. Metric style is dictated by the narrow-versus-wide trade-off: the original IS-IS metric is a 6-bit field with a maximum of 63, which makes modern traffic engineering and any link with a meaningful cost distinction impossible. metric-style wide moves to 32-bit metrics, and it is mandatory if you intend to use IPv6, MPLS TE, or wide-metric interoperability with other vendors. During a migration window, metric-style wide transition advertises both formats so that old and new routers can coexist; remove the transition keyword once the fleet is converted.

Circuit type is how you pin an interface to a level rather than relying on the process default. isis circuit-type level-2-only on a backbone port prevents that port from forming level-1 adjacencies at all, which is a useful safety property: a mis-cabled area router cannot accidentally create an L1 adjacency across your core.

Optional: Multiple Processes and Passive Interfaces

R1(config)# router isis as64510        ! named process
R1(config-router)# passive-interface Loopback0

Process names let one router run several IS-IS instances; the name is local to the router and never exchanged. Loopbacks should be enabled with ip router isis but made passive so their prefix is advertised without forming adjacencies.

Passive interfaces are worth understanding properly, because the failure mode they cause is subtle. A passive interface still advertises its subnet into the LSDB - that is the point - but it suppresses hello generation and will not form an adjacency. Put passive-interface on the loopback and on any interface that faces hosts. Do not put it on a transit port: the port will look perfectly healthy, its prefix will appear in everyone's routing table, and no neighbour will ever appear. When an adjacency is missing and the configuration "looks right", a stray passive interface is the first thing to check.

Timers, DIS Election and Neighbour Rules

IS-IS runs timers that are similar to OSPF's but are set in a different place - per interface, not per network type:

R1(config-if)# isis hello-interval 10
R1(config-if)# isis hello-multiplier 3
R1(config-if)# isis priority 100
R1(config-if)# isis csnp-interval 10
R1(config-if)# isis retransmit-interval 5
R1(config-if)# isis network point-to-point

• hello-interval and hello-multiplier set the hold time as interval x multiplier. The default 10-second hello with a multiplier of 3 gives a 30-second hold time. On a point-to-point core link, a 3-second hello with a multiplier of 3 detects failure in around 9 seconds - a common backbone tuning.
• hello padding is on by default, which means hellos are padded to the full interface MTU. This catches MTU mismatches before they break a routing update, but it also makes adjacency formation slower and can prevent an adjacency from forming at all on links with mismatched MTUs. Disabling padding is a legitimate troubleshooting step and occasionally a permanent choice on links you know are homogeneous.
• priority (default 64) decides which router becomes the DIS on a broadcast network. IS-IS elects a Designated Intermediate System, and unlike the OSPF DR there is no backup DIS and the election is preemptive - a router with a higher priority takes over as soon as it appears. Ties are broken by the highest SNPA, in practice the highest MAC address. The DIS represents the broadcast segment as a pseudonode in the LSDB, which is why you will see entries with 6-byte LAN IDs that do not correspond to any router.
• csnp-interval controls how often the DIS floods complete sequence number PDUs to keep the segment's database synchronised - a different mechanism from OSPF's periodic LSA ageing, and one reason IS-IS converges so predictably.
• isis network point-to-point declares a link as point-to-point, which skips the DIS election and the pseudonode entirely. On any link between exactly two routers this is both faster and simpler, and it is the standard configuration for routed core links.

Metrics, Redistribution and Overload Protection

IS-IS does not derive metrics from bandwidth the way OSPF does; it uses a fixed default of 10 on every interface, and you set the ones that should differ:

R1(config-if)# isis metric 100 level-2
R1(config-router)# redistribute connected
R1(config-router)# redistribute static level-2
R1(config-router)# default-information originate
R1(config-router)# set-overload-bit on-startup 300
R1(config-router)# set-overload-bit on-startup wait-for-bgp

Because the default metric is flat, a backbone that never sets per-interface metrics will route every path as if it were equal cost - which is usually not what the design intended. Level-1 and level-2 metrics are configured separately, and with metric-style wide you have enough range to express real link costs without running out of headroom.

set-overload-bit is IS-IS's answer to the OSPF max-metric router-lsa: the router advertises itself as overloaded so that transit traffic avoids it, while its directly connected prefixes remain reachable. The wait-for-bgp form is the one worth committing to memory - it keeps the router out of the transit path until BGP has converged, which prevents the classic black-hole window during a core router reload.

IPV6 and Multi-Topology

IS-IS is address-family agnostic, so enabling IPv6 is a two-line change - but the choice between single and multi-topology matters:

R1(config)# router isis
R1(config-router)# metric-style wide
R1(config-router)# address-family ipv6
R1(config-router-af)# multi-topology
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ipv6 address 2001:db8:1::1/64
R1(config-if)# ipv6 router isis

With multi-topology enabled, IS-IS maintains a separate topology for IPv6, so the IPv4 and IPv6 forwarding paths can differ and a router that does not run IPv6 does not become a black hole for IPv6 traffic. Without it, single-topology mode assumes both address families share one topology and requires every router in the domain to be dual-stack. Multi-topology is the safer default in mixed environments and requires metric-style wide.

Verification Commands

show clns neighbors                 ! adjacencies (state, level, holdtime)
show clns is-neighbors
show isis database                  ! link-state database
show isis topology
show route isis                    /  show ip route isis
show clns protocol                  ! NET, IS-type, areas, interfaces
debug isis adj-packets              ! adjacency troubleshooting

When an adjacency will not form, IS-IS is Layer-2 based - there is no IP to ping - so check mismatched levels, NET area IDs, MTU (IS-IS does not fragment hello packets; see our Junos IS-IS flap case study for the hello-padding failure mode) and authentication. For the OSPF comparison and its configuration on IOS XR, see our IOS XR OSPF examples and the Junos OSPF guide.

Three more commands repay the habit of using them. show clns interface prints, per interface, the circuit type actually in use, the hello interval and the metric - the three values that most often disagree between two routers. show isis spf-log answers "why did the topology change at 02:14", which is otherwise very hard to reconstruct. And show isis database detail shows the LSP contents, including the overload bit and the attached-bit information that level-1 routers use to find the nearest L1/L2 border.

A representative adjacency listing looks like this - abbreviated, and with the SNPA column showing the neighbour's MAC on broadcast media or *HDLC* on a point-to-point link:

R1# show clns neighbors
System Id      Interface   SNPA              State  Holdtime  Type  Protocol
R2             Gi0/1       0060.5c3b.0a01    Up     24        L2    IS-IS
R3             Gi0/2       *HDLC*            Up     25        L2    IS-IS

The Type column is the one to read first when something is wrong: a neighbour that shows L1 where you expected L2 is a circuit-type or is-type mismatch, not a routing problem.

A Two-Area Example

Putting it together, a classic backbone plus stub-area layout on IOS looks like this. R2 is the area border router; R1 is a level-1 router in area 0001; R3 is level-2-only in the backbone.

! R1 - level-1 router inside area 0001
R1(config)# router isis
R1(config-router)# net 49.0001.1921.6800.0001.00
R1(config-router)# is-type level-1
R1(config-router)# metric-style wide
R1(config-if)# ip router isis
R1(config-if)# isis circuit-type level-1

! R2 - area border router (level-1/2) between 0001 and the backbone
R2(config)# router isis
R2(config-router)# net 49.0001.1921.6800.0002.00
R2(config-router)# is-type level-1-2
R2(config-router)# metric-style wide
R2(config-router)# set-overload-bit on-startup wait-for-bgp
R2(config-if)# ip router isis
R2(config-if)# isis circuit-type level-1-2

! R3 - backbone-only router in area 0002
R3(config)# router isis
R3(config-router)# net 49.0002.1921.6800.0003.00
R3(config-router)# is-type level-2-only
R3(config-router)# metric-style wide
R3(config-if)# ip router isis
R3(config-if)# isis circuit-type level-2-only

Note what the levels buy you. R1 keeps a level-1 database containing only area 0001 and installs a default route towards R2 - it never learns the backbone topology. R3 sees only the level-2 topology. R2 maintains both databases and is the only router that has to know about the seam. That is the whole design, and it is the reason IS-IS scales in backbones where OSPF's area hierarchy and ABR behaviour become operationally awkward.

If a level-1 router needs reachability to specific prefixes instead of a default route, leak the routes rather than the whole L2 database:

R2(config)# router isis
R2(config-router)# redistribute isis ip level-2 into level-1 route-map LEAK

IS-IS and OSPF Configuration Compared

The headline difference is the one that shapes operations: IS-IS does not need IP to form an adjacency. That is why it can bring up a neighbour on an interface that is in the wrong subnet, and also why "the link is up but I cannot ping the neighbour" is not necessarily a contradiction in an IS-IS network. It is a genuinely different debugging model, and it is the single most common reason engineers who know OSPF well find their first IS-IS incident confusing.

Troubleshooting an Adjacency That Will Not Form

Work the list in order; it covers the overwhelming majority of real-world failures:

1. Is ip router isis on the interface? Without it, no hellos are sent at all and both routers sit there advertising a subnet nobody can reach.
2. Is the interface passive? A passive transit port advertises its prefix and never forms an adjacency - the most misleading failure on this list.
3. Do the levels match? Compare the Type column in show clns neighbors with the intended design. A level mismatch produces silence, not an error.
4. Do the area IDs match, including their length? Level-1 routers in different areas, or the same area written with different lengths, will not form an L1 adjacency.
5. Is the system ID unique? Two routers with the same system ID corrupt each other's databases; the symptom is flapping adjacencies and LSPs that will not stay installed.
6. Is the MTU consistent? Hello padding makes this visible early - a mismatch shows up as adjacencies that never leave INIT, and the fix is either to match the MTU or to disable padding.
7. Is authentication configured on both sides with the same mode and key? IS-IS authentication is per level, so a level-1 key mismatch breaks the L1 adjacency while the L2 adjacency stays up.
8. Does the circuit type agree? One side configured as point-to-point and the other as broadcast will not come up; check show clns interface on both ends.

Only after the adjacency exists does it make sense to look at routing: show isis database for whether the neighbour's LSPs are present, and show ip route isis for whether they turned into routes.

Frequently Asked Questions

Do I have to use the private AFI 49? No. 49 is the private address space convention and the correct choice for an enterprise or data-center deployment. Service providers with an allocated NSAP prefix use that instead, and it appears in the first component of the area ID.

Can two routers in different areas be level-1 neighbours? No. Level-1 adjacency requires the same area ID. Connectivity between areas is the job of a level-1/2 router.

原文链接：https://infotechninja.com/cisco-ios-isis-configuration-guide