The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes the Cisco IOS XR commands to configure ISIS.
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
When multiple instances of IS-IS are being run, an interface can be associated with only one instance (process). Instances may not share an interface.
To implement IS-IS you need to understand the following concepts:
Small IS-IS networks are typically built as a single area that includes all routers in the network. As the network grows larger, it may be reorganized into a backbone area made up of the connected set of all Level 2 routers from all areas, which is in turn connected to local areas. Within a local area, routers know how to reach all system IDs. Between areas, routers know how to reach the backbone, and the backbone routers know how to reach other areas.
The IS-IS routing protocol supports the configuration of backbone Level 2 and Level 1 areas and the necessary support for moving routing information between the areas. Routers establish Level 1 adjacencies to perform routing within a local area (intra-area routing). Routers establish Level 2 adjacencies to perform routing between Level 1 areas (interarea routing).
Each IS-IS instance can support either a single Level 1 or Level 2 area, or one of each. By default, all IS-IS instances automatically support Level 1 and Level 2 routing. You can change the level of routing to be performed by a particular routing instance using the is-type command.
When multiple instances of IS-IS are being run, an interface can be associated with only one instance (process). Instances may not share an interface.
The following list outlines key features supported in the implementation:
Multitopology
Nonstop forwarding (NSF), both Cisco proprietary and IETF
Three-way handshake
Mesh groups
Multiple IS-IS instances
Configuration of a broadcast medium connecting two networking devices as a point-to-point link
Fast-flooding with different threads handling flooding and shortest path first (SPF).
Cisco IOS XR groups all of the IS-IS configuration in router IS-IS configuration mode, including the portion of the interface configurations associated with IS-IS. To display the IS-IS configuration in its entirety, use the show running router isis command. The command output displays the running configuration for all configured IS-IS instances, including the interface assignments and interface attributes.
The following sections show how to enter each of the configuration modes. From a mode, you can enter the ? command to display the commands available in that mode.
The following example shows how to enter router configuration mode:
RP/0/RP0::hostname# configuration
RP/0/RP0:hostname(config)# router isis isp
RP/0/RP0:hostname(config-isis)#
The following example shows how to enter router address family configuration mode:
RP/0/(config)# router isis isp
RP/0/(config-isis)# address-family ipv4 unicast
RP/0/(config-isis-af)#
The following example shows how to enter interface configuration mode:
RP/0/(config)# router isis isp
RP/0/(config-isis)# interface TenGigE0/6/0/2.10
RP/0/(config-isis-if)#
The following example shows how to enter interface address family configuration mode:
RP/0/(config)# router isis isp
RP/0/(config-isis)# interface TenGigE0/6/0/2.10
RP/0/(config-isis-if)# address-family ipv4 unicast
RP/0/(config-isis-if-af)#
IS-IS interfaces can be configured as one of the following types:
Active—advertises connected prefixes and forms adjacencies. This is the default for interfaces.
Passive—advertises connected prefixes but does not form adjacencies. The passive command is used to configure interfaces as passive. Passive interfaces should be used sparingly for important prefixes such as loopback addresses that need to be injected into the IS-IS domain. If many connected prefixes need to be advertised then the redistribution of connected routes with the appropriate policy should be used instead.
Suppressed—does not advertise connected prefixes but forms adjacencies. The suppress command is used to configure interfaces as suppressed.
Shutdown—does not advertise connected prefixes and does not form adjacencies. The shutdown command is used to disable interfaces without removing the IS-IS configuration.
Limiting link-state packets (LSP) may be desirable in certain “meshy” network topologies. An example of such a network might be a highly redundant one such as a fully meshed set of point-to-point links over a nonbroadcast multiaccess (NBMA) transport. In such networks, full LSP flooding can limit network scalability. One way to restrict the size of the flooding domain is to introduce hierarchy by using multiple Level 1 areas and a Level 2 area. However, two other techniques can be used instead of or with hierarchy: Block flooding on specific interfaces and configure mesh groups.
Both techniques operate by restricting the flooding of LSPs in some fashion. A direct consequence is that although scalability of the network is improved, the reliability of the network (in the face of failures) is reduced because a series of failures may prevent LSPs from being flooded throughout the network, even though links exist that would allow flooding if blocking or mesh groups had not restricted their use. In such a case, the link-state databases of different routers in the network may no longer be synchronized. Consequences such as persistent forwarding loops can ensue. For this reason, we recommend that blocking or mesh groups be used only if specifically required, and then only after careful network design.
With this technique, certain interfaces are blocked from being used for flooding LSPs, but the remaining interfaces operate normally for flooding. This technique is simple to understand and configure, but may be more difficult to maintain and more error prone than mesh groups in the long run. The flooding topology that IS-IS uses is fine-tuned rather than restricted. Restricting the topology too much (blocking too many interfaces) makes the network unreliable in the face of failures. Restricting the topology too little (blocking too few interfaces) may fail to achieve the desired scalability.
To improve the robustness of the network in the event that all nonblocked interfaces drop, use the csnp-interval command in interface configuration mode to force periodic complete sequence number PDUs (CSNPs) packets to be used on blocked point-to-point links. The use of periodic CSNPs enables the network to become synchronized.
Configuring mesh groups (a set of interfaces on a router) can help to limit flooding. All routers reachable over the interfaces in a particular mesh group are assumed to be densely connected with each router having at least one link to every other router. Many links can fail without isolating one or more routers from the network.
In normal flooding, a new LSP is received on an interface and is flooded out over all other interfaces on the router. With mesh groups, when a new LSP is received over an interface that is part of a mesh group, the new LSP is not flooded over the other interfaces that are part of that mesh group.
By default, the router sends a periodic LSP refresh every 15 minutes. LSPs remain in a database for 20 minutes by default. If they are not refreshed by that time, they are deleted. You can change the LSP refresh interval or maximum LSP lifetime. The LSP interval should be less than the LSP lifetime or else LSPs time out before they are refreshed. In the absence of a configured refresh interval, the software adjusts the LSP refresh interval, if necessary, to prevent the LSPs from timing out.
Authentication is available to limit the establishment of adjacencies by using the hello-password command, and to limit the exchange of LSPs by using the lsp-password command.
IS-IS supports plain-text authentication, which does not provide security against unauthorized users. Plain-text authentication allows you to configure a password to prevent unauthorized networking devices from forming adjacencies with the router. The password is exchanged as plain text and is potentially visible to an agent able to view the IS-IS packets.
When an HMAC-MD5 password is configured, the password is never sent over the network and is instead used to calculate a cryptographic checksum to ensure the integrity of the exchanged data.
IS-IS stores a configured password using simple encryption. However, the plain-text form of the password is used in LSPs, sequence number protocols (SNPs), and hello packets, which would be visible to a process that can view IS-IS packets. The passwords can be entered in plain text (clear) or encrypted form.
To set the domain password, configure the lsp-password command for Level 2; to set the area password, configure the lsp-password command for Level 1.
The keychain feature allows IS-IS to reference configured keychains. IS-IS key chains enable hello and LSP keychain authentication. Keychains can be configured at the router level (in the case of the lsp-password command) and at the interface level (in the case of the hello-password command) within IS-IS. These commands reference the global keychain configuration and instruct the IS-IS protocol to obtain security parameters from the global set of configured keychains.
IS-IS is able to use the keychain to implement hitless key rollover for authentication. Key rollover specification is time based, and in the event of clock skew between the peers, the rollover process is impacted. The configurable tolerance specification allows for the accept window to be extended (before and after) by that margin. This accept window facilitates a hitless key rollover for applications (for example, routing and management protocols).
On software, NSF minimizes the amount of time a network is unavailable to its users following a route processor (RP) failover. The main objective of NSF is to continue forwarding IP packets and perform a graceful restart following an RP failover.
When a router restarts, all routing peers of that device usually detect that the device went down and then came back up. This transition results in what is called a routing flap, which could spread across multiple routing domains. Routing flaps caused by routing restarts create routing instabilities, which are detrimental to the overall network performance. NSF helps to suppress routing flaps in NSF-aware devices, thus reducing network instability.
NSF allows for the forwarding of data packets to continue along known routes while the routing protocol information is being restored following an RP failover. When the NSF feature is configured, peer networking devices do not experience routing flaps. Data traffic is forwarded through intelligent line cards while the standby RP assumes control from the failed active RP during a failover. The ability of line cards to remain up through a failover and to be kept current with the Forwarding Information Base (FIB) on the active RP is key to NSF operation.
When the Cisco IOS XR router running IS-IS routing performs an RP failover, the router must perform two tasks to resynchronize its link-state database with its IS-IS neighbors. First, it must relearn the available IS-IS neighbors on the network without causing a reset of the neighbor relationship. Second, it must reacquire the contents of the link-state database for the network.
The IS-IS NSF feature offers two options when configuring NSF:
IETF NSF
Cisco NSF
If neighbor routers on a network segment are NSF aware, meaning that neighbor routers are running a software version that supports the IETF Internet draft for router restartability, they assist an IETF NSF router that is restarting. With IETF NSF, neighbor routers provide adjacency and link-state information to help rebuild the routing information following a failover.
Cisco NSF checkpoints (stores persistently) all the state necessary to recover from a restart without requiring any special cooperation from neighboring routers. The state is recovered from the neighboring routers, but only using the standard features of the IS-IS routing protocol. This capability makes Cisco NSF suitable for use in networks in which other routers have not used the IETF standard implementation of NSF.
 Note |
