Cisco Network Solutions for the Telco DCN: SONET/SDH OSI Environments
Available Languages
Table Of Contents
Cisco Network Solutions for the Telco DCN: SONET/SDH OSI Environments
Scaling SONET/SDH in the Telco DCN: Overview
OSI as a DCN Transport Mechanism
IP Standards Development for the DCC and the DCN
DCN Design Considerations for OSI
DCN Design with a Classic OSI Implementation
IS-IS Multiarea DCN Architecture with SONET/SDH Deployment in All Central Offices
The Cisco Three-Tiered DCN Network Architecture
Three-Tiered DCN Network Overview
OSI Addressing Issues and Suggestions
SONET/SDH Scaling Issues for Multiple OSI Areas
Defining IS-IS Multiareas with ISL Trunking
Configuring an IS-IS Multiarea Network on a VLAN Using ISL Encapsulation
Designated IS Election Process on a LAN
Verifying an IS-IS Multiarea Network Using VLAN Trunking and ISL Encapsulation
Configuring a Cisco Catalyst 2924XL VLAN Using ISL Encapsulation
Verifying the Cisco Catalyst 2924XL VLAN Configuration Using ISL Encapsulation
Defining IS-IS Multiareas with IEEE 802.1Q Trunking
Configuring an IEEE 802.1Q Trunk Router
Configuring a Cisco Catalyst 2924XL VLAN with IEEE 802.1Q Encapsulation
Verifying a Cisco Catalyst 2924XL VLAN with IEEE 802.1Q Encapsulation
Defining Multiple Areas with Manual Area Addressing
Configuring Manual Area Addressing
Verifying Adjacencies in a Network with Manual Area Addresses
Troubleshooting Adjacencies in a Network with Manual Area Addresses
Using Generic Routing Encapsulation Tunnels to Prevent Area Partitions
IS-IS Attach-Bit Control Feature
Verifying IS-IS Attach-Bit Control
Using IP over CLNS Tunnels to Access Remote Devices
Configuring a Tunnel Using IP over CLNS
Verifying the IP over CLNS Tunnel Configuration
Configuring a Contact Closure Device
Verifying the Contact Closure Device Configuration
Mapping NSAPs to Device Names Using TARP
Using TARP with Remote Login Applications
Controlling TARP Propagation Using Split Horizon
Additional Methods of Controlling the Propagation of TARP Packets
TARP PDU Packet Propagation Control Configuration Commands
Maintaining and Troubleshooting the IS-IS Network
Mapping NSAPs to CLNS Host Names
Using TLV 137 to Correlate Router and Host Names
Displaying IS-IS Network Topology
Verifying IS-IS Adjacency Formation
Verifying IS-IS Network Connectivity Using the ping and traceroute Commands
Troubleshooting Network Connections Using the ping clns Command
Troubleshooting Network Connections Using TARP PDUs
Distribution Layer Configuration
Configuring the Distribution Network
Distribution Network Configuration Example
Core Network Configuration Examples
Configuring the First Core Router
Verifying the First Core Router Configuration
Configuring a Second Core Router
Configuring the ISO IGRP Routing Protocol
Configuring a Third Core Router
Verifying Network Connectivity
Completing the Core Router Configurations
Cisco Network Solutions for the Telco DCN: SONET/SDH OSI Environments
This document is directed to competitive local exchange carriers (CLECs), incumbent local exchange carriers (ILECs), and Post, Telephone and Telegraphs (PTTs), collectively referred to as telcos (short for telephone companies). This document describes Cisco network solutions for transporting data between Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) and the Operations Support System (OSS) in a telco data communications network (DCN).
The DCN transports network management traffic between network elements and their respective OSS, making them a vital link between the service network and the network operations center (NOC). The solutions presented in this document will help telcos connect their SONET/SDH network elements to a router-based network using the Open System Interconnection (OSI) protocol, which simplifies the DCN and reduces equipment costs.
Version History
Contents
The document presents the recommended Cisco architecture for building the OSI network. Several methods for implementing and scaling an OSI network are included with detailed configuration examples. Specific Cisco IOS software features such as Intermediate System-to-Intermediate System (IS-IS) multiareas, VLAN support for International Standards Organization Connectionless Network Service (ISO CLNS), Target Identifier Address Resolution Protocol (TARP), and IS-IS attach bit control are described. These architectures and software features are described in the following main sections:
•
Scaling SONET/SDH in the Telco DCN: Overview
•
•
Prerequisites
The features described in this document are supported on the Cisco Telco and Enterprise feature sets.
Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator at http://www.cisco.com/go/fn.
To access Cisco Feature Navigator, you must have an account on Cisco.com. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register. If you have an account but have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you.
Scaling SONET/SDH in the Telco DCN: Overview
SONET/SDH has become the transport technology of choice for regional Bell operating companies (RBOCs), inter-exchange carriers (IXCs), Post, Telephone, and Telegraph (PTT) organizations, and other carriers to meet the demand for bandwidth and new services. The growth of SONET/SDH and the increasing demands for both existing time-division multiplexing (TDM) and new packet-based data services necessitate better and more scalable DCNs for network operations and management connectivity between network elements and their respective OSSs. As SONET/SDH rings grow in both size and number, the service provider needs to deploy higher bandwidth and more scalable DCN networks to manage SONET/SDH network elements.
RBOCs, Inter-exchange carriers (IXCs), PTTs, and their vendors have worked with standards bodies to define more powerful management networks for SONET/SDH. These standards documents recommend that OSI-based protocols be used by the SONET/SDH network elements' ring network management.
While IP and OSI protocols are being widely adopted and deployed by RBOCs and PTTs within their DCNs, it is not realistic to replace their vast installed infrastructure of overlay networks that support legacy DCN protocols. To streamline operations and stay competitive, telcos must reduce the number of overlay DCNs they currently have deployed to support various legacy protocols. The new DCNs must support both legacy protocols, which will continue to be in use for the foreseeable future, and the new standards-based protocols. The challenge is to provide this support over a common infrastructure and create a seamless network of networks that can manage the network through a single DCN utility. Figure 1 shows a typical DCN network.
Figure 1 Typical DCN Network Elements
Multiple networks are included in the DCN network cloud. The networks serve to connect a mainframe or minicomputer and workstation configured as an OSS at a NOC to a large array of devices and systems referred to as network elements.
Network elements in a DCN include alarm units, telephone switches such as the Lucent 5ESS, SONET/SDH add-drop multiplexers (ADMs) and optical repeaters, voice switches, digital cross-connect systems, Frame Relay or ATM switches, routers, digital subscriber line access multiplexers (DSLAMs), remote access switches, digital loop transmission systems, and so on, that make up the provisioned services infrastructure used to deliver services to customers.
The OSS controls and stores the network management data collected about and from the various network elements.
DCNs are the networks deployed by a telco or service provider that contain all the cabling, network management (NM) stations, switches, network elements and other necessary equipment for delivering and managing services to the service providers' customers (see Figure 1). The DCN is an out-of-band network; that is, it does not transit the same bandwidth segment used by services such as voice and its associated in-band signaling. It does, however, share the same transport equipment and interfaces with switching equipment considered to be the infrastructure of the public switched telephone network (PSTN). This document focuses on a design architecture and Cisco IOS software features for scaling the OSI DCNs.
In addition to the need for scalability, there are other factors driving change in the traditional DCN that is providing operations support for today's TDM-based services.
These factors are:
•
•
•
•
•
OSI as a DCN Transport Mechanism
With the advent of SONET/SDH networks, service providers and their equipment vendors foresaw the need for new, more powerful service delivery support networks to manage today's optical networks. In 1988, the International Telecommunication Union (ITU) adopted the M.30 recommendation, which was revised in 1992 and again in 1996, and today is known as recommendation M.3010, Principles for a Telecommunications Management Network.
Recommendation M.3010 defines the architectural requirements for a Telecommunications Management Network (TMN) to support management network operators in planning, provisioning, installing, maintaining, operating, and administering telecommunications networks and services. Within that document, the ITU describes the DCN, which provides the communications backbone between network elements and OSSs in the PSTN.
Using the DCN concepts outlined in M.3010, in December 1995 Bellcore developed an industry standard for SONET—GR-253-CORE—that includes generic DCN requirements. GR253-CORE has become the standard for DCNs within the United States. These standards recommend that OSI-based protocols be used by the OSSs for SONET/SDH ring network management.
As a result of the GR253 and M.3010 standards, SONET/SDH vendors worldwide use the seven-layer OSI protocol stack for the management of their equipment. One application protocol that rides on Layer 7 of the OSI protocol stack, for example, is Transaction Language 1 (TL1). TL1 provides for the definition of messages and protocols between network elements and management stations, and facilitates the gathering of data from SONET equipment.
As SONET/SDH rings grow in both size and number, telcos must deploy higher bandwidth and more scalable DCN networks to manage SONET/SDH network elements. This growth necessitates a migration of DCNs from X.25 networks running from 9.6 kbps to 56 kbps to intranets running at 1.544 Mbps or higher. Both synchronous and asynchronous interfaces are migrating to Ethernet interfaces running at 10 Mbps on network elements and OSSs.
OSI protocol stacks used in SONET/SDH network elements for management require that the DCN be able to use OSI to route to and from the network element and its associated OSS, in addition to the higher bandwidth requirements. A typical RBOC, for example, may have already deployed several thousand SONET rings and is rapidly adding new rings by the hundreds or thousands annually. This large number of SONET network elements demands a DCN that can scale.
IP Standards Development for the DCC and the DCN
The ITU-T has developed a new standard outlining architecture requirements for IP-only domains, OSI-only domains, and IP and OSI domains titled Architecture and Specification of the Data Communication Network, document number G.7712/Y.1703. Basically, the standard adds IP to the DCN and the data communications channel (DCC) architectures. The premise of the standard is that SONET/SDH network elements will still act as routers to forward management traffic across the DCC. In OSI environments, IS-IS is the routing protocol of choice. In mixed environments, Integrated IS-IS is the routing protocol of choice. In IP-only environments, the routing protocol can be either Open Shortest Path First (OSPF) or Integrated IS-IS. The ITU-T document also describes manual tunneling mechanisms for bridging IP-only or for CLNS-only involvements; however, this document focuses on only OSI solutions for SONET/SDH.
DCN Design Considerations for OSI
The current Bellcore and ITU standards recommend the use of the OSI protocol stack for the management of SONET/SDH network elements. Figure 2 shows the packet flow from the OSS to a SONET network element. The packet leaves the OSS and is routed across the DCN by routers to the gateway network element (GNE). The GNE routes the packet from the Ethernet network onto the SONET DCC. The packet is routed around the ring. The SONET network element is acting as an IS-IS router. The SONET DCC is the physical path. The SONET network element and GNE are IS-IS Level 1 routers. The standalone routers in the DCN perform the IS-IS Level 2 function. Notice that the DCC has become part of the DCN. The performance of the DCN is determined by all of the components.
Figure 2 Packet Flow in a DCN Network
Fundamental issues to address in designing a DCN today are the routing performance of the IS-IS routers and the bandwidth on the DCC. When designing the DCN network, the service provider must take into account the performance characteristic of all the routers, including the routing engine in the network element. Today, the routing engine in the network elements (NEs) can typically support a routing table of only 50 to 100 entries, so this limitation binds the Level 1 area size to 50 to 100 routers. The section DCC is used for management. The bandwidth of the section DCC is 192 KB. The D1 through D3 bytes of the section overhead DCC are used. A packet should not have to make more than seven hops on the DCC to enter the DCN because of bandwidth limitations and the performance of the router in the network element. As the size of the ring approaches 16 nodes, a second GNE must be added to the ring.
The first step for designing a DCN network is to gather information about a particular network environment. The natural geographic groupings of rings should be identified and a breakdown of the average central office size should be computed. This information is required for planning the OSI-based DCN.
Following are the questions that need to be answered before the design process is begun:
•
•
•
•
•
•
•
•
•
•
•
•
DCN Design with a Classic OSI Implementation
This document reviews a classic OSI design, and then reviews an improved design using multiareas. For purpose of example, answers to questions from a hypothetical large-sized service provider network are provided. This information is needed to design a network based on the three-tiered architecture.
•
There are 25,000 SONET/SDH nodes deployed today.
•
There are 4000 SONET/SDH nodes added per year.
•
The Level 1 area size is 50 routers.
•
The domain size is 500 Level 2 routers.
•
The service provider wants to place 30 network elements in an area and leave address space for 20 additional network elements in an area.
•
There are 1700 central offices in the network.
•
Most of the rings have a single GNE. The design will assume a single GNE per ring.
•
Average ring size is ten.
•
A maximum of three SONET/SDH rings will be placed in an area.
•
The large-sized central office will have 36 SONET rings.
•
The medium-sized central office will have ten SONET rings.
•
The small-sized central office will have one SONET ring.
To begin the network design, place the central offices in geographic areas. In this network design, there are five geographic areas. Within each geographic area, the service provider can determine the actual number of large-, medium-, and small-sized central offices. This network design example will use the following rules:
•
•
•
An alternative to estimating the percentage of small-, medium- and large-sized central offices is for the service provider to count the number of central offices. Table 1 lists the central office breakdown by geographic area using the estimated percentages.
Next, determine the number of Level 2 routers required in each geographic area. Today in small-sized central offices, the service provider in the classic implementation of this network design would typically not have any SONET rings. The network design allows for one ring per office eventually, for growth. Because of the performance limitations of the SONET/SDH network elements, the design calls for many small areas. Remember that the network element routing engine can support only 50 entries in its routing table. Each area requires a Level 2 router, so the logical place for the Level 2 function to be performed is on a standalone router in each central office.
Placing the Level 2 function on the GNE will constrain the size of the routing domain because of performance limitations of the IS-IS routing engine in the GNE. The network design calls for every central office to have at least one OSI area. In this network, large-sized central offices have 36 rings, which equates to 12 Level 2 routers. Also remember that the design criteria questions indicated the average ring size to be ten network elements, and that three rings should be placed in an area. This design will leave address space in an area to add network elements when the rings grow. The computation for the network design is as follows:
36 rings ÷ 3 rings per area = 12 Level 1 areas
The 36 SONET rings in a large-sized central office are split among 12 Level 1 areas. For every Level 1 area, a connection to the backbone is made through a standalone Level 1/Level 2 router, so 12 standalone routers are needed.
The medium-sized office has ten SONET/SDH rings per office. The new network design calls for three rings per OSI area. The computation for the network design is as follows:
10 rings ÷ 3 rings per area = 4 Level 1 areas (rounded up)
The small-sized central office has at most one SONET ring and requires one router per central office. Given these design parameters, the number of standalone routers that will be required are listed in Table 2.
To show how the numbers in Table 2 were derived from Table 1, look at Group 1: There are 150 small-sized central offices and one Level 1/Level 2 router per central office. In all, there are 150 Level 2 routers to support small-sized central offices for Group 1, as the following computation indicates:
Group 1 small-sized central offices:
150 small-sized central offices x 1 router per central office = 150 Level 2 routers
There are 75 medium-sized central offices in Group 1. Each medium-sized central office requires four Level 1/Level 2 routers as previously computed, so the total number of Level 1/ Level 2 routers for medium-sized central offices is as defined in the following equation:
Group 1 medium-sized central offices:
75 medium-sized central offices x 4 routers per central office = 300 Level 2 routers
There are 25 large-sized central offices in Group 1. A large-sized central office requires 12 Level 1/Level 2 routers, as computed in the first equation following Table 1. The following computation indicates the total number of Level 1/Level 2 routers required:
Group 1 large-sized central offices:
25 large-sized central offices x 12 routers per central office = 300 Level 2 routers
In Table 2, the number of standalone Level 2 routers is 5,100. The total number of domains for each group was computed as follows: The number of Level 2 routers in a group was divided by the domain size. The domain size was determined by the routing engine performance of the standalone router. In this design, the domain size is 500, and there would be a total of 13 domains for the network.
A number of obvious issues come up with this example: It is necessary to purchase a large number of standalone routers to provide the Level 2 functions. All of the routers must be monitored and maintained by a NOC. A method of routing between OSI domains is required, and either an interdomain routing protocol or static routes must be used.
IS-IS Multiarea DCN Architecture with SONET/SDH Deployment in All Central Offices
Now let us design the network using the Cisco IOS software IS-IS multiarea feature. Service providers deploying SDH rings today typically are managing all of their rings with OSI, and their network design option assumes that at least one OSI area should be supported in every central office, and that a Level 2 router is placed in every central office.
The following are the key assumptions for this network design:
•
There are 25,000 SONET/SDH nodes deployed today.
•
There are 4000 SONET/SDH nodes added per year.
•
The Level 1 area size is 50 routers.
•
The domain size is 500 Level 2 routers.
•
The customer wants to place 30 network elements in an area and leave address space for 20 additional network elements in an area.
•
There are 1700 central offices in the network.
•
Most of the rings have a single GNE.
•
Average ring size is ten.
•
Three SONET/SDH rings per area 3 are required.
•
The large-sized central office will have 36 SONET rings.
•
The medium-sized central office will have ten SONET rings.
•
The small-sized central office will have one SONET ring.
There are five geographic areas, and within each geographic area the actual number of large-, medium-, and small-sized central offices must be determined. The central office size can be allocated as follows: 10 percent large-sized, 30 percent medium-sized, and 60 percent small-sized. Table 1 will be used again to represent the numbers of central offices per geographic area. The number of rings terminating in a differently sized central office can be as follows: A small-sized central office can have 1, a medium-sized central office can have 10, and a large-sized central office can have 36 rings. Small-sized central offices would have one SONET/SDH ring. Each central office will have at least one OSI area.
The next step is to compute the number of Level 2 routers required to implement the design. The design will use Cisco 3621 routers in small-sized central offices, which can support up to twelve Level 1 OSI areas. The assumption is that there will be only one OSI area per small-sized central office, and one Cisco 3621 router will be sufficient per small-sized central office. The Cisco 3631 router has two network modules that can be used for contact closure and serial connectivity.
Next, compute the number of small-sized routers for each group. In Group 1, there are 150 small-sized central offices and there is one Level 1/Level 2 router per central office. There are 150 Level 2 routers to support small-sized central offices for Group 1. The computations follow the totals that are listed in Table 3.
As Table 3 indicates, the number of Level 2 routers has still been substantially reduced over the classic DCN design. Use the following computations to understand how the reductions were made:
Group 1 small-sized central office:
150 small-sized central offices x 1 router per central office = 150 Level 2 routers
Group 2 small-sized central offices:
300 small-sized central offices x 1 router per central office = 300 Level 2 routers
Group 3 small-sized central offices:
120 small-sized central offices x 1 router per central office = 120 Level 2 routers
Group 4 small-sized central offices:
360 small-sized central offices x 1 router per central office = 360 Level 2 routers
Group 5 small-sized central offices:
90 small-sized central offices x 1 router per central office = 90 Level 2 routers
Next, compute the number of routers required for the medium-sized central offices. The network design uses Cisco 3631-DC-central office or Cisco 3662-DC-central office routers. Both of these routers support 12 Level 1 OSI areas with the IS-IS multiarea software. This design calls for ten OSI rings per central office. The original network design called for four Level 1 areas:
10 rings ÷ 3 rings per area = 4 Level 1 areas (rounded up)
One Cisco 3631 or Cisco 3662 router running the IS-IS multiarea software will support a medium-sized central office. The design calls for redundant IS-IS Level 1/Level 2 routers for medium- and large-sized offices. There are 75 medium-sized central offices in Group 1. Each medium-sized central office requires one Level 1/Level 2 router as previously computed, and a second router for backup. The total number of Level 1/ Level 2 routers for medium-sized central offices is as follows (see Table 3):
Group 1 medium-sized central offices:
75 medium-sized central offices x 2 routers per central office = 150 Level 2 routers
Group 2 medium-sized central offices:
150 medium-sized central offices x 2 routers per central office = 300 Level 2 routers
Group 3 medium-sized central offices:
60 medium-sized central offices x 2 routers per central office = 120 Level 2 routers
Group 4 medium-sized central offices:
180 medium-sized central offices x 2 routers per central office = 360 Level 2 routers
Group 5 medium-sized central offices:
45 medium-sized central offices x 2 routers per central office = 90 Level 2 routers
The computation of the large-sized central office numbers for Table 3 is the same process as previously outlined for the medium-sized central offices. (See Table 1 for the number of central offices.) The design uses Cisco 3631-DC-central office or Cisco 3662-DC-central office routers. Both of these routers support 12 Level 1 OSI areas with the IS-IS multiarea software. The design calls for 36 OSI rings per central office, as defined in the original network design computation:
36 rings ÷ 3 rings per area = 12 Level 1 areas
One Cisco 3631 or Cisco 3662 router running the IS-IS multiarea software will support a large-sized central office. The design calls for redundant IS-IS Level 1/Level 2 routers for medium- and large-sized offices. A second router will be placed in every large-sized office. There are 25 large-sized central offices in Group 1. The total number of Level 1/ Level 2 routers for large-sized central offices is as follows:
Group 1 large-sized central offices:
25 large-sized central offices x 2 routers per central office = 50 Level 2 routers.
The following examples show the remainder of the group's computations:
Group 2 large-sized central offices:
50 large-sized central offices x 2 routers per central office = 100 Level 2 routers.
Group 3 large-sized central offices:
20 large-sized central offices x 2 routers per central office = 40 Level 2 routers
Group 4 large-sized central offices:
60 large-sized central offices x 2 routers per central office = 120 Level 2 routers
Group 5 large-sized central offices:
15 large-sized central offices x 2 routers per central office = 30 Level 2 routers
The total number of Level 2 routers is listed in Table 3.
The network is divided into five geographic areas, and each geographic area is a logical grouping of central offices. The logical central office grouping will make up an OSI domain. (In IS-IS, a domain is a logical set of networks, unlike Internet domains that are general groupings of networks based on organization type or geography.) In this design, the performance characteristics of Level 2 routers allow the OSI domain to grow to 500 standalone routers. The domain size assumes that the routers have at least the performance capability of a Cisco 3662 or 3631 router. In Table 3, the number of Level 2 routers in Groups 2 and 4 exceeds 500, so these groups are split into two domains. A domain is made up of standalone access routers and standalone distribution routers; see Figure 3 and the next section.
The Cisco Three-Tiered DCN Network Architecture
Service providers need a basic architecture for the DCN network. The recommended architecture is a three-tiered design. This design is described in the following sections:
•
•
•
Three-Tiered DCN Network Overview
A three-tiered DCN architecture design will ensure manageable and scalable networks with the ability to easily add network equipment with new features and new services as needed. At the core of the DCN are multiprotocol routers capable of transporting IP, OSI, and X.25.
A three-tiered architecture solution as shown in Figure 3 consists of core, distribution, and access elements. A backbone contains routers or WAN switches that form a core or transport utility. Switching centers equipped with distribution routers are located around the backbone to provide symmetric connectivity to central offices. At each central office, access routers provide connectivity into their respective switching and distribution center. Reliability is built into the DCN by designing in redundancy at each tier of the architecture. The access layer defines the DCN interface to the network elements located within the central office. The access routers are configured as Level 1/Level 2. The core and distribution routers are configured as Level 1/Level 2 or Level 2.
Figure 3 DCN Three-Tiered Architecture
The IS-IS routing protocol is run within the OSI domains. Static routes or an interdomain routing protocol can be run between the OSI domains. Cisco recommends running an interdomain routing protocol in the core. Cisco customers have traditionally used ISO-IGRP (the Interior Gateway Routing Protocol developed by Cisco Systems for ISO CLNS) as their interdomain routing protocol. Cisco has developed support for CLNS extensions within multiprotocol Border Gateway Protocol (BGP). The BGP work is based on Internet Engineering Task Force (IETF) RFC 2283. BGP is the mostly widely implemented interdomain routing protocol today.
When implementing the three-tier architecture, it is important to look at the bandwidth of the links and location of the NOC. Typically, the NOC or the data centers with the OSS are built as an additional access site in the architecture. The size of the links to the distribution center may be larger because of the amount of traffic. In the DCN environment, the flow of data is between the OSSs and the network elements, which are downstream from the central office. Typically, very little data is sent between network elements and central offices today, but there are applications that will create more traffic between central offices. These applications include remote login and signaling for bandwidth. Remote login allows a technician logged in to a network element to access another network element over the DCN. The remote login feature saves the technician from needing to be physically at a site to perform maintenance and troubleshooting tasks.
Bandwidth signaling applications are being defined as part of the following standards:
•
•
•
OSI Addressing Issues and Suggestions
In ITU-T Recommendation X.213, Data Networks and Open Systems Communications Open Systems Interconnections Service Definitions, the network layer addressing is described in ANNEX A. The document is also referred to as ISO/IEC 8348:1996(E). Refer to ITU-T Recommendation X.213 for complete details about OSI addressing. This section focuses on basic address information used in the SONET/SDH environments.
The OSI network address is referred to as a network service access point (NSAP). The NSAP is assigned to the end system (ES) or intermediate system (IS) device. Unlike in IP, which has an address for every network interface, the OSI network device receives only one address, the NSAP address. The NSAP address has two parts, the Initial Domain Part (IDP) and Domain Specific Part (DSP), as shown in Figure 4.
Figure 4 NSAP Addresses
The IDP of the NSAP is assigned by address authorities. The address authorities allocate the bytes in the DSP. Six address authorities are currently defined, each briefly described as follows:
•
•
•
•
•
•
The SONET/SDH environments utilize the address authority defined by the ISO DCC. The AFI can have a value of 38 or 39. The value for the IDI is the country code. For the United States, the IDI is 840. The American National Standards Institute (ANSI) is the ISO body in the United States that assigns the 39.840 address space. The DSP addressing is defined in the American National Standard X3.216-1992, Structure and Semantics of the Domain Specific Part of the Network Service Access Point Address.
An ANSI-defined DSP is shown in Figure 5. The DSP is 17 binary octets long. The breakdown of the DSP is listed after the figure; the number of octets is shown under each category.
Figure 5 ANSI DSP Structure
•
•
•
•
•
•
•
•
•
In the Telcordia Specification GR-253-core, in Section 8 of the document, the NSAP address is described with reference to the DCN and SONET network elements. ISO DCC is the selected address format, and the AFI has a decimal value of 39 that is encoded in binary coded decimal. The AFI is configured into Cisco IOS software in decimal format. The AFI is broken down in Figure 6.
Figure 6 AFI Structure
The ISO DCC in this example is for the United States, so the IDI decimal value is 840. The IDP portion of the NSAP is encoded in packed binary coded decimal format. The AFI and a portion of the IDI is shown in Figure 7.
Figure 7 AFI and IDI Structure
Octets
1
1.5
0.5
Decimal
3
9
8
4
0
None
Binary
0011
1001
1000
0100
0000
1111
Cisco IOS entry
3
9
8
4
0
F
The IDI shown in Figure 7 takes up 1.5 octets. The IDI has two octets set aside. The Telcordia GR-253 specification calls for filling the last four bits of the octet with ones. This process is referred to as the IDI PAD. Because there is no decimal value for the binary number 1111 in Binary Coded Decimal (BCD), the number is represented in hexadecimal as an F. The DSP portion of the NSAP is typically configured in hexadecimal. The DFI portion of the DSP has a decimal value of 128, a binary value of 1000 0000, and a hexadecimal value of 80; see Figure 8.
Figure 8 AFI, IDI , and DFI Structure
Octets
1
1.5
0.5
1
Decimal
3
9
8
4
0
None
128
Binary
0011
1001
1000
0100
0000
1111
1000
0000
Cisco IOS entry
3
9
8
4
0
F
8
0
The next portion of the DSP, which is the organizational identifier, is assigned by ANSI. The organization identifier is made up of three octets that are entered into the Cisco IOS software as six hexadecimal characters.
The following example uses an organization identifier of 119999. The NSAP has the following format:
39.840f.80yy.yyyy.rrrr.dddd.aaaa.iiii.iiii.iiiii.ss
and can be interpreted as follows:
•
•
•
•
•
•
Following is an example of the Cisco IOS software commands used to configure the NSAP on a Cisco router:
router isis DCNnet 39.840f.8011.9999.0000.0001.000b.00e0.f725.3338.00OSI Addressing Implementation
This section describes how to implement an addressing plan based on the "OSI Addressing Issues and Suggestions" section. ANSI or the ISO DCC address authority in your geographic area of the world assigns the address space. ANSI can be contacted at http://ansi.org/.
Instructions for applying for a unique organizational identifier are included under the registration services portion of the ANSI website. In this example, the unique organizational identifier is 119999. The next portion of the DSP is marked reserved. The reserved portion of the NSAP is two octets. The NSAP up to this point looks like 39.840f.8011.9999.0000, and the format of the DSP is defined, but the service provider determines the assignment of the address space.
Because the remainder of the DSP is left up to the service provider, let us look at an example. In the example, the routing domain, the area, the individual system identifier, and NSAP selector will be filled out. The example has the following five OSI routing domains—domain 1111, domain 2222, domain 3333, domain 4444, and domain 5555. The first alternative has five OSI domains or routing domains. Each domain is two octets long. The key to laying out the address space is to allow summarization of domains, as follows:
OSI domain 1: 39.840f. 8011.9999.0000.1111
OSI domain 2: 39.840f. 8011.9999.0000.2222
OSI domain 3: 39.840f. 8011.9999.0000.3333
OSI domain 4: 39.840f. 8011.9999.0000.4444
OSI domain 5: 39.840f. 8011.9999.0000.5555
The area addressing can be created by adding the area addresses one at a time within a domain. Therefore, the first area within domain 1111 could be area address 0001, and the NSAP would be as follows:
39.840f.8011.9999.0000.1111.0001
The system identifier uniquely identifies the device within the area. To create this identifier, service providers often use the MAC address of the first Ethernet port on the router, which is displayed by entering the show interface EXEC command on the router (for purpose of example, the MAC address is shown in bold text):
Router# show interface ethernet 0/0Ethernet0/0 is up, line protocol is downHardware is AmdP2, address is 00d0.5872.9720 (bia 00d0.5872.9720)Internet address is 172.168.0.22/24MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,reliability 231/255, txload 1/255, rxload 1/255Encapsulation ARPA, loopback not setKeepalive set (10 sec)ARP type: ARPA, ARP Timeout 04:00:00Last input never, output 00:00:08, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/40 (size/max)5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec0 packets input, 0 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored0 input packets with dribble condition detected12 packets output, 1009 bytes, 0 underruns12 output errors, 0 collisions, 2 interface resets0 babbles, 0 late collision, 0 deferred13 lost carrier, 0 no carrier0 output buffer failures, 0 output buffers swapped outThe following example shows how to use the MAC address 00d0.5872.9720 to create the area identifier:
39.840f.8011.9999.0000.1111.0001.00d0.5872.9720
It is also acceptable to use the IP address in the station identifier. In the following example, the IP address on the Ethernet interface is 172.168.0.22. Some service providers choose to use the IP address on the loopback interface, but for this example the Ethernet interface is used. The 172 portion of the IP address was left out and the remainder of the IP address was imbedded.
39.840f.8011.9999.0000.1111.0001.0168.0000.0022
The following example is another way to use the IP address to create the area address:
39.840f.8011.9999.0000.0001.1721.6800.0022
A final example would be to take the IP address and encode it in hexadecimal format. This action allows the entire IP address to be placed into the end system identifier, but recognizing the IP address is not as straightforward by doing so. The following list shows the loopback address 172.168.0.22 encoded as hexadecimal numbers:
•
•
•
•
Plugging the hexadecimal numbers into the end system identifier would result in the number 39.840f.8011.9999.0000.1111.0001.0000.aca8.0016. Notice that the first two octets of the system identifier are padded with 0s.
Note
Access Layer Configuration
This section focuses on the access layer of Cisco's three-tiered network architecture and contains these sections:
•
•
•
•
•
•
•
•
•
SONET/SDH Scaling Issues for Multiple OSI Areas
All SONET/SDH nodes on a ring are typically Level 1 routers, because of the performance issue described in the "DCN Design Considerations for OSI" section. SONET/SDH nodes on a ring should be in the same OSI area if the nodes are all Level 1. SONET/SDH devices must be organized into many small-sized OSI areas, as described in earlier sections about IS-IS multiarea DCN architecture. The IS-IS multiarea was added to the Cisco IOS feature set to improve the scaling of an IS-IS network in the SONET/SDH environments. The feature allows the configuration of up to 29 Level 1 IS-IS processes on Cisco routers.
Note
The configuration for ISO-IGRP takes two IS-IS processes. You can configure multiple ISO-IGRP processes and each ISO-IGRP process configured uses two IS-IS processes. If you configure two ISO-IGRP processes, then four IS-IS processes would be used. You have the ability to configure 25 IS-IS processes, which is 29 IS-IS processes minus the four IS-IS processes used by the two ISO-IGRP instances.
If you configure the mBGP CLNS process and one ISO-IGRP processes, you can configure 25 IS-IS processes. You start with 29 IS-IS processes and subtract the two IS-IS processes used by the one ISO-IGRP process and subtract the two IS-IS processes used by the mBGP CLNS process.
The number of IS-IS processes supported are specific to a platform, the architecture of the network, and the other tasks being performed on a platform. Specific base guidelines have been released for the Cisco 1800, 2600, and 3600 series platforms, as listed in Table 4.
These numbers assume that the customer is implementing the three-tiered network architecture described in the "The Cisco Three-Tiered DCN Network Architecture" section. A flat network with many IS-IS adjacencies will not perform as well as the tiered network. For example, a poor design builds a Frame Relay cloud that peers all the sites together. As the number of sites in the Frame Relay network increase, the number of IS-IS adjacencies to maintain and the number of CPU cycles would also increase.
The CPU cycles on the router can be affected by other features enabled in the Cisco IOS software. Service providers often perform protocol translation on access routers. The router is translating between a TCP/IP session from the OSS and X.25 to the network element. Each packet is process-switched by the CPU, which affects the amount of CPU cycles available for maintaining IS-IS adjacencies.
Cisco routers are used to interconnect each Level 1 area or ring to the Level 2 backbone. A typical routing engine in a SONET network element can support only a routing table of 50 to 100 entries. This limitation bounds the area size to 50 Level 1 SONET routers. The service provider will need to check with their specific SONET/SDH vendors. Basic network designs were reviewed earlier in this document. Also, some SONET/SDH vendors have limitations on the number of ES adjacencies and Level 1 adjacencies that a GNE can support. The number of adjacencies has been as low as 15 on some SONET/SDH nodes. In early deployments, service providers were running into adjacency problems when implementing Ethernet hubs because they were putting multiple GNEs from different OSI areas on the same Ethernet hub, as shown in Figure 9. The GNEs in the different areas were forming ES adjacencies, which caused performance problems for the GNEs.
Note
Figure 9 GNEs Forming ES Adjacencies
Cisco's solution is shown in Figure 10. Cisco recommends installing an Ethernet switch and separating the GNEs, thereby placing all the GNEs in different OSI areas on a separate VLAN. Figure 10 shows 12 OSI areas that correspond to 12 VLANs.
Figure 10 GNEs Separated by an Ethernet Switch
SONET network elements communicate over a DCC in-band channel in the SONET ring at 192 KB. The in-band channel is used to access SONET nodes on the ring. Typically, there is only one GNE onto smaller rings deployed in a metropolitan setting. The DCC is often used to access the SONET node placed on a customer site or to access an optical amplifier in the fiber. Extending the DCN to these sites would not make sense from an economic or security standpoint. The limited 192 KB bandwidth of the DCC limits the size of the SONET/SDH ring. One method around the DCC bandwidth limitation is to add GNEs to the ring. The GNEs should be separated by four to seven hops. The service provider should consult the GNE vendor.
Defining IS-IS Multiareas with ISL Trunking
This section describes the configuration for an IS-IS multiarea with VLANs using Inter-Switch Link (ISL) trunking (a Cisco-proprietary protocol that maintains VLAN information as traffic flows between switches and routers). Typically, the multiarea feature is used at the access portion of the network. The OSS is located in the data center, and the CLNS packets are routed across the network to the central office router. Figure 11 shows a typical configuration.
Figure 11 IS-IS Multiarea Network Using ISL
Figure 11 shows three IS-IS Level 1 areas. For purpose of example, the areas are small, with only two or three SONET or SDH network elements per area. A more typical area would have 30 to 50 network elements.
This configuration example uses a Cisco 3640 router and a Cisco Catalyst 2924XL switch. The IS-IS multiarea feature supports only one Level 1 or Level 2 IS-IS process per router. The router can be configured for up to 28 independent Level 1 processes and one Level 1/Level 2 process.
The number of IS-IS Level 1 processes supported depends upon the router platform. Each Level 1 IS-IS process must have a unique NSAP within an OSI area. The unique portion of the NSAP is the system identifier. The same unique system identifier must be used when creating multiple NSAPS on the Cisco 3640 router. In this example, the system identifier used is MAC address 0010.7bc7.ae40 from Ethernet port 0/0. See the "OSI Addressing Implementation" section for more information about selecting system identifiers.
The MAC address is listed in the output of the show interface command, as the following example shows (text bolded for purpose of example):
3640A# show interface ethernet0/0Ethernet0/0 is up, line protocol is upHardware is AmdP2, address is 0010.7bc7.ae40 (bia 0010.7bc7.ae40)Internet address is 192.168.0.49/24MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,reliability 255/255, txload 1/255, rxload 1/255Encapsulation ARPA, loopback not setKeepalive set (10 sec)ARP type: ARPA, ARP Timeout 04:00:00Last input 00:00:07, output 00:00:00, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/40 (size/max)5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec4 packets input, 533 bytes, 0 no bufferReceived 3 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored0 input packets with dribble condition detected11 packets output, 786 bytes, 0 underruns0 output errors, 0 collisions, 4 interface resets0 babbles, 0 late collision, 0 deferred0 lost carrier, 0 no carrier0 output buffer failures, 0 output buffers swapped outUsing address examples from the "OSI Addressing Implementation" section, the routing domain number is 1111. The following example configures the access router to handle the following three OSI areas:
39.840f.8011.9999.0000.1111.0001
39.840f.8011.9999.0000.1111.0002
39.840f.8011.9999.0000.1111.0003
The corresponding NSAPs for the Cisco 3640 router are built with a unique system identifier and a network selector value of 00. The network selector for the network layer is 00. The chosen system identifier for this example is the MAC address from Ethernet interface 0/0, so the NSAPs for the Cisco 3640 routers are as follows:
net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00
net 39.840f.8011.9999.0000.1111.0002.0010.7bc7.ae40.00
net 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00
An interface can be associated with only one IS-IS processes. In the first solution that Cisco provided to service providers, a separate Ethernet interface was configured for every IS-IS process and LAN. Each LAN was on a separate hub, as shown in Figure 12.
Figure 12 IS-IS Multiarea Network Using Separate Ethernet Interfaces
The next solution that Cisco provides makes it possible to consolidate the individual hubs into a Cisco Catalyst switch with VLANs. Each VLAN on the Cisco Catalyst switch had a separate Ethernet connection from the router, as shown in Figure 13.
Figure 13 IS-IS Multiarea Network Consolidating Hubs on a Switch (VLAN Trunking)
The number of physical Ethernet interfaces can be reduced by using VLAN trunking. A separate IS-IS process can be assigned to a subinterface. The example in this section focuses on implementing an IS-IS multiarea on an ISL trunk, as shown in Figure 14.
Figure 14 IS-IS Multiarea Network Using VLAN Trunking and ISL Encapsulation
Configuring an IS-IS Multiarea Network on a VLAN Using ISL Encapsulation
This section uses the network shown in Figure 14 as the basis for the configurations. The examples use a Cisco 3640 router with the Telco Feature Set running Cisco IOS Release 12.2(15)T.
Begin by enabling a CLNS routing and enabling TARP (assuming that TARP will be used). TARP is the target identifier (TID) Address Resolution Protocol, which is the name given to a piece of equipment by service providers in the United States. (TARP is an application that automates the mapping of CLNS addresses to TIDs, and will be described in more detail in the "Enabling TARP" section.)
The following example shows how to enable TARP and assign the router a TID using the router's host name; in this example, the assigned TID is 3640A for a Cisco 3640 router:
clns routingtarp runtarp tid 3640ANext, create the IS-IS routing processes for the three areas shown in Figure 14. The first IS-IS routing process created can be a Level 1/Level 2, which is a circuit-type Level 1/Level 2. (Note that the circuit-type Level 1/Level 2 configuration will not show up in the system configuration output because "is-type level-1-2" is the default.) The remaining IS-IS processes will be Level 1, which is specified and identified in the Cisco IOS software as "is-type level-1." After the first Level 1/Level 2 IS-IS process is configured, the remaining processes will automatically be configured by the software as "is-type level-1."
Each IS-IS process has an identifier. In the examples, the IS-IS process identifiers are named after the OSI area. For example, the IS-IS process identifier area0001 is used for area 0001. (Note that the IS-IS process identifier name is arbitrary, but that area names are useful for troubleshooting. The service provider could have named the IS-IS processes after colors, for example.) The system identifier used in the example is the MAC address (0010.7bc7.ae40) from Ethernet port 0/0.
The following example shows how to configure the IS-IS routing processes for the three areas:
router isis area0001net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00!router isis area0002net 39.840f.8011.9999.0000.1111.0002.0010.7bc7.ae40.00is-type level-1!router isis area0003net 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00is-type level-1
The IS-IS process area0001 is specified in the Cisco IOS software with the is-type level-1-2 command, which is the Cisco IOS software default, but no is-type commands will be displayed in the configuration output. The area0001 process will provide connectivity back to the IS-IS backbone. There can be only one Level 2 IS-IS process, and each additional IS-IS process will be at Level 1. Each IS-IS process must be assigned to a separate interface. Fast Ethernet port 3/0 is configured for ISL trunking with three subinterfaces. The encapsulation on the interface is ISL (specified with the encapsulation isl command).
Designated IS Election Process on a LAN
Generally, service providers configure the Cisco access router to be the designated IS on the Ethernet interface. In IS-IS routing, a broadcast medium such as a LAN is not treated as a fully connected topology. Instead, a logical representation of the LAN is created called a pseudonode, which is generated by a Designated Intermediate System (DIS).
The DIS is responsible for creating and updating the pseudonode line-state packet (LSP) and flooding the LSPs over the LAN. On a broadcast medium such as Ethernet, one DIS is selected for Level 1 routers and a separate DIS is selected for Level 2 routers. There is no backup DIS. The election of a DIS can be preempted by a DIS with a higher priority. The routers on the LAN, including the DIS, form an adjacency with the pseudonode. A router elects itself the DIS based on interface priority. The priority range is from 0 (lowest) to 127 (highest). A priority of 64 is the default, and a priority of 127 sets the router to be elected as the DIS. If two routers have the same priority, the router with the highest subnetwork point of attachment (SNPA) wins the election.
The SNPA, which is the MAC address on the LAN or the data-link connection identifier (DLCI) on a Frame Relay network, is also used to configure a CLNS route for an interface. For the configuration example in this section, the SONET network elements are configured as Level 1 IS-IS routers. In real network implementations, service providers have found that forcing the Cisco router to be the DIS works best. Service providers are basically offloading the DIS functions onto the CPU of the standalone Cisco routers, as opposed to a SONET/SDH network element. This configuration is done by setting the IS-IS priority to 127 on the interface. A Level 1 IS-IS pseudonode is selected on each VLAN.
The Cisco router labeled "3640A" in Figure 14 is the DIS for each VLAN, and Fast Ethernet interface 3/0.1 is configured first. In the following example, the interface is configured with ISL encapsulation and VLAN 1 is assigned to the interface. IS-IS process area0001 is assigned to the interface using the clns router isis area0001 command. The assignment of the IS-IS processes to the interfaces is shown in the following example. The IS-IS priority for selecting the DIS is modified to 127, from the default 64, to force the Cisco 3640 router to be the DIS. TARP is enabled on the interface. An IP subnet is assigned to VLAN 1 so that the network administrator can assign an IP address to the Cisco Catalyst 2924XL switch for management of the switch. The following example shows how to configure the Cisco router labeled "3640A" as the DIS for each VLAN. The IS-IS priority is set to 127 on the interface.
interface FastEthernet3/0no ip addressduplex autospeed autono cdp enable!interface FastEthernet3/0.1description IS-IS area 0001encapsulation isl 1ip address 192.168.2.61 255.255.255.192no ip redirectsno cdp enableclns router isis area0001isis priority 127tarp enableFast Ethernet interface 3/0.2 is configured next. In the following example, the interface is configured with ISL encapsulation, and VLAN 2 is assigned to the interface. IS-IS process area0002 is assigned to the interface by the clns router isis area0002 command. The assignment of the IS-IS processes to the interfaces is shown in the following example. The IS-IS priority for selecting the DIS is modified to 127 from the default 64, to force the Cisco 3640 router to be the DIS. TARP is enabled on the interface.
interface FastEthernet3/0.2description IS-IS area 0002encapsulation isl 2no cdp enableclns router isis area0002isis priority 127tarp enableFast Ethernet interface 3/0.3 is the third subinterface to be configured. As with the first two subinterfaces, this interface is configured with ISL encapsulation, and VLAN 3 is assigned to the interface. IS-IS process area0003 is assigned to the interface by the clns router isis area0003 command. The assignment of the IS-IS processes to the interfaces is shown in the following example. The IS-IS priority for selecting the DIS is modified to 127 from the default 64, to force the Cisco 3640 router to be the DIS. TARP is enabled on the interface.
interface FastEthernet3/0.3description IS-IS area 0003encapsulation isl 3no cdp enableclns router isis area0003isis priority 127tarp enable!Verifying an IS-IS Multiarea Network Using VLAN Trunking and ISL Encapsulation
The next step is to verify that CLNS is operating on the router. Use the show clns EXEC command to verify that CLNS is running. The following example shows typical output of the show clns command:
3640A# show clnsGlobal CLNS Information:3 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00NET: 39.840f.8011.9999.0000.1111.0002.0010.7bc7.ae40.00NET: 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area0001Routing for Area: 39.840f.8011.9999.0000.1111.0001IS-IS level-1 Router: area0002Routing for Area: 39.840f.8011.9999.0000.1111.0002IS-IS level-1 Router: area0003Routing for Area: 39.840f.8011.9999.0000.1111.0003The sample output shows that the router has CLNS enabled on three interfaces. The three OSI NSAPs are listed. Notice that the system identifier—0010.7bc7.ae40—is the same for all three NSAPs. The three IS-IS processes are listed with their respective process identifiers—area0001, area0002, and area0003. The routing area assigned to each process is also listed.
The three interfaces running CLNS can be further examined using the show clns interface EXEC command. Sample command output for all three interfaces follows, starting with Fast Ethernet interface 3/0.1:
3640A# show clns interface fastethernet 3/0.1FastEthernet3/0.1 is up, line protocol is upChecksums enabled, MTU 1497, Encapsulation SAPERPDUs enabled, min. interval 10 msec.RDPDUs enabled, min. interval 100 msec., Addr Mask enabled, last sent 00:47:38Congestion Experienced bit set at 4 packetsCLNS fast switching enabledCLNS SSE switching disabledDEC compatibility mode OFF for this interfaceNext ESH/ISH in 23 secondsRouting Protocol: IS-IS (area0001)Circuit Type: level-1-2Interface number 0x0, local circuit ID 0x1Level-1 Metric: 10, Priority: 127, Circuit ID: 3640A.01Level-1 IPv6 Metric: 10Number of active level-1 adjacencies: 2Level-2 Metric: 10, Priority: 127, Circuit ID: 3640A.01Level-2 IPv6 Metric: 10Number of active level-2 adjacencies: 0Next IS-IS LAN Level-1 Hello in 1 secondsNext IS-IS LAN Level-2 Hello in 2 secondsIn this sample output for Fast Ethernet interface 3/0.1, the interface is up and the line protocol is up. Notice that CLNS fast switching is enabled by default. The routing protocol is IS-IS and the associated IS-IS process identifier is area0001. The Circuit Type report indicates whether this circuit is Level 1, Level 2, or Level-1-2. In this case, the circuit type is Level-1-2. The IS-IS priority is 127 on the interface for the Cisco router labeled "3640A." The Cisco 3640 router is the DIS and identified as the DIS in the Circuit ID field. In other words, the circuit identifier lists the designated router's host name or system identifier if the routers do not know the host name. In this case, the designated router's host name is 3640A. Remember that the Cisco 3640 router interface is set to IS-IS priority of 127, which is the highest value. There are two active Level 1 adjacencies. The adjacency numbers correspond to those shown in Figure 14. The Cisco router labeled "3640A" should have a Level 1 adjacency with the SONET/SDH nodes labeled "NE14A" and "NE15A." The Level 2 routing metric is 10 and the IS-IS Level 2 priority is 127. The Circuit ID field lists 3640A as the designated router. There are no Level 2 IS-IS adjacencies on Fast Ethernet interface 3/.01. (Normally, the Level 2 adjacency would come from the WAN connection back to the distribution router, or to a Level 2 adjacency with a second Level-1-2 router in the central office configured for a different OSI area on the Level-1-2 IS-IS process.)
The following example shows sample output for Fast Ethernet interface 3/0.2:
3640A# show clns interface fastethernet 3/0.2FastEthernet3/0.2 is up, line protocol is upChecksums enabled, MTU 1497, Encapsulation SAPERPDUs enabled, min. interval 10 msec.RDPDUs enabled, min. interval 100 msec., Addr Mask enabledCongestion Experienced bit set at 4 packetsCLNS fast switching enabledCLNS SSE switching disabledDEC compatibility mode OFF for this interfaceNext ESH/ISH in 40 secondsRouting Protocol: IS-IS (area0002)Circuit Type: level-1-2Interface number 0x0, local circuit ID 0x1Level-1 Metric: 10, Priority: 127, Circuit ID: 3640A.01Level-1 IPv6 Metric: 10Number of active level-1 adjacencies: 1Next IS-IS LAN Level-1 Hello in 2 secondsThis sample output indicates the second VLAN is configured on Fast Ethernet interface 3/0.2. The interface is up and the line protocol is up. CLNS fast switching is enabled by default. The routing protocol is IS-IS and the associated IS-IS process identifier is area0002. The circuit type is Level-1-2 . Fast Ethernet interface 3/0.2 is a Level 1/Level 2 link. The IS-IS priority is 127 on the interface for the Cisco router labeled "3640A," so 3640A is the DIS and is identified as the DIS in the Circuit ID report. There is one active Level 1 adjacency with SONET/SDH node NE25A.
The following example shows sample output for Fast Ethernet interface 3/0.3:
3640A# show clns interface fastethernet 3/0.3FastEthernet3/0.3 is up, line protocol is upChecksums enabled, MTU 1497, Encapsulation SAPERPDUs enabled, min. interval 10 msec.RDPDUs enabled, min. interval 100 msec., Addr Mask enabledCongestion Experienced bit set at 4 packetsCLNS fast switching enabledCLNS SSE switching disabledDEC compatibility mode OFF for this interfaceNext ESH/ISH in 17 secondsRouting Protocol: IS-IS (area0003)Circuit Type: level-1-2Interface number 0x0, local circuit ID 0x1Level-1 Metric: 10, Priority: 127, Circuit ID: 3640A.01Level-1 IPv6 Metric: 10Number of active level-1 adjacencies: 1Next IS-IS LAN Level-1 Hello in 1 secondsThe third VLAN is configured on Fast Ethernet interface 3/0.3. The interface is up and the line protocol is up. CLNS fast switching is enabled by default. The routing protocol is IS-IS, and the associated IS-IS process is area0003. The circuit type is Level-1-2. The IS-IS priority is 127 on the interface for the Cisco router labeled "3640A," so 3640A is the DIS and is identified as the DIS as part of the Circuit ID report. There is one active Level 1 adjacency with SONET/SDH node NE26A.
The next step is to examine the IS-IS adjacencies. Use the show clns is-neighbor detail EXEC command to see the adjacency to the SONET/SDH node NE14A:
3640A# show clns is-neighbor detailArea area0001:System Id Interface State Type Priority Circuit Id FormatNE15A Fa3/0.1 Up L1 55 3640A.01 Phase VArea Address(es): 39.840f.8011.9999.0000.1111.0001Uptime: 00:04:16NE14A Fa3/0.1 Up L1 64 3640A.01 Phase VArea Address(es): 39.840f.8011.9999.0000.1111.0001Uptime: 00:04:16Area area0002:System Id Interface State Type Priority Circuit Id FormatNE25A Fa3/0.2 Up L1 64 3640A.01 Phase VArea Address(es): 39.840f.8011.9999.0000.1111.0002Uptime: 00:04:17Area area0003:System Id Interface State Type Priority Circuit Id FormatNE26B Fa3/0.3 Up L1 64 3640A.01 Phase VArea Address(es): 39.840f.8011.9999.0000.1111.0003Uptime: 00:04:16In this sample output, the three IS-IS processes running on the Cisco router are listed by process identifier. The IS-IS process identifiers are area0001, area0002, and area0003.
Examining the IS-IS process identifier area0001 in more detail indicates the following:
•
•
•
•
•
•
Configuring a Cisco Catalyst 2924XL VLAN Using ISL Encapsulation
This section reviews configuration for the Cisco Catalyst switch seen in Figure 14. The example configures three VLANs, one VLAN for each OSI area. VLAN 1 is the default. For management of the switch interface, VLAN 1 is defined and assigned an IP address, as shown in the following example:
interface VLAN1ip address 192.168.12.50 255.255.255.0no ip route-cacheIn the following example, Fast Ethernet ports 0/1 through 0/4 and 0/13 through 0/22 are assigned to VLAN 1:
interface FastEthernet0/1!interface FastEthernet0/2!interface FastEthernet0/3!interface FastEthernet0/4!interface FastEthernet0/13!interface FastEthernet0/14!interface FastEthernet0/15!interface FastEthernet0/16!interface FastEthernet0/17!interface FastEthernet0/18!interface FastEthernet0/19!interface FastEthernet0/20!interface FastEthernet0/21!interface FastEthernet0/22!The switch ports are configured as both access and for VLAN 1. VLAN 1 is the default and does not display in the Cisco IOS software configuration file. The OSI area 39.840f.8011.9999.0000.1111.0001 is assigned to IS-IS routers or network elements connected to VLAN 1. Device NE14A in Figure 14 is connected to switch port 0/2. Device NE15A is connected to switch port 0/3.
In the following example, Fast Ethernet ports 0/5 through 0/8 are assigned to VLAN 2:
interface FastEthernet0/5switchport access vlan 2!interface FastEthernet0/6switchport access vlan 2!interface FastEthernet0/7switchport access vlan 2!interface FastEthernet0/8switchport access vlan 2The switch ports are configured as both access and for VLAN 2. The OSI area 39.840f.8011.9999.0000.1111.0002 is assigned to IS-IS routers or network elements connected to VLAN 2. Device NE25A in Figure 14 is connected to switch port 0/5.
In the following example, Fast Ethernet ports 0/9 through 0/12 are assigned to VLAN 3:
!interface FastEthernet0/9switchport access vlan 3!interface FastEthernet0/10switchport access vlan 3!interface FastEthernet0/11switchport access vlan 3!interface FastEthernet0/12switchport access vlan 3!The switch ports are configured as both access and for VLAN 3. The OSI area 39.840f.8011.9999.0000.1111.0003 is assigned to IS-IS routers or network elements connected to VLAN 3. Device NE26A in Figure 14 is connected to switch port 0/10.
In the following example, switch ports 0/23 and 0/24 are configured as trunks with ISL encapsulation. The Cisco IOS software default trunk encapsulation type is ISL.
interface FastEthernet0/23switchport mode trunk!interface FastEthernet0/24switchport mode trunkVerifying the Cisco Catalyst 2924XL VLAN Configuration Using ISL Encapsulation
To verify port assignment to the VLANs, use the show vlan brief EXEC command:
Router-2924XL# show vlan briefVLAN Name Status Ports---- -------------------------------- --------- -------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4,Fa0/13, Fa0/14, Fa0/15, Fa0/16,Fa0/17, Fa0/18, Fa0/19, Fa0/20,Fa0/21, Fa0/222 VLAN0002 active Fa0/5, Fa0/6, Fa0/7, Fa0/83 VLAN0003 active Fa0/9, Fa0/10, Fa0/11, Fa0/121002 fddi-default active1003 token-ring-default active1004 fddinet-default active1005 trnet-default activeStatus of a specific port such as the device NE14A connection can be verified using the show interface EXEC command:
Router-2924XL# show interface fastethernet 0/3FastEthernet0/3 is up, line protocol is upHardware is Fast Ethernet, address is 00d0.796c.acc3 (bia 00d0.796c.acc3)MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255Encapsulation ARPA, loopback not set, keepalive not setFull-duplex, 100Mb/s, 100BaseTX/FXARP type: ARPA, ARP Timeout 04:00:00Last input never, output 00:00:00, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 2000 bits/sec, 0 packets/sec5 minute output rate 7000 bits/sec, 2 packets/sec2186 packets input, 1256415 bytes, 0 no bufferReceived 1535 broadcasts, 0 runts, 0 giants, 0 throttles105 input errors, 105 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort0 watchdog, 1528 multicast0 input packets with dribble condition detected12421 packets output, 5859914 bytes, 0 underruns0 output errors, 0 collisions, 1 interface resets0 babbles, 0 late collision, 0 deferred0 lost carrier, 0 no carrier0 output buffer failures, 0 output buffers swapped outDefining IS-IS Multiareas with IEEE 802.1Q Trunking
This section describes the requirements for implementing an IS-IS multiarea using IEEE 802.1Q encapsulation, instead of the ISL encapsulation used in the "Defining IS-IS Multiareas with ISL Trunking" section. In this configuration, which is shown in Figure 15, the network is basically the same as that used in the ISL example—the OSS is located in the data center and the CLNS packets are routed across the network to the central office router. The difference is that IEEE 802.1Q encapsulation will be used for the VLAN trunks.
Figure 15 IS-IS Multiarea Network with an IEEE 802.1Q Trunk
Figure 16 shows three IS-IS Level 1 areas. For the purpose of example, the areas are small, with only two or three SONET/SDH network elements per area. A typical area would have 30 to 50 network elements. This configuration is done using a Cisco 3640 router and Cisco Catalyst 2924XL switch.
Figure 16 IS-IS Multiarea Network Using VLAN Trunking and IEEE 802.1Q Encapsulation
Configuring an IEEE 802.1Q Trunk Router
The following configuration shows the IEEE 802.1Q encapsulation changes on the Cisco router interfaces. The configuration is the same as that seen in the "Configuring an IS-IS Multiarea Network on a VLAN Using ISL Encapsulation" section except for the encapsulation scheme. The encapsulation dot1q command is used on the three subinterfaces, which enables IEEE 802.1Q encapsulation.
interface FastEthernet3/0.1description IS-IS area 0001encapsulation dot1Q 1 nativeip address 192.168.12.24 255.255.255.0no ip redirectsno cdp enableclns router isis area0001isis priority 127tarp enable!interface FastEthernet3/0.2description IS-IS area 0002encapsulation dot1Q 2no ip redirectsno cdp enableclns router isis area0002isis priority 127tarp enable!interface FastEthernet3/0.3description IS-IS area 0003encapsulation dot1Q 3no ip redirectsno cdp enableclns router isis area0003isis priority 127tarp enableConfiguring a Cisco Catalyst 2924XL VLAN with IEEE 802.1Q Encapsulation
This section describes the changes required for the Cisco Catalyst switch configuration using the ISL implementation shown in Figure 14, to using the IEEE 802.1Q implementation shown in Figure 15. The configuration is the same as that in the "Configuring a Cisco Catalyst 2924XL VLAN Using ISL Encapsulation" section except for the VLAN encapsulation scheme. The VLAN trunking encapsulation changes from ISL to IEEE 802.1Q encapsulation. Fast Ethernet port 0/23 is set up as the switch trunk port in both examples. In the following example, the switchport trunk encapsulation dot1q command is used on the switch port trunk, which enables IEEE 802.1Q encapsulation:
interface FastEthernet0/23switchport trunk encapsulation dot1qswitchport mode trunk!interface FastEthernet0/24switchport trunk encapsulation dot1qswitchport mode trunkVerifying a Cisco Catalyst 2924XL VLAN with IEEE 802.1Q Encapsulation
To verify port assignments of the VLANs, use the show vlan brief EXEC command:
Router# show vlan briefVLAN Name Status Ports---- -------------------------------- --------- -------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4,Fa0/13, Fa0/14, Fa0/15, Fa0/16,Fa0/17, Fa0/18, Fa0/19, Fa0/20,Fa0/21, Fa0/222 VLAN0002 active Fa0/5, Fa0/6, Fa0/7, Fa0/83 VLAN0003 active Fa0/9, Fa0/10, Fa0/11, Fa0/121002 fddi-default active1003 token-ring-default active1004 fddinet-default active1005 trnet-default activeStatus of a specific port, such as the device NE14A connection, can be verified using the show interface EXEC command:
Router# show interface fastethernet 0/10FastEthernet0/10 is up, line protocol is upHardware is Fast Ethernet, address is 00d0.796c.accb (bia 00d0.796c.accb)MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255Encapsulation ARPA, loopback not set, keepalive not setHalf-duplex, 10Mb/s, 100BaseTX/FXARP type: ARPA, ARP Timeout 04:00:00Last input never, output 00:00:00, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/40, 0 drops; input queue 0/75, 0 drops5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 1 packets/sec1 packets input, 64 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort0 watchdog, 0 multicast0 input packets with dribble condition detected72 packets output, 4039 bytes, 0 underruns0 output errors, 0 collisions, 1 interface resets0 babbles, 0 late collision, 0 deferred0 lost carrier, 0 no carrier0 output buffer failures, 0 output buffers swapped outDefining Multiple Areas with Manual Area Addressing
The designers of the ISO IS-IS protocol realized that there would be situations when the network would need to be readdressed. A provision was made in ISO 10589 to allow multiple area addresses to be associated with one area. ISO 10589 defines a management parameter for manual area addresses. A manual area address parameter is set in each IS-IS router that contains a list of all of the area addresses. The list of area addresses is distributed in the Level 1 LSP. The area comprises the union of all of the area addresses advertised, and the Level 2 router creates a composite list. All of the IS-IS routers, according to ISO 10589, must support at least three area addresses within an area. Two IS-IS routers must have at least one area address in common for an adjacency to be formed.
Originally, the Cisco IOS software supported only three area addresses within an area. Cisco changed this limit to support a minimum of three and a maximum of 254 addresses. The change was made to accommodate the SONET/SDH environment.
Caution
Service providers have used manual area addressing as a tool to expand their networks without readdressing the network. Manual area addressing was used before the IS-IS multiarea feature was available. Incumbent local exchange carriers (ILECs) and PTTs typically deploy large numbers of small-sized SONET/SDH rings or chains. The rings and chains grow over time. Service providers did not want to readdress the network as it grew in size, so they would split the rings into groups and assign an area address. As SONET/SDH nodes were added to the rings or chains in the group, the overall area grew in size. The number of Level 1 IS-IS routers also grew. Eventually, the area size needed to be split. When a new standalone router was added to the area, one of the groups was migrated to the new router, and the NET was removed from the old group. This technique is used less frequently since the introduction of the IS-IS multiarea feature.
The configuration to add the manual area addressing is based on the network shown in Figure 17. NETs will be added to IS-IS process area 0001.
Figure 17 Sample Network for Configuring Manual Area Addresses
The following example shows the configuration before manual area addresses are added:
router isis area0001net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00Configuring Manual Area Addressing
This section shows how to configure manual area addresses using the max-area-addresses router configuration command. The default value for this command is three addresses (which will not appear in router configurations).
The following example shows how to change the maximum number of manual area addresses to four, and configure four corresponding NETs:
3640A(config)# router isis area00013640A(config-router)# max-area-addresses 43640A(config-router)# net 39.840f.8011.9999.0000.1111.0004.0010.7bc7.ae40.003640A(config-router)# net 39.840f.8011.9999.0000.1111.0005.0010.7bc7.ae40.003640A(config-router)# net 39.840f.8011.9999.0000.1111.0006.0010.7bc7.ae40.003640A(config-router)# net 39.840f.8011.9999.0000.1111.0007.0010.7bc7.ae40.00%The maximum allowed addresses already configuredThe IS-IS router configured for manual area addressing with multiple areas will have multiple NETs associated with one IS-IS process. There will still be one IS-IS process and one IS-IS area.
Note
The following example displays the new IS-IS portion of the configuration. Under IS-IS process area0001, there are now four NET statements; one area will advertise the multiple NETs.
router isis area0001max-area-addresses 4net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00net 39.840f.8011.9999.0000.1111.0004.0010.7bc7.ae40.00net 39.840f.8011.9999.0000.1111.0005.0010.7bc7.ae40.00net 39.840f.8011.9999.0000.1111.0006.0010.7bc7.ae40.00!router isis area0002net 39.840f.8011.9999.0000.1111.0002.0010.7bc7.ae40.00is-type level-1!router isis area0003net 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00is-type level-1Use the show clns EXEC command to display all the NETs that are configured:
3640A# show clnsGlobal CLNS Information:3 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00NET: 39.840f.8011.9999.0000.1111.0004.0010.7bc7.ae40.00NET: 39.840f.8011.9999.0000.1111.0005.0010.7bc7.ae40.00NET: 39.840f.8011.9999.0000.1111.0006.0010.7bc7.ae40.00NET: 39.840f.8011.9999.0000.1111.0002.0010.7bc7.ae40.00NET: 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area0001Routing for Area: 39.840f.8011.9999.0000.1111.0001IS-IS level-1 Router: area0002Routing for Area: 39.840f.8011.9999.0000.1111.0002IS-IS level-1 Router: area0003Routing for Area: 39.840f.8011.9999.0000.1111.0003The show clns protocol EXEC command provides useful information about the manual area addresses configured. The following example displays the system identifier and the IS type as Level-1-2. There are four manual area addresses and four areas are listed. This example displays one area, but all area addresses would be advertised. An adjacent host still needs to be configured for the same number of manual area addresses and matching NETs to form balanced adjacencies.
3640A# show clns protocolIS-IS Router: area0001System Id: 0010.7BC7.AE40.00 IS-Type: level-1-2Maximum nr of area adresses in this area is 4Manual area address(es):39.840f.8011.9999.0000.1111.000139.840f.8011.9999.0000.1111.000439.840f.8011.9999.0000.1111.000539.840f.8011.9999.0000.1111.0006Routing for area address(es):39.840f.8011.9999.0000.1111.000139.840f.8011.9999.0000.1111.000439.840f.8011.9999.0000.1111.000539.840f.8011.9999.0000.1111.0006Interfaces supported by IS-IS:FastEthernet3/0.1 - OSIRedistribute:static (on by default)Distance for L2 CLNS routes: 110RRR level: noneGenerate narrow metrics: level-1-2Accept narrow metrics: level-1-2Generate wide metrics: noneAccept wide metrics: noneIS-IS Router: area0002System Id: 0010.7BC7.AE40.00 IS-Type: level-1Manual area address(es):39.840f.8011.9999.0000.1111.0002Routing for area address(es):39.840f.8011.9999.0000.1111.0002Interfaces supported by IS-IS:FastEthernet3/0.2 - OSIRedistribute:static (on by default)Distance for L2 CLNS routes: 110RRR level: noneGenerate narrow metrics: level-1-2Accept narrow metrics: level-1-2Generate wide metrics: noneAccept wide metrics: noneIS-IS Router: area0003System Id: 0010.7BC7.AE40.00 IS-Type: level-1Manual area address(es):39.840f.8011.9999.0000.1111.0003Routing for area address(es):39.840f.8011.9999.0000.1111.0003Interfaces supported by IS-IS:FastEthernet3/0.3 - OSIRedistribute:static (on by default)Distance for L2 CLNS routes: 110RRR level: noneGenerate narrow metrics: level-1-2Accept narrow metrics: level-1-2Generate wide metrics: noneAccept wide metrics: noneVerifying Adjacencies in a Network with Manual Area Addresses
Use the show clns neighbors EXEC command to verify that adjacencies are being formed. The following example indicates that an adjacency is up for IS-IS process area0001. The adjacency type is IS but the protocol is End System-Intermediate System (ES-IS) (see bold text), so an IS-IS adjacency is not being formed for IS-IS process area0001:
3640A# show clns neighborsArea area0001:System Id Interface SNPA State Holdtime Type ProtocolNE15A Fa3/0.1 0010.7bd8.c7d0 Up 263 IS ES-ISNE14A Fa3/0.1 00e0.b064.4325 Up 293 IS ES-ISArea area0002:System Id Interface SNPA State Holdtime Type ProtocolNE25A Fa3/0.2 00e0.b064.434e Up 22 L1 IS-ISArea area0003:System Id Interface SNPA State Holdtime Type ProtocolNE26A Fa3/0.3 00d0.5872.9720 Up 28 L1 IS-ISTroubleshooting Adjacencies in a Network with Manual Area Addresses
Use the debug isis adj-packets command to debug IS-IS adjacency packets. In the following example, an IS-IS Hello (IIH) message comes in on Fast Ethernet interface 3/0.1 and causes a maximum area address mismatch error report to be displayed. (In the following output, text is in bold for purpose of example.) The network element with MAC address 00e0.b064.4325, which is device NE14A, is sending an IIH. The IIH has a different number of maximum area addresses than router 3640A. The number of maximum area addresses needs to be changed to match router 3640A. The change also needs to be made to device NE15A.
3640A# debug isis adj-packetsIS-IS Adjacency related packets debugging is on3640A#00:45:07: ISIS-Adj (area0001): Rec L1 IIH from 00e0.b064.4325 (FastEthernet3/0.1), cir type L1, cir id 00E0.B064.4324.02, length 14700:45:07: ISIS-Adj (area0001): Max-area-addresses mismatch, in L1 IIH from FastEthernet3/0.1In the network configuration, the maximum number of manual area addresses has been changed to four on devices NE14A, NE14B, and NE15A. The show clns neighbors command now indicates that the adjacency is up and the protocol being used is IS-IS:
3640A# show clns neighborsArea area0001:System Id Interface SNPA State Holdtime Type ProtocolNE15A Fa3/0.1 0010.7bd8.c7d0 Up 27 L1 IS-ISNE14A Fa3/0.1 00e0.b064.4325 Up 24 L1 IS-ISArea area0002:System Id Interface SNPA State Holdtime Type ProtocolNE25A Fa3/0.2 00e0.b064.434e Up 22 L1 IS-ISArea area0003:System Id Interface SNPA State Holdtime Type ProtocolNE26A Fa3/0.3 00d0.5872.9720 Up 23 L1 IS-ISUsing Generic Routing Encapsulation Tunnels to Prevent Area Partitions
A GNE provides a gateway between the DCN LAN and the SONET DCC. The DCC is the embedded operations channel. There are two DCCs in the SONET/SDH frame: the section DCC and the line DCC. The section DCC is embedded in the section overhead and is made up of three bytes that create a 192-kbps data path. The section DCC has been standardized in TMN for management of the downstream SONET network elements. The line DCC is made up of nine bytes that create a 576-kbps data channel. The standards have carved out the bandwidth in the line DCC, but the TMN standards do not define use of the line DCC. Therefore, vendors have implemented proprietary uses for the line DCC.
Figure 18 shows the flow of CLNS packets across the network. For a CLNS packet to move from the OSS to device NE3, the packet must be routed across the DCN to the LAN in central office Router A or Router B. For purpose of example, assume that the packet arrives at the LAN in central office Router A. Device GNE 1 routes the packet from the LAN to the DCC and forward the packet across the section DCC to device NE2. Device NE2 forwards the packet across the section DCC to device NE3. The action of routing packets between the DCN and the section DCC is the definition of a GNE.
Figure 18 Typical GNE Configuration
The service provider will typically implement one GNE per SONET/SDH ring on small-sized rings. The definition of small is typically six network elements or fewer. ILECs and PTTs typically have many small-sized rings or chains to extend services out from the central office to businesses. The service provider will build large collector rings to aggregate bandwidth from the small-sized rings. The larger rings typically have multiple GNEs to add redundancy to ring access, as shown in Figure 18. This section describes generic routing encapsulation (GRE) tunnels and the IS-IS default Originate features, both of which can be used to improve redundancy.
CLNS over GRE Tunnels
Traditionally the SONET/SDH technology is deployed in ring topologies for redundancy. In the event of a fiber cut (see Figure 19), the ring will wrap and the traffic will be either path switched or line switched onto the protected portion of the fiber. The DCC will be preserved as well.
There are times when it may be necessary to deploy fiber-optic cable in a long chain without the geographic diversity shown in Figure 19.
Figure 19 GRE Tunnel over CLNS with Cut Fiber Link
If the fiber gets cut, the OSI area will become partitioned and the OSS will not be able to communicate with some of the network elements.
One solution to the partitioned Level 1 area is to build a GRE tunnel between the Cisco routers for CLNS. The GRE tunnel will pass the IS-IS traffic between the partitioned parts of the network, as shown in Figure 19.
Configuring a GRE Tunnel
This section describes a sample GRE configuration. The sample network is shown in Figure 20 and depicts the following scenario: Router 3640A is in central office A and router 2600D is in central office D. The two central offices have a SONET/SDH chain running between them. The SONET/SDH network elements are all Level 1 routers. Network elements NE14A and NE25A are both GNEs to the SONET/SDH chain, which is in area 00001. The routers 3640A and 2600D are both Level 1/Level 2 access routers. A fiber cut between the network elements would partition area 0001.
Figure 20 Typical Network Before GRE Tunnel Configuration
The configuration builds a GRE tunnel between router 3640A and router 2600D. The GRE tunnel and the IP addresses that are used in the tunnel are shown in Figure 21.
Figure 21 GRE Tunnel Configuration
The following configuration example for the GRE tunnel shows that the router labeled 2600D in Figure 21 is configured for IS-IS routing in area 0001:
router isis area0001net 39.840f.8011.9999.0000.1111.0001.00e0.1ee3.c720.00Router 2600D is connected to the SONET/SDH device NE25A over Ethernet interface 0/0:
interface Ethernet0/0ip address 192.168.5.189 255.255.255.192half-duplexclns router isis area0001A loopback interface has been created for the GRE tunnel to terminate on router 2600D:
interface Loopback0ip address 192.168.5.252 255.255.255.192The source of the GRE tunnel on router 2600D is the loopback address 192.168.5.252. The tunnel destination is the loopback IP address 192.168.14.252 on the router labeled 3640A in Figure 21. The routing metric assigned to the GRE tunnel is 30. Some service providers prefer to use the tunnel only in the event of an outage. IS-IS routing for CLNS has been turned up on the tunnel. The IS-IS metric can range from 1 to 63, with 63 being the worst route. The GRE keepalive feature is implemented in the example. The keepalive feature will take down the GRE tunnel interface if the far end of the tunnel becomes unavailable. See the following example:
interface Tunnel1no ip addresskeepalive 3 3clns router isis area0001isis metric 30tunnel source 192.168.5.252tunnel destination 192.168.14.252tarp enableThe following example shows how to configure router 3640A for IS-IS routing in area 0001:
router isis area0001net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00In the following example, router 3640A is connected to SONET/SDH device NE14A over Fast Ethernet interface 3/0.1:
interface FastEthernet3/0.1description ISIS area 0001encapsulation dot1Q 1 nativeip address 192.168.12.24 255.255.255.0no ip redirectsno cdp enableclns router isis area0001isis priority 127tarp enableThe following example creates a loopback interface for the GRE tunnel to terminate on router 3640A:
interface Loopback0ip address 192.168.14.252 255.255.255.192The source of the GRE tunnel on router 3640A is the loopback 0 IP address 192.168.14.252. The tunnel destination is loopback IP address 192.168.5.252 on router 2600D. The routing metric assigned to the GRE tunnel is 30. The GRE keepalive feature is implemented. See the following example:
interface Tunnel1no ip addresskeepalive 3 3clns router isis area0001isis metric 30tunnel source 192.168.5.252tunnel destination 192.168.14.252tarp enable
Note
The status of the tunnel can be examined with the show interface command. In the following example, tunnel 1 is up and line protocol is up. The keepalive option is set to send keepalives every 3 seconds, and set to retry three times before marking the interface line protocol down.
3640A# show interface tunnel 1Tunnel1 is up, line protocol is upHardware is TunnelMTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,reliability 255/255, txload 28/255, rxload 28/255Encapsulation TUNNEL, loopback not setKeepalive set (3 sec), retries 3Tunnel source 192.168.14.252, destination 192.168.5.252Tunnel protocol/transport GRE/IP, key disabled, sequencing disabledTunnel TTL 255Checksumming of packets disabled, fast tunneling enabledLast input 00:00:07, output 00:00:00, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 29Queueing strategy: fifoOutput queue: 0/0 (size/max)5 minute input rate 1000 bits/sec, 0 packets/sec5 minute output rate 1000 bits/sec, 0 packets/sec1767 packets input, 705632 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort1945 packets output, 712879 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets0 output buffer failures, 0 output buffers swapped outUse the debug tunnel command to debug the tunnel. The following example shows the debug tunnel command output:
3640A# debug tunnelTunnel Interface debugging is on3640A#01:11:24: Tunnel1: GRE/IP to decaps 192.168.5.252->192.168.14.252 (len=1537 ttl=253)01:11:24: Tunnel1: GRE decapsulated CLNS packet01:11:24: Tunnel1: GRE/IP encapsulated 192.168.14.252->192.168.5.252 (linktype=7, len=48)01:11:24: Tunnel1: GRE/IP to decaps 192.168.5.252->192.168.14.252 (len=24 ttl=252)01:11:25: Tunnel1: GRE/IP encapsulated 192.168.14.252->192.168.5.252 (linktype=25, len=1537)01:11:27: Tunnel1: GRE/IP encapsulated 192.168.14.252->192.168.5.252 (linktype=7, len=48)01:11:27: Tunnel1: GRE/IP to decaps 192.168.5.252->192.168.14.252 (len=24 ttl=252)01:11:30: Tunnel1: GRE/IP encapsulated 192.168.14.252->192.168.5.252 (linktype=7, len=48)01:11:30: Tunnel1: GRE/IP to decaps 192.168.5.252->192.168.14.252 (len=24 ttl=252)01:11:31: Tunnel1: GRE/IP to decaps 192.168.5.252->192.168.14.252 (len=1537 ttl=253)01:11:31: Tunnel1: GRE decapsulated CLNS packetUse the debug tunnel keepalive command to debug the tunnel keepalive. In the following example, notice that the keepalive packets are being sent every 3 seconds:
3640A# debug tunnel keepaliveTunnel keepalive debugging is on3640A#01:12:27: Tunnel1: sending keepalive, 192.168.5.252->192.168.14.252 (len=24 ttl=255), counter=101:12:27: Tunnel1: keepalive received, 192.168.5.252->192.168.14.252 (len=24 ttl=252), resetting counter01:12:30: Tunnel1: sending keepalive, 192.168.5.252->192.168.14.252 (len=24 ttl=255), counter=101:12:30: Tunnel1: keepalive received, 192.168.5.252->192.168.14.252 (len=24 ttl=252), resetting counter01:12:33: Tunnel1: sending keepalive, 192.168.5.252->192.168.14.252 (len=24 ttl=255), counter=101:12:33: Tunnel1: keepalive received, 192.168.5.252->192.168.14.252 (len=24 ttl=252), resetting counter01:12:36: Tunnel1: sending keepalive, 192.168.5.252->192.168.14.252 (len=24 ttl=255), counter=101:12:36: Tunnel1: keepalive received, 192.168.5.252->192.168.14.252 (len=24 ttl=252), resetting counter01:12:39: Tunnel1: sending keepalive, 192.168.5.252->192.168.14.252 (len=24 ttl=255), counter=101:12:39: Tunnel1: keepalive received, 192.168.5.252->192.168.14.252 (len=24 ttl=252), resetting counter01:12:42: Tunnel1: sending keepalive, 192.168.5.252->192.168.14.252 (len=24 ttl=255), counter=101:12:42: Tunnel1: keepalive received, 192.168.5.252->192.168.14.252 (len=24 ttl=252), resetting counter01:12:45: Tunnel1: sending keepalive, 192.168.5.252->192.168.14.252 (len=24 ttl=255), counter=101:12:45: Tunnel1: keepalive received, 192.168.5.252->192.168.14.252 (len=24 ttl=252), resetting counterThe next step is to look at the IS-IS topology after breaking the link between SONET/SDH nodes. The following example shows the IS-IS topology with the GRE tunnel up and the SONET/SDH chain in place:
3640A# show isis topologyArea area0001:IS-IS IP paths to level-1 routersSystem Id Metric Next-Hop Interface SNPA3640A --NE15A 30 NE14A Fa3/0.1 00e0.b064.4325NE25B 40 NE14A Fa3/0.1 00e0.b064.4325NE14B 20 NE14A Fa3/0.1 00e0.b064.43252600D 30 2600D Tu1 *Tunnel*NE14A 10 NE14A Fa3/0.1 00e0.b064.4325NE25A 40 2600D Tu1 *Tunnel*IS-IS IP paths to level-2 routersSystem Id Metric Next-Hop Interface SNPA3640A --2600D 30 2600D Tu1 *Tunnel*All of the network elements can be reached within the area from router 3640A, even though the IS-IS metric was raised to 30 on the tunnel. The tunnel is still the preferred path to router 2600D and network element device NE25A. The traffic could be forced out of the tunnel and onto the SONET/SDH DCC by raising the IS-IS metric.
The next part of this example breaks the connection between devices NE14B and NE15A, as shown in Figure 22. The example after the figure displays the new IS-IS topology after the connection break. All of the network elements and routers are still listed, and the connection to devices NE15A and NE25B has moved to the tunnel.
Figure 22 GRE Tunnel with Broken Connection
3640A# show isis topologyArea area0001:IS-IS IP paths to level-1 routersSystem Id Metric Next-Hop Interface SNPA3640A --NE15A 60 2600D Tu1 *Tunnel*NE25B 50 2600D Tu1 *Tunnel*NE14B 20 NE14A Fa3/0.1 00e0.b064.43252600D 30 2600D Tu1 *Tunnel*NE14A 10 NE14A Fa3/0.1 00e0.b064.4325NE25A 40 2600D Tu1 *Tunnel*Without the tunnel connection, routers 3640A and 2600D would not be able to see the entire IS-IS area 0001. Devices may not be able to communicate, depending upon where the devices sit in the network. The loss of connectivity can be demonstrated by shutting down the tunnel interface.
The following example displays the new IS-IS topology and indicates that packets reaching router 3640A from the network cloud could be forwarded only to devices NE14A and NE14B.
3640A# show isis topologyArea area0001:IS-IS IP paths to level-1 routersSystem Id Metric Next-Hop Interface SNPA3640A --NE15A **NE25B **NE14B 20 NE14A Fa3/0.1 00e0.b064.43252600D **NE14A 10 NE14A Fa3/0.1 00e0.b064.4325NE25A **IS-IS Attach-Bit Control Feature
Routing traffic between Level 1 areas is done by Level 2 routers. Level 1 routers forward the packets to their nearest Level 1/Level 2 router. Typically located at the access layer of the network, the Level 1/Level 2 routers are standalone Cisco routers, and Level 1 routers are SONET/SDH network elements.
The Level 1/Level 2 Cisco router identifies itself by setting the attach-bit in the link-state packets (LSPs). Often service providers have more than one Level 1/Level 2 router per area for redundancy. On large rings, there may be multiple GNEs with access to separate Level 1/Level 2 routers. A Level 1/Level 2 router can lose connectivity to the area with the OSS or the network backbone. If a Level 1/Level 2 Cisco router is configured for IS-IS multiarea, the Level 1/Level 2 router will set the attach bit. If there are multiple Level 1/ Level 2 routers in the same central office networked to share the WAN link, these two routers would form a Level 2 adjacency. The Level 2 attach bit would be set. In either case, the central office Level 1/Level 2 routers will not have access to the OSS systems in the NOC if the WAN link is down. Packets forwarded to the Level 1/Level 2 router destined for the NOC will be discarded. The service provider wants the packets to be sent out the alternate GNE to an alternate central office.
There is a solution to this problem. For purpose of example, we will use a router named "3640A" (see Figure 23) to show the configurations and verifications. Router 3640A will continue to set the attach-bit when it has another Level 2 adjacency or the Cisco IOS IS-IS Multiarea feature is configured. In other words, router 3640A will set the attach-bit if it can reach multiple areas. The Level 1 routers nearest router 3640A will continue to forward traffic to router 3640A. Traffic sent to router 3640A is most likely destined for the area containing the OSS. The traffic, which is usually alarms destined for the NOC and alarm packets, will be dropped.
Cisco developed the IS-IS Attach-Bit Control feature to provide the network administrator with more control in setting the attach-bit. The feature is modeled after the IP default-information originate route-map router subcommand. The new command, set-attach-bit, is an IS-IS CLNS router subcommand and its syntax is as follows:
router isis
set-attach-bit {always | never | route-map mapname}The route-map keyword can be used to specify multiple CLNS routes or prefixes. If one of the routes or prefixes is matched in the Level 2 CLNS routing table, the Level 1/Level 2 router sets the attach bit in the LSP.
The following example contains five SONET/SDH network elements in a chain between central office A and central office D. NE14A and router 3640A are located in central office A. NE14A is a GNE between the SONET/SDH DCC and the Ethernet. Device NE14A forwards traffic destined for another area to the nearest Level 2 router, which is router 3640A.
Located in central office D is the Level 1/Level 2 router labeled 2600D and GNE NE25A. The other three SONET/SDH network elements are located is separate central offices. All of these devices are configured for area 0001. Router 3640A is configured for IS-IS multiarea and is located in area 0003. Figure 23 shows the network and the connections to the backbone, which is area 9999.
Figure 23 Network with IS-IS Attach-Bit Control Configured
Verifying IS-IS Attach-Bit Control
To verify that the IS-IS Attach-Bit Control feature is configured, first display a baseline configuration without the IS-IS Attach-Bit Control feature configured. The network administrator can look at the attach-bit settings using the show isis database EXEC command. The following example shows output for router 3640A. In the IS-IS process called area000, router 3640A's attach-bit is set to 1 in the Level-1 link state database. The attach-bit field is labeled "ATT." The router is configured to run two IS-IS processes, area0001 and area0003.
3640A# show isis databaseArea area0001:IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL3640A.00-00 * 0x00000009 0x7AB5 758 1/0/03640A.03-00 * 0x00000007 0x6705 649 0/0/0NE15A.00-00 0x00000009 0x88E2 520 0/0/0NE25B.00-00 0x0000000A 0x1DB6 660 0/0/0NE25B.02-00 0x00000007 0x2941 871 0/0/0NE14B.00-00 0x00000008 0xF840 744 0/0/0NE14B.02-00 0x00000007 0x622C 794 0/0/02600D.00-00 0x0000000A 0xC715 758 1/0/0NE14A.00-00 0x00000008 0x7C68 578 0/0/0NE14A.01-00 0x00000007 0x8232 735 0/0/0NE25A.00-00 0x00000007 0x8E92 563 0/0/0NE25A.01-00 0x00000007 0x95E2 745 0/0/0NE25A.02-00 0x00000007 0x69E3 578 0/0/0IS-IS Level-2 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OLBackBoneR1.00-00 0x0000000D 0x6BEF 599 0/0/03640A.00-00 * 0x0000000A 0x8457 758 0/0/03640A.02-00 * 0x00000007 0xC0AC 886 0/0/02600D.00-00 0x00000009 0xDE1C 765 0/0/02600D.02-00 0x00000007 0xFA61 847 0/0/0Area area0003:IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL3631A.00-00 0x00000008 0x33D5 827 0/0/0NE26B.00-00 0x00000009 0xAFE0 652 0/0/0NE26B.02-00 0x00000007 0x87A3 554 0/0/03640A.00-00 * 0x00000008 0x52DE 564 1/0/03640A.01-00 * 0x00000007 0x5325 532 0/0/0NE26A.00-00 0x00000009 0xA756 668 0/0/0NE26A.02-00 0x00000008 0x8904 1128 0/0/0Next, use the ping clns and show clns route EXEC commands to verify connectivity. Following is the output of ping to an IS-IS router in the area backbone:
3640A# ping clns 39.840f.8011.9999.0000.1111.9999.000d.bc2e.6d80.00Type escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 msThe following example shows the CLNS routing table with a route to backbone area 9999 (text in bold is for purpose of example only and indicates the backbone route):
3640A# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.1111.0003 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.1111.0001 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00 [1/0], Local IS-IS NETC 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00 [1/0], Local IS-IS NETi 39.840f.8011.9999.0000.1111.9999 [110/10]via BackBoneR1, Ethernet0/1Disconnect the connection to the backbone from router 3640A as shown in Figure 24, and display the IS-IS database again using the show isis database EXEC command.
Figure 24 Broken Network Link with IS-IS Attach-Bit Control Configured
Router 3640A still has the attach-bit set because the router is configured for the IS-IS Multiarea feature, so router 3640A can reach multiple areas. (You can determine the attach-bit setting by looking at the ATT field in the show isis database command output. The attach-bit is set when the value is 1.)
3640A# show isis databaseArea area0001:IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL3640A.00-00 * 0x00000004 0x84B0 1181 1/0/03640A.03-00 * 0x00000002 0x71FF 1180 0/0/0NE15A.00-00 0x00000004 0x92DD 612 0/0/0NE25B.00-00 0x00000004 0x29B0 491 0/0/0NE25B.02-00 0x00000003 0x313D 1165 0/0/0NE14B.00-00 0x00000003 0x033B 417 0/0/0NE14B.02-00 0x00000002 0x6C27 537 0/0/0NE14A.00-00 0x00000005 0x8265 1179 0/0/0NE14A.01-00 0x00000003 0x8A2E 1170 0/0/0NE25A.00-00 0x00000003 0x46FD 1056 0/0/0NE25A.02-00 0x00000002 0x73DE 409 0/0/0IS-IS Level-2 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL3640A.00-00 * 0x00000001 0x4A75 1173 0/0/0
Area area0003:IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL3631A.00-00 0x00000003 0x3DD0 503 0/0/0NE26B.00-00 0x00000004 0xB9DB 576 0/0/0NE26B.02-00 0x00000003 0x8F9F 538 0/0/03640A.00-00 * 0x00000005 0x58DB 1177 1/0/03640A.01-00 * 0x00000004 0x5922 1177 0/0/0NE26A.00-00 0x00000005 0xAF52 1178 0/0/0NE26A.02-00 0x00000003 0x93FE 1166 0/0/0The CLNS routing table displayed by the show clns route EXEC command shows that no connection to the backbone is available. There are only routes for areas 39.840f.8011.9999.0000.1111.0003 and 39.840f.8011.9999.1111.0001. The backbone route 39.840f.8011.9999.0000.1111.9999 has dropped out of the routing table. Packets destined to the backbone are dropped by router 3640A.
3640A# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.1111.0003 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.1111.0001 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00 [1/0], Local IS-IS NETC 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00 [1/0], Local IS-IS NETThe following example configures the set-attach-bit command. The route-map command sets conditions for setting the attach-bit. The route-map name or map tag assigned for the example is BackBone_Connection. The match clns command names the clns filter command that contains the NSAP address to match in the route table. In this example, the focus is on connectivity to the backbone.
clns filter-set BackBone_Area permit 39.840f.8011.9999.0000.1111.9999!router isis area0001net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00set-attached-bit route-map BackBone_Connection!route-map BackBone_Connection permit 10match clns address BackBone_AreaThe following example reexamines the IS-IS database and the CLNS routing table after the set-attach-bit command is configured. The Level 1 database for the IS-IS area process area0001 shows that router 3640A is no longer setting the attach bit. The ATT field is set to zero for the LSP from router 3640A. Router 2600D is setting the attach-bit and providing access to the backbone. The ATT field is set to 1 for the LSP from router 2600D.
3640A# show isis databaseArea area0001:IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL3640A.00-00 * 0x00000011 0x62CD 1143 0/0/03640A.03-00 * 0x0000000E 0x590C 557 0/0/0NE15A.00-00 0x00000011 0x78EA 910 0/0/0NE25B.00-00 0x0000000F 0x13BB 766 0/0/0NE25B.02-00 0x0000000E 0x1B48 671 0/0/0NE14B.00-00 0x0000000F 0xEA47 700 0/0/0NE14B.02-00 0x0000000E 0x5433 512 0/0/02600D.00-00 0x00000011 0xB91C 1013 1/0/0NE14A.00-00 0x0000000F 0x6E6F 647 0/0/0NE14A.01-00 0x0000000F 0x723A 1106 0/0/0NE25A.00-00 0x0000000E 0x8099 879 0/0/0NE25A.01-00 0x0000000F 0x85EA 917 0/0/0NE25A.02-00 0x0000000F 0x59EB 1140 0/0/0IS-IS Level-2 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OLBackBoneR1.00-00 0x00000010 0x65F2 426 0/0/03640A.00-00 * 0x00000010 0x2C84 1131 0/0/03640A.02-00 * 0x0000000E 0xB2B3 541 0/0/02600D.00-00 0x0000000F 0xD222 454 0/0/02600D.02-00 0x0000000F 0xEA69 818 0/0/0Area area0003:IS-IS Level-1 Link State Database:LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL3631A.00-00 0x0000000F 0x25DC 491 0/0/0NE26B.00-00 0x00000010 0xA1E7 523 0/0/0NE26B.02-00 0x0000000F 0x77AB 975 0/0/03640A.00-00 * 0x0000000F 0x44E5 562 1/0/03640A.01-00 * 0x0000000E 0x452C 510 0/0/0NE26A.00-00 0x00000011 0x975E 1151 0/0/0NE26A.02-00 0x0000000F 0x7B0B 1144 0/0/03640A#Additional information on the IS-IS Attach-Bit Control feature can be found on CCO. Refer also to the Cisco IOS Product Marketing Application Note, Using the IS-IS Attach-Bit Control Feature.
Using IP over CLNS Tunnels to Access Remote Devices
The SONET/SDH DCC is an extension of the telco DCN. Service providers do not want to build the DCN out to every SONET/SDH location. Figure 25 shows a typical telco network where each of the network elements are located at different physical locations. The DCC is used to communicate to remote SONET/SDH add/drop multiplexers (ADMs) on the ring.
Figure 25 Typical Telco Network with Network Elements at Different Locations
Service providers need to reach asynchronous and IP devices in the same location as the SONET/SDH nodes. Typically, the service providers are trying to access a contact closure device, as shown in Figure 26. Service providers can use the DCC by tunneling IP over CLNS. The router located in the central office in front of the GNE is usually the one used to create the tunnel. The router in the remote location usually terminates the CLNS tunnel and the TCP/IP session. The data is sent out the asynchronous connection to the contact closure device.
Figure 26 Telco Network Data Flow to a Contact Closure Device
Cisco has developed a contact closure device, which is a network module called the NM-AIC-64 that can be installed in the Cisco 2600, 3600, and 3700 series routers. The tunneling examples in this section use a Contact Closure device (the NM-AIC-64) embedded in router 3631A shown in Figure 27.
Figure 27 Telco Network with Cisco Contact Closure Device
Configuring a Tunnel Using IP over CLNS
In Figure 27, the IP over CLNS tunnel is created from the Cisco 3640A router to the Cisco 3631A router. The following example shows the CLNS tunnel configuration for the two routers:
Cisco 3640A Router Configuration
interface CTunnel1description connection remote site with 3631Aip address 192.168.10.1 255.255.255.252ctunnel destination 39.840f.8011.9999.0000.1111.0003.0001.6444.3410.cc!router isis area0003net 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00is-type level-1Cisco 3631A Router Configuration
clns routing!interface CTunnel1ip address 192.168.10.2 255.255.255.252ctunnel destination 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.cc!router isis area0003net 39.840f.8011.9999.0000.1111.0003.0001.6444.3410.00is-type level-1Verifying the IP over CLNS Tunnel Configuration
The tunnel is actually configured as an interface and the status of the tunnel can be checked with the show interfaces ctunnel1 command, as follows:
3640A# show interfaces ctunnel1CTunnel1 is up, line protocol is upHardware is CTunnelDescription: connection remote site with 3631AInternet address is 192.168.10.1/30MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,reliability 255/255, txload 56/255, rxload 28/255Encapsulation TUNNEL, loopback not setKeepalive set (10 sec)Tunnel destination 39.840f.8011.9999.0000.1111.0003.0001.6444.3410.ccLast input 00:00:00, output 00:00:00, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/0 (size/max)5 minute input rate 1000 bits/sec, 3 packets/sec5 minute output rate 2000 bits/sec, 2 packets/sec217 packets input, 13104 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort177 packets output, 33658 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets0 output buffer failures, 0 output buffers swapped outThe report shows that the CLNS tunnel is physically up. The "line protocol is up" report indicates that the router has a route to the CLNS tunnel destination. The hardware report indicates the interface type is CTunnel. The tunnel destination is 39.840f.8011.9999.0000.1111.0003.0001.6444.3410.cc, which is the NET for the Cisco 3631A router. Additional information about the show interfaces ctunnel command can be found in the Cisco IOS Software Release 12.1T IP over a CLNS Tunnel feature module at the following URL: http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1834/products_feature_guide09186a0080080382.html
Note
Configuring a Contact Closure Device
The tunnel in the previous configuration example was created to access the Contact Closure device (the NM-AIC-64) in the Cisco 3631 router. The NM-AIC-64 is installed in the second network module slot and communicates across the PCI bus in the router. The NM-AIC-64 requires an IP address to access it, and must be assigned an IP address and a static route that points to the IP address of the NM-AIC-64. The static route should be redistributed into the IP routing protocol.
The following example shows the basic configuration for the NM-AIC-64:
alarm-interface 2ip address 192.168.10.5!ip route 192.168.10.5 255.255.255.255 Serial2/0!router ospf 795log-adjacency-changesredistribute static subnetsnetwork 192.168.0.0 0.0.255.255 area 0Verifying the Contact Closure Device Configuration
The following example shows the report from issuing the show ip route command on the Cisco 3631A router. The static route to reach NM-AIC-64 is highlighted in bold text for purpose of example. Notice that the NM-AIC-64 looks like a serial device connected to the router.
3631A# show ip routeCodes: C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area* - candidate default, U - per-user static route, o - ODRP - periodic downloaded static routeGateway of last resort is not setO 192.168.12.0/24 [110/11112] via 192.168.10.1, 00:10:51, CTunnel1192.168.10.0/24 is variably subnetted, 2 subnets, 2 masksC 192.168.10.0/30 is directly connected, CTunnel1S 192.168.10.5/32 is directly connected, Serial2/0O 192.168.0.0/24 [110/11121] via 192.168.10.1, 00:10:51, CTunnel1192.168.2.0/26 is subnetted, 2 subnetsO 192.168.2.64 [110/11112] via 192.168.10.1, 00:10:51, CTunnel1O 192.168.2.128 [110/11112] via 192.168.10.1, 00:10:51, CTunnel1192.168.3.0/26 is subnetted, 1 subnetsO 192.168.3.128 [110/11122] via 192.168.10.1, 00:10:52, CTunnel1The following example shows the report from issuing the show ip route command on the Cisco 3640A router. The static route to reach the NM-AIC-64 is highlighted in bold text for purpose of example, and looks like an external route learned over OSPF.
3640A# show ip routeCodes: C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area* - candidate default, U - per-user static route, o - ODRP - periodic downloaded static routeGateway of last resort is 192.168.0.1 to network 0.0.0.0C 192.168.12.0/24 is directly connected, FastEthernet3/0.1192.168.10.0/24 is variably subnetted, 2 subnets, 2 masksC 192.168.10.0/30 is directly connected, CTunnel1O E2 192.168.10.5/32 [110/20] via 192.168.10.2, 00:09:48, CTunnel1C 192.168.0.0/24 is directly connected, Ethernet0/012.0.0.0/32 is subnetted, 1 subnetsR 12.222.16.0 [120/1] via 192.168.0.1, 00:00:16, Ethernet0/0192.168.2.0/26 is subnetted, 2 subnetsC 192.168.2.64 is directly connected, FastEthernet3/0.2C 192.168.2.128 is directly connected, FastEthernet3/0.3192.168.3.0/26 is subnetted, 1 subnetsO 192.168.3.128 [110/11] via 192.168.2.190, 00:09:48, FastEthernet3/0.3R* 0.0.0.0/0 [120/1] via 192.168.0.1, 00:00:16, Ethernet0/0For more information about configuring the NM-AIC-64, refer to the document NM-AIC-64, Contact Closure Network Module.
Mapping NSAPs to Device Names Using TARP
This section describes a method of mapping NSAPs to device names. In North America, ILECs and long distance carriers use a TID—a network-wide unique target identifier—to name a piece of equipment. The TID is a string of up to 20 case-sensitive characters. Service providers needed a dynamic method to map TIDs to NSAPs or network entity titles (NETs)—the terms NSAP and NET are often used interchangeably within the telco industry—and TARP serves that purpose. TARP runs over the Connectionless Network Protocol (CLNP), as defined in ISO 8473, and all Cisco routers that support CLNS routing support TARP. TARP is documented in GR-253-Core section 8. Additional documentation about TARP can be found on the ATIS website at www.atis.org. TARP was developed as part of the SONET Interoperability Forum (SIF).
TARP was developed to map the name for a network element (NE) to an NSAP. The OSS administrator typically knows the network element TID when building a profile for the device, but often does not know the NSAP. TARP was designed to dynamically map the TID to the NSAP. TARP was implemented on the router to facilitate the mapping across a network. Typically, the service provider has an OSS in the data center that needs to communicate with a network element in the central office, as shown in Figure 28.
Figure 28 Typical TARP Configuration and Packet Flow
A router can be configured to participate in TARP. The router is actually assigned a TID. The NET of a router is associated with the TID.
Note
The following example shows how to configure the IS-IS router to assign the NET (notice that the NET is the NSAP with a network selector value of 00):
router isis area0001net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00In OSI, File Transfer, Access, and Management (FTAM) and other applications have a specific network selector (also called N-selector) value that identifies the application. The network selector value for the TARP application are the hexadecimal digits AF. The network selector is analogous to a TCP port number.
TARP uses five types of protocol data units (PDUs):
•
•
•
•
•
In a traditional IS-IS implementation, a single IS-IS process is configured. The TARP application uses the NET in the single process for creating the NSAP. If the router is configured with an IS-IS multiarea, TARP will behave as follows:
•
•
Note
If a Level 1 process is added or removed, the NSAP associated with the TID can change at the next reload of the router.
•
•
•
•
The Cisco router labeled "3640A" in Figure 29 is configured with multiple IS-IS processes.
Figure 29 IS-IS Multiarea Network Using VLAN Trunking and ISL Encapsulation
Use the show tarp tid-cache EXEC command to examine the TARP TID cache. The following is sample output from this command:
3640A# show tarp tid-cacheTID ('*' : static; & : local) NSAP& 3640A 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.003640A#The following example lists the configuration for the Cisco 3640 router. The first IS-IS process listed is area0001. The NET associated with the process area0001 is 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00, which matches the NET listed in the TARP TID cache for the Cisco router labeled "3640A." (Remember the rule that the NET of the Level 2 IS-IS process would be associated with the TID.)
3640A# show configurationUsing 2849 out of 129016 bytes!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname 3640A!boot system slot1:boot system flashboot system romboot system slot0:logging queue-limit 100!ip subnet-zeroclns routingmpls ldp logging neighbor-changesno ftp-server write-enable!!!!interface Ethernet0/0ip address 192.168.0.49 255.255.255.0half-duplexno cdp enable!interface Ethernet0/1no ip addressshutdownhalf-duplexno cdp enable!interface Ethernet0/2no ip addressshutdownhalf-duplexno cdp enable!interface Ethernet0/3ip address 10.19.250.33 255.255.255.248shutdownhalf-duplexno cdp enable!interface Serial1/0no ip addressclockrate 9600no cdp enable!interface Serial1/1no ip addressshutdownno cdp enable!interface Serial1/2no ip addressclockrate 9600no cdp enable!interface Serial1/3no ip addressclockrate 9600no cdp enable!interface FastEthernet3/0no ip addressduplex autospeed autono cdp enable!interface FastEthernet3/0.1description ISIS area 0001encapsulation dot1Q 1 nativeip address 192.168.12.24 255.255.255.0no ip redirectsno cdp enableclns router isis area0001isis priority 127tarp enable!interface FastEthernet3/0.2description ISIS area 0002encapsulation dot1Q 2ip address 192.168.2.125 255.255.255.192no ip redirectsno cdp enableclns router isis area0002isis priority 127tarp enable!interface FastEthernet3/0.3description ISIS area 0003encapsulation dot1Q 3ip address 192.168.2.189 255.255.255.192no ip redirectsno cdp enableclns router isis area0003isis priority 127tarp enable!router ospf 795no log-adjacency-changesnetwork 192.168.0.0 0.0.255.255 area 0!router isis area0001net 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00!router isis area0002net 39.840f.8011.9999.0000.1111.0002.0010.7bc7.ae40.00is-type level-1!router isis area0003net 39.840f.8011.9999.0000.1111.0003.0010.7bc7.ae40.00is-type level-1!router ripnetwork 192.168.0.0!no ip http serverno ip classlessip route 0.0.0.0 0.0.0.0 172.31.232.17!!no cdp runclns host NE14A 39.840f.8011.9999.0000.1111.0001.00e0.b064.4324.00clns host NE14B 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00clns host NE25A 39.840f.8011.9999.0000.1111.0002.00e0.b064.434e.00clns host NE25B 39.840f.8011.9999.0000.1111.0002.0030.94e2.6ce0.00clns host NE26A 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host NE26B 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.00clns host NE15A 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.00clns host 3640A 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00!tftp-server slot1:tarp runtarp tid 3640A!line con 0password ciscoline aux 0line vty 0 4exec-timeout 0 0password ciscologinline vty 5 99login!endEnabling TARP
The following example shows the tarp run and tarp tid global configuration commands used to enable TARP on a central office router:
tarp runtarp tid 3640ATARP must be enabled on an interface in order for TARP packets to be forwarded. TARP is enabled on the Cisco router labeled "3640A," shown in Figure 30. The configuration for Fast Ethernet interface 3/0.1 is listed in the following example; the tarp enable interface configuration command is the last command listed.
interface FastEthernet3/0.1description ISIS area 0001encapsulation dot1Q 1 nativeip address 192.168.12.24 255.255.255.0no ip redirectsno cdp enableclns router isis area0001isis priority 127tarp enableUse the show tarp EXEC command to display the global TARP configuration information on a router:
3640A# show tarpGlobal TARP information:TID of this station is "3640A"Timer T1 (timer for response to TARP Type 1 PDU) is 15 secondsTimer T2 (timer for response to TARP Type 2 PDU) is 25 secondsTimer T3 (timer for response to ARP request) is 40 secondsTimer T4 (timer that starts when T2 expires) is 15 secondsLoop Detection Buffer entry timeout : 300 secondsLoop Detection Buffer zero sequence timer is 300 secondsTID cache entry timeout : 3600 secondsThis station will propagate TARP PDUsThis station will originate TARP PDUsTID<->NET cache is enabledSequence number that next packet originated by this station will have : 1Update remote cache (URC) bit is 0Packet lifetime : 100 hopsProtocol type used in outgoing packets : "FE"N-Selector used in TARP PDU's : "AF"Use the following information to interpret the report:
•
•
–
–
–
–
•
•
•
•
•
•
•
•
•
•
•
Using TARP with Remote Login Applications
One reason TARP was developed was to assist remote login applications. Central office technicians may not know the NSAP of the device that they want to log in to remotely, but they can determine the name of the equipment or the TID.
Network monitoring applications such as Telcordia's Network Management Application (NMA) or Provision applications such as Fujitsu's Flexr can also take advantage of TARP as a dynamic method to map TIDs to NSAPs or NETs. The system administrator would have to type in only the TID for the device that was to be monitored or provisioned, which is much easier than typing the NSAP. The OSS application would then issue a TARP type 1 or type 2 packet to learn the NET.
To issue a TARP type 1 or type 2 request on a Cisco router, use the tarp resolve tid EXEC command. Use Figure 30 as an example network for interpreting the reports displayed.
Figure 30 Sample Network for Interpreting TARP Reports
Issue a TARP type 1 request for the NET for device NE15A using the tarp resolve tid EXEC command:
3640A# tarp resolve tid NE15AType escape sequence to abort.Sending TARP type 1 PDU, timeout 15 seconds ...NET corresponding to TID NE15A is 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.00The request returns a message indicating that a TARP type 1 PDU was sent out. The software will wait for 15 seconds for a reply (the default time value for the T1 timer). If no response is received after 15 seconds, a type 2 PDU would be sent out to all of the IS-IS and ES-IS nodes that support TARP.
In this example, the network element with the TID value of NE15A did respond with a TARP type 3 PDU, and the software picked up and displayed the NET on the screen. The NET is 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.00. The TID-to-NET map will be stored in the router's TARP data cache.
To display the contents of the TARP data cache, use the show tarp tid-cache EXEC command. The TID for router 3640A and device NE15A is listed in the TARP data cache.
3640A# show tarp tid-cacheTID ('*' : static; & : local) NSAP& 3640A 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00NE15A 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.00To clear the TARP cache, use the clear tarp tid-cache command:
3640A# clear tarp tid-tableCheck the TARP TID cache after clearing it to verify that only the Cisco router labeled "3640A" is listed:
3640A# show tarp tid-cacheTID ('*' : static; & : local) NSAP& 3640A 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00It is possible to watch the propagation of the TARP PDUs, for example, to watch router 3640A generate a TARP type 1 PDU for every adjacency. Use the show clns neighbors EXEC command to show all of the adjacencies:
3640A# show clns neighborsArea area0001:System Id Interface SNPA State Holdtime Type ProtocolNE15A Fa3/0.1 0010.7bd8.c7d0 Up 27 L1 IS-ISNE14A Fa3/0.1 00e0.b064.4325 Up 21 L1 IS-ISArea area0002:System Id Interface SNPA State Holdtime Type ProtocolNE25A Fa3/0.2 00e0.b064.434e Up 22 L1 IS-ISArea area0003:System Id Interface SNPA State Holdtime Type ProtocolNE26A Fa3/0.3 00d0.5872.9720 Up 21 L1 IS-ISFour adjacencies are listed and all are of type Level 1. Figure 30 has been redrawn in Figure 31 with an arrow depicting each of the TARP type 1 PDUs being sent out. One important point to note is that TARP is not a broadcast protocol. A type 1 packet is generated and sent out to each of the IS-IS adjacencies. Sending separate PDUs to each adjacency will generate more network traffic than a single broadcast packet.
Figure 31 Transmission of TARP Type 1 PDUs
TARP debug commands can also help track the packets that are being sent. Before the debug command is issued, a list of the system identifiers will help analyze the command output:
3640A system id 0010.7bc7.ae40NE14A system is 00e0.b064.4324NE14B system id 0050.7363.7b40NE25A system id 00e0.b064.434eNE25B system is 0030.94e2.6ce0NE26A system id 00d0.5872.9720NE26B system id 0010.7b17.f880NE15A system id 0010.7bd8.c7d0To verify the TARP type 1 PDUs that are being sent out, issue the debug tarp packet command. In addition, issue the debug tarp events command to track additional TARP PDU activity.
3640A# debug tarp packetsTARP packet info debugging is on3640A# debug tarp eventsTARP events debugging is onNext issue the tarp resolve tid EXEC command for device NE15A. In the following example, the router will wait 15 seconds for a response before issuing a TARP type 2 PDU. Device NE15A responds within 15 seconds with its NET, which is the NSAP address and selector value of 00.
3640A# tarp resolve tid NE15AType escape sequence to abort.Sending TARP type 1 PDU, timeout 15 seconds ...NET corresponding to TID NE15A is 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.00The debug tarp packets command output shows a TARP type 1 PDU being sent to each of the four IS-IS adjacencies over the Fast Ethernet interface connection; four type 1 PDU packet will be sent out. The first type 1 packet is sent to device NE15A (0010.7bd8.c7d0) from the Cisco router labeled "3640A" (0010.7bc7.ae40):
3640A#00:16:50: TARP-PA: Propagated TARP packet, type 1, out on FastEthernet3/0.100:16:50: Lft = 100, Seq = 7, Prot type = 0xFE, URC = TRUE00:16:50: Dtid len = 5, Stid len = 5, Prot addr len = 2000:16:50: Destination NSAP : 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.0000:16:50: Originator's NSAP : 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.0000:16:50: Target TID : NE15A00:16:50: Originator's TID : 3640AThe debug tarp packets output continues by showing the second type 1 packet being sent to device NE14A (00e0.b064.4324) from the Cisco router labeled "3640A" (0010.7bc7.ae40):
00:16:50: TARP-PA: Propagated TARP packet, type 1, out on FastEthernet3/0.100:16:50: Lft = 100, Seq = 7, Prot type = 0xFE, URC = TRUE00:16:50: Dtid len = 5, Stid len = 5, Prot addr len = 2000:16:50: Destination NSAP : 39.840f.8011.9999.0000.1111.0001.00e0.b064.4324.0000:16:50: Originator's NSAP : 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.0000:16:50: Target TID : NE15A00:16:50: Originator's TID : 3640AThe debug tarp packets output continues by showing the third type 1 packet being sent to device NE25A (00e0.b064.434e) from the Cisco router labeled "3640A" (0010.7bc7.ae40):
00:16:50: TARP-PA: Propagated TARP packet, type 1, out on FastEthernet3/0.200:16:50: Lft = 100, Seq = 7, Prot type = 0xFE, URC = TRUE00:16:50: Dtid len = 5, Stid len = 5, Prot addr len = 2000:16:50: Destination NSAP : 39.840f.8011.9999.0000.1111.0002.00e0.b064.434e.0000:16:50: Originator's NSAP : 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.0000:16:50: Target TID : NE15A00:16:50: Originator's TID : 3640AThe debug tarp packets output shows a fourth type 1 packet being sent to device NE26A (00d0.5872.9720) from the Cisco router labeled "3640A" (0010.7bc7.ae40):
00:16:50: TARP-PA: Propagated TARP packet, type 1, out on FastEthernet3/0.300:16:50: Lft = 100, Seq = 7, Prot type = 0xFE, URC = TRUE00:16:50: Dtid len = 5, Stid len = 5, Prot addr len = 2000:16:50: Destination NSAP : 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.0000:16:50: Originator's NSAP : 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.0000:16:50: Target TID : NE15A00:16:50: Originator's TID : 3640ANext, the debug tarp packets output shows a type 3 packet being received on Fast Ethernet interface 3/0.1 by router 3640A (0010.7bc7.ae40) from device NE15A (0010.7bd8.c7d0):
00:16:50: TARP-PA: Received TARP type 3 PDU on interface FastEthernet3/0.100:16:50: Lft = 100, Seq = 3, Prot type = 0xFE, URC = TRUE00:16:50: Ttid len = 0, Stid len = 5, Prot addr len = 2000:16:50: Packet sent/propagated by 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.af00:16:50: Originator's NSAP : 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.0000:16:50: Originator's TID : NE15AFinally, the debug tarp events output shows a TARP cache entry being created. A value is set for the loop detection buffer (LDB). The loop detection buffer is a method of deterring packets from propagating TARP packets that the IS-IS router has already seen.
00:16:50: TARP-PA: Created new DYNAMIC cache entry for NE15A00:16:50: TARP-EV: Packet from 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00 discarded - sequence00:16:50: number (7) <= that in LDB cache entry (7)00:16:50: TARP-EV: Packet from 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00 discarded - sequence00:16:50: number (7) <= that in LDB cache entry (7)Notice that the TARP application generated a separate unicast packet for every adjacency instead of a single broadcast packet.
Controlling TARP Propagation Using Split Horizon
The original implementations of TARP had type 1, type 2, and type 4 packets forwarded to IS-IS and ES-IS adjacencies. Service providers were experiencing problems with TARP PDUs looping through the network and causing congestion. One of the first things that Cisco did to control the propagation of TARP packets was to implement split horizon, so that a TARP packet would not be forwarded on the same interface that the packet was received on. The problem was worse on Ethernet interfaces: A router or other device on an Ethernet interface would receive a type 2 PDU. A separate type 2 PDU would be sent to all of the router adjacencies, and these devices should have already received the packet.
This section steps through an example of the network elements without split horizon. Figure 32 shows a TARP type 1 PDU being generated from router 3640A. Router 3640A will generate a type 1 PDU to all of its Level 1 adjacencies. The arrows in Figure 32 depict the Type 1 PDUs that are being sent out to all of router 3640A's Level 1 adjacencies.
Figure 32 TARP Propagation Control Using Split Horizon
Figure 33 shows how the early implementations of TARP would respond to the type 1 PDUs sent out in Figure 32. Type 1 PDUs would be forwarded out the interface that the type 1 PDU had arrived on. Device NE 14A has an adjacency with devices NE14B, NE15A, and router 3640A, so device NE14A would send out three type 1 PDUs, which are represented by the three arrows coming out of device NE14A. Device NE15A is the object of the type 1 PDU, and device NE15A responds with a TARP type 3 PDU directly to router 3640A. Device NE25A has two Level 1 IS-IS adjacencies, which are router 3640A and device NE25B, and two type 1 packets are forwarded out, as shown in Figure 33 by the two parallel arrows. Similarly, device NE26A has two Level-1 IS-IS adjacencies, which are router 3640A router and device NE26B, and Figure 33 shows two TARP type 1 packets being forwarded out.
Figure 33 Split Horizon Not Implemented on a Network Element
The point is that TARP packets can multiply quickly on the network. Split horizon is only one method that Cisco implemented to control the number of TARP packets.
At this point, router 3640A has received a type 3 response to the type 1 query; however, numerous packets have been launched. Without split horizon implemented, router 3640A would respond to each of the incoming type 1 PDUs and send back a type 1 packet to each of the adjacencies on the Ethernet interface. Eventually, the packets would expire due to the time-to-live field, but in the meantime much bandwidth has been expended.
Figure 34 shows what happens when split horizon is implemented on the network elements and the router. Device NE15A responds with a type 3 PDU. Device NE14A sends a type 1 PDU out on the DCC, but not on the Ethernet interface. Remember that split horizon does not allow the device to send a type 1 packet on the same interface that the packet arrived on. With split horizon configured, devices NE15A and NE26A send a type 1 PDU out on the DCC, but not on the Ethernet interface.
Figure 34 Split Horizon Implemented on Network Elements and Router 3640A
The problem of looping TARP PDUs has also been addressed by the SONET Interoperability Forum, which is discussed in the next section.
Additional Methods of Controlling the Propagation of TARP Packets
In the original TARP implementation, traffic multiplied exponentially. Cisco developed split horizon to help customers reduce this traffic, which can be implemented by placing all the network elements in the same OSI area. In Figure 35, the area is designated 0001.
Figure 35 Split Horizon and All Network Elements in the Same Area
The SONET Interoperability forum later developed a loop detection procedure using the loop detection buffer on the IS-IS router. Upon receiving a type 1, type 2, or type 4 PDU, the IS-IS router checks the loop detection buffer for a match. If there is no match, an entry is created with the system identifier that originated the packet and its sequence number.
Use the show tarp ldp EXEC command to display the TARP loop detection database on a Cisco router. The output lists the TARP sequence number and the time until the entry is aged out.
In the following example, any new TARP PDUs arriving from system identifier 0010.7BC7.AE40 with a sequence number of 9 or less will be discarded for the next 287 seconds. Any new TARP PDUs arriving from system identifier 0010.7BD8.C7D0 with a sequence number of 5 or less will be discarded for the next 287 seconds.
3640A# show tarp ldbSystem ID Sequence Number Expiration (sec) Zero-sequence timer0010.7BC7.AE40 9 287 00010.7BD8.C7D0 5 287 0
In the following example, the output from the debug tarp events command indicates that the TARP entries in the LDB are being aged:
3640A# debug tarp events01:56:18: TARP-EV: Aging LDB entry for 0010.7BC7.AE4001:56:18: TARP-EV: Aging LDB entry for 0010.7BD8.C7D0A TARP type 4 packet is used to notify the network of changes. The type 4 packet is used to notify IS-IS and ES devices of TID changes or address changes. The TARP type 4 packet is used to reset the TARP sequence number to 0 (zero).
TARP PDU Packet Propagation Control Configuration Commands
Cisco has developed software commands that help control the propagation of type 1, type 2, and type 4 TARP PDU packets throughout the network. The tarp route-static global configuration command provides the ability to statically map the propagation of TARP packets across the network, and is issued as follows:
tarp route-static nsap [all | message-type type-number [type-number] [type-number]]
This command creates a manual adjacency to forward the TARP packet. The command can also be used to forward the TARP packets across IS-IS routers that do not support the TARP application. Use this command to forward TARP packets across the core of the network, yet control the propagation of the packets. The tarp route-static command can be implemented by a TARP packet type and is valid for the packet types 1, 2, and 4. TARP type 3 and 5 packets are unicast and sent to only one address; there is no need to apply the tarp route-static command to type 3 and 5 packets.
To control the propagation of TARP packets, use the no tarp propagate interface configuration command:
no tarp propagate [all | message-type type-number [type-number] [type-number]]
This command turns off the propagation by TARP packet type. The no tarp propagate command can be implemented by individual TARP packet type, and types 1, 2, and 4 are valid for the command.
Note
Maintaining and Troubleshooting the IS-IS Network
The Cisco IOS software provides commands to help determine the topology and connectivity of the network, and that are useful for verifying and troubleshooting the IS-IS network. The following EXEC commands are described in this section:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Caution
Mapping NSAPs to CLNS Host Names
Managing and troubleshooting the networks using NSAP addresses can be cumbersome, because the system identifier in the NSAP is typically in hexadecimal format. This format makes monitoring the IS-IS adjacencies, the ES-IS adjacencies, the IS-IS database, and other information a difficult task. Issuing debugging commands such as the ping clns EXEC command and TARP commands can also be cumbersome. One solution is to statically map NSAPs to host names. In the Cisco IOS software, this mapping can be done using the clns host command. The following example shows how to map CLNS hosts to IS-IS devices:
clns host 3640A 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host NE14A 39.840f.8011.9999.0000.1111.0001.00e0.b064.4325.00clns host NE14B 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00clns host NE25A 39.840f.8011.9999.0000.1111.0002.00e0.b064.434e.00clns host NE25B 39.840f.8011.9999.0000.1111.0002.0030.94e2.6ce0.00clns host NE26A 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host NE26B 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host NE15A 39.840f.8011.9999.0000.1111.0001.0010.7bd8.c7d0.00Using TLV 137 to Correlate Router and Host Names
The maintenance of the CLNS host statements in every IS-IS router and CLNS host in the network can be cumbersome in a large-sized network. A dynamic solution has been developed as part of the IS-IS protocol. A new type, length, value (TLV) has been defined in Informational RFC 2763, Dynamic Hostname Exchange Mechanism for IS-IS. IS-IS, originally designed for OSI routing, uses TLV parameters to carry information in link-state packets. The new TLV type 137, dynamic host name, and its value field contain the name of the router originating the link-state packet. The feature was introduced in Cisco IOS Release 12.0(4)T, and the show clns neighbors EXEC command uses TLV 137 or the clns host command to correlate router and host name.
Following is sample output from the show clns neighbors command showing the system identifier with the host name:
3640A# show clns neighborsArea area0001:System Id Interface SNPA State Holdtime Type ProtocolNE15A Fa3/0.1 0010.7bd8.c7d0 Up 24 L1 IS-ISNE14A Fa3/0.1 00e0.b064.4325 Up 25 L1 IS-ISArea area0002:System Id Interface SNPA State Holdtime Type ProtocolNE25A Fa3/0.2 00e0.b064.434e Up 23 L1 IS-ISArea area0003:System Id Interface SNPA State Holdtime Type ProtocolNE26B Fa3/0.3 00d0.5872.9720 Up 26 L1 IS-IS
Note
Displaying IS-IS Network Topology
This section describes how to use Cisco IOS software commands to determine network topology. Use Figure 36 as a reference for the command examples.
Figure 36 Sample Network for Determining IS-IS Network Topology
Use the show isis topology EXEC command to list the topology of the IS-IS network. The following example lists the topology as shown in Figure 36:
3640A# show isis topologyArea area0001:IS-IS IP paths to level-1 routersSystem Id Metric Next-Hop Interface SNPA3640A --NE15A 10 NE15A Fa3/0.1 0010.7bd8.c7d0NE14B 20 NE14A Fa3/0.1 00e0.b064.4325NE14A 10 NE14A Fa3/0.1 00e0.b064.4325IS-IS IP paths to level-2 routersSystem Id Metric Next-Hop Interface SNPA3640A --Area area0002:IS-IS IP paths to level-1 routersSystem Id Metric Next-Hop Interface SNPA3640A --NE25B 20 NE25A Fa3/0.2 00e0.b064.434eNE25A 10 NE25A Fa3/0.2 00e0.b064.434eArea area0003:IS-IS IP paths to level-1 routersSystem Id Metric Next-Hop Interface SNPANE26B 20 NE26A Fa3/0.3 00d0.5872.97203640A --NE26A 10 NE26A Fa3/0.3 00d0.5872.9720In Figure 36, the IS-IS Level 1 area0001 contains the IS-IS Level 1/Level 2 Cisco 3640 router and the IS-IS Level 1 devices NE15A, NE14B, and NE14A. Device NE15A is directly connected using Fast Ethernet interface 3/0.1 to router 3640A, and has a routing metric of 10. The SNPA for device NE15A is 0010.7bd8.c7d0. On an Ethernet interface, the SNPA is the MAC address. Device NE14B is one hop away from router 3640A; therefore, the routing metric is 20 and the next hop IS-IS router is device NE14A. Device NE14A is connected using Fast Ethernet interface 3/0.1. The SNPA is the MAC address (00e0.b064.4325) of device NE14A, the next hop device. Device NE14A is directly connected to Fast Ethernet 3/0.1 and has a routing metric of 10. The SNPA or MAC address of device NE14A is 00e0.b064.4325.
In IS-IS area 0002, there are three system identifiers—router 3640A and devices NE25B and NE25A—as seen in Figure 36. Device NE25B can be reached one hop away through device NE25A on Fast Ethernet interface 3/0.2. The routing metric is 20 because device NE25B is one hop away. The SNPA for the next hop device, NE25A, is 00e0.b064.434e. Device NE25A is directly connected with a routing metric of 10.
In IS-IS area 0003, there are three system identifiers—router 3640A and devices NE26B and NE26A, as seen in Figure 36. Device NE26B can be reached one hop away through device NE26A on Fast Ethernet interface 3/0.3. The routing metric is 20. The SNPA for the next hop device, NE26A, is 00d0.5872.9720. Device NE26A is directly connected with a routing metric of 10.
Similar network topology information can be gathered from the show isis route EXEC command. The information is similar to that displayed by the show isis topology command, except for an additional field that indicates the state of the adjacency to the next hop IS-IS router. The following example output shows the information displayed by the show isis route command:
3640A# show isis routeArea area0001:IS-IS Level-1 Routing Table - version 5System Id Next-Hop Interface SNPA Metric State3640A --NE15A NE15A Fa3/0.1 0010.7bd8.c7d0 10 UpNE14B NE14A Fa3/0.1 00e0.b064.4325 20 UpNE14A NE14A Fa3/0.1 00e0.b064.4325 10 UpArea area0002:IS-IS Level-1 Routing Table - version 5System Id Next-Hop Interface SNPA Metric State3640A --NE25B NE25A Fa3/0.2 00e0.b064.434e 20 UpNE25A NE25A Fa3/0.2 00e0.b064.434e 10 UpArea area0003:IS-IS Level-1 Routing Table - version 4System Id Next-Hop Interface SNPA Metric State3640A --NE26B NE26A Fa3/0.3 00d0.5872.9720 20 UpNE26A NE26A Fa3/0.3 00d0.5872.9720 10 UpThe show isis route EXEC command can be used to specify the next hop to a specific IS-IS router. The following example shows the route to device NE14B:
3640A# show isis route NE14BArea area0001:System Id Next-Hop Interface SNPA Metric StateNE14B NE14A Fa3/0.1 00e0.b064.4325 20 UpArea area0002:No IS-IS Level-1 route to NE14B foundArea area0003:No IS-IS Level-1 route to NE14B foundThe which-route EXEC command displays the next hop in the route for the packet and specific information about the hop, and is better suited to display the route to device NE14B. The command displays the routing table where the CLNS address is found in the router. The command can also be useful if you are running multiple routing processes on the router.
3640A# which-route NE14BRoute look-up for destination 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00, NE14BFound route in IS-IS level-1 routing tableAdjacency entry used:System Id Interface SNPA State Holdtime Type ProtocolNE14A Fa3/0.1 00e0.b064.4325 Up 23 L1 IS-ISArea Address(es): 39.840f.8011.9999.0000.1111.0001Uptime: 01:11:57In this display:
•
•
•
•
•
•
•
•
•
Verifying IS-IS Adjacency Formation
This section describes how to determine whether two IS-IS router devices are forming IS-IS adjacencies. If the devices are not forming adjacencies, it will be necessary to determine why not. Cisco has found from working with service providers that typically the SONET/SDH nodes do not have a robust debugging capability. Figure 37 shows a typical operational IS-IS network.
Figure 37 Operational IS-IS Network
The portion of the network that this section focuses on debugging is shown in Figure 38, and examines the access router in the central office that supports the Level-1-2 adjacency to the network elements.
Figure 38 Access Router in the Central Office that Supports the Level 1-2 Adjacency to the Network Elements
The Cisco IOS software provides commands that determine the status of the IS-IS adjacency between the Cisco router labeled "3640A" in Figure 38 and the network elements. All of the network elements in the example are set up as Level 1 IS-IS routers. Devices NE14A and NE15A are in OSI area 0001, and there should be two Level 1 adjacencies established on Fast Ethernet interface 3/.01.
The show clns interface EXEC command displays the number adjacencies on the interface (report displayed in bold text for purpose of example).
3640A# show clns interface FastEthernet3/0.1FastEthernet3/0.1 is up, line protocol is upChecksums enabled, MTU 1497, Encapsulation SAPERPDUs enabled, min. interval 10 msec.RDPDUs enabled, min. interval 100 msec., Addr Mask enabled, last sent 00:00:40Congestion Experienced bit set at 4 packetsCLNS fast switching enabledCLNS SSE switching disabledDEC compatibility mode OFF for this interfaceNext ESH/ISH in 38 secondsRouting Protocol: IS-IS (area0001)Circuit Type: level-1-2Interface number 0x0, local circuit ID 0x1Level-1 Metric: 10, Priority: 127, Circuit ID: 3640A.01Level-1 IPv6 Metric: 10Number of active level-1 adjacencies: 2Level-2 Metric: 10, Priority: 127, Circuit ID: 3640A.01Level-2 IPv6 Metric: 10Number of active level-2 adjacencies: 0Next IS-IS LAN Level-1 Hello in 254 millisecondsNext IS-IS LAN Level-2 Hello in 2 secondsThe output of the command shows that there are two Level 1 adjacencies. There are no Level 2 adjacencies, which corresponds to the configuration seen in Figure 38.
The ES-IS protocol works with the IS-IS protocol. When a router is configured for IS-IS, ES-IS is automatically enabled. End systems and routers send End System Hello (ESH) and Intermediate System Hello (ISH) messages to determine the network addresses of adjacent neighbors. On a LAN, the ESHs are sent to a broadcast address of 09-00-2b-00-00-05 to reach the routers. The ISHs are sent to a broadcast address of 09-00-2b-00-00-04 to reach the end systems. The IS-IS adjacencies are formed IS-IS Hello (IIH) messages and there are three types, as follows:
•
•
•
Examine the adjacencies coming up on a working network using Figure 38 as an example. This task requires the MAC address or SNPA for debugging the IIH messages. One method of quickly determining the system identifier is to use the show clns neighbors EXEC command.
In the following example, when the show clns neighbors EXEC command is issued, the host name is displayed instead of the actual system identifier. The host name will be displayed when static host name assignments have been made in the Cisco router, or when the SONET/SDH nodes support dynamic host assignment. Static and dynamic host assignment are explained in the "Mapping NSAPs to CLNS Host Names" section.
3640A# show clns neighborsArea area0001:System Id Interface SNPA State Holdtime Type ProtocolNE15A Fa3/0.1 0010.7bd8.c7d0 Up 22 L1 IS-ISNE14A Fa3/0.1 00e0.b064.4325 Up 20 L1 IS-ISArea area0002:System Id Interface SNPA State Holdtime Type ProtocolNE25A Fa3/0.2 00e0.b064.434e Up 23 L1 IS-ISArea area0003:System Id Interface SNPA State Holdtime Type ProtocolNE26B Fa3/0.3 00d0.5872.9720 Up 29 L1 IS-ISExamining IS-IS Adjacency Formation
The next step is to look at how IS-IS adjacencies are formed. Use the debug isis adj-packets EXEC command to watch the IIHs being sent. In the following example, the Fast Ethernet interface has been turned down and then brought up after debugging was turned on to capture the entire process. (Key reports are in bold text for purpose of example.)
3640A# debug isis adj-packetsThe Fast Ethernet interface comes up:
00:05:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to upRouter 3640A in Figure 38 sends Level 1 and Level 2 IIHs:
00:05:44: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149700:05:44: ISIS-Adj (area0001): Sending L2 LAN IIH on FastEthernet3/0.1, length 149700:05:44: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149700:05:44: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149700:05:52: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149700:05:53: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149700:05:53: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149700:05:53: ISIS-Adj (area0001): Sending L2 LAN IIH on FastEthernet3/0.1, length 149700:06:00: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149700:06:02: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149700:06:02: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149700:06:03: ISIS-Adj (area0001): Sending L2 LAN IIH on FastEthernet3/0.1, length 149700:06:08: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149700:06:10: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 1497Router 3640A receives a Level 1 IIH from MAC address 0010.7bd8.c7d0, which is device NE15A. The Level 1 adjacency comes up between router 3640A and device NE15A.
00:06:10: ISIS-Adj (area0001): Rec L1 IIH from 0010.7bd8.c7d0 (FastEthernet3/0.1), cir type L1, cir id 0010.7BD8.C7D0.01, length 14700:06:10: ISIS-Adj (area0001): New adjacency, level 1 for 0010.7bd8.c7d0Router 3640A receives a Level 1 IIH from MAC address 00e0.b064.4325, which is device NE14A. The Level 1 adjacency comes up between router 3640A and device NE14A.
00:06:10: ISIS-Adj (area0001): Rec L1 IIH from 00e0.b064.4325 (FastEthernet3/0.1), cir type L1, cir id 00E0.B064.4324.02, length 14700:06:10: ISIS-Adj (area0001): New adjacency, level 1 for 00e0.b064.4325...00:06:11: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 1497Router 3640A receives a second IIH from device NE15A. The Cisco 3640A router's Level 1 adjacency count goes to 1 and the adjacency state is up.
00:06:11: ISIS-Adj (area0001): Rec L1 IIH from 0010.7bd8.c7d0 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14700:06:11: ISIS-Adj (area0001): L1 adj count 100:06:11: ISIS-Adj (area0001): Adjacency state goes to UpRouter 3640A and device NE15A are going through the designated router selection. The system identifier of the designated router is 0001.0010.7bc7.AE40, which is router 3640A.
00:06:11: ISIS-Adj (area0001): Run level-1 DR election for FastEthernet3/0.100:06:11: ISIS-Adj (area0001): New level-1 DR 0010.7BC7.AE40 on FastEthernet3/0.100:06:11: ISIS-Adj (area0001): Didn't purge DR LSP--not fully electedRouter 3640A receives a second Level 1 IIH from device NE14A. The Level 1 adjacency count goes to 2. The adjacency state between router 3640A and device NE14A goes to up.
00:06:11: ISIS-Adj (area0001): Rec L1 IIH from 00e0.b064.4325 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14700:06:11: ISIS-Adj (area0001): L1 adj count 200:06:11: ISIS-Adj (area0001): Adjacency state goes to UpThe designated router election process runs again. Router 3640A remains the designated router.
00:06:11: ISIS-Adj (area0001): Run level-1 DR election for FastEthernet3/0.100:06:11: ISIS-Adj (area0001): No change (it's us)The normal sending and receiving of IIHs in area 0001 is shown in the following example:
00:06:12: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149700:06:12: ISIS-Adj (area0001): Rec L1 IIH from 0010.7bd8.c7d0 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14700:06:12: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149700:06:12: ISIS-Adj (area0001): Sending L2 LAN IIH on FastEthernet3/0.1, length 149700:06:14: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 1497The same procedure for establishing adjacency in area 0002 and area 0003 takes place. The start of the process of sending and receiving IIHs for both areas is shown in the following example:
00:06:16: ISIS-Adj (area0003): Rec L1 IIH from 00d0.5872.9720 (FastEthernet3/0.3), cir type L1, cir id 00D0.5872.9720.01, length 14700:06:16: ISIS-Adj (area0003): New adjacency, level 1 for 00d0.5872.972000:06:16: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149700:06:16: ISIS-Adj (area0002): Rec L1 IIH from 00e0.b064.434e (FastEthernet3/0.2), cir type L1, cir id 00E0.B064.434E.01, length 14700:06:16: ISIS-Adj (area0002): New adjacency, level 1 for 00e0.b064.434eSample Adjacency Debugging Scenario
In Figure 39, Nodes 1 through 4 are TN-16s and are SDH network elements that are connected over a fiber-optic link. The GNEs and Cisco routers are located in the Router 1 and Router 2 central offices. The problem is that NE 1 cannot establish a Level 1 adjacency with the Cisco router. The result is that the service provider will have connectivity problems reaching NE 1 from Element Manager System EM-1 Primary. The network elements are configured as Level 1 IS-IS routers. The Cisco routers are configured as Level-1-2 IS-IS routers.
Figure 39 Sample Network for Troubleshooting IS-IS Adjacency Problems
The first problem encountered is that the IS-IS adjacency will not come up between Router 1 and NE 1. One way to solve this problem is to determine if the Cisco router interface is up. Use the show clns interface EXEC command to do so (key reports shown in bold text for purpose of example):
Router1# show clns interface Ethernet0Ethernet0 is up, line protocol is upChecksums enabled, MTU 1497, Encapsulation SAPERPDUs enabled, min. interval 10 msec.RDPDUs enabled, min. interval 100 msec., Addr Mask enabledCongestion Experienced bit set at 4 packetsCLNS fast switching enabledCLNS SSE switching disabledDEC compatibility mode OFF for this interfaceNext ESH/ISH in 47 secondsRouting Protocol: IS-ISCircuit Type: level-1-2Interface number 0x0, local circuit ID 0x1Level-1 Metric: 10, Priority: 64, Circuit ID: 0000.0000.60B1.01Number of active level-1 adjacencies: 0Level-2 Metric: 10, Priority: 64, Circuit ID: 0000.0000.60B1.01Number of active level-2 adjacencies: 0Next IS-IS LAN Level-1 Hello in 2 secondsNext IS-IS LAN Level-2 Hello in 1 secondsThe report indicates that the interface is up and the line protocol is up and that the next ESH/ISH will be sent in 47 seconds. The IS-IS routing protocol is turned on and the circuit type is Level-1-2. The number of Level 1 adjacencies is 0 (zero) and the number of Level 2 adjacencies is 0 in the following output. On the Ethernet interface, according to Figure 39, there should be an adjacency with Node 1. The adjacency type should be Level 1 because Node 1 can be configured as only Level 1. The interface is advertising Level 1 and Level 2 IS-IS hello messages.
The next step would be to examine the IS-IS adjacency formation using the debug isis adjacency command. In the following example, Router 1 is sending Level 1 and Level 2 IIHs. The debug command output indicates that the Cisco router is sending out the Level 1 IIH packets and the Level 2 IIH packets on Ethernet interface 0. Router 1 is not receiving the IIHs from NE 1 on Ethernet interface 0.
Router1# debug isis adjacencyIS-IS Adjacency related packets debugging is onRouter1#ISIS-Adj: Sending L2 IIH on Ethernet0ISIS-Adj: Sending L1 IIH on Ethernet0ISIS-Adj: Sending L2 IIH on Ethernet0ISIS-Adj: Sending L1 IIH on Ethernet0It is also recommended that the Ethernet interface be verified as operational. In this example, the problem was with the software on the SDH network element. The SDH node had to be rebooted for the IS-IS to come up and send the IIH.
Take another look at the problems described previously for Figure 39; that is, the IS-IS adjacency will not come up between Router 1 and NE 1. A report from the show clns interface EXEC command indicates that the interface is up, but no Level 1 adjacency is formed because the value is 0 (report shown in bold text for purpose of example):
Router1# show clns interface Ethernet 0Ethernet0 is up, line protocol is upChecksums enabled, MTU 1497, Encapsulation SAPERPDUs enabled, min. interval 10 msec.RDPDUs enabled, min. interval 100 msec., Addr Mask enabledCongestion Experienced bit set at 4 packetsCLNS fast switching enabledCLNS SSE switching disabledDEC compatibility mode OFF for this interfaceNext ESH/ISH in 32 secondsRouting Protocol: IS-ISCircuit Type: level-1-2Interface number 0x0, local circuit ID 0x1Level-1 Metric: 10, Priority: 64, Circuit ID: 0000.0000.60B1.01Number of active level-1 adjacencies: 0Level-2 Metric: 10, Priority: 64, Circuit ID: 0000.0000.60B1.01Number of active level-2 adjacencies: 0Next IS-IS LAN Level-1 Hello in 2 secondsNext IS-IS LAN Level-2 Hello in 1 secondsNext, enter the debug isis adjacency command on Router 1. In the following example, Router 1 is sending Level 1 and Level 2 IIHs, and receives an IIH from system identifier 0010.7bc7.ae41, which is the NE 1. The circuit type is Level 1. The circuit identifier is 0000.0000.0130.01, which is the view NE 1 has of the DIS (key reports shown in bold text text for purpose of example).
ISIS-Adj: Sending L1 IIH on Ethernet0ISIS-Adj: Sending L2 IIH on Ethernet0ISIS-Adj: Rec L1 IIH from 0010.7bc7.ae41 (Ethernet0), cir type 1, cir id 0000.0000.0130.01ISIS-Adj: Area mismatch, level 1 IIH on Ethernet0ISIS-Adj: Sending L1 IIH on Ethernet0ISIS-Adj: Sending L2 IIH on Ethernet0The report by the debug isis adjacency command lists an area mismatch for Level 1 IIH. The IS-IS router NE 1 and Router 1 do not have the same area identifier. The NSAP for both devices needs to be checked.
In the following example, the Cisco router is running an IS-IS multiarea, so the IS-IS process associated with Ethernet interface 0 must be checked. The report indicates that IS-IS process area_02 was assigned to Ethernet interface 0.
router isis area_02net 39.840f.8011.9999.0000.1111.0200.0000.0000.0130.00To prevent the mismatch, IS-IS process area_01 should have been assigned to Ethernet interface 0:
router isis area_01net 39.840f.8011.9999.0000.1111.0100.0000.0000.0130.00The following example shows how to verify that the IS-IS adjacency shown in Figure 39 is coming up correctly after the change. NE 1 is configured as Level 1 IS-IS. Router 1 is configured as a Level 1 and Level 2 router. The debugging is being done on Router 1. Router 1 is sending Level 1 and Level 2 IIHs. Router 1 is receiving Level 1 IIHs from NE 1. The IS-IS adjacencies are coming up correctly.
Router1# debug isis adjacencyIS-IS Adjacency related packets debugging is onRouter1#ISIS-Adj: Sending L2 IIH on Ethernet0ISIS-Adj: Sending L1 IIH on Ethernet0ISIS-Adj: Sending L2 IIH on Ethernet0ISIS-Adj: Sending L1 IIH on Ethernet0ISIS-Adj: Sending L2 IIH on Ethernet0ISIS-Adj: Sending L1 IIH on Ethernet0ISIS-Adj: Sending L2 IIH on Ethernet0ISIS-Adj: Rec L1 IIH from 00e0.b064.4325 (Ethernet0), cir type 1, cir id 0000.0000.60B1.01ISIS-Adj: Sending L1 IIH on Ethernet0ISIS-Adj: Sending L2 IIH on Ethernet0In the following example output from the show clns isis neighbors command, Router 1 and TN-16 Node 1 have formed a Level 1 adjacency. The designated Level 1 IS on the LAN is circuit identifier 0000.0000.60B1 according to the system identifier 0000.0000.0F0F.
Router1# show clns isis neighborsSystem Id Interface State Type Priority Circuit Id Format0000.0000.0F0F Et0 Up L1 64 0000.0000.60B1.01 Phase VVerifying IS-IS Network Connectivity Using the ping and traceroute Commands
The route to a specific network element can be traced with the traceroute command. The traceroute command uses the Time to Live (TTL) field in an IP datagram to cause routers in the path to send back error messages. The IP version of the traceroute command is the default, and there is a CLNS version of the command. The following example shows a route traced to device NE14B for the sample network shown in Figure 40.
Figure 40 Sample Network for Determining IS-IS Network Topology
3640A# traceroute clns NE14BType escape sequence to abort.Tracing the route to NE14B (39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00)1 NE14A(39.840f.8011.9999.0000.1111.0001.00e0.b064.4324.00) 0 msec ! 0 msec ! 4 msec !2 NE14B(39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00) 0 msec ! 0 msec ! 0 msec !The ping clns EXEC command is another method to determine connectivity to an IS-IS router or ES. The following example shows sample output of the ping clns EXEC command to device NE14B:
3640A# ping clns NE14BType escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 msThe following example shows debug command output from the CLNS packets sent from the ping clns command. The ping originates from the Cisco 3640 router with NET 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00, to device NE14B with NET 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00.
3640A#00:03:45: CLNS: Originating packet, size 10000:03:45: from 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00to 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00via 00E0.B064.4324 (FastEthernet3/0.1 00e0.b064.4325)00:03:45: CLNS: Echo Reply PDU received on FastEthernet3/0.1!00:03:45: CLNS: Originating packet, size 10000:03:45: from 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00to 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00via 00E0.B064.4324 (FastEthernet3/0.1 00e0.b064.4325)00:03:45: CLNS: Echo Reply PDU received on FastEthernet3/0.1!00:03:45: CLNS: Originating packet, size 10000:03:45: from 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00to 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00via 00E0.B064.4324 (FastEthernet3/0.1 00e0.b064.4325)00:03:45: CLNS: Echo Reply PDU received on FastEthernet3/0.1!00:03:45: CLNS: Originating packet, size 10000:03:45: from 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00to 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00via 00E0.B064.4324 (FastEthernet3/0.1 00e0.b064.4325)00:03:45: CLNS: Echo Reply PDU received on FastEthernet3/0.1!00:03:45: CLNS: Originating packet, size 10000:03:45: from 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00to 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00via 00E0.B064.4324 (FastEthernet3/0.1 00e0.b064.4325)00:03:45: CLNS: Echo Reply PDU received on FastEthernet3/0.1!The Cisco IOS ping EXEC command does not require the clns keyword in the command string. It is possible to enter the ping command with the CLNS host identifier or the NET and get the same results. The following examples show sample reports from both command strings:
3640A# ping 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00Translating "39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00"...domain server (255.255.255.255)Type escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms3640A# ping NE14BTranslating "NE14B"...domain server (255.255.255.255)Type escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 msTroubleshooting Network Connections Using the ping clns Command
A typical service provider network is shown in Figure 41. In this troubleshooting example, the OSS cannot access device NE26B. The technician at the network operations center (NOC) has connectivity to the central office router.
Figure 41 Typical Service Provider Network
Figure 42 shows router 3640A and connections to the network elements in the central office. The NOC technician has telnetted to router 3640A and is troubleshooting the OSI connectivity to network element device NE26B.
Figure 42 Troubleshooting OSI Connectivity
The first part of the example uses the ping clns EXEC command to try a connection to device NE26B.
Note
In the following example, the ping clns command was not successful at making the connection:
3640A# ping clns NE26BType escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 secondsCLNS: cannot send ECHO.CLNS: cannot send ECHO.CLNS: cannot send ECHO.CLNS: cannot send ECHO.CLNS: cannot send ECHO.Success rate is 0 percent (0/5)Next, issue the ping clns EXEC command to try a connection to the GNE. In the following example, the network element supports the ping clns command and a successful connection is made:
3640A# ping clns NE26AType escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 msThe router is configured with clns host command statements for the network elements, so the technician did not have to type out the whole NSAP address; see the section "Mapping NSAPs to CLNS Host Names" section.
The next step is to determine whether the IS-IS adjacency is coming up between router 3640A and device NE26A. Use the show clns interface EXEC command to see that the number of Level 1 IS-IS adjacencies is 0 (text in bold for purpose of example):
3640A# show clns interface fastethernet 3/0.3FastEthernet3/0.3 is up, line protocol is upChecksums enabled, MTU 1497, Encapsulation SAPERPDUs enabled, min. interval 10 msec.RDPDUs enabled, min. interval 100 msec., Addr Mask enabledCongestion Experienced bit set at 4 packetsCLNS fast switching enabledCLNS SSE switching disabledDEC compatibility mode OFF for this interfaceNext ESH/ISH in 21 secondsRouting Protocol: IS-IS (area0003)Circuit Type: level-1-2Interface number 0x0, local circuit ID 0x1Level-1 Metric: 10, Priority: 127, Circuit ID: 3640A.01Level-1 IPv6 Metric: 10Number of active level-1 adjacencies: 0Next IS-IS LAN Level-1 Hello in 51 millisecondsThe next step is to check processes in area 0003. Use the show clns neighbors EXEC command to display the areas. In the following example, the system identifier for device NE26A is listed and is on Fast Ethernet interface 3/0.3. The protocol that is coming up is ES-IS; therefore, one of the systems is configured as an ES on this interface.
3640A# show clns neighborsArea area0001:System Id Interface SNPA State Holdtime Type ProtocolNE15A Fa3/0.1 0010.7bd8.c7d0 Up 21 L1 IS-ISNE14A Fa3/0.1 00e0.b064.4325 Up 25 L1 IS-ISArea area0002:System Id Interface SNPA State Holdtime Type ProtocolNE25A Fa3/0.2 00e0.b064.434e Up 24 L1 IS-ISArea area0003:System Id Interface SNPA State Holdtime Type ProtocolNE26A Fa3/0.3 00d0.5872.9720 Up 278 IS ES-ISUse the debug isis adjacency command to watch IS-IS adjacencies come up. IIHs are being received by router 3640A on Fast Ethernet interfaces 3/0.2 and 3/0.1. IIHs are being sent by router 3640A on Fast Ethernet interfaces 3/0.1, 3/0.2, and 3/0.3. The problem is with device NE26A; it is not sending Level 1 IIHs on Fast Ethernet interface 3/0.3.
3640A# debug isis adjacencyIS-IS Adjacency related packets debugging is on3640A#01:23:04: ISIS-Adj (area0002): Rec L1 IIH from 00e0.b064.434e (FastEthernet3/0.2), cir type L1, cir id 0010.7BC7.AE40.01, length 14701:23:05: ISIS-Adj (area0001): Rec L1 IIH from 00e0.b064.4325 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14701:23:06: ISIS-Adj (area0001): Sending L2 LAN IIH on FastEthernet3/0.1, length 149701:23:06: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149701:23:07: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149701:23:07: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149701:23:09: ISIS-Adj (area0001): Rec L1 IIH from 0010.7bd8.c7d0 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14701:23:09: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149701:23:09: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149701:23:10: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149701:23:12: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149701:23:12: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149701:23:12: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149701:23:13: ISIS-Adj (area0001): Rec L1 IIH from 00e0.b064.4325 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14701:23:14: ISIS-Adj (area0002): Rec L1 IIH from 00e0.b064.434e (FastEthernet3/0.2), cir type L1, cir id 0010.7BC7.AE40.01, length 14701:23:14: ISIS-Adj (area0001): Sending L2 LAN IIH on FastEthernet3/0.1, length 149701:23:15: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149701:23:15: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149701:23:15: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149701:23:18: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149701:23:18: ISIS-Adj (area0001): Rec L1 IIH from 0010.7bd8.c7d0 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14701:23:18: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149701:23:18: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149701:23:21: ISIS-Adj (area0001): Sending L1 LAN IIH on FastEthernet3/0.1, length 149701:23:21: ISIS-Adj (area0003): Sending L1 LAN IIH on FastEthernet3/0.3, length 149701:23:21: ISIS-Adj (area0002): Sending L1 LAN IIH on FastEthernet3/0.2, length 149701:23:22: ISIS-Adj (area0001): Rec L1 IIH from 00e0.b064.4325 (FastEthernet3/0.1), cir type L1, cir id 0010.7BC7.AE40.01, length 14701:23:23: ISIS-Adj (area0002): Rec L1 IIH from 00e0.b064.434e (FastEthernet3/0.2), cir type L1, cir id 0010.7BC7.AE40.01, length 147The next step is to debug the ES-IS protocol using the debug clns esis packets command. The following example shows a configuration error by the technician:
3640A# debug clns esis packetsES-IS packets debugging is on3640A#01:32:22: ES-IS: ISH from 00e0.b064.4325 (FastEthernet3/0.1), HT 30001:32:26: ES-IS: ISH from 00e0.b064.434e (FastEthernet3/0.2), HT 30001:32:30: ES-IS: ISH sent to All ESs (FastEthernet3/0.1): NET 39.840f.8011.9999.0000.1111.0001.0010.7bc7.ae40.00, HT 300, HLEN 3001:32:35: ES-IS: ISH from 00d0.5872.9720 (FastEthernet3/0.3), HT 300Router 3640A first receives an IS Hello (ISH) from device NE14A (SNPA 00e0.b064.4325) on Fast Ethernet interface 3/0.1. The holdtime is 300 seconds before discarding. Router 3640A receives an ISH from device NE25A (SNPA 00e0.b064.434e) on Fast Ethernet interface 3/0.2. An ISH was sent to all end systems on Fast Ethernet interface 3/0.1 with a hold time of 300 seconds. The packet header length is 30 bytes. The last packet is an ISH from device NE26A (SNPA 00d.0.5872.9720) with a hold time of 300 seconds. Device NE26A has only the ES-IS protocol turned up. Router 3640A is sending out ESHs on all the Fast Ethernet interfaces. Device NE26A is sending an ISH. Device NE26A is configured only to support ES-IS, which was determined because ISHs were being sent, but not IIH.
Once device NE26A is correctly configured for IS-IS routing, verify the correct adjacency using the show clns neighbors EXEC command. The following example shows the report displayed:
3640A# show clns neighborsArea area0001:System Id Interface SNPA State Holdtime Type ProtocolNE15A Fa3/0.1 0010.7bd8.c7d0 Up 23 L1 IS-ISNE14A Fa3/0.1 00e0.b064.4325 Up 22 L1 IS-ISArea area0002:System Id Interface SNPA State Holdtime Type ProtocolNE25A Fa3/0.2 00e0.b064.434e Up 24 L1 IS-ISArea area0003:System Id Interface SNPA State Holdtime Type ProtocolNE26A Fa3/0.3 00d0.5872.9720 Up 22 L1 IS-ISThe following example shows the results of ping clns commands:
3640A# ping clns NE26AType escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms3640A# ping clns NE26BType escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 msSuccessful connection indicates that the network is up and working.
Troubleshooting Network Connections Using TARP PDUs
A TARP type 5 PDU can be used to troubleshoot the network. (See the "Mapping NSAPs to Device Names Using TARP" section for more information about TARP.) The type 5 PDU is sent to a specific NSAP address requesting the TID. The analogy would be sending an IP ping command in an IP network. The Cisco IOS software provides a ping clns EXEC command, but not all network vendors of SONET/SDH equipment have implemented support for the CLNS ping command. In Figure 43, a TARP type 5 PDU is being sent from router 3640A to device NE26B. Figure 43 also shows that the response is a type 3 PDU.
Figure 43 TARP Type 5 PDU Transmissions
The following example shows how to issue the debug tarp packets and debug tarp events commands and interpret the output:
3640A# debug tarp packetsTARP packet info debugging is on3640A# debug tarp eventsTARP events debugging is onThe tarp query is issued for 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.003640A# tarp query 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.00Type escape sequence to abort.Sending TARP type 5 PDU, timeout 40 seconds ...TID corresponding to NET 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.00 is NE26BThe debug tarp packets command output shows the type 5 PDU being sent to its destination:
3640A#00:15:22: TARP-PA: Originated TARP packet, type 5, todestination 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.0000:15:22: TARP-EV: Packet from 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.00 has a00:15:22: sequence number (4) > that in LDB cache entry (3)00:15:22: - updating cache entryA type 3 PDU is received on Fast Ethernet interface 3/0.3. The PDU is the response from device NE26B for the type 5 PDU.
00:15:22: TARP-PA: Received TARP type 3 PDU on interface FastEthernet3/0.300:15:22: Lft = 100, Seq = 4, Prot type = 0xFE, URC = TRUE00:15:22: Ttid len = 0, Stid len = 5, Prot addr len = 2000:15:22: Packet sent/propagated by 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.af00:15:22: Originator's NSAP : 39.840f.8011.9999.0000.1111.0003.0010.7b17.f880.0000:15:22: Originator's TID : NE26BThe debug tarp event command output indicates that device NE26B is entered into the TARP data cache:
00:15:22: TARP-PA: Created new DYNAMIC cache entry for NE26BThe tarp query command issues a TARP type 5 PDU, which is sent to a specific network and requests the TID or name of the network element.
The following example shows a TARP query being sent to device NE14B with NET 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00. The TID is device NE14B. Note that the CLNS host name and the TID were both set to device NE14B, which was chosen by the system administrator.
3640A# tarp query 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00Type escape sequence to abort.Sending TARP type 5 PDU, timeout 40 seconds ...TID corresponding to NET 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00 is NE14BCisco IOS debug commands allow packets issued from a tarp query command to be examined. The following examples show output from the debug tarp events and debug tarp packets EXEC commands. The debug command output is based on the tarp query command. (Bold text highlights key parts of the report for purpose of example.)
3640A# debug tarp eventsTARP events debugging is on3640A# debug tarp packetsTARP packet info debugging is on3640A#00:33:23: TARP-PA: Originated TARP packet, type 5, todestination 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.0000:33:23: TARP-PA: Received TARP type 3 PDU on interface FastEthernet3/0.100:33:23: Lft = 100, Seq = 2, Prot type = 0xFE, URC = TRUE00:33:23: Ttid len = 0, Stid len = 5, Prot addr len = 2000:33:23: Packet sent/propagated by 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.af00:33:23: Originator's NSAP : 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.0000:33:23: Originator's TID : NE14B00:33:23: TARP-PA: Created new DYNAMIC cache entry for NE14BThe output indicates a TARP type 5 PDU is sent to NET 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00. The packet that was receive is a type 3 PDU and was sent by NSAP 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.af. The network selector on the NSAP is "af," which designates the TARP application. The output also reports the originator's NSAP as 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00. More accurately, this label should be the originator's NET. The originator's TID is listed as NE14B.
If the NSAP or NET of the IS-IS router is not known but the TID is known, use the tarp resolve EXEC command to test connectivity between devices. The following example shows sample output:
3640A# tarp resolve NE14BType escape sequence to abort.Sending TARP type 1 PDU, timeout 15 seconds ...NET corresponding to TID NE14B is 39.840f.8011.9999.0000.1111.0001.0050.7363.7b40.00In the output, the router will wait 15 seconds for a response before issuing a TARP type 2 PDU. Device NE14B responds within 15 seconds with its NET, which is the NSAP address and selector value of 00.
Distribution Layer Configuration
This section focuses on the distribution layer of Cisco's three-tiered network architecture and contains these sections:
•
•
Configuring the Distribution Network
The hypothetical network that will be used in this section assumes the network is laid out in three geographic areas. Each geographic area will be a separate Open System Interconnection (OSI) domain. The core routers will be placed in a separate domain in the center. Figure 44 shows the concept; domain designations have also been provided.
Figure 44 OSI Domains for the Distribution Network
As previously mentioned in this document, Cisco recommends that customers implement a three-tiered architecture in the data communications network (DCN) (see "The Cisco Three-Tiered DCN Network Architecture" section). The network shown in Figure 45 has the access layer and distribution routers in the same OSI domain.
Figure 45 Three-Tiered Architecture with Routing Protocols and Domains
The IS-IS routing protocol is running within the OSI domain. The core routers have been placed in a separate OSI domain. An Interdomain Routing Protocol (IDRP) is running between the distribution and core routers. The Level 2 routers within a domain must be connected contiguously to provide access throughout the domain. In Figure 45, the distribution routers are connected with Ethernet, and IS-IS is run over the Ethernet. The IDRP runs over a separate Ethernet network, as shown in Figure 45. The two Ethernet networks could also be configured using VLANs. A redundant alternative would be to install two switches and configure a separate VLAN for IS-IS and the IDRP on each switch. The service provider should not configure IS-IS and the IDRP on the same VLAN if the IDRP is ISO-IGRP.
The distribution routers should be configured in one IS-IS area that is shared by only the distribution routers in this site. The distribution routers can be configured as Level 1/Level 2 routers. The distribution routers will form a Level 2 adjacency to the access routers over the WAN links, because the access routers in the central office will be in a separate OSI area. The distribution routers will form a Level 1/Level 2 adjacency over the LAN connecting the routers at the distribution site. The service provider should make sure the routers have redundant LANs tiering the area together. The Level 1 area must stay contiguous. In Figure 46, there is a separate VLAN configured for IS-IS on each switch. Figure 46 also shows the adjacencies.
Figure 46 Three-Tiered Architecture with Level 1/Level 2 Adjacencies
An alternative method is to configure the distribution routers as Level 2 routers only. Use the is-type level-2-only command to do so. The service provider would still place all the distribution routers at site A in the same OSI area. The advantage of configuring the routers as Level 2 is that the router needs to maintain only one set of adjacencies and one database. In other words, the Level 1 database and the Level 1 adjacencies are eliminated, which lowers the overhead on the router. The adjacencies are shown in Figure 47.
Figure 47 Three-Tiered Architecture with Level 2 Adjacencies
Distribution Network Configuration Example
In the following sample configuration, the distribution router is in domain 3333 and area0003. The Connectionless Network Service (CLNS) configuration for a distribution router in Distribution site A is listed. The host name of the router is 7507A. Ethernet interfaces 0/0 and 0/1 are connected to two separate LANs, which make up the redundant LANs in the distribution center. Serial interfaces 1/0 through 6/7 are connected using a DS1 link to a separate access site or central office. A second distribution site is recommended for redundancy, as shown in Figure 47. The second distribution routers would be connected to the same access sites with a DS1. The configuration would be very similar.
hostname Access7507A!clns routing!!interface Ethernet0/0clns router isis area0003tarp enable!interface Ethernet0/1clns router isis area0003tarp enable!interface Serial1/0description DS1 City1clns router isis area0003tarp enable!interface Serial1/1description DS1 City2clns router isis area0003tarp enable!interface Serial1/2description DS1 City3clns router isis area0003tarp enable!interface Serial1/3description DS1 City4clns router isis area0003tarp enable!interface Serial1/4description DS1 City5clns router isis area0003tarp enable!interface Serial1/5description DS1 City6clns router isis area0003tarp enable!interface Serial1/6description DS1 City7clns router isis area0003tarp enable!interface Serial1/7description DS1 City8clns router isis area0003tarp enable!interface Serial4/0description DS1 City9clns router isis area0003tarp enable!interface Serial4/1description DS1 City10clns router isis area0003tarp enable!interface Serial4/2description DS1 City11clns router isis area0003tarp enable!interface Serial4/3description DS1 City12clns router isis area0003tarp enable!interface Serial4/4description DS1 City13clns router isis area0003tarp enable!interface Serial4/5description DS1 City14clns router isis area0003tarp enable!interface Serial4/6description DS1 North1clns router isis area0003tarp enable!interface Serial4/7description T1 City15clns router isis area0003tarp enable!interface Serial5/0description DS1 City16clns router isis area0003tarp enable!interface Serial5/1description DS1 City17clns router isis area0003tarp enable!interface Serial5/2description City18clns router isis area0003tarp enable!interface Serial5/3description DS1 City19clns router isis area0003tarp enable!interface Serial5/4description DS1 Main1clns router isis area0003tarp enable!interface Serial5/5description DS1 City20clns router isis area0003tarp enable!interface Serial5/6description DS1 City21clns router isis area0003tarp enable!interface Serial5/7description DS1 City22clns router isis area0003tarp enable!interface Serial6/0description DS1 City23clns router isis area0003tarp enable!interface Serial6/1description DS1 City24clns router isis area0003tarp enable!interface Serial6/2description DS1 City25clns router isis area0003tarp enable!interface Serial6/3description DS1 City26clns router isis area0003tarp enable!interface Serial6/4description DS1 City27clns router isis area0003tarp enable!interface Serial6/5description DS1 City28clns router isis area0003tarp enable!interface Serial6/6description DS1 City29clns router isis area0003tarp enable!interface Serial6/7description DS1 City30clns router isis area0003tarp enable!router isis area0003net 39.840f.8011.9999.0000.3333.0003.1234.0c15.86a3.00!tarp runtarp tid Access7507ACore Layer Configuration
The following sections describe how to configure the core portion of the OSI network:
•
OSI Domains and the Core
A large OSI network is made up of multiple OSI domains. The recommended architectural design for a large OSI network is to place the core in an OSI domain. The individual OSI domains are connected to the core at two points. Figure 48 illustrates this concept. The core configuration can be configured with static routes, ISO-IGRP, or multiprotocol BGP. Multiprotocol BGP configuration is described in the feature module titled Multiprotocol BGP (MP-BGP) Support for CLNS.
ISO-IGRP can be used in the core to link the three OSI domains. The IS-IS routing protocol will be run in each of the three IS-IS domains, as shown in Figure 48. The IS-IS routing protocol will be run on the access routers and the distribution routers. The core routers will be the boundary between the IS-IS domains and the ISO-IGRP domain, and the core routers will run the IS-IS and ISO-IGRP routing protocols. The ISO-IGRP routes will be redistributed directly into IS-IS. IS-IS should not be redistributed directly into ISO-IGRP. The routes injected into ISO-IGRP should be summarized. The domain can be summarized with a single static route that can be injected into the core.
Configuring the Core Network
The example network used in this section is based on a lab network. The lab network sample configurations will have only one core, instead of the recommended two cores. This section will describe some configuration tricks to implement a second core. The lab network has three routers in the core, which will connect together using Ethernet. In a real network, WAN links, rather than Ethernet, would be used to make the connections. The core routers are connected using Ethernet to distribution routers as shown in Figure 48. The four domains are addressed as follows:
39.840f.8011.9999.0000.111139.840f.8011.9999.0000.222239.840f.8011.9999.0000.333339.840f.8011.9999.0000.bbbbFigure 48 Sample Core Network
In the lab network, each backbone router is connected using an Ethernet connection to a distribution router. The distribution router is connected using Ethernet to an access router. To simplify the example, the access site is not redundant and is sufficient for examining the core.
Core Network Configuration Examples
This section contains the following configuration examples:
•
•
•
•
•
•
•
•
Configuring the First Core Router
Start configuration of the core routers with the router named BackBone1. The router will be configured to participate in both IS-IS domain 1111 and area 9999. The IS-IS process identifier is area9999. Remember that the process identifier is similar in concept to a UNIX process identifier.
!router isis area9999net 39.840f.8011.9999.0000.1111.9999.000d.bc2e.6d80.00redistribute iso-igrp backboneThe backbone has been assigned its own domain bbbb and all three core routers have been placed in area 1001. The ISO-IGRP process identifier is called backbone.
The following example shows the ISO-IGRP configuration:
router iso-igrp backbonenet 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00redistribute staticThe challenge is to summarize the domain into the core using a static route. The route is summarized with the following clns route command. The following clns route command configures a path to domain 1111 or 39.840f.8011.9999.0000.1111. The route can be accessed using Ethernet interface 1/0 on router BackBone1.
clns route 39.840f.8011.9999.0000.1111 Ethernet1/0 000d.bc2e.6d90Ethernet interface 1/0 is the BackBone1 interface connected to the distribution router, which is labeled Distribution1. The MAC address of Ethernet interface 1/0 on the BackBone1 router is 000d.bc2e.6d90. Use the show interfaces command, as the following sample output shows, to confirm the MAC address.
BackBone1# show interfaces ethernet 1/0Ethernet1/0 is up, line protocol is downHardware is AmdP2, address is 000d.bc2e.6d90 (bia 000d.bc2e.6d90)Internet address is 192.168.10.1/26MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,reliability 128/255, txload 1/255, rxload 1/255Encapsulation ARPA, loopback not setKeepalive set (10 sec)ARP type: ARPA, ARP Timeout 04:00:00Last input never, output 00:00:08, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/40 (size/max)5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec0 packets input, 0 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored0 input packets with dribble condition detected254 packets output, 18476 bytes, 0 underruns254 output errors, 0 collisions, 4 interface resets0 babbles, 0 late collision, 0 deferred255 lost carrier, 0 no carrier0 output buffer failures, 0 output buffers swapped outFigure 48 shows that router BackBone1 on Fast Ethernet interface 0/0 is connected to router BackBone2 on Fast Ethernet interface 0/0. Router BackBone1 on FastEthernet interface 0/1 is connected to router BackBone3 on Fast Ethernet interface 0/1. ISO-IGRP is turned up on these interfaces. For purpose of example, the following configuration shows the routing processes for ISO-IGRP in bold text. The ISO-IGRP process is called backbone. TARP is enabled on the backbone.
interface FastEthernet0/0ip address 192.168.20.1 255.255.255.252speed autohalf-duplexclns router iso-igrp backbonetarp enableinterface FastEthernet0/1ip address 192.168.20.5 255.255.255.252speed autohalf-duplexclns router iso-igrp backbonetarp enableFigure 48 shows that BackBone1 router Ethernet interface 1/0 is connected to the distribution router Distribution1. The IS-IS routing protocol is run over the Ethernet interface 1/0 connection between router BackBone1 and router Distribution1. The core router BackBone1 participates in domain 1111 and the backbone domain bbbb. The following example shows the configuration for Ethernet interface 1/0:
interface Ethernet1/0ip address 192.168.10.1 255.255.255.192half-duplexclns router isis area9999Verifying the First Core Router Configuration
Use the show clns EXEC command to check interface configuration for the core router. The following example shows three interfaces configured for CLNS. Two NETs are shown, one NET for ISO-IGRP and a second for IS-IS.
BackBone1# show clnsGlobal CLNS Information:3 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00NET: 39.840f.8011.9999.0000.1111.9999.000d.bc2e.6d80.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)ISO-IGRP level-1 Router: backboneRouting for Domain: 39.840F.8011.9999.0000.BBBB, Area: 1001ISO-IGRP level-2 Router: DOMAIN_backboneRouting for Domain: 39.840F.8011.9999.0000.BBBBIS-IS level-1-2 Router: area9999Routing for Area: 39.840f.8011.9999.0000.1111.9999Use the show clns neighbors EXEC command to verify that there are three neighbors. BackBoneR1 has a Level 1 ISO-IGRP adjacency on Fast Ethernet interface 0/1 with BackBoneR3. The router Distribution1 has a Level 1/Level 2 adjaceny on Ethernet interface 1/0. BackBoneR2 has a Level 1 ISO-IGRP adjacency on Fast Ethernet interface 0/0 with BackBoneR3. The following show clns neighbors command output matches the configuration listed earlier and in Figure 48.
BackBoneR1# show clns neighborsSystem Id Interface SNPA State Holdtime Type ProtocolBackBoneR3 Fa0/1 0010.7bd8.c7d1 Up 39 L1 ISO-IGRPDistribution1 Et1/0 0010.7b17.f880 Up 9 L1L2 IS-ISBackBoneR2 Fa0/0 000d.bc2e.6d40 Up 50 L1 ISO-IGRP
Use the show clns neighbors detail EXEC command to show additional detail about the neighbors.
BackBoneR1# show clns neighbors detailSystem Id Interface SNPA State Holdtime Type ProtocolBackBoneR3 Fa0/1 0010.7bd8.c7d1 Up 36 L1 ISO-IGRPArea Address(es): 39.840f.8011.9999.0000.bbbb.1001Uptime: 01:32:07Distribution1 Et1/0 0010.7b17.f880 Up 7 L1L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.1111.9999Uptime: 01:32:08NSF capableBackBoneR2 Fa0/0 000d.bc2e.6d40 Up 47 L1 ISO-IGRPArea Address(es): 39.840f.8011.9999.0000.bbbb.1001Uptime: 01:32:08Configuring a Second Core Router
The configuration for a second core router named BackBone2 in the example network is next. The router will be configured to participate in both IS-IS domain 2222 and area 0002. The IS-IS process identifier is area0002. Remember the process identifier is similar in concept to a UNIX process identifier. In the following example, notice the command to redistribute the routes in ISO-IGRP back into IS-IS. The number of routes will be small, because each domain is summarized with a static route into ISO-IGRP.
!router isis area0002net 39.840f.8011.9999.0000.2222.0002.000d.bc2e.6d40.00redistribute iso-igrp backboneConfiguring the ISO IGRP Routing Protocol
This section describes how to configure the ISO-IGRP routing protocol. The backbone has been assigned its own domain as bbbb, and all three core routers have been placed in area 1001. In the following ISO-IGRP configuration example, notice the redistribute static command that redistributes the static route that summarizes domain 2222 into ISO-IGRP:
router iso-igrp backbonenet 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00redistribute staticThe challenge is to summarize the domain into the core on a static route. The route is summarized with the clns route command, as shown in the following example. The clns route command configures a path to domain 2222 or 39.840f.8011.9999.0000. 2222. The route can be accessed using Ethernet interface 1/0, on router BackBone1.
clns route 39.840f.8011.9999.0000.2222 Ethernet1/0 000d.bc2e.6d50Ethernet interface 0/1 is connected to the distribution router labeled Distribution1. The MAC address of Ethernet interface 1/0 on the BackBone1 router is 000d.bc2e.6d50. Use the show interfaces command, as the following sample output shows, to confirm the MAC address.
BackBoneR2# show interfaces ethernet 1/0Ethernet1/0 is up, line protocol is upHardware is AmdP2, address is 000d.bc2e.6d50 (bia 000d.bc2e.6d50)Internet address is 192.168.50.1/26MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,reliability 255/255, txload 1/255, rxload 1/255Encapsulation ARPA, loopback not setKeepalive set (10 sec)ARP type: ARPA, ARP Timeout 04:00:00Last input 00:00:00, output 00:00:04, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/40 (size/max)5 minute input rate 8000 bits/sec, 1 packets/sec5 minute output rate 4000 bits/sec, 0 packets/sec2273 packets input, 2301496 bytes, 0 no bufferReceived 2266 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored0 input packets with dribble condition detected1048 packets output, 816754 bytes, 0 underruns0 output errors, 0 collisions, 4 interface resets0 babbles, 0 late collision, 0 deferred0 lost carrier, 0 no carrier0 output buffer failures, 0 output buffers swapped outFigure 48 shows that BackBone2 Fast Ethernet interface 0/0 is connected to the BackBone1 router, and BackBone2 Fast Ethernet interface 0/1 is connected to the BackBone3 router. ISO-IGRP is turned up on these interfaces. For purpose of example, the following sample configuration shows the routing process for ISO-IGRP in bold text. The ISO-IGRP process is called backbone. TARP is enabled on the backbone.
interface FastEthernet0/0ip address 192.168.20.2 255.255.255.252speed autohalf-duplexclns router iso-igrp backbonetarp enable!interface FastEthernet0/1ip address 192.168.20.10 255.255.255.252speed autohalf-duplexclns router iso-igrp backbonetarp enableFigure 48 shows Ethernet interface 1/0 is connected to the distribution router labeled Distribution1. The IS-IS routing protocol is run over the Ethernet interface 1/0 connection between router BackBone2 and router Distribution2. The core router BackBone2 participates in domain 2222 and the backbone domain bbbb. The following example shows the configuration for Ethernet interface 1/0:
interface Ethernet1/0ip address 192.168.50.1 255.255.255.192half-duplexclns router isis area0002tarp enableConfiguring a Third Core Router
Following is the configuration for the BackBone3 router, without step-by-step explanation. See the "Configuring the First Core Router" and "Verifying the First Core Router Configuration" sections for more details on core router configuration and verification.
router iso-igrp backboneredistribute staticnet 39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00!router isis area0033redistribute iso-igrp backbonenet 39.840f.8011.9999.0000.3333.0033.0010.7bd8.c7d0.00!clns route 39.840f.8011.9999.0000.3333 Ethernet5/0 0010.7bd8.c821!interface FastEthernet0/0ip address 192.168.20.9 255.255.255.252duplex autospeed autoclns router iso-igrp backbonetarp enable!interface FastEthernet0/1ip address 192.168.20.6 255.255.255.252duplex autospeed autoclns router iso-igrp backbonetarp enable!interface Ethernet5/0ip address 192.168.100.1 255.255.255.252half-duplexclns router isis area0033Verifying the Routing Table
To verify the routing table created on the BackBoneR1 router, use the show clns route EXEC command. You will see the static route to domain 39.840f.8011.9999.0000.1111. The routes to domains 39.840f.8011.9999.0000.2222 and 39.840f.8011.9999.0000.3333 are learned from the ISO-IGRP routing protocol. You will also see the IS-IS routes to areas within domain 39.840f.8011.9999.0000.1111.
BackBoneR1# show clns routeISO-IGRP Routing Table for Domain 39.840F.8011.9999.0000.BBBB, Area 1001System Id Next-Hop SNPA Interface Metric StateBackBoneR3 BackBoneR3 0010.7bd8.c7d1 Fa0/1 110 UpBackBoneR2 BackBoneR2 000d.bc2e.6d40 Fa0/0 110 UpBackBoneR1 0000.0000.0000 -- -- 0 UpISO-IGRP Routing Table for Domain 39.840F.8011.9999.0000.BBBBArea Id Next-Hop SNPA Interface Metric State1001 0000.0000.0000 -- -- 0 UpCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.1111.9999 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.bbbb [2/0], Local ISO-IGRP DomainC 39.840f.8011.9999.0000.1111.9999.000d.bc2e.6d80.00 [1/0], Local IS-IS NETC 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00 [1/0], Local ISO-IGRP NETi 39.840f.8011.9999.0000.1111.0003 [110/20]via Distribution1, Ethernet1/0S 39.840f.8011.9999.0000.1111 [10/0]via Ethernet1/0I 39.840f.8011.9999.0000.2222 [100/110]via BackBoneR2, FastEthernet0/0I 39.840f.8011.9999.0000.3333 [100/110]via BackBoneR3, FastEthernet0/1Verifying Network Connectivity
To verify network connectivity, use the clns ping and trace EXEC commands.
In the following example, the ping is from access router Access1 in domain 1111 to access router Access2 in domain 2222:
Access2# ping clns Access1Type escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 msThe following example traces the route from Access2 to Access1; the route matches what is shown in Figure 48.
Access2# trace clns Access1Type escape sequence to abort.Tracing the route to Access1 (39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00)1 Distribution2(39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00) 0 msec ! 0 msec ! 0 msec !2 BackBoneR2(39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00) 4 msec ! 4 msec ! 4 msec !3 BackBoneR1(39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00) 4 msec ! 4 msec ! 4 msec !4 Distribution1(39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00) 4 msec ! 4 msec ! 4 msec !5 Access1(39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00) 4 msec ! 4 msec ! 4 msec !Access2#Adding Redundancy to the Core
When considering redundancy in the core portion of the network, most service providers will implement more redundancy than has been shown in the examples in this document. The first place the service providers will increase redundancy is between the core router and the distribution router, and the service provider will do so by building redundant LANs. Therefore, a second static route would need to be added for the second LAN. An earlier example in this document configured a single static route for a router designated BackBone1; this configuration is listed again in the following example. A second route would be almost identical, except that the route statement (clns route command) would reflect the appropriate Ethernet interface and its equivalent MAC address.
clns route 39.840f.8011.9999.0000.1111 Ethernet1/0 000d.bc2e.6d90To continue adding redundancy, add a second core and a second set of distribution sites. In an ISO-IGRP configuration, one core must be a primary route and the second core a secondary or backup. The primary and secondary routes are designated by the length of the route specified in the static routes. The Cisco IOS software prefers the path with the longest route. Examine the route statements for the primary core using the following example:
! BackBone1 Routerclns route 39.840f.8011.9999.0000.1111 Ethernet1/0 000d.bc2e.6d90! BackBone2 Routerclns route 39.840f.8011.9999.0000.2222 Ethernet1/0 000d.bc2e.6d50! BackBone3 Routerclns route 39.840f.8011.9999.0000.3333 Ethernet5/0 0010.7bd8.c821The second core will be made up of routers BackBone1A, BackBone2A and BackBone3A. The following examples show the static route for each of the secondary core routers, by router.
! BackBone1A Routerclns route 39.840f.8011.9999.0000.11 Ethernet1/1 000d.bc2e.7d90! BackBone2A Routerclns route 39.840f.8011.9999.0000.22 Ethernet1/1 000d.bc2e.7d50! BackBone3A Routerclns route 39.840f.8011.9999.0000.33 Ethernet4/1 0010.7bd8.d421Notice that the route is shorter in length for the secondary routers. For example, router BackBone1 has a static route configured for 39.840f.8011.9999.0000.1111 and router BackBone1A has a static route configured for 39.840f.8011.9999.0000.11. The distribution routers have both routes in their routing tables. The distribution routers will choose the longer route or more significant route to forward packets to.
Tunneling Across the Core
Some service providers will have routers in the core that do not route CLNS. So tunnels must be built across the core. Cisco recommends that you route up to the distribution router and build a small number of tunnels across the core between the distribution routers.
Completing the Core Router Configurations
The following sections provide the configurations for the remaining routers in the sample lab network shown in Figure 48:
•
•
•
Configuring Router Access1
The following example shows the relevant CLNS configuration commands for the router designated Access1 in Figure 48:
Access1# show configurationhostname Access1!clns routing!interface Ethernet0/0ip address 192.168.10.66 255.255.255.192half-duplexclns router isis area0003tarp enable!interface BRI0/0no ip addressshutdown!router isis area0003net 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00!clns host BackBoneR1 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00clns host BackBoneR2 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00clns host BackBoneR3 39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00clns host Distribution2 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00clns host Distribution1 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00clns host Access1 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00!tarp runtarp tid Access1!Verifying the Configuration
The following examples display output from the show clns and show clns neighbors EXEC commands for router Access1. The commands display global information about CLNS and the router. The routing area is identified as 39.840f.8011.9999.0000.1111.0003.
Access1# show clnsGlobal CLNS Information:2 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area0003Routing for Area: 39.840f.8011.9999.0000.1111.0003Access1# show clns neighborsSystem Id Interface SNPA State Holdtime Type Protocol3640A Et0/0 0010.7bc7.ae41 Up 26 L2 IS-ISDistribution1 Et0/1 0010.7b17.f881 Up 28 L2 IS-ISThe following example displays information from the show clns route EXEC command:
Access1# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.1111.0003 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00 [1/0], Local IS-IS NETi 39.840f.8011.9999.0000.1111.0001 [110/10]via 3640A, Ethernet0/0i 39.840f.8011.9999.0000.1111 [110/30]via Distribution1, Ethernet0/1i 39.840f.8011.9999.0000.2222 [110/20]via Distribution1, Ethernet0/1i 39.840f.8011.9999.0000.3333 [110/20]via Distribution1, Ethernet0/1i 39.840f.8011.9999.0000.1111.9999 [110/10]via Distribution1, Ethernet0/1i 39.840f.8011.9999.0000.bbbb [110/20]via Distribution1, Ethernet0/1The following example shows how to test connectivity by issuing the ping clns command to a backbone router:
Access1# ping clns BackBoneR3Type escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/5 msThe following example shows how to trace a route to another router:
Access1# trace clns Distribution2Type escape sequence to abort.Tracing the route to Distribution2 (39.840f.8011.9999.0000.2222.0002.0030.94e2.)1 Distribution1(39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00) 0 msec ! !2 BackBoneR1(39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00) 0 msec ! 0 m!3 BackBoneR2(39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00) 0 msec ! 0 m!4 Distribution2(39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00) 4 msec ! !Configuring Router Access2
The following example shows the relevant CLNS configuration commands for the router designated Access2 in Figure 48:
Access2# show configurationclns routing!interface Ethernet0ip address 192.168.5.190 255.255.255.192no ip route-cacheno ip mroute-cacheclns router isis area0012tarp enable!interface Ethernet1ip address 192.168.50.66 255.255.255.252no ip route-cacheno ip mroute-cacheclns router isis area0012tarp enable!router isis area0012net 39.840f.8011.9999.0000.2222.0012.00e0.b064.434e.00!clns host BackBoneR1 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00clns host BackBoneR2 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00clns host BackBoneR3 39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00clns host Distribution2 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00clns host Distribution1 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00clns host Access1 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host Access2 39.840f.8011.9999.0000.2222.0012.00e0.b064.434e.00!tarp runtarp tid Access2endVerifying the Configuration
The following examples display output from the show clns and show clns neighbors EXEC commands for router Access2. The commands display global information about CLNS and the router. The routing area is identified as 39.840f.8011.9999.0000.2222.0012.
Access2# show clnsGlobal CLNS Information:2 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.2222.0012.00e0.b064.434e.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area0012Routing for Area: 39.840f.8011.9999.0000.2222.0012Access2# show clns neighborsSystem Id Interface SNPA State Holdtime Type ProtocolDistribution2 Et1 0030.94e2.6ce0 Up 23 L2 IS-ISAccess2#show clns neighbors detailSystem Id Interface SNPA State Holdtime Type ProtocolDistribution2 Et1 0030.94e2.6ce0 Up 23 L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.2222.0002Uptime: 01:49:34The following example shows the routing table for router Access2. The routes are listed to the backbone domain and the other two domains.
Access2# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISC 39.840f.8011.9999.0000.2222.0012 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.2222.0012.00e0.b064.434e.00 [1/0], Local IS-IS NETi 39.840f.8011.9999.0000.2222.0002 [110/10]via Distribution2, Ethernet1i 39.840f.8011.9999.0000.1111 [110/20]via Distribution2, Ethernet1i 39.840f.8011.9999.0000.2222 [110/30]via Distribution2, Ethernet1i 39.840f.8011.9999.0000.3333 [110/20]via Distribution2, Ethernet1i 39.840f.8011.9999.0000.bbbb [110/20]via Distribution2, Ethernet1Configuring Router Access3
The following example shows the relevant CLNS configuration commands for the router designated Access3 in Figure 48:
Access3# show configuration!hostname Access3!enable password cisco!clns routing!interface Ethernet0/0ip address 192.168.3.62 255.255.255.192half-duplextarp enable!interface Ethernet0/1ip address 192.168.101.66 255.255.255.192half-duplexclns router isis area0035tarp enable!router isis area0035net 39.840f.8011.9999.0000.3333.0035.0050.7363.7b40.00!clns host Distribution3 39.840f.8011.9999.0000.3333.0035.00e0.1ee3.c720.00clns host BackBoneR2 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00clns host BackBoneR3 39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00clns host BackBoneR1 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00clns host Distribution2 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00clns host Distribution1 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00clns host Access1 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host Access2 39.840f.8011.9999.0000.2222.0012.00e0.b064.434e.00clns host Access3 39.840f.8011.9999.0000.3333.0035.0050.7363.7b40.00!tarp runtarp tid Access3!Verifying the Configuration
The following examples display output from the show clns, show clns neighbors, and show clns neighbors detail EXEC commands for router Access3. The commands display global information about CLNS and the router. The routing area is identified as 39.840f.8011.9999.0000.3333.0035.
Access3# show clnsGlobal CLNS Information:1 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.3333.0035.0050.7363.7b40.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area0035Routing for Area: 39.840f.8011.9999.0000.3333.0035Access3# show clns neighborsSystem Id Interface SNPA State Holdtime Type ProtocolDistribution3 Et0/1 00e0.1ee3.c721 Up 9 L1L2 IS-ISAccess3# show clns neighbors detailSystem Id Interface SNPA State Holdtime Type ProtocolDistribution3 Et0/1 00e0.1ee3.c721 Up 9 L1L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.3333.0035Uptime: 00:05:32The following example displays information from the show clns route EXEC command:
Access3# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.3333.0035 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.3333.0035.0050.7363.7b40.00 [1/0], Local IS-IS NETi 39.840f.8011.9999.0000.3333.0033 [110/20]via Distribution3, Ethernet0/1i 39.840f.8011.9999.0000.1111 [110/20]via Distribution3, Ethernet0/1i 39.840f.8011.9999.0000.2222 [110/20]via Distribution3, Ethernet0/1i 39.840f.8011.9999.0000.3333 [110/30]via Distribution3, Ethernet0/1i 39.840f.8011.9999.0000.bbbb [110/20]via Distribution3, Ethernet0/1The following example shows how to test connectivity by issuing the ping clns command to router Access1:
Access3# ping clns Access1Type escape sequence to abort.Sending 5, 100-byte CLNS Echos with timeout 2 seconds!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/9 msThe following example shows how to trace a route to another router:
Access3# trace clns Access1Type escape sequence to abort.Tracing the route to Access1 (39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00)1 Distribution3(39.840f.8011.9999.0000.3333.0035.00e0.1ee3.c720.00) 4 msec ! 0 msec ! 0 msec !2 BackBoneR3(39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00) 0 msec ! 0 msec ! 0 msec !3 BackBoneR1(39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00) 0 msec ! 0 msec ! 0 msec !4 Distribution1(39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00) 4 msec ! 4 msec ! 4 msec !5 Access1(39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00) 4 msec ! 4 msec ! 4 msec !Configuring Router Distribution1
The following example shows the relevant CLNS configuration commands for the router designated Distribution1 in Figure 48:
Distribution1# show configurationhostname Distribution1!enable password cisco!clns routing!interface Ethernet0/0ip address 192.168.10.2 255.255.255.252no ip mroute-cachehalf-duplexclns router isis area9999tarp enable!interface Ethernet0/1ip address 192.168.10.65 255.255.255.192no ip mroute-cachehalf-duplexclns router isis area9999tarp enable!router isis area9999net 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00!clns host BackBoneR1 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00clns host BackBoneR2 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00clns host BackBoneR3 39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00clns host Distribution1 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00clns host Distribution2 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00clns host Access1 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00!tarp runtarp tid Distribution1Verifying the Configuration
The following examples display output from the show clns, show clns neighbors, and show clns neighbors detail EXEC commands for router Distribution1. The commands display global information about CLNS and the router. The routing area is identified as 39.840f.8011.9999.0000.1111.9999.
Distribution1# show clnsGlobal CLNS Information:2 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area9999Routing for Area: 39.840f.8011.9999.0000.1111.9999Distribution1# show clns neighborsSystem Id Interface SNPA State Holdtime Type ProtocolAccess1 Et0/1 00d0.5872.9721 Up 9 L2 IS-ISBackBoneR1 Et0/0 000d.bc2e.6d90 Up 25 L1L2 IS-ISDistribution1# show clns neighbors detailSystem Id Interface SNPA State Holdtime Type ProtocolAccess1 Et0/1 00d0.5872.9721 Up 8 L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.1111.0003Uptime: 00:03:20BackBoneR1 Et0/0 000d.bc2e.6d90 Up 29 L1L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.1111.9999Uptime: 02:16:45NSF capableThe following example displays information from the show clns route EXEC command:
Distribution1# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00 [1/0], Local IS-IS NETC 39.840f.8011.9999.0000.1111.9999 [2/0], Local IS-IS Areai 39.840f.8011.9999.0000.1111.0001 [110/20]via Access1, Ethernet0/1i 39.840f.8011.9999.0000.1111.0003 [110/10]via Access1, Ethernet0/1i 39.840f.8011.9999.0000.1111 [110/20]via BackBoneR1, Ethernet0/0i 39.840f.8011.9999.0000.2222 [110/10]via BackBoneR1, Ethernet0/0i 39.840f.8011.9999.0000.bbbb [110/10]via BackBoneR1, Ethernet0/0Configuring Router Distribution2
The following example shows the relevant CLNS configuration commands for the router designated Distribution2 in Figure 48:
Distribution2# show configurationhostname Distribution2!interface Ethernet0/0ip address 192.168.50.65 255.255.255.252no ip mroute-cachehalf-duplexclns router isis area0002tarp enable!interface Ethernet0/1ip address 192.168.50.2 255.255.255.192no ip mroute-cachehalf-duplexclns router isis area0002!router isis area0002net 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00!clns host BackBoneR1 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00clns host BackBoneR2 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00clns host BackBoneR3 39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00clns host Distribution2 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00clns host Distribution1 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00clns host Access1 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host Access2 39.840f.8011.9999.0000.2222.0012.00e0.b064.434e.00!tarp runtarp tid Distribution2!Verifying the Configuration
The following examples display output from the show clns, show clns neighbors, and show clns neighbors detail EXEC commands for router Distribution2. The commands display global information about CLNS and the router. The routing area is identified as 39.840f.8011.9999.0000.2222.0002.
Distribution2# show clnsGlobal CLNS Information:2 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area0002Routing for Area: 39.840f.8011.9999.0000.2222.0002Distribution2# show clns neighborsSystem Id Interface SNPA State Holdtime Type ProtocolAccess2 Et0/0 00e0.b064.434f Up 8 L2 IS-ISBackBoneR2 Et0/1 000d.bc2e.6d50 Up 27 L1L2 IS-ISDistribution2# show clns neighbors detailSystem Id Interface SNPA State Holdtime Type ProtocolAccess2 Et0/0 00e0.b064.434f Up 7 L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.2222.0012Uptime: 01:48:26BackBoneR2 Et0/1 000d.bc2e.6d50 Up 23 L1L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.2222.0002Uptime: 01:48:26NSF capableThe following example displays CLNS route information:
Distribution2# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.2222.0002 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00 [1/0], Local IS-IS NETi 39.840f.8011.9999.0000.2222.0012 [110/10]via Access2, Ethernet0/0i 39.840f.8011.9999.0000.1111 [110/10]via BackBoneR2, Ethernet0/1i 39.840f.8011.9999.0000.2222 [110/20]via BackBoneR2, Ethernet0/1i 39.840f.8011.9999.0000.3333 [110/10]via BackBoneR2, Ethernet0/1i 39.840f.8011.9999.0000.bbbb [110/10]via BackBoneR2, Ethernet0/1Configuring Router Distribution3
The following example shows the relevant CLNS configuration commands for the router designated Distribution3 in Figure 48:
Distribution3# show configurationUsing 3873 out of 29688 bytes!version 12.3service timestamps debug uptimeservice timestamps log uptimeno service password-encryption!hostname Distribution3!boot-start-markerboot system flashboot system romboot-end-marker!!enable password cisco!clock timezone EST -5no aaa new-modelip subnet-zeroip domain name compgen.comip host 1d12RAA-2600 172.20.220.61ip host 1d12RAB-2600 172.20.220.60ip host 1d38RAE-7200 172.20.221.65ip host 1d38RAF-7200 172.20.221.66ip host 1d12RAC-2600 172.20.220.62ip name-server 172.30.4.11clns routingno ftp-server write-enablex25 routing!!stun peer-name 172.25.192.47stun protocol-group 103 basic!!interface Loopback0ip address 192.168.5.252 255.255.255.192!interface Ethernet0/0ip address 192.168.100.2 255.255.255.192half-duplexclns router isis area0035tarp enable!interface Ethernet0/1ip address 192.168.5.61 255.255.255.192half-duplexclns router isis area0035tarp enable!interface Serial1/0mtu 1562no ip addressencapsulation x25 dceno ip mroute-cachex25 ltc 5x25 ips 512x25 ops 512x25 threshold 1x25 pvc 1 rbp local port 10000clockrate 9600!router ospf 795log-adjacency-changesnetwork 192.168.0.0 0.0.255.255 area 0!router isis area0035net 39.840f.8011.9999.0000.3333.0035.00e0.1ee3.c720.00!clns host Distribution3 39.840f.8011.9999.0000.3333.0035.00e0.1ee3.c720.00clns host BackBoneR2 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d40.00clns host BackBoneR3 39.840f.8011.9999.0000.bbbb.1001.0010.7bd8.c7d0.00clns host BackBoneR1 39.840f.8011.9999.0000.bbbb.1001.000d.bc2e.6d80.00clns host Distribution2 39.840f.8011.9999.0000.2222.0002.0030.94e2.6ce0.00clns host Distribution1 39.840f.8011.9999.0000.1111.9999.0010.7b17.f880.00clns host Access1 39.840f.8011.9999.0000.1111.0003.00d0.5872.9720.00clns host Access2 39.840f.8011.9999.0000.2222.0012.00e0.b064.434e.00!tarp runtarp tid Distribution3!Verifying the Configuration
The following examples display output from the show clns, show clns neighbors, and show clns neighbors detail EXEC commands for router Distribution3. The commands display global information about CLNS and the router. The routing area is identified as 39.840f.8011.9999.0000.3333.0035.
Distribution3# show clnsGlobal CLNS Information:2 Interfaces Enabled for CLNSNET: 39.840f.8011.9999.0000.3333.0035.00e0.1ee3.c720.00Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64ERPDU's requested on locally generated packetsIntermediate system operation enabled (CLNS forwarding allowed)IS-IS level-1-2 Router: area0035Routing for Area: 39.840f.8011.9999.0000.3333.0035Distribution3# show clns neighborsSystem Id Interface SNPA State Holdtime Type ProtocolBackBoneR3 Et0/0 0010.7bd8.c821 Up 29 L2 IS-ISNE14B Et0/1 0050.7363.7b41 Up 26 L1L2 IS-ISDistribution3# show clns neighbors detailSystem Id Interface SNPA State Holdtime Type ProtocolBackBoneR3 Et0/0 0010.7bd8.c821 Up 23 L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.3333.0033Uptime: 00:52:12NE14B Et0/1 0050.7363.7b41 Up 26 L1L2 IS-ISArea Address(es): 39.840f.8011.9999.0000.3333.0035Uptime: 00:17:36The following example displays information from the show clns route EXEC command:
Distribution3# show clns routeCodes: C - connected, S - static, d - DecnetIVI - ISO-IGRP, i - IS-IS, e - ES-ISB - BGP, b - eBGP-neighborC 39.840f.8011.9999.0000.3333.0035 [2/0], Local IS-IS AreaC 39.840f.8011.9999.0000.3333.0035.00e0.1ee3.c720.00 [1/0], Local IS-IS NETi 39.840f.8011.9999.0000.3333.0033 [110/10]via BackBoneR3, Ethernet0/0i 39.840f.8011.9999.0000.1111 [110/10]via BackBoneR3, Ethernet0/0i 39.840f.8011.9999.0000.2222 [110/10]via BackBoneR3, Ethernet0/0i 39.840f.8011.9999.0000.3333 [110/20]via BackBoneR3, Ethernet0/0i 39.840f.8011.9999.0000.bbbb [110/10]via BackBoneR3, Ethernet0/0Additional References
This section provides the following additional reference information:
Related Documents
Bandwidth signaling applications
•
•
•
Cisco IS-IS technical support
Integrated Intermediate System-to-Intermediate System (IS-IS) Cisco IOS support page
CLNS tunnel configuration
•
•
IP requirements for a DCN
ITU-T G.7712/Y.1703, Architecture and Specification of the Data Communication Network
IS-IS attach-bit
Using the IS-IS Attach-Bit Control Feature, Cisco IOS Product Marketing Application Note
NM-AIC-64 configuration
NM-AIC-64, Contact Closure Network Module, Cisco IOS Release 12.2(8)T feature module
NSAP address structure
American National Standard X3.216-1992, Structure and Semantics of the Domain Specific Part of the Network Service Access Point Address
NSAP IDP structure
•
•
•
•
•
Optical internetworking
Optical Internetworking Forum (OIF) User Network Interface (UNI) 1.0
OSI addressing issues
ITU-T X.213, Data Networks and Open Systems Communications Open Systems Interconnections Service Definitions
SONET requirements for a DCN
•
•
Telcordia SONET transport systems
Telcordia Specification, Issue 3 of GR-253-CORE, Synchronous Optical Network (SONET) Transport Systems: Common Criteria, Section 8
Standards
Technical Assistance
Glossary
ADMs—add/drop multiplexers
AFI—authority and format identifier
ANSI—American National Standards Institute
BCD—Binary Coded Decimal
CLECs—competitive local exchange carriers
CLNP—Connectionless Network Protocol
DCC—data communications channel
DCN—data communications network
DFI—Domain Specific Part format identifier
DIS—Designated Intermediate System
DLCI—data-link connection identifier
DSLAMs—digital subscriber line access multiplexers
DSP—Domain Specific Part
ES—end system
ESH—End System Hello
FTAM—File Transfer, Access, and Management
GNE—gateway network element
GRE—generic routing encapsulation
IDI—initial domain identifier
IDP—Initial Domain Part
IEEE—Institute of Electrical and Electronics Engineers
IETF—Internet Engineering Task Force
IIH—IS-IS Hello message
ILECs—incumbent local exchange carriers
ISH—Intermediate System Hello
IS—intermediate system
IS-IS—Intermediate System-to-Intermediate System
ISL—Inter-Switch Link
ISO CLNS—International Standards Organization Connectionless Network Service
ISO DCC—Data Country Code
ISO/IEC—International Organization for Standardization/International Electrotechnical Commission
ISO-IGRP—Interior Gateway Routing Protocol developed by Cisco Systems for ISO CLNS)
ITU—International Telecommunication Union
IXC—inter-exchange carriers
LDB—loop detection buffer
LSP—line-state packet and link-state packet
MAC—Media Access Control
NET—network entity title
NMA—Network Management Application
NOC—network operations center
NSAP—network service access point
OAM&P—operations, administration, maintenance, and provisioning
OSI—Open System Interconnection
PDUs—protocol data units
PSTN—public switched telephone network
PTT—Post, Telephone and Telegraph
RBOCs—regional Bell operating companies
SDH—Synchronous Digital Hierarchy
SNPA—subnetwork point of attachment
SONET—Synchronous Optical Network
TARP—Target Identifier Address Resolution Protocol
TDM—time-division multiplexing
TID—target identifier
TMN—Telecommunications Management Network
TTL—Time-to-Live field
URC—update remote cache
VLAN—virtual LAN
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2004-2007 Cisco Systems, Inc. All rights reserved.
Feedback