Table of Contents

Configuring Virtual Connections

This chapter describes how to configure virtual connections (VCs) in a typical ATM network after autoconfiguration has established the default network connections. The network configuration modifications described in this chapter are used to optimize your ATM network operation.

Note   This chapter provides advanced configuration instructions for the Catalyst 8540 MSR, Catalyst 8510 MSR, and LightStream 1010 ATM switch routers. For an overview of virtual connection types and applications, refer to the Guide to ATM Technology. For complete descriptions of the commands mentioned in this chapter, refer to the ATM Switch Router Command Reference publication.

The tasks to configure virtual connections are described in the following sections:

Characteristics and Types of Virtual Connections

This section lists the various virtual connections (VC) types in Table 6-1.

Configuring Virtual Channel Connections

This section describes configuring virtual channel connections (VCCs) on the ATM switch router. A VCC is established as a bidirectional facility to transfer ATM traffic between two ATM layer users. Figure 6-1 shows an example VCC between ATM user A and user D.

An end-to-end VCC, as shown in Figure 6-1 between user A and user D, has two parts:

The common endpoint between an internal connection and a link occurs at the switch interface. The endpoint of the internal connection is also referred to as a connection leg or half-leg. A cross-connect connects two legs together.

Note   The value of the VPIs and VCIs can change as the traffic is relayed through the ATM network.

To configure a point-to-point VCC, perform the following steps, beginning in global configuration mode:

Note   The row index for rx-cttr and tx-cttr must be configured before using this optional parameter. See the "Configuring the Connection Traffic Table" section.

Note   When configuring PVC connections, begin with lower VCI numbers. Using low VCI numbers allows more efficient use of the switch fabric resources.

Examples

The following example shows how to configure the internal cross-connect PVC on Switch B between interface ATM 3/0/1 (VPI = 0, VCI = 50) and interface ATM 3/0/2 (VPI = 2, VCI = 100) (see Figure 6-1):

The following example shows how to configure the internal cross-connect PVC on Switch C between interface ATM 0/0/0, VPI = 2, VCI = 100, and interface ATM 0/0/1, VPI 50, VCI = 255:

Each subsequent VC cross-connection and link must be configured until the VC is terminated to create the entire VCC.

Note   The above examples show how to configure cross-connections using one command. This is the preferred method, but it is also possible to configure each leg separately, then connect them with the atm pvc vpi vci interface atm card/subcard/port vpi vci command. This alternative method requires more steps, but might be convenient if each leg has many additional configuration parameters or if you have configured individual legs with SNMP commands and you want to connect them with one CLI command.

Displaying VCCs

To show the VCC configuration, use the following EXEC commands:

Note   The following examples differ depending on the feature card installed on the processor.

Examples

The following example shows the Switch B PVC configuration on ATM interface 3/0/1:

The following example shows the Switch B PVC configuration on ATM interface 3/0/1:

The following example shows the Switch B PVC configuration on ATM interface 3/0/1, VPI = 0, VCI = 50, with the switch processor feature card installed:

Deleting VCCs from an Interface

This section describes how to delete a VCC configured on an interface. To delete a VCC, perform the following steps, beginning in global configuration mode:

Example

The following example shows how to delete the VCC on ATM interface 3/0/0, VPI = 20, VCI = 200:

Confirming VCC Deletion

To confirm the deletion of a VCC from an interface, use the following EXEC command before and after deleting the VCC:

Example

The following example shows how to confirm that the VCC is deleted from the interface:

Configuring Terminating PVC Connections

This section describes configuring point-to-point and point-to-multipoint terminating permanent virtual channel (PVC) connections. Terminating connections provide the connection to the ATM switch router's route processor for LAN emulation (LANE), IP over ATM, and control channels for Integrated Local Management Interface (ILMI), signalling, and Private Network-Network Interface (PNNI) plus network management.

Figure 6-2 shows an example of transit and terminating connections.

Point-to-point and point-to-multipoint are two types of terminating connections. Both terminating connections are configured using the same commands as transit connections (discussed in the previous sections). However, all switch terminating connections use interface atm0 to connect to the route processor.

Note   Since release 12.0(1a)W5(5b) of the system software, addressing the interface on the processor (CPU) has changed. The ATM interface is now called atm0, and the Ethernet interface is now called ethernet0. The old formats (atm 2/0/0 and ethernet 2/0/0) are still supported.

To configure both point-to-point and point-to-multipoint terminating PVC connections, perform the following steps, beginning in global configuration mode:

When configuring point-to-multipoint PVC connections using the atm pvc command, the root point is port A and the leaf points are port B.

Note   The row index for rx-cttr and tx-cttr must be configured before using this optional parameter. See the "Configuring the Connection Traffic Table" section.

Examples

The following example shows how to configure the internal cross-connect PVC between interface ATM 3/0/1, VPI = 1, VCI = 50, and the terminating connection at the route processor interface ATM 0, VPI = 0, and VCI unspecified:

The following example shows how to configure the route processor leg of any terminating PVC:

When configuring the route processor leg of a PVC that is not a tunnel, the VPI should be configured as 0. The preferred method of VCI configuration is to select the any-vci parameter, unless a specific VCI is needed as a parameter in another command, such as map-list.