If you configure IETF NSF on the Cisco IOS XR router and a neighbor router does not support IETF NSF, the affected adjacencies flap, but nonstop forwarding is maintained to all neighbors that do support IETF NSF. A restart reverts to a cold start if no neighbors support IETF NSF. |
You can configure up to eight IS-IS instances. MPLS can run on multiple IS-IS processes as long as the processes run on different sets of interfaces. Each interface may be associated with only a single IS-IS instance. Cisco IOS XR software prevents the double-booking of an interface by two instances at configuration time—two instances of MPLS configuration causes an error.
Because the Routing Information Base (RIB) treats each of the IS-IS instances as equal routing clients, you must be careful when redistributing routes between IS-IS instances. The RIB does not know to prefer Level 1 routes over Level 2 routes. For this reason, if you are running Level 1 and Level 2 instances, you must enforce the preference by configuring different administrative distances for the two instances.
The MPLS TE feature enables an MPLS backbone to replicate and expand the traffic engineering capabilities of Layer 2 ATM and Frame Relay networks. MPLS is an integration of Layer 2 and Layer 3 technologies.
For IS-IS, MPLS TE automatically establishes and maintains MPLS TE label-switched paths across the backbone by using Resource Reservation Protocol (RSVP). The route that a label-switched path uses is determined by the label-switched paths resource requirements and network resources, such as bandwidth. Available resources are flooded by using special IS-IS TLV extensions in the IS-IS. The label-switched paths are explicit routes and are referred to as traffic engineering (TE) tunnels.
The overload bit is a special bit of state information that is included in an LSP of the router. If the bit is set on the router, it notifies routers in the area that the router is not available for transit traffic. This capability is useful in four situations:
During a serious but nonfatal error, such as limited memory.
During the startup and restart of the process. The overload bit can be set until the routing protocol has converged. However, it is not employed during a normal NSF restart or failover because doing so causes a routing flap.
During a trial deployment of a new router. The overload bit can be set until deployment is verified, then cleared.
During the shutdown of a router. The overload bit can be set to remove the router from the topology before the router is removed from service.
Because the overload bit applies to forwarding for a single topology, it may be configured and cleared independently for IPv4 during multitopology operation. For this reason, the overload is set from the router address family configuration mode. If the IPv4 overload bit is set, all routers in the area do not use the router for IPv4 transit traffic.
The IS-IS overload bit avoidance feature allows network administrators to prevent label switched paths (LSPs) from being disabled when a router in that path has its Intermediate System-to-Intermediate System (IS-IS) overload bit set.
When the IS-IS overload bit avoidance feature is activated, all nodes with the overload bit set, including head nodes, mid nodes, and tail nodes, are ignored, which means that they are still available for use with label switched paths (LSPs).
Note |
The IS-IS overload bit avoidance feature does not change the default behavior on nodes that have their overload bit set if those nodes are not included in the path calculation (PCALC). |
The IS-IS overload bit avoidance feature is activated using the following command:
mpls traffic-eng path-selection ignore overload
The IS-IS overload bit avoidance feature is deactivated using the no form of this command:
no mpls traffic-eng path-selection ignore overload
When the IS-IS overload bit avoidance feature is deactivated, nodes with the overload bit set cannot be used as nodes of last resort.
You can force a default route into an IS-IS routing domain. Whenever you specifically configure redistribution of routes into an IS-IS routing domain, the software does not, by default, redistribute the default route into the IS-IS routing domain. The default-information originate command generates a default route into IS-IS, which can be controlled by a route policy. You can use the route policy to identify the level into which the default route is to be announced, and you can specify other filtering options configurable under a route policy. You can use a route policy to conditionally advertise the default route, depending on the existence of another route in the routing table of the router.
The attached bit is set in a router that is configured with the is-type command and level-1-2 keyword. The attached bit indicates that the router is connected to other areas (typically through the backbone). This functionality means that the router can be used by Level 1 routers in the area as the default route to the backbone. The attached bit is usually set automatically as the router discovers other areas while computing its Level 2 SPF route. The bit is automatically cleared when the router becomes detached from the backbone.
Note |
If the connectivity for the Level 2 instance is lost, the attached bit in the Level 1 instance LSP would continue sending traffic to the Level 2 instance and cause the traffic to be dropped. |
To simulate this behavior when using multiple processes to represent the level-1-2 keyword functionality, you would manually configure the attached bit on the Level 1 process.
The IS-IS Support for route tags feature provides the capability to associate and advertise a tag with an IS-IS route prefix. Additionally, the feature allows you to prioritize the order of installation of route prefixes in the RIB based on a tag of a route. Route tags may also be used in route policy to match route prefixes (for example, to select certain route prefixes for redistribution).
MPLS TE forwarding adjacency allows a network administrator to handle a traffic engineering, label switch path (LSP) tunnel as a link in an Interior Gateway Protocol (IGP) network, based on the Shortest Path First (SPF) algorithm. A forwarding adjacency can be created between routers in the same IS-IS level. The routers can be located multiple hops from each other. As a result, a TE tunnel is advertised as a link in an IGP network, with the cost of the link associated with it. Routers outside of the TE domain see the TE tunnel and use it to compute the shortest path for routing traffic throughout the network.
MPLS TE forwarding adjacency is considered in IS-IS SPF only if a two-way connectivity check is achieved. This is possible if the forwarding adjacency is bidirectional or the head end and tail end routers of the MPLS TE tunnel are adjacent.
The MPLS TE forwarding adjacency feature is supported by IS-IS. For details on configuring MPLS TE forwarding adjacency, see the MPLS Configuration Guide.
MPLS TE interarea tunnels allow you to establish MPLS TE tunnels that span multiple IGP areas (Open Shorted Path First [OSPF]) and levels (IS-IS), removing the restriction that required that both the tunnel headend and tailend routers be in the same area. The IGP can be either IS-IS or OSPF. See the Configuring MPLS Traffic Engineering for IS-IS for information on configuring MPLS TE for IS-IS.
For details on configuring MPLS TE interarea tunnels, see the MPLS Configuration Guide.
The unequal cost multipath (UCMP) load-balancing adds the capability with intermediate system-to-intermediate system (IS-IS) to load-balance traffic proportionally across multiple paths, with different cost.
Generally, higher bandwidth links have lower IGP metrics configured, so that they form the shortest IGP paths. With the UCMP load-balancing enabled, IGP can use even lower bandwidth links or higher cost links for traffic, and can install these paths to the forwarding information base (FIB). IS-IS IGP still installs multiple paths to the same destination in FIB, but each path will have a 'load metric/weight' associated with it. FIB uses this load metric/weight to decide the amount of traffic that needs to be sent on a higher bandwidth path and the amount of traffic that needs to be sent on a lower bandwidth path.
The UCMP computation is provided under IS-IS per address family, enabling UCMP computation for a particular address family. The UCMP configuration is also provided with a prefix-list option, which would limit the UCMP computation only for the prefixes present in the prefix-list. If prefix-list option is not provided, UCMP computation is done for the reachable prefixes in IS-IS. The number of UCMP nexthops to be considered and installed is controlled using the variance configuration. Variance value identifies the range for the UCMP path metric to be considered for installation into routing information base (RIB) and is defined in terms of a percentage of the primary path metric. Total number of paths, including ECMP and UCMP paths together is limited by the max-path configuration or by the max-path capability of the platform.
Enabling the UCMP configuration indicates that IS-IS should perform UCMP computation for the all the reachable ISIS prefixes or all the prefixes in the prefix-list, if the prefix-list option is used. The UCMP computation happens only after the primary SPF and route calculation is completed. There would be a delay of ISIS_UCMP_INITIAL_DELAY (default delay is 100 ms) milliseconds from the time route calculation is completed and UCMP computation is started. UCMP computation will be done before fast re-route computation. Fast re-route backup paths will be calculated for both the primary equal cost multipath ( ECMP) paths and the UCMP paths. Use the ucmp delay-interval command to configure the delay between primary SPF completion and start of UCMP computation.
By using the bandwidth command in interface configuration mode .
By adjusting ISIS metric on the links.
There is an option to exclude an interface from being used for UCMP computation. If it is desired that a particular interface should not be considered as a UCMP nexthop, for any prefix, then use the ucmp exclude interface command to configure the interface to be excluded from UCMP computation.
This task explains how to enable IS-IS and configure the routing level for an area.
Note |
Configuring the routing level in Step 4 is optional, but is highly recommended to establish the proper level of adjacencies. |
Although you can configure IS-IS before you configure an IP address, no IS-IS routing occurs until at least one IP address is configured.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 3 |
net network-entity-title Example:Configures network entity titles (NETs) for the routing instance.
|
|
Step 4 |
is-type { level-1 | level-1-2 | level-2-only } Example:(Optional) Configures the system type (area or backbone router).
|
|
Step 5 |
commit |
|
Step 6 |
show isis [ instance instance-id ] protocol Example:(Optional) Displays summary information about the IS-IS instance. |
After an IS-IS instance is enabled, it must be configured to compute routes for a specific network topology.
This task explains how to configure the operation of the IS-IS protocol on an interface for an IPv4 topology.
Note |
To enable the router to run in single-topology mode, configure each of the IS-IS interfaces with all of the address families enabled and “single-topology” in the address-family unicast in the IS-IS router stanza. You can use the IPv4 address family, but your configuration must represent the set of all active address families on the router. Two exceptions to these instructions exist:
The default metric style for single topology is narrow metrics. However, you can use either wide metrics or narrow metrics. How to configure them depends on how single topology is configured. |
|
Step 1 |
configure |
|
Step 2 |
interface type interface-path-id Example:Enters interface configuration mode. |
|
Step 3 |
Do one of the following:
Example:Defines the IPv4 address for the interface. An IP address is required on all interfaces in an area enabled for IS-IS if any one interface is configured for IS-IS routing.
|
|
Step 4 |
exit Example:Exits interface configuration mode, and returns the router to XR config mode. |
|
Step 5 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 6 |
net network-entity-title Example:Configures NETs for the routing instance.
|
|
Step 7 |
single-topology Example: |
|
Step 8 |
exit Example:Exits router address family configuration mode, and returns the router to router configuration mode. |
|
Step 9 |
interface type interface-path-id Example:Enters interface configuration mode. |
|
Step 10 |
circuit-type { level-1 | level-1-2 | level-2-only } Example:(Optional) Configures the type of adjacency.
|
|
Step 11 |
address-family ipv4 ] Example:Specifies the IPv4 address family, and enters interface address family configuration mode.
|
|
Step 12 |
commit |
|
Step 13 |
show isis [ instance instance-id ] interface [ type interface-path-id ] [ detail ] [ level { 1 | 2 }] Example:(Optional) Displays information about the IS-IS interface. |
|
Step 14 |
show isis [ instance instance-id ] topology [ systemid system-id ] [ level { 1 | 2 }] [ summary ] Example:(Optional) Displays a list of connected routers in all areas. |
This set of procedures configures multitopology routing, which is used by PIM for reverse-path forwarding (RPF) path selection.
Only the default VRF is currently supported in a multitopology solution.
Only intermediate system-intermediate system (IS-IS) routing protocols are currently supported.
Topology selection is restricted solely to (S, G) route sources for both SM and SSM. Static and IS-IS are the only interior gateway protocols (IGPs) that support multitopology deployment.
For non-(S, G) route sources like a rendezvous point or bootstrap router (BSR), or when a route policy is not configured, the current policy default remains in effect. In other words, a unicast-default table is selected for all sources, based on OSFP/IS-IS/Multiprotocol Border Gateway Protocol (MBGP) configuration.
Configuring multitopology networks requires the following tasks:
Follow these steps to enable a global topology in the default VRF and to enable its use with a specific interface.
|
Step 1 |
configure |
|
Step 2 |
address-family { ipv4 } topo-name Example:Configures a topology in the default VRF table that will be associated with a an interface. |
|
Step 3 |
maximum prefix limit Example:(Optional) Limits the number of prefixes allowed in a topology routing table. Range is 32 to 2000000. |
|
Step 4 |
interface type interface-path-id Example:Specifies the interface to be associated with the previously specified VRF table that will add the connected and local routes to the appropriate routing table. |
|
Step 5 |
address-family { ipv4 } topo-name Example:Enables the topology for the interface specified in Configuring a Global Topology and Associating It with an Interface, adding the connected and local routes to the appropriate routing table. |
|
Step 6 |
Repeat Step 4 and Step 5 until you have specified all the interface instances you want to associate with your topologies. Example: |
|
Step 7 |
commit |
To enable a topology in IS-IS, you must associate an IS-IS topology ID with the named topology. IS-IS uses the topology ID to differentiate topologies in the domain.
Note |
This command must be configured prior to other topology commands. |
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enters IS-IS configuration submode. |
|
Step 3 |
address-family { ipv4 } topo-name Example:Associates an IS-IS topology ID with the named topology. |
|
Step 4 |
topology-id toplogy-id Example: |
|
Step 5 |
commit |
To associate an interface with a topology in IS-IS, follow these steps.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enters IS-IS configuration submode. |
|
Step 3 |
net network-entity-title Example:Creates a network entity title for the configured isis interface. |
|
Step 4 |
interface type interface-path-id Example:Enters isis interface configuration submode and creates an interface instance. |
|
Step 5 |
address-family { ipv4 topo-name Example:
|
|
Step 6 |
Repeat Placing an Interface in a Topology in IS-IS and Placing an Interface in a Topology in IS-IS until you have specified all the interface instances and associated topologies you want to configure in your network. |
|
Step 7 |
commit |
|
Step 1 |
configure |
|
Step 2 |
route-policy policy-name Example:Defines a routing policy and enters routing policy configuration submode. |
|
Step 3 |
end-policy Example:Signifies the end of route policy definition and exits routing policy configuration submode. |
|
Step 4 |
commit |
Multitopology is configured in the same way as the single topology. However, the single - topology command is omitted, invoking the default multitopology behavior. This task is optional.
Flooding of LSPs can limit network scalability. You can control LSP flooding by tuning your LSP database parameters on the router globally or on the interface. This task is optional.
Many of the commands to control LSP flooding contain an option to specify the level to which they apply. Without the option, the command applies to both levels. If an option is configured for one level, the other level continues to use the default value. To configure options for both levels, use the command twice. For example:
RP/0/(config-isis)# lsp-refresh-interval 1200 level 2
RP/0/(config-isis)# lsp-refresh-interval 1100 level 1
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 3 |
lsp-refresh-interval seconds [ level { 1 | 2 }] Example:(Optional) Sets the time between regeneration of LSPs that contain different sequence numbers
|
|
Step 4 |
lsp-check-interval seconds [ level { 1 | 2 }] Example:(Optional) Configures the time between periodic checks of the entire database to validate the checksums of the LSPs in the database.
|
|
Step 5 |
lsp-gen-interval { [ initial-wait initial | secondary-wait secondary | maximum-wait maximum ] ... } [ level { 1 | 2 }] Example:(Optional) Reduces the rate of LSP generation during periods of instability in the network. Helps reduce the CPU load on the router and number of LSP transmissions to its IS-IS neighbors.
|
|
Step 6 |
max-lsp-lifetime seconds [ level { 1 | 2 }] Example:(Optional) Sets the initial lifetime given to an LSP originated by the router.
|
|
Step 7 |
ignore-lsp-errors disable Example:(Optional) Sets the router to purge LSPs received with checksum errors. |
|
Step 8 |
interface type interface-path-id Example:Enters interface configuration mode. |
|
Step 9 |
lsp-interval milliseconds [ level { 1 | 2 }] Example:(Optional) Configures the amount of time between each LSP sent on an interface. |
|
Step 10 |
csnp-interval seconds [ level { 1 | 2 }] Example:(Optional) Configures the interval at which periodic CSNP packets are sent on broadcast interfaces.
|
|
Step 11 |
retransmit-interval seconds [ level { 1 | 2 }] Example:(Optional) Configures the amount of time that the sending router waits for an acknowledgment before it considers that the LSP was not received and subsequently resends. |
|
Step 12 |
retransmit-throttle-interval milliseconds [ level { 1 | 2 }] Example:(Optional) Configures the amount of time between retransmissions on each LSP on a point-to-point interface.
|
|
Step 13 |
mesh-group { number | blocked } Example:(Optional) Optimizes LSP flooding in NBMA networks with highly meshed, point-to-point topologies.
|
|
Step 14 |
commit |
|
Step 15 |
show isis interface [ type interface-path-id | level { 1 | 2 }] [ brief ] Example:(Optional) Displays information about the IS-IS interface. |
|
Step 16 |
show isis [ instance instance-id ] database [ level { 1 | 2 }] [ detail | summary | verbose ] [ * | lsp-id ] Example:(Optional) Displays the IS-IS LSP database. |
|
Step 17 |
show isis [ instance instance-id ] lsp-log [ level { 1 | 2 }] Example:(Optional) Displays LSP log information. |
|
Step 18 |
show isis database-log [ level { 1 | 2 }] Example:(Optional) Display IS-IS database log information. |
This task explains how to configure your router with NSF that allows to resynchronize the IS-IS link-state database with its IS-IS neighbors after a process restart. The process restart could be due to an:
RP failover (for a warm restart)
Simple process restart (due to an IS-IS reload or other administrative request to restart the process)
IS-IS software upgrade
In all cases, NSF mitigates link flaps and loss of user sessions. This task is optional.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 3 |
nsf { cisco | ietf } Example:Enables NSF on the next restart.
|
|
Step 4 |
nsf interface-expires number Example:Configures the number of resends of an acknowledged NSF-restart acknowledgment.
|
|
Step 5 |
nsf interface-timer seconds Example:Configures the number of seconds to wait for each restart acknowledgment. |
|
Step 6 |
nsf lifetime seconds Example:Configures the maximum route lifetime following an NSF restart.
|
|
Step 7 |
commit |
|
Step 8 |
show running-config [ command ] Example:(Optional) Displays the entire contents of the currently running configuration file or a subset of that file.
|
This task explains how to configure authentication for IS-IS. This task is optional.
|
Step 1 |
configure |
||
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
||
|
Step 3 |
lsp-password { hmac-md5 | text } { clear | encrypted } password [ level { 1 | 2 }] [ send-only ] [ snp send-only ] Example:Configures the LSP authentication password.
|
||
|
Step 4 |
interface type interface-path-id Example:Enters interface configuration mode. |
||
|
Step 5 |
hello-password { hmac-md5 | text } { clear | encrypted } password [ level { 1 | 2 }] [ send-only ] Example:Configures the authentication password for an IS-IS interface. |
||
|
Step 6 |
commit |
This task explains how to configure keychains for IS-IS. This task is optional.
Keychains can be configured at the router level ( lsp-password command) and at the interface level ( hello-password command) within IS-IS. These commands reference the global keychain configuration and instruct the IS-IS protocol to obtain security parameters from the global set of configured keychains. The router-level configuration (lsp-password command) sets the keychain to be used for all IS-IS LSPs generated by this router, as well as for all Sequence Number Protocol Data Units (SN PDUs). The keychain used for HELLO PDUs is set at the interface level, and may be set differently for each interface configured for IS-IS.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 3 |
l sp-password keychain keychain-name [ level { 1 | 2 }] [ send-only ] [ snp send-only ] Example:Configures the keychain. |
|
Step 4 |
interface type interface-path-id Example:Enters interface configuration mode. |
|
Step 5 |
h ello-password keychain keychain-name [ level { 1 | 2 }] [ send-only ] Example:Configures the authentication password for an IS-IS interface. |
|
Step 6 |
commit |
This task explains how to configure IS-IS for MPLS TE. This task is optional.
Your network must support the MPLS software feature before you enable MPLS TE for IS-IS on your router.
Note |
You must enter the commands in the following task list on every IS-IS router in the traffic-engineered portion of your network. |
Note |
MPLS traffic engineering currently does not support routing and signaling of LSPs over unnumbered IP links. Therefore, do not configure the feature over those links. |
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 3 |
address-family { ipv4 } [ unicast ] Example:Specifies the IPv4 address family, and enters router address family configuration mode. |
|
Step 4 |
mpls traffic-eng level { 1 | 2 } Example:Configures a router running IS-IS to flood MPLS TE link information into the indicated IS-IS level. |
|
Step 5 |
mpls traffic-eng router-id { ip-address | interface-name interface-instance } Example:Specifies that the MPLS TE router identifier for the node is the given IP address or an IP address associated with the given interface. |
|
Step 6 |
metric-style wide [ level { 1 | 2 }] Example:Configures a router to generate and accept only wide link metrics in the Level 1 area. |
|
Step 7 |
commit |
|
Step 8 |
show isis [ instance instance-id ] mpls traffic-eng tunnel Example:(Optional) Displays MPLS TE tunnel information. |
|
Step 9 |
show isis [ instance instance-id ] mpls traffic-eng adjacency-log Example:(Optional) Displays a log of MPLS TE IS-IS adjacency changes. |
|
Step 10 |
show isis [ instance instance-id ] mpls traffic-eng advertisements Example:(Optional) Displays the latest flooded record from MPLS TE. |
This task explains how to enable logging of adjacency state changes, alter the timers for IS-IS adjacency packets, and display various aspects of adjacency state. Tuning your IS-IS adjacencies increases network stability when links are congested. This task is optional.
For point-to-point links, IS-IS sends only a single hello for Level 1 and Level 2, which means that the level modifiers are meaningless on point-to-point links. To modify hello parameters for a point-to-point interface, omit the specification of the level options.
The options configurable in the interface submode apply only to that interface. By default, the values are applied to both Level 1 and Level 2.
The hello-password command can be used to prevent adjacency formation with unauthorized or undesired routers. This ability is particularly useful on a LAN, where connections to routers with which you have no desire to establish adjacencies are commonly found.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 3 |
log adjacency changes Example:Generates a log message when an IS-IS adjacency changes state (up or down). |
|
Step 4 |
interface type interface-path-id Example:Enters interface configuration mode. |
|
Step 5 |
hello-padding { disable | sometimes } [ level { 1 | 2 }] Example:Configures padding on IS-IS hello PDUs for an IS-IS interface on the router.
|
|
Step 6 |
hello-interval seconds [ level { 1 | 2 }] Example:Specifies the length of time between hello packets that the software sends. |
|
Step 7 |
hello-multiplier multiplier [ level { 1 | 2 }] Example:Specifies the number of IS-IS hello packets a neighbor must miss before the router should declare the adjacency as down.
|
|
Step 8 |
h ello-password { hmac-md5 | text } { clear | encrypted } password [ level { 1 | 2 }] [ send-only ] Example:Specifies that this system include authentication in the hello packets and requires successful authentication of the hello packet from the neighbor to establish an adjacency. |
|
Step 9 |
commit |
|
Step 10 |
show isis [ instance instance-id ] adjacency t ype interface- path-id ] [ detail ] [ systemid system-id ] Example:(Optional) Displays IS-IS adjacencies. |
|
Step 11 |
show isis adjacency-log Example:(Optional) Displays a log of the most recent adjacency state transitions. |
|
Step 12 |
show isis [ instance instance-id ] interface [ type interface-path-id ] [ brief | detail ] [ level { 1 | 2 }] Example:(Optional) Displays information about the IS-IS interface. |
|
Step 13 |
show isis [ instance instance-id ] neighbors [ interface-type interface-instance ] [ summary ] [ detail ] [ systemid system-id ] Example:(Optional) Displays information about IS-IS neighbors. |
This task explains how to make adjustments to the SPF calculation to tune router performance. This task is optional.
Because the SPF calculation computes routes for a particular topology, the tuning attributes are located in the router address family configuration submode. SPF calculation computes routes for Level 1 and Level 2 separately.
To tune the SPF calculation parameters for single-topology mode, configure the address-family ipv4 unicast command.
The incremental SPF algorithm can be enabled separately. When enabled, the incremental shortest path first (ISPF) is not employed immediately. Instead, the full SPF algorithm is used to “seed” the state information required for the ISPF to run. The startup delay prevents the ISPF from running for a specified interval after an IS-IS restart (to permit the database to stabilize). After the startup delay elapses, the ISPF is principally responsible for performing all of the SPF calculations. The reseed interval enables a periodic running of the full SPF to ensure that the iSFP state remains synchronized.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
|
|
Step 3 |
address-family { ipv4 } [ unicast ] Example:Specifies the IPv4 address family, and enters router address family configuration mode. |
|
Step 4 |
spf-interval {[ initial-wait initial | secondary-wait secondary | maximum-wait maximum ] ...} [ level { 1 | 2 }] Example:(Optional) Controls the minimum time between successive SPF calculations.
|
|
Step 5 |
ispf [ level { 1 | 2 }] Example:(Optional) Configures incremental IS-IS ISPF to calculate network topology. |
|
Step 6 |
commit |
|
Step 7 |
show isis [ instance instance-id ] [[ ipv4 | afi-all ] [ unicast | safi-all ]] spf-log [ level { 1 | 2 }] [ ispf | fspf | prc | nhc ] [ detail | verbose ] [ last number | first number ] Example:(Optional) Displays how often and why the router has run a full SPF calculation. |
This task explains how to perform route functions that include injecting default routes into your IS-IS routing domain and redistributing routes learned in another IS-IS instance. This task is optional.
|
Step 1 |
configure |
||
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing process, and places the router in router configuration mode.
|
||
|
Step 3 |
set-overload-bit [ on-startup { delay | wait-for-bgp }] [ level { 1 | 2 }] Example:(Optional) Sets the overload bit.
|
||
|
Step 4 |
address-family { ipv4 } [ unicast ] Example:Specifies the IPv4 address family, and enters router address family configuration mode. |
||
|
Step 5 |
default-information originate [ route-policy route-policy-name ] Example:(Optional) Injects a default IPv4 route into an IS-IS routing domain.
|
||
|
Step 6 |
redistribute isis instance [ level-1 | level-2 | level-1-2 ] [ metric metric ] [ metric-type { internal | external }] [ policy policy-name ] Example:(Optional) Redistributes routes from one IS-IS instance into another instance.
|
||
|
Step 7 |
Do the following:
Example:or (Optional) Allows a Level 1-2 router to summarize Level 1 IPv4 prefixe at Level 2, instead of advertising the Level 1 prefixes directly when the router advertises the summary.
|
||
|
Step 8 |
maximum-paths route-number Example:(Optional) Configures the maximum number of parallel paths allowed in a routing table. |
||
|
Step 9 |
distance weight [ address / prefix-length [ route-list-name ]] Example:(Optional) Defines the administrative distance assigned to routes discovered by the IS-IS protocol.
|
||
|
Step 10 |
set-attached-bit Example:(Optional) Configures an IS-IS instance with an attached bit in the Level 1 LSP. |
||
|
Step 11 |
commit |
This optional task describes how to associate a tag with a connected route of an IS-IS interface.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing process, and places the router in router configuration mode. In this example, the IS-IS instance is called isp. |
|
Step 3 |
address-family { ipv4 } [ unicast ] Example:Specifies the IPv4 address family, and enters router address family configuration mode. |
|
Step 4 |
metric-style wide [ transition ] [ level { 1 | 2 }] Example:Configures a router to generate and accept only wide link metrics in the Level 1 area. |
|
Step 5 |
exit Example:Exits router address family configuration mode, and returns the router to router configuration mode. |
|
Step 6 |
interface type number Example:Enters interface configuration mode. |
|
Step 7 |
address-family { ipv4 } [ unicast ] Example:Specifies the IPv4 address family, and enters address family configuration mode. |
|
Step 8 |
tag tag Example:Sets the value of the tag to associate with the advertised connected route. |
|
Step 9 |
commit |
|
Step 10 |
show isis [ ipv4 | afi-all ] [ unicast | safi-all ] route [ detail ] Example:Displays tag information. Verify that all tags are present in the RIB. |
This optional task describes how to set the priority (order) for which specified prefixes are added to the RIB. The prefixes can be chosen using an access list (ACL), prefix list, or by matching a tag value.
|
Step 1 |
configure |
|
Step 2 |
router isis instance-id Example:Enables IS-IS routing for the specified routing process, and places the router in router configuration mode. In this example, the IS-IS instance is called isp. |
|
Step 3 |
address-family { ipv4 } [ unicast ] Example:Specifies the IPv4 address family, and enters router address family configuration mode. |
|
Step 4 |
metric-style wide [ transition ] [ level { 1 | 2 }] Example:Configures a router to generate and accept only wide-link metrics in the Level 1 area. |
|
Step 5 |
spf prefix-priority [ level { 1 | 2 }] { critical | high | medium } { access-list-name | tag tag } Example:Installs all routes tagged with the value 3 first. |
|
Step 6 |
commit |
This section provides the following configuration examples:
The following example shows usage of the set- attached-bit and redistribute commands. Two instances, instance “1” restricted to Level 1 and instance “2” restricted to Level 2, are configured.
The Level 1 instance is propagating routes to the Level 2 instance using redistribution. Note that the administrative distance is explicitly configured higher on the Level 2 instance to ensure that Level 1 routes are preferred.
Attached bit is being set for the Level 1 instance since it is redistributing routes into the Level 2 instance. Therefore, instance “1” is a suitable candidate to get from the area to the backbone.
router isis 1
is-type level-2-only
net 49.0001.0001.0001.0001.00
address-family ipv4 unicast
distance 116
redistribute isis 2 level 2
!
interface TenGigE 0/3/0/0
address-family ipv4 unicast
!
!
router isis 2
is-type level-1
net 49.0002.0001.0001.0002.00
address-family ipv4 unicast
set
-attached
!
interface TenGigE 0/1/0/0
address-family ipv4 unicast
The following example shows how to activate IS-IS overload bit avoidance:
RP/0/# config
RP/0/(config)# mpls traffic-eng path-selection ignore overload
The following example shows how to deactivate IS-IS overload bit avoidance:
RP/0/# config
RP/0/(config)# no mpls traffic-eng path-selection ignore overload
The following example shows how to tag routes.
route-policy isis-tag-55
end-policy
!
route-policy isis-tag-555
if destination in (5.5.5.0/24 eq 24) then
set tag 555
pass
else
drop
endif
end-policy
!
router static
address-family ipv4 unicast
0.0.0.0/0 2.6.0.1
5.5.5.0/24 Null0
!
!
router isis uut
net 00.0000.0000.12a5.00
address-family ipv4 unicast
metric-style wide
redistribute static level-1 route-policy isis-tag-555
spf prefix-priority critical tag 13
spf prefix-priority high tag 444
spf prefix-priority medium tag 777
The following example shows how to activate IS-IS overload bit avoidance:
RP/0/# config
RP/0/(config)# mpls traffic-eng path-selection ignore overload
The following example shows how to deactivate IS-IS overload bit avoidance:
RP/0/# config
RP/0/(config)# no mpls traffic-eng path-selection ignore overload
This section describes an example for configuring IS-IS to handle overloading of routers, without setting the overload bit.
When a router is configured with the IS-IS overload bit, it participates in the routing process when the overload bit is set, but does not forward traffic (except for traffic to directly connected interfaces). To configure the overload behavior for IS-IS, without setting the overload bit, configure the max-link-metric statement. By configuring this statement, the router participates in the routing process and is used as a transit node of last resort.
Ensure that you are familiar with configuring router interfaces for a given topology.
|
Step 1 |
Configure Routers A, B, and C as shown in the topology. Use the following IP Addresses:
|
|
Step 2 |
Configure IS-IS and the corresponding net addresses on Routers A, B and C. Example: |
|
Step 3 |
Configure IPv4 address families on the loopback interfaces of Routers A, B, and C. Example: |
|
Step 4 |
Configure the link metrics on the router interfaces. Example: |
|
Step 5 |
Confirm your configuration by viewing the route prefixes on Routers A, B, and C. Example: |
|
Step 6 |
Confirm the link metrics on Router B, prior to configuring the max-link-metric statement. Example: |
|
Step 7 |
Configure the max-link-metric statement on Router B. Example: |
|
Step 8 |
Commit your configuration. Example: |
|
Step 9 |
Confirm the change in link metrics on Router B. Example: |
|
Step 10 |
(Optional) Verify the change in route prefixes on Routers A and C. Example: |
IS-IS has been successfully configured to handle router overload without setting the overload bit.
Feedback