Table of Contents

Setting Up a Circuit Line

Flow Diagram for ATM Line Setup
Line Commands

Setting Up Ports and Virtual Ports

Virtual Ports

Local Management Interface and
Integrated Local Management Interface

Early Abit Notification with Configurable Timer on LMI/ILMI Interface
Configuring Early Abit Notification

Recommended Settings
Behavior with Previous Releases
Performance Considerations

ILMI Neighbor Discovery

Configuring the BPX for ILMI Neighbor Discovery
Publishing the BXM Interface Information
Meaning of the NebrDiscEnable Parameter
Configuring the ILMI Management IP address
Displaying Neighbors

Configuring Circuit Lines and Ports

A circuit line is the physical wire that carries data, voice, Frame Relay, or ATM traffic between a BPX node (or IGX node) and customer premises equipment (CPE). Each piece of customer premises equipment is attached to a node through a circuit line.

A circuit line is connected to a physical interface on a switch backcard. Each physical line interface is represented by a unique software configuration called a port or logical interface for that line. A port is the logical interface between the BPX network and a single ATM device attached by a line. There is one port for each active line.

ATM ports are provided on ASI and BXM cards.

Before you can add connections on the circuit line, you must create a port or a virtual port on the line.

This chapter describes:

• Setting Up a Circuit Line

• Setting Up Ports and Virtual Ports

• Local Management Interface and Integrated Local Management Interface

• ILMI Neighbor Discovery

Setting Up a Circuit Line

ATM connections require an active line.

Before you can activate and configure a circuit line on a card, you must first establish or "up" a card by using the upcd command.

Use the cnfln to configure circuit lines. The switch software prompts for the parameters appropriate for the card type it detects. For details on each circuit line command, see the Cisco WAN Switching Command Reference. Note: Line commands are the same as "circuit line" commands.

To establish (or "up") an active line:

Step 2   Use upln to activate a circuit line in a slot that contains the appropriate circuit line card set.

Step 3   Use cnfln to configure the circuit line.

The upln and cnfln commands establish the general parameters for the line but do not establish specific Frame Relay, data, or voice parameters. Refer to applicable chapters for details on a particular service.

To down a line:

Step 2   Use dnln to down the line. A downed line is inactive, so no signals or statistics are generated.

Flow Diagram for ATM Line Setup

The command sequence for setting up lines for ATM is shown in Figure 19-1

A yes/no decision branch for "Other Side?" and the vt command in the sequence indicates command sequences on local and far nodes.

Line Commands

Table 19-1 Here are the names and descriptions for each line command:

Setting Up Ports and Virtual Ports

Once you have set up a circuit line, you are ready for the next step in adding connections: to create a port or one or more virtual ports for the line.

A port is the unique logical interface between the BPX network and a single attached ATM device.

Once you have activated a line by using the upln command, to set up a port or virtual port:

Step 2   Activate the port by using the upport X.Y[.Z] command, where X is the slot, Y is the port, and Z is an optional virtual port number.

Step 3   Use the cnfport command to establish the characteristics for the port.

Note   When adding a connection to a virtual port on a BXM card, the virtual port number is not required. The slot, port, and VPI will map to the supporting virtual port.

Note   In Release 9.3.0, if a slot-port combination for a BXM card has been brought up as a port (upport X.X), that slot-port cannot have virtual ports activated unless the port is first deleted (delport X.X). The opposite also applies; once a virtual port is configured, it cannot be used as a port until all virtual ports are deleted (delport X.X).

Virtual Ports

Virtual ports are logical interfaces like virtual trunks, trunks, and ports. (A maximum of 31 logical entities are available on a BXM card.)

Virtual ports is an optional feature that must be configured by Cisco on the BPX.

One or more virtual ports may function on a single port connected to CPE devices, directly or through an ATM cloud. Although virtual ports, like ports, can connect directly to CPEs, they are generally used to connect indirectly.

Traffic shaping has previously been supported on ports and on connections. Virtual ports on BPX switches provide hierarchical traffic shaping, which means both virtual port traffic shaping and connection traffic shaping.

A virtual port may carry multiple PVCs or PVPs. VI traffic shaping capability is provided per virtual port. Additionally, connection traffic shaping is available on a QOS basis. While virtual port shaping is always ON, you can turn connection traffic shaping ON or OFF by using the cnfportq command.

Each virtual port supports all Automatic Routing Management (AutoRoute) traffic types that are currently supported by ports.

To set the maximum bandwidth available for use on that virtual port, use the Bandwidth parameter of the command cnfport (see Figure 19-3). This parameter is similar to the Bandwidth parameter used for ports. However, while the Bandwidth parameter is configurable on a virtual port, on a port, this parameter is not configurable; it is automatically set to the line speed.

You can configure a virtual port's bandwidth to the full port bandwidth or a subset thereof. However, the bandwidth sum of all virtual ports on a port cannot exceed the port's total bandwidth.

Local Management Interface and
Integrated Local Management Interface