Note   If configuring a specific VCI value for the route processor leg, select a VCI value higher than 300 to prevent a conflict with an automatically assigned VCI for well-known channels if the ATM switch router reboots.

Displaying the Terminating PVC Connections

To display the terminating PVC configuration VCs on the interface, use the following EXEC command:

See the "Displaying VCCs" section for examples of the show atm vc commands.

Configuring PVP Connections

This section describes configuring a permanent virtual path (PVP) connection. Figure 6-3 shows an example of PVPs configured through the ATM switch routers.

To configure a PVP connection, perform the following steps, beginning in global configuration mode:

Note   The row index for rx-cttr and tx-cttr must be configured before using this optional parameter. See the "Configuring the Connection Traffic Table" section.

Note   When configuring PVP connections, begin with lower virtual path identifier (VPI) numbers. Using low VPI numbers allows more efficient use of the switch fabric resources.

Examples

The following example shows how to configure the internal cross-connect PVP within Switch B between interfaces 4/0/0, VPI = 30, and interface ATM 1/1/1, VPI = 45:

The following example shows how to configure the internal cross-connect PVP within Switch C between interfaces 0/1/3, VPI = 45, and interface ATM 1/1/0, VPI = 50:

Each subsequent PVP cross connection and link must be configured until the VP is terminated to create the entire PVP.

Displaying PVP Configuration

To show the ATM interface configuration, use the following EXEC command:

Example

The following example shows the PVP configuration of Switch B:

The following example shows the PVP configuration of Switch B with the switch processor feature card installed:

Deleting PVPs from an Interface

This section describes how to delete a PVP configured on an interface. To delete a PVP, perform the following steps, beginning in global configuration mode:

Example

The following example shows how to delete the PVP on ATM interface 1/1/0, VPI = 200:

Confirming PVP Deletion

To confirm the deletion of a PVP from an interface, use the following EXEC command before and after deleting the PVP:

Example

The following example shows how to confirm that the PVP is deleted from the interface:

Configuring Point-to-Multipoint PVC Connections

This section describes configuring point-to-multipoint PVC connections. In Figure 6-4, cells entering the ATM switch router at the root point (on the left side at interface ATM 0/0/0, VPI = 50, VCI = 100) are duplicated and switched to the leaf points (output interfaces) on the right side of the figure.

Note   If desired, one of the leaf points can terminate in the ATM switch router at the route processor interface ATM 0.

To configure the point-to-multipoint PVC connections shown in Figure 6-4, perform the following steps, beginning in global configuration mode:

To configure the point-to-multipoint PVC connections using the atm pvc command, the root point is port A and the leaf points are port B.

Note   The row index for rx-cttr and tx-cttr must be configured before using this optional parameter. See the "Configuring the Connection Traffic Table" section.

Examples

The following example shows how to configure the root-point PVC on ATM switch router interface ATM 0/0/0, VPI = 50, VCI = 100, to the leaf-point interfaces (see Figure 6-4):

Displaying Point-to-Multipoint PVC Configuration

To display the point-to-multipoint PVC configuration, use the following EXEC mode command:

Examples

The following example shows the PVC configuration of the point-to-multipoint connections on ATM interface 0/0/0:

The following example shows the VC configuration on interface ATM 0/0/0, VPI = 50, VCI = 100, with the switch processor feature card installed:

Configuring Point-to-Multipoint PVP Connections

This section describes configuring point-to-multipoint PVP connections. Figure 6-5 provides an example of point-to-multipoint PVP connections.

In Figure 6-5, cells entering the ATM switch router at the root point (the left side at interface ATM 4/0/0), VPI = 50, are duplicated and switched to the leaf points (output interfaces), on the right side of the figure.

To configure point-to-multipoint PVP connections, perform the following steps, beginning in global configuration mode:

To configure the point-to-multipoint PVP connections using the atm pvp command, the root point is port A and the leaf points are port B.

Note   The row index for rx-cttr and tx-cttr must be configured before using this optional parameter. See the "Configuring the Connection Traffic Table" section.

Examples

The following example shows how to configure the root-point PVP on ATM switch router interface ATM 4/0/0 (VPI = 50), to the leaf point interfaces ATM 1/1/1 (VPI = 60), ATM 3/0/0 (VPI = 70), and ATM 3/0/3 (VPI = 80) (see Figure 6-5):

Displaying Point-to-Multipoint PVP Configuration

To display the ATM interface configuration, use the following EXEC command:

Examples

The following example shows the PVP configuration of the point-to-multipoint PVP connections on ATM interface 4/0/0:

The following example shows the PVP configuration of the point-to-multipoint PVP connections on ATM interface 4/0/0, VPI = 50, with the switch processor feature card installed:

Configuring Soft PVC Connections

This section describes configuring soft permanent virtual channel (PVC) connections, which provide the following features:

Figure 6-6 illustrates the soft PVC connections used in the following examples.

Guidelines for Creating Soft PVCs

Perform the following steps when you configure soft PVCs:

Step 2   Decide which of these two ports you want to designate as the destination (or passive) side of the soft PVC.

