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 back card. 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.

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

Setting Up a Circuit 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, refer to the Cisco WAN Switching Command Reference, Release 9.3.30.

Step 2

Enter the upln command to activate a circuit line in a slot that contains the appropriate circuit line card set.

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

Step 1

Remove all connections on a line by entering the delcon or delcongrp commands).

Step 2

Enter the dnln command o down the line. A downed line is inactive, so no signals or statistics are generated.

Flow Diagram for ATM Line Setup

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 Line Commands
Name	Description
cnfln	Configures the line (See also the cnfcln command.).
cnfrsrc	Configures the resources.
dnln	Downs the line (See also the dncln command.). A downed line is inactive, so no signals or statistics are generated. Before you down the line by using the dnln command, you must remove all connections on a line by using either the delcon command or the delcongrp command.
dsplncnf	Displays the line configuration (See also the dspclncnf command.). Displays the configuration of a specified circuit line.
dsplns	Displays the circuit line configuration and alarm status for the node (See also the dspclns command.).
prtlns	Prints the circuit line configuration and circuit line alarm status for the node (See also the prtclns command.).
upln	Ups the line (See also the upcln 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. You can also 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 shown in Figure 19-2.

Once you have activated a line by using the upln command, set up a port or virtual port by using the following procedure.

Step 1

Add a port by using the addport X.Y[.Z] command. For example, X is the slot, Y is the port, and Z is an optional virtual port number.

Step 2

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

Step 3

Enter 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

If a slot-port combination for a BXM card has been brought up as a port (upport X.X), the 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 such as 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 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 cnfport command (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 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 total bandwidth.

Virtual Port Examples

This section describes two of many possible examples of virtual port configurations.

•

Type I Virtual Ports can have PVP or PVC connections terminating on it.
All traffic through this Virtual Port is constrained to the Virtual Port's configured bandwidth (Virtual Port shaping). Moreover, if connection shaping is enabled (per QOS), each connection is constrained to a PCR and given a fair chance to transmit by using WFQ (Weighted Fair Queuing).

•

Type II Virtual Ports have PVC connections all with the same VPI terminating on it.
As with the type I Virtual Port above, all traffic through this port is constrained to the Virtual Port's configured bandwidth. If connection shaping is enabled, each connection is constrained to a PCR and under goes WFQ.

The BPX switch software does not distinguish between the two types of virtual ports.

Depending on the interface type, UNI or NNI, the maximum number of PVPs are 255 or 4095 respectively. The maximum number of VCIs is 65535.

Local Management Interface and Integrated Local Management Interface

Local Management Interface (LMI) is a protocol that monitors 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 functions are supported on ports and feeder trunks. ILMI functions are supported on ports, virtual ports, and virtual trunks.

Table 19-2 ILMI Parameters
Parameter	Description
VPI.VCI	VPI.VCI for ILMI signaling channel equal 0.16 as default
Polling Enabled	Keep-alive polling
Trap Enabled	VCC change of state traps
Polling Interval	Time between GetRequest polls
Error Threshold	Number of failed entries before ILMI link failure is declared.
Event Threshold	Number of successful polls before ILMI link failure is cancelled.
Advertise Intf Info	Indicates whether the BPX should communicate the interface information to the ILMI peer.

Table 19-3 LMI Parameters
Parameter	Description
VPI.VCI	VPI.VCI for LMI signaling channel equal 0.31
Polling Enable	Keep-alive polling
T393	Status Enquiry timeout value
T394	Update Status timeout value
T396	Status Enquiry polling timer
N394	Status Enquiry retry count
N395	Update Status retry count

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, 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 is not 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 the 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.

•

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

•

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, 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

•

Abit Timer Granularity N—Defines the granularity of the timers where the time period is referred to as N. You specify N by the value of the cnfnodeparm Abit Timer Granularity N parameter. The default value for N is 3 sec.

•

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

•

Abit Timer Multiplier M—Configures M to be from 0 to 100. The default value for M (Abit Timer Multiplier M parameter) is 0, which means 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 can 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 is configured to be from 3 to 255 seconds; the greater 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) is set so 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 can 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 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 can 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 preRelease 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.

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 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 are 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 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 specifies the conditioning information on a maximum of 47 connections. It can take on the order of minutes for the ILMI/LMI manager to process the Abit status when there is a large number of connections.

•

System performance—Determines the value of the time interval that is affected by system performance. 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—Specifies that the 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 must send Abit update to the card. These messages are throttled. When this happens, the estimated time to reroute all 12K connections increases no more than five percent.

Note On the IGX, enabling the Sending Abit Notification using Configurable Timer feature can 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. The ATM devices must also support ILMI Neighbor Discovery.

Configuring the BPX for ILMI Neighbor Discovery

To enable ILMI Neighbor Discovery on the BXM card, use the following the procedure.

Step 1

Enter the cnfport command to set the BXM card parameters as listed in Table 19-4.

Table 19-4 ILMI Neighbor Discovery Parameters
Parameters	Value
Protocol	ILMI
Protocol by Card	Yes
Advertise Intf Info	Yes
ILMI Polling Enabled	Yes

The following example shows the report of this command for ILMI Neighbor Discovery:

Publishing the BXM Interface Information

When the Advertise Intf Info parameter 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 through the ILMI protocol.

•

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

Table 19-5 Advertise Intf Info Parameter
Value	Description
No	The BPX will NOT publish its interface information to its neighbor. However, the BPX still queries for its neighbor information and if the neighbor's interface information is available, it will make the information available to CWM or any NMS applications requesting it. If there is a desire to keep the BPX interface information secure, set this parameter to No.
Yes	The BPX provides the interface information to its neighbor if queried.

Note If the port is also controlled by a PNNI controller, disabling this parameter has no affect.

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.

Step 1

Enter the cnfnodeparm command with option #56 Dnld LanIP or NwIP to select LAN IP or NETW IP as follows:

Step 2

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

Displaying Neighbors

Step 1

Enter the dspnebdisc command to display all the neighbor's information discovered by the BPX through the procedure in the ILMI Neighbor Discovery section:

Table Of Contents