Local Management Interface (LMI) is a protocol that lets you monitor the status of permanent virtual connections between two communication devices.

Integrated Local Management Interface (ILMI) provides a means for configuration, status and control information between two ATM entities.

LMI and ILMI functions for the BXM card support virtual UNIs, feeder and virtual trunk ports, a total of 256 sessions on different interfaces (ports, trunks, virtual UNIs) per BXM.

For ILMI information, refer to Table 19-2

For the LMI information, refer to Table 19-3

.

Early Abit Notification with Configurable Timer on LMI/ILMI Interface

The time required to reroute connections varies depending on different parameters, such as the number of connections to reroute, reroute bundle size, and so on.

It is important to notify the customer premise equipment if a connection is derouted and fails to transport user data after a specified time interval. However, it is also desirable not to send out Abit = 0, then Abit =1 when a connection is derouted and rerouted quickly. Such notifications might prematurely trigger the CPE backup facilities, causing instabilities in an otherwise stable system.

The Early Abit Notification on ILMI/LMI Using Configurable Timer feature allows Abit notifications to be sent over the LMI/ILMI interface if a connection cannot be rerouted after a user-specified time. Abit = 0 will not be sent if the connection is rerouted successfully during that time.

The time period is configurable. The configurable time gives you the flexibility to synchronize the operation of the primary network and backup utilities, such as dialed backup over the ISDN or PSTN network.

Configuring Early Abit Notification

You configure the timer delay period by setting cnfnodeparm parameters. You want to choose timer settings that give you the flexibility to synchronize the operation of the primary network and backup utilities, such as dialed backup over the ISDN or PSTN network.

Be aware of these guidelines when using the Early Abit feature:

• When you enable this feature by using the cnfnodeparm command, you can specify that Abit Notification be:

  • sent either on deroute

  • or a user-configurable time after deroute

• This feature can also be turned off

• It is recommended that this feature be set the same on all nodes. Otherwise, the Abit behavior can be different on different nodes.

• If this feature is turned off, switch software behaves the same as in previous releases. Existing functionality continues to function in a mixed release network (releases 8.4, 8.5, or 9.1 IGX or BPX network).

• If the cnfnodeparm parameter Abit Timer Multiplier M is set to 0, then switch software behaves the same way as in Release 9.1.07 (which supported the Send Abit on Deroute feature).

• To follow the general Release 9.2 interoperability guideline, it is not recommended that the Early Abit Notification on ILMI/LMI Using Configurable Timer feature be used when the standby control processor is in a locked state.

Recommended Settings

You should be aware of the dynamic relation between the two timer parameters:

• Abit Timer Granularity N
  The time period is referred to as N, which defines the granularity of the timers. You specify N by the value of the cnfnodeparm Abit Timer Granularity N parameter.
  The default value for N is 3 sec.

• Parameter X
  The time to wait before Abit = 0 is sent out if the connection is in a derouted state.
  X, is set to be M*N

• Abit Timer Multiplier M
  M can be configured to be from 0 to 100. Default value for M (Abit Timer Multiplier M parameter) is 0, meaning Abit = 0 is sent out on deroute.

A connection that is derouted at a period of time between 0 and N will send out Abit = 0 at a time between X and X + N, if the connection continues to be in a derouted state. In cases where there are many Abit status changes to report to CPE, the last Abit updates may be delayed much longer because Abit updates process about 47 connections per second.

To make a compromise between performance and the granularity of timers, N can be configured to be from 3 to 255 seconds; the bigger the value of N, the better the system performance.

It is recommended that X (value of Abit Timer Multiplier M * the value of the Abit Timer Granularity N) be set such that when a trunk fails, the connections are given sufficient time to reroute successfully, avoiding the need to send out Abit = 0.

If the value of X (value of Abit Timer Multiplier M * value of Abit Timer Granularity N) is set to be smaller than the normal time to reroute connections when a trunk fails, the time it takes to finish rerouting them may take longer. This can happen for line cards and feeder trunks that have the LMI/ILMI protocol running on those cards, such as BXM on BPX and Frame Relay cards on IGX. Note that it takes time for those cards to process the Abit status information for each connection coming from the controller card.

The change in the Abit behavior is completely local to the node and is applicable to the master and slave ends of connections when the connections are derouted. When only one of the nodes connected by a connection has this feature turned on, the timing in sending the Abit notification at one end of the connection may be drastically different from the other end.

Therefore it is recommended that the Early Abit Notification on ILMI/LMI Using Configurable Timer feature be configured the same on all nodes.

Also, because timers on nodes are not in sync, there is a slight time difference (3 seconds maximum) in sending Abit from the two ends of a connection, even if the cnfnodeparm parameter settings on the nodes are the same.

Behavior with Previous Releases

Early Abit Notification on ILMI/LMI Using Configurable Timer is supported on both the BPX and IGX platforms. A Release 9.2 IGX or BPX node using this feature is compatible with Release 8.4 and Release 8.5 nodes or Release 9.1 IGX and BPX nodes so that all existing connection related functions will continue to work. However, the timing in sending out the Abit notifications at both ends of connections may behave differently, depending on how this feature is configured.