This decision is arbitrary—it makes no difference which port you define as the destination end of the circuit.

Step 3   Retrieve the ATM address of the destination end of the soft PVC using the show atm address command.

Step 4   Retrieve the VPI/VCI values for the circuit using the show atm vc command.

Step 5   Configure the source (active) end of the soft PVC. At the same time, complete the soft PVC setup using the information derived from Step 3 and Step 4. Be sure to select an unused VPI/VCI value (one that does not appear in the show atm vc display).

Note   To ensure that the soft PVCs are preserved during a route processor switchover, you must configure the switch to synchronize dynamic information between the route processors. For more information, see the "Synchronizing the Dynamic Information (Catalyst 8540 MSR)" section

Configuring Soft PVCs

To configure a soft PVC connection, perform the following steps, beginning in privileged EXEC mode:

Note   The row index for rx-cttr and tx-cttr must be configured before using this optional parameter. See the "Configuring the Connection Traffic Table" section.

Examples

The following example shows the destination ATM address of the interface connected to User D:

The following example shows how to configure a soft PVC on Switch B between interface ATM 0/0/2, source VPI = 0, VCI = 1000; and Switch C, destination VPI = 0, VCI = 1000 with a specified ATM address (see Figure 6-6):

Displaying Soft PVC Configuration

To display the soft PVC configuration at either end of a ATM switch router, use the following EXEC commands:

Examples

The following example shows the soft PVC configuration of Switch B, on interface ATM 0/0/2 out to the ATM network:

The following example shows the soft PVC configuration of Switch C, on interface ATM 1/1/1 out to the ATM network:

The following example shows the soft PVC configuration of Switch B, on interface ATM 0/0/2 (VPI = 0, VCI = 1000) out to the ATM network with the switch processor feature card installed:

Configuring Soft PVP Connections

This section describes configuring soft permanent virtual path (PVP) connections, which provide the following features:

Figure 6-7 is an illustration of the soft PVP connections used in the examples in this section.

To configure a soft PVP connection, perform the following steps, beginning in global configuration mode:

The row index for rx-cttr and tx-cttr must be configured before using this optional parameter. See the "Configuring the Connection Traffic Table" section.

Example

The following example shows how to configure a soft PVP on Switch B between interface ATM 0/0/2, source VPI = 75; and Switch C, destination VPI = 75, with a specified ATM address (see Figure 6-7):

Displaying Soft PVP Connections

To display the ATM soft PVP configuration, use the following EXEC command:

Examples

The following example shows the soft PVP configuration at Switch B, on interface ATM 0/0/2 out to the ATM network:

The following example shows the soft PVP configuration on interface ATM 1/1/1 at Switch C out to the ATM network:

The following example shows the soft PVP configuration at Switch B on interface ATM 0/0/2 (VPI = 75) out to the ATM network with the switch processor feature card installed:

Configuring the Soft PVP or Soft PVC Route Optimization Feature

This section describes the soft PVP or soft PVC route optimization feature. Most soft PVPs or soft PVCs have a much longer lifetime than SVCs. The route chosen during the soft connection setup remains the same even though the network topology might change.

Soft connections, with the route optimization percentage threshold set, provide the following features:

Route optimization is directly related to administrative weight, which is similar to hop count. For a description of administrative weight, see the "Configuring the Global Administrative Weight Mode" section.

Configuring soft PVP or soft PVC route optimization is described in the following sections:

For overview information about the route optimization feature refer to the Guide to ATM Technology.

Enabling Soft PVP or Soft PVC Route Optimization

Soft PVP or soft PVC route optimization must be enabled and a threshold level configured to determine the point when a better route is identified and the old route is reconfigured.

To enable and configure route optimization, use the following global configuration command:

Example

The following example enables route optimization and sets the threshold percentage to 85 percent:

Configuring a Soft PVP/PVC Interface with Route Optimization

Soft PVP or soft PVC route optimization must be enabled and configured to determine the point at which a better route is found and the old route is reconfigured.

To enable and configure a soft PVC/PVP interface with route optimization, perform the following steps, beginning in global configuration mode:

Example

The following example shows how to configure an interface with a route optimization interval configured as every 30 minutes between the hours of 6:00 P.M. and 5:00 A.M.:

Displaying an Interface Route Optimization Configuration

To display the interface route optimization configuration, use the following EXEC command:

Example

The following example shows the route optimization configuration of ATM interface 0/0/0:

Configuring Soft PVCs with Explicit Paths

Normally, soft PVCs and soft PVPs are automatically routed by PNNI over paths that meet the traffic parameter objectives. However, for cases where manually configured paths are needed, PNNI explicit paths can optionally be specified for routing the soft PVC or soft PVP. For detailed information on configuring PNNI explicit paths, see the "Configuring Explicit Paths" section.

The explicit paths are assigned using precedence numbers 1 through 3. The precedence 1 path is tried first and if it fails the soft connection is routed using the precedence 2 path and so forth. If all of the explicit paths fail, standard on-demand PNNI routing is tried unless the only-explicit keyword is specified.

If the soft connection destination address is reachable at one of the included entries in an explicit path, any following entries in that path are automatically disregarded. This allows longer paths to be reused for closer destinations. Alternatively, the upto keyword can be specified for an explicit path in order to disregard later path entries.

Example

The following example shows how to configure a soft PVC between ATM switch router dallas_1 and an address on ATM switch router new_york_3 using either of the two explicit paths new_york.path1 and new_york.path2. If both explicit paths fail, the ATM switch router uses PNNI on-demand routing to calculate the route.

Changing Explicit Paths for an Existing Soft PVC

Explicit paths can be added, modified or removed without tearing down existing soft PVCs by using the redo-explicit keyword. Only the source VPI and VCI options need to be specified. All applicable explicit path options are replaced by the respecified explicit path options.

The soft PVC is not immediately rerouted using the new explicit path. However, reroutes using the new explicit path can happen for the following four reasons:

1. A failure occurs along the current path.

2. The EXEC command atm route-optimization soft-connection is entered for the soft PVC.

3. route-optimization is enabled and the retry time interval has expired.

4. The soft PVC is disabled and then reenabled using the disable and enable keywords.

Example

The following example shows how to change the explicit path configuration for an existing soft PVC on the ATM switch router dallas_1 without tearing down the connection. The new configuration specifies the two explicit paths, new_york.path3 and new_york.path4, and uses the only-explicit option.

Note   The configuration displayed for soft connections with explicit paths is always shown as two separate lines using the redo-explicit keyword on the second line, even if it is originally configured using a single command line.

Displaying Explicit Path for Soft PVC Connections

To display a soft PVC connection successfully routed over an explicit path, use the following EXEC command:

Example

The following example shows the last explicit path status for a soft PVC using the show atm vc interface EXEC command. Note that the first listed explicit path new_york.path2 shows an unreachable result, but the second explicit path new_york.path1 succeeded.

Configuring Nondefault Well-Known PVCs

Normally the default well-known VCs are automatically created with default virtual channel identifiers (VCIs). However, for the unusual instances where the ATM switch router interfaces with nonstandard equipment, you can configure nondefault well-known VCI values on a per-interface basis.

For overview information about the well-known PVCs, refer to the Guide to ATM Technology.

Table 6-2 lists the default well-known VCs and their default configuration.

Caution   Do not change the well-known channels to use a VC where the remote end is sending AAL5 messages not intended for the well-known VC. For example, do not swap VC values between two types of well-known VCs.

Overview of Nondefault PVC Configuration

Following is an overview of the steps needed to configure nondefault well-known VCs:

Step 2   Delete any existing automatically created well-known VCs.

Step 3   Configure the individual encapsulation type as follows:

Step 4   Copy the running-configuration file to the startup-configuration file.

Configuring Nondefault PVCs

To configure the nondefault PVCs for signalling, ILMI, and PNNI, perform the following steps, beginning in global configuration mode:

Note   An error condition occurs if either the signalling or ILMI well-known VCs remain unconfigured when an interface is enabled.

Example

The following example shows the nondefault VC configuration steps:

Step 2   Change to interface configuration mode for ATM interface 0/0/0.

Step 3   Enter manual well-known-vc mode and delete the existing default well-known VCs using the atm manual-well-known-vc delete command.

Step 4   Confirm deletion by entering y.

Step 5   Configure the nondefault VC for signalling from 5 (the default) to 35 using the atm pvc command.

Step 6   Configure the ILMI VC, then configure the PNNI VC if needed using the same procedure.

Step 7   Save the new running configuration to the startup configuration.

An example of this procedure follows:

Configuring a VPI/VCI Range for SVPs and SVCs

You can configure a virtual path identifier/virtual channel identifier (VPI/VCI) range for switched virtual channels and switched virtual paths (SVCs and SVPs). ILMI uses the specified range to negotiate the VPI/VCI range parameters with peers. This feature allows you to:

You can still configure PVPs and PVCs in any supported range, including any VPI/VCI range you configured for SVPs/SVCs.

Note   This feature is supported in ILMI 4.0.

Note   To ensure that SVCs are preserved during a route processor switchover, you must configure the switch to synchronize dynamic information between the route processors. For more information, see the "Synchronizing the Dynamic Information (Catalyst 8540 MSR)" section

The default maximum switched virtual path connection (SVPC) VPI is equal to 255. You can change the maximum SVPC VPI by entering the atm svpc vpi max value command. See Table 6-3 for the allowable ranges.

Note   The maximum value specified applies to all interfaces except logical interfaces, which have a fixed value of 0.

For further information and examples of using VPI/VCI ranges for SVPs/SVCs, refer to the Guide to ATM Technology.

Every interface negotiates the local values for the maximum SVPC VPI, maximum SVCC VPI, and minimum SVCC VCI with the peer's local value during ILMI initialization. The negotiated values determine the ranges for SVPs and SVCs. If the peer interface does not support these objects or autoconfiguration is turned off on the local interface, the local values determine the range.

To configure a VPI/VCI range for SVCs/SVPs, perform the following steps, beginning in global configuration mode:

The following example shows configuring ATM interface 0/0/0 with the SVPC and SVCC VPI maximum set to 100, and SVCC VCI minimum set to 60.