A pre-Release 9.1.07 node or Release 9.1.07 node with the Send Abit on Deroute feature (cnfnodeparm Send Abit immediately parameter) turned off behaves the same way as a Release 9.2 node with the Early Abit Notification on ILMI/LMI Using Configurable Timer feature disabled.

A Release 9.1.07 node with the cnfnodeparm Send Abit immediately parameter set to yes behaves the same way as a Release 9.2 node with the Send Abit Early parameter set to yes and the Abit Timer Multiplier M set to 0.

To follow the general Release 9.2 interoperability guideline, it is not recommended that the Early Abit Notification on ILMI/LMI Using Configurable Timer feature be used when the standby control processor is in a locked state.

There is no impact on control processor switchover or trunk card redundancy switchover because connections are not rerouted.

In releases previous to Release 9.1.07, when connections are derouted, the CPE does not receive Abit notifications. In Release 9.1.07 on BPX, the Send Abit on Deroute feature was developed, which allowed the Abit = 0 to be sent immediately when a connection is derouted. (This was specified by the cnfnodeparm parameter Send Abit immediately parameter.)

To further enhance the Send Abit on Deroute feature in Release 9.1.07, the Early Abit Notification on ILMI/LMI Using Configurable Timer feature was implemented in Release 9.2 to allow the network administrator to configure the node as to when Abit = 0 is sent out if a connection is derouted and not rerouted quickly. This feature allows you to specify when Abit notifications will be sent at Frame Relay and ATM ports, and at feeder trunks in a tiered network architecture that supports the ILMI/LMI interface. In a tiered network, the Abit information is used by the feeder nodes such as MGX 8220 (AXIS) which then relays the Abit information to the CPE.

Performance Considerations

The status update messages are throttled at the rate of one message per second. Each message can be used to specify the conditioning information on a maximum of 47 connections. It may take on the order of minutes for the ILMI/LMI manager to process the Abit status when there is a large number of connections.

There are two factors in performance:

• System performance
  System performance is affected by the value of the time interval. In a network where connections are normally derouted and rerouted quickly before the bucket timer expires, the performance impact is very small. Only when the timer expires, then looping through all LCONs and sending update messages will take up some CPU time which is estimated to be smaller than 1 percent.

• Reroute time
  Reroute time is not affected if LMI/ILMI is running on the controller card. When the protocol is implemented on the line cards and feeder trunk cards, some additional Abit status communication between them and controller card may delay the reroute process.

On the BPX, if the BXM runs LMI/ILMI, the BCC has to send Abit update to the card. These messages will be throttled. When this happens, the estimated time to reroute all 12K connections increases no more than 5 percent.

Note that on the IGX, enabling the Sending Abit Notification using Configurable Timer feature may impact performance if many connections end at Frame Relay cards. This is due to the restricted format of interface between NPM and Frame Relay cards.

ILMI Neighbor Discovery

The ILMI Neighbor Discovery feature, available only with the BXM card, enables a network management system such as Cisco WAN Manager or CiscoWorks 2000 to discover other attached ATM devices such as Cisco ATM routers or switches, provided that those devices also support ILMI Neighbor Discovery.

The ILMI Neighbor Discovery feature is supported only on a BXM port, but not on a virtual port.

Configuring the BPX for ILMI Neighbor Discovery

To enable ILMI Neighbor Discovery on the BXM card, use the cnfport command to set the BXM card parameters shown in ILMI Neighbor Discovery ParametersTable 19-4.

Publishing the BXM Interface Information

When ILMI Neighbor Discover is enabled on a BXM port, the BPX and the attached ATM device exchange their management IP addresses and other interface information with each other via the ILMI protocol.

The exchanged information consists of:

• atmfMyIfName: physical interface name

• atmfMyIfIdentifier: Interface identifier

• atmfMyIpNmAddress: Management IP Address, either the LAN IP or network IP.

• atmfMySysIdentifier: System Identifier, a 6-byte string read from the BPX NOVRAM, or if not available, the default value is "000001".

Meaning of the NebrDiscEnable Parameter

Note   If the port is also controlled by a PNNI controller, disabling Neighbor Discovery has no effect.

Configuring the ILMI Management IP address

The Management IP address is used by the NMS application to access the BPX or the ATM device. Depending on your network set up, you can configure the BPX to send either the LAN IP address or Network IP address as part of the neighbor information exchange with the attached ATM device.

To select LAN IP or NETW IP, use the cnfnodeparm command with option #56 Dnld LanIP or NwIP.

Enter 0 for LAN IP address, or 1 for Network IP address. The default is the network IP address for BPX.

Displaying Neighbors

You can use the dspnebdisc command to display all the neighbor's information discovered by the BPX via the ILMI Neighbor Discovery procedure.

Posted: Fri Jul 27 17:41:34 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.