Displaying the VPI/VCI Range Configuration

To confirm the VPI or VCI range configuration, use one of the following commands:

Examples

The following example shows how to confirm the VPI and VCI range configuration on an ATM interface. The values displayed for ConfMaxSvpcVpi, ConfMaxSvccVpi, and ConfMinSvccVci are local values. The values displayed for CurrMaxSvpcVpi, CurrMaxSvccVpi, and CurrMinSvccVci are negotiated values.

The following example shows how to confirm the peer's local values for VPI and VCI range configuration by displaying the ILMI status on an ATM interface:

Note   Note that the show atm ilmi-status command displays the information above only if the peer supports it.

Configuring VP Tunnels

This section describes configuring virtual path (VP) tunnels, which provide the ability to interconnect ATM switch routers across public networks using PVPs. You can configure a VP tunnel to carry a single service category, or you can configure a VP tunnel to carry multiple service categories, including merged VCs.

Figure 6-8 shows a public UNI interface over a DS3 connection between the ATM switch router (HB-1) in the Headquarters building and the ATM switch router (SB-1) in the Remote Sales building. To support signalling across this connection, a VP tunnel must be configured.

Configuring a VP Tunnel for a Single Service Category

The type of VP tunnel described in this section is configured as a VP of a single service category. Only virtual circuits (VCs) of that service category can transit the tunnel.

To configure a VP tunnel connection for a single service category, perform the following steps, beginning in global configuration mode:

Note   The row index for nondefault rx-cttr and tx-cttr must be configured before these optional parameters are used.

Examples

The following example shows how to configure the ATM VP tunnel on the ATM switch router (HB-1) at interface ATM 1/0/0, VPI 99:

The following example shows how to configure the ATM VP tunnel on the ATM switch router (SB-1) interface ATM 0/0/0, VPI 99:

Displaying the VP Tunnel Configuration

To show the ATM virtual interface configuration, use the following EXEC command:

The following example shows the ATM virtual interface configuration for interface ATM 1/0/0.99:

Configuring a Shaped VP Tunnel

This section describes configuring a shaped VP tunnel for a single service category with rate-limited tunnel output on a switch.

A shaped VP tunnel is configured as a VP of the CBR service category. By default, this tunnel can carry VCs only of the CBR service category. However, you can configure this VP tunnel to carry VCs of other service categories. The overall output of this VP tunnel is rate-limited by hardware to the peak cell rate (PCR) of the tunnel.

Note   Shaped VP tunnels are supported only on systems with the FC-PFQ feature card. (Catalyst 8510 MSR and LightStream 1010)

A shaped VP tunnel is defined as a CBR VP with a PCR. The following limitations apply:

Configuring a Shaped VP Tunnel on an Interface

To configure a shaped VP tunnel, perform the following steps, beginning in global configuration mode:

Note   The rx-cttr and tx-cttr row indexes must be configured before they are used.

Example

The following example shows how to configure a shaped VP tunnel with a VPI of 99 as ATM interface 0/0/0.99

Displaying the Shaped VP Tunnel Configuration

To display the shaped VP tunnel interface configuration, use the following EXEC command:

For an example display from the show atm interface command, see the "Displaying the Hierarchical VP Tunnel Configuration" section.

Configuring a Hierarchical VP Tunnel for Multiple Service Categories

This section describes configuring a hierarchical VP tunnel for multiple service categories with rate-limited tunnel output.

A hierarchical VP tunnel allows VCs of multiple service categories to pass through the tunnel. In addition, the overall output of the VP tunnel is rate-limited to the PCR of the tunnel. There is no general limit on the number of connections allowed on a such a tunnel. Hierarchical VP tunnels can also support merged VCs for tag switching. See the "Configuring VC Merge" section.

Service categories supported include the following:

While capable of carrying any traffic category, a hierarchical VP tunnel is itself defined as CBR with a PCR. The following limitations apply on the Catalyst 8540 MSR:

The following limitations apply on the Catalyst 8510 MSR and LightStream 1010:

The following limitations apply on the Catalyst 8540 MSR, Catalyst 8510 MSR and LightStream 1010:

Enabling Hierarchical Mode

Before configuring a hierarchical VP tunnel, you must first enable hierarchical mode, then reload the ATM switch router. Perform the following steps, beginning in global configuration mode:

Note   Enabling hierarchical mode causes the minimum rate allocated for guaranteed bandwidth to a connection to be increased.

Example

The following example shows how to enable hierarchical mode, then save and reload the configuration.

Configuring a Hierarchical VP Tunnel on an Interface

To configure a hierarchical VP tunnel, perform the following steps, beginning in global configuration mode:

Note   The rx-cttr and tx-cttr row indexes must be configured before they are used.

Example

The following example shows how to configure a hierarchical VP tunnel with a PVP of 99 as ATM interface 0/0/0.99

Displaying the Hierarchical VP Tunnel Configuration

To display the hierarchical VP tunnel interface configuration, use the following EXEC command:

Example

The following example shows the VP tunnel configuration on interface ATM 1/0/0 with PVP 99:

Configuring an End-Point PVC to a PVP Tunnel

To configure an end point of a permanent virtual channel (PVC) to a previously created PVP tunnel, perform the following steps, beginning in global configuration mode:

The following restrictions apply to an end point of a PVC-to-PVP tunnel subinterface:

Example

The following example shows how to configure the example tunnel ATM 1/0/0.99 with a PVC from ATM interface 0/0/1 to the tunnel at ATM interface 1/0/0.99:

Displaying PVCs

To confirm PVC interface configuration, use the following EXEC command:

Example

The following example shows the configuration of ATM subinterface 1/0/0.99 on the ATM switch router Switch(HB-1):

Configuring Signalling VPCI for VP Tunnels

You can specify the value of the virtual path connection identifier (VPCI) that is to be carried in the signalling messages within a VP tunnel. The connection identifier information element (IE) is used in signalling messages to identify the corresponding user information flow. The connection identifier IE contains the VPCI and VCI.

Note   By default, the VPCI is the same as the VPI on the ATM switch router.

This feature can also be used to support connections over a virtual UNI.

To configure a VP tunnel connection signalling VPCI, perform the following steps, beginning in global configuration mode:

Example

The following example configures a VP tunnel on ATM interface 0/0/0, PVP 99, and then configures the connection ID VCPI as 0.

Displaying the VP Tunnel VPCI Configuration

To confirm the VP tunnel VPCI configuration, use the following privileged EXEC command:

Deleting VP Tunnels

To delete a VP tunnel connection, perform the following steps, beginning in global configuration mode:

Example

The following example shows deleting subinterface 99 at ATM interface 1/0/0 and then PVP half-leg 99:

Confirming VP Tunnel Deletion

To confirm the ATM virtual interface deletion, use the following EXEC command:

Example

The following example shows that ATM subinterface 1/0/0.99 on the ATM switch router (HB-1) has been deleted:

Configuring Interface and Connection Snooping

Snooping allows the cells from all connections, in either receive or transmit direction, on a selected physical port to be transparently mirrored to a snoop test port where an external ATM analyzer can be attached. Unlike shared medium LANs, an ATM system requires a separate port to allow nonintrusive traffic monitoring on a line.

Note   Only cells that belong to existing connections are sent to the snoop test port. Any received cells that do not belong to existing connections are not copied. In addition, the STS-3c (or other) overhead bytes transmitted at the test port are not copies of the overhead bytes at the monitored port.

Snooping Test Ports (Catalyst 8510 MSR and LightStream 1010)

With the FC-PCQ installed, only the highest port on the last module in the ATM switch router can be configured as a snoop test port. Table 6-4 lists the interface number of the allowed snoop test port for the various port adapter types. If you specify an incorrect snoop test port for the currently installed port adapter type, an error appears on the console. The feature card per-class queuing (FC-PCQ) also does not support per-connection snooping.

The port number of the test port depends on the card type. Table 6-4 lists the allowed snoop test port number for the supported interfaces.

Effect of Snooping on Monitored Port

There is no effect on cell transmission, interface or VC status and statistics, front panel indicators, or any other parameters associated with a port being monitored during snooping. Any port, other than the highest port, that contains a port adapter type with a bandwidth less than or equal to the port adapter bandwidth for the test port can be monitored by snooping.

Shutting Down Test Port for Snoop Mode Configuration

The port being configured as a test port must be shut down before configuration. While the test port is shut down and after snoop mode has been configured, no cells are transmitted from the test port until it is reenabled using the no shutdown command. A test port can be put into snoop mode even if there are existing connections to it; however, those connections remain "Down" even after the test port is reenabled using the no shutdown command. This includes any terminating connections for ILMI, PNNI, or signalling channels on the test port.

If you use a show atm interface command while the test port is enabled in snoop mode, the screen shows the following:

Other Configuration Options for Snoop Test Port

Most inapplicable configurations on the test port interface are disregarded while in snoop mode. However, the following configuration options are not valid when specified for the snoop test port and may affect the proper operation of the snoop mode on the test port:

Caution    You should ensure that all options are valid and configured correctly while in the snoop mode.

Configuring Interface Snooping

The atm snoop interface atm command enables a snoop test port. Cells transmitted from the snoop test port are copies of cells from a single direction of a monitored port.

When in snoop mode, any prior permanent virtual connections to the snoop test port remain in the down state.

To configure interface port snooping, perform the following steps, beginning in global configuration mode:

Example

The following example shows how to configure ATM interface 12/1/3 as the port in snoop mode to monitor ATM interface 3/0/0, tested in the receive direction:

Displaying Interface Snooping

To display the test port information, use the following EXEC command:

Example

The following example shows the snoop configuration on the OC-3c port and the actual register values for the highest interface:

Configuring Per-Connection Snooping

With per-connection snooping you must specify both the snooped connection endpoint and the snooping connection endpoint. The Cisco IOS software adds the snooping connection endpoint as a leaf to the snooped connection. The root of the temporary multicast connection depends on the direction being snooped. Snooping in the direction of leaf to root is not allowed for multicast connections. Per-connection snooping features are as follows:

The snooping connection can be configured on any port when there is no VPI/VCI collision for the snoop connection with the existing connections on the port. Also the port should have enough resources to satisfy the snoop connection resource requirements. In case of failure, due to VPI/VCI collision or resource exhaustion, a warning message is displayed, and you can reconfigure the connection on a different port.

To snoop both transmit and receive directions of a connection, you need to configure two different snoop connections.

Note   Per-connection snooping is available only with the switch processor feature card.

Nondisruptive per-connection snooping is achieved by dynamically adding a leaf to an existing connection (either unicast or multicast). This can lead to cell discard if the added leaf cannot process the snooped cells fast enough. For a multicast connection, the queue buildup is dictated by the slowest leaf in the connection. The leaf added for snooping inherits the same traffic characteristics as the other connection leg. This ensures that the added leaf does not become the bottleneck and affect the existing connection.

To configure connection snooping, perform the following steps, beginning in global configuration mode:

Examples

The following example shows how to configure VC 100 200 on ATM interface 3/1/0 to snoop VC 200 150 on ATM interface 1/0/0:

The following example shows how to configure VP 100 on ATM interface 3/1/0 to snoop VP 200 on ATM interface 1/0/0:

Displaying Per-Connection Snooping

To display the test per-connection information, use the following EXEC commands:

Examples

The following example shows all VC snoop connections on the ATM switch router:

The following example shows the VC snoop connections on ATM interface 0/1/2:

The following example shows the VC snoop connection 0, 55 on ATM interface 0/0/2 in extended mode with the switch processor feature card installed:

The following example shows all VP snoop connections on the ATM switch router:

The following example shows all VP snoop connections on ATM interface 0/1/2, VPI = 57, in extended mode with the switch processor feature card installed:

Input Translation Table Management

The Input Translation Table (ITT) is a data structure used in the switch fabric chipsets for the Catalyst 8540MSR, Catalyst 8510MSR, LightStream1010, and 6400 NSP1 platforms. It is used in the handling of input cells. The ITT can be allocated in blocks of entries, each ITT block is dedicated to a VPI on a switch port. The size of ITT blocks must be a power of two. Because the size of the ITT memory is limited, and blocks may be large, allocation of ITT space can be a constraint in configuring new VCs/VPs, and in installing connections at startup and after interface flaps.

Feature Overview

1. The Input Translation Table Management feature improves the use of ITT resources by:

· Minimizing fragmentation

· Shrinking ITT blocks

· Viewing used, and unused ITT blocks

2. For each direction of a transit VP or VC installed in the hardware, there is an entry in the ITT.

3. If the VPI is valid, the entry in the look-up table maps to either a single ITT entry, in the case of transit VP, or to a block of ITT, in the case of a VPI that consists of transit VCs.

For the Catalyst 8510 MSR, the LightStream 1010, and the 6400NSP1, the ITT is implemented as two banks of 32,000 entries each.

The ITT is a hardware data structure designed to handle incoming cells. The ITT consists of entries that, for Virtual Circuit (VC) switching, are allocated in contiguous blocks, and each block is dedicated to a Virtual Path Identifier (VPI) on an interface. ITT functionality is used only when both interfaces through which the VC transits are up.

VC Block Allocation

Interfaces mst be up in order for connections to be installed in hardware. No connections are installed for interfaces that are down (either as a result of an administrative shutdown or because the physical interface is down). Only cross-connects are installed in hardware (PVC/PVP legs that are not cross-connected are not installed), and the installation only occurs in both interfaces participating in the cross-connect are up.

No ITT space is allocated for connections that are not installed in hardware; shutting down an interface releases all ITT blocks allocated for input from that interface.

Freeing an ITT Block

When an ITT block is freed, an attempt is made to combine it with a same-size ITT block already in the free-pool, thereby resulting in a block of a size qualifying for the next-largest category on the free-chain list. This process (attempting to combine blocks) is continued up the list until a match is no longer found; however, blocks are not merged across the 16K VP support line.

Growing an ITT Block

When a request occurs for a new VC in a VPI, and the VCI exceeds the size of the current ITT block, it is possible to expand the size of the ITT block, without significant service interruption. To do this, software allocates a new block of the desired size, copies the entries found in the small block to the large block, modifies the LUT to point to the new block, and frees the small block.

On LightStream 1010 platforms, the process of combining ITT blocks is restricted to same-bank blocks; the new block must reside in the same bank as the old block (similar to the way that other hardware data structures are "banked").

ITT Fragmentation

ITT memory can become fragmented as blocks are allocated, grow, and are freed; blocks then consist of numerous used and free memory sections, of varying sizes. Under such circumstances, the aggregate amount of free memory can be significantly larger than the capacity of the largest single block.

Benefits

The primary benefits of the ITT management feature are:

· Reduced fragmentation in ITT blocks

· Capability to display ITT allocation

· Capability to autoshrink ITT blocks

Reducing ITT Fragmentation

It is important to make adjustments to the VC configuration processing, both at initial boot-up and in response to interface flaps. Optimal-size ITT blocks will be allocated on the first pass, and eliminate fragmentation due to sequentially growing the ITT blocks.

System and Startup ITT Fragmentation

Two sources of ITT fragmentation are the way that configured connections are installed in hardware upon startup and the way they are installed when an interface comes up.

When a startup configuration file is created (e.g. entering the write terminal command), the PVC cross-connect definitions are specified in the file in ascending order by interface, first addressing VPIs, and then VCIs (choosing one interface of a PVC as the source). This is the order in which they are processed when the system reads the file at startup. If the interface is considered up when the startup configuration is read, the VCI values in a VPI are allocated starting with the low values and proceeding to the high values; this can result in a series of steps that contribute to the growth of the ITT block used by the VPI.

Whether or not interfaces are up at startup, the startup configuration software creates data structures representing the PVCs specified in the startup configuration file.

Following a similar procedure, these data structures also order the PVCs by VPI, then VCI, and allocations start with the low values and proceed to the high values.

Whenever an interface comes up, connection management software evaluates each of the connections defined (in data structures) as residing on the interface, to see whether the connection can be brought up. This evaluation also proceeds by VPI, then VCI, and can result in fragmentation due to growth of the ITT blocks.

Solution: Minimum block-size per-VPI

The remedy proposed is to provide hints in configuration for the minimum ITT block size to allocate when allocating a block for a VPI on an interface.

Using the minblock Command to Specify a Minimum Block Size

Use the minblock command to specify the minimum block size for each VPI on an interface. Use the force keyword to specify a minimum ITT block size if autominblock mode is not enabled, or to ensure that the block size is not overridden by the autominblock mode. The minblock command is an interface configuration mode command.

The CLI-specified non-force minblock interface configuration command is overridden when one or more of the following four conditions are present:

Using the Autominblock Command to Enable the Minimum Mode

Use the autominblock command to enable the automatic analysis of minimum ITT needs of each interface/VPI in the system. The system uses this information for a subsequent ITT request, and specifies minimum block sizes in startup configuration generation via the insertion of minblock commands. This is a global configuration mode command.

On initial configuration of the atm input-xlate-table autominblock command, ITT memory may already be somewhat fragmented due to previous commands.

The effect of the fragmentation can be minimized by configuring, when first using the VPI, a cross-connect that uses the maximum VCI on a VPI. Note, however, that this should not be considered the best everyday practice; in general, for effective automatic determination of minimum block size on a VPI, a PVC should be configured by using the planned maximum VCI on a VPI.

When autominblock mode is disabled (via use of the no form of the command), all previously entered minblock configuration commands entered without the force keyword are lost.

Unless one of the atm input-xlate-table configuration commands is entered, the system operates as it did prior to these enhancements.

Whether or not the atm input-xlate-table autominblock configuration is in effect, the user can configure atm input-xlate-table minblock for interface/VPIs, (if the force keyword is used). The affect of the minblock command in the various situations in which it can be used is shown in Table 1:

Shrinking ITT Block Size

Natively, an ITT block will grow as necessary to accommodate higher VCIs on a given port/VPI, but will not automatically shrink as the high-numbered VCIs are removed from the configuration. An allocated ITT block will be freed if it has only one member VC, and that member VC is deleted; if one member VC is deleted but one or more other VCs still uses the block, the block retains its previously allocated size.

Two advantages of this process are the amount of time and processing required. It requires less processing time and resources, since blocks are not evaluated for size reduction, and preserving the block size facilitates the subsequent addition of other VCs to the block. In addition, if it does become necessary to resize the block, entering the shutdown/no shutdown command sequence on the interface will release ITT space, and a smaller block will be allocated.

When high-numbered VCs are deleted from the configuration, use the autoshrink global configuration command to shrink an ITT block in-place and release the unused ITT resources.

The autoshrink command and minblock/autominblock commands have the different effects on the system. When autominblock is disabled and no minblock commands are outstanding, as VCs are deleted, the autoshrink feature reduces ITT use of VCs that are sharing a VPI. The minblock commands specify a minimum desired block size

Displaying ITT resources

The non-privileged EXEC mode command show atm input-xlate-table provides a comprehensive view of ITT utilization, including the blocks that are used and available, and the ports at which the blocks are allocated. The output of the command shows details of the free blocks by size and bank, the aggregate remaining free space, and the location of blocks that are in use.

When you use the show command with the inuse keyword, the output of the command shows a detailed list of in-use blocks, by the port/VPI to which they are dedicated.

Configuration Examples

This section shows two examples of the show atm input-xkate-table command.

Example
LightStream1010 and 6400 NSP1

show atm input-xlate-table [inuse]
Use this nonprivileged exec mode command to display ITT usage details. The output of the unqualified command, (without the inuse keyword) shows detail of the free blocks by size and bank, the aggregate free space, and the location of the blocks that are in use. The output of the command with the inuse keyword show remaining a detailed list of the blocks that are in use, and lists them the by port/VPI to which they are dedicated.

The output of the unqualified command (without the inuse keyword) is:

The output of the command with the inuse keyword is:

Example
Catalyst 8540 MSR

show atm input-xlate-table [module-id module] [inuse]
Where module is a value 1-8.

The output of the unqualified command (without the inuse keyword) is:

The output of the command with the inuse keyword is: