Table Of Contents

Managing PNNI Nodes and PNNI Routing

Managing PNNI Nodes

Creating Upper Level Peer Groups

Enabling and Disabling the Complex Node Feature

Enabling and Disabling Routes Through a Node

Enabling and Disabling Point-to-Multipoint Branching

Adding an ATM Summary Address Prefix

Configuring SVCC RCC Variables

Configuring Routing Policies for Shortest Path Tables

Configuring PNNI Timers

Managing PNNI Routes

Configuring the On-Demand Route Selection Method (First Fit or Best Fit)

Configuring the Load Balance Selection Method

Managing Preferred Routes

Maintaining the Network Node Table

Creating a Preferred Route

Modifying a Preferred Route

Deleting a Preferred Route

Deleting a Node from the Network Node Table

Configuring Link Selection for Parallel Links

Configuring the Maximum Bandwidth for a Link

Configuring the Administrative Weight

Configuring the Aggregation Token

Configuring the Bandwidth Overbooking Factor

Configuring the Deroute Delay

Improving and Managing Rerouting Performance

Pure PXM45/C Networks

Hybrid Networks with PXM45/C and PXM45/B

Pure PXM45/B Networks Running Version 3.0.10 or Later

Hybrid Networks with PXM45/C and PXM45/A

Managing Priority Routing

Establishing Priority Routing on a Node

Configuring Priority Routing for an SPVC

Modifying SPVC Priority Routing Configuration

Configuring Priority Routing for an SVCs

Managing Priority Bumping

Enabling, Configuring, and Disabling Priority Bumping

Displaying the Priority Bumping Configuration

Displaying Priority Bumping Statistics

Resetting the Priority Bumping Statistics

Displaying Priority Bumping Resource Usage

Managing Connection Grooming

How Grooming Reroutes Connections

Enabling and Disabling Soft Rerouting for Grooming

Configuring Scheduled Grooming

Manually Grooming Connections

Configuring the Grooming Thresholds

Configuring Orderly Grooming

Configuring the Trunk Utilization Limit

Displaying Grooming Configuration Parameters

Displaying Threshold and Schedule Configuration Parameters

Displaying Nodal Grooming Configuration Parameters

Displaying Grooming Configuration Statistics

Configuring the AIS Delay

Enabling and Disabling the Soft Reroute IE

Displaying Node Configuration Information

Displaying the PNNI Node Table

Displaying the PNNI Summary Address

Displaying System Addresses

Displaying PNNI Interface Parameters

Displaying the PNNI Link Table

Displaying the PNNI Routing Policy

Displaying the SVCC RCC Timer

Displaying Routing Policy Parameters

Displaying the SVCC RCC Table

Managing CUGs

Assigning Address Prefixes and AESAs

Creating Closed User Groups

Displaying CUG Configuration Data

Setting a Default Address for CUG Validation

Deleting a Default CUG Address

Managing Access Between Users in the Same CUG

Managing Access Between a CUG Member and Non-Members or Members of other CUGS

Deleting a CUG Assignment

Blocking the CUG IE

Maintaining a Persistent Network Topology for CWM

Configuring a Gateway Node

Displaying the Network Topology Database

Displaying Link Information

Displaying Feeder Information

Disabling a Gateway Node

Deleting a Node from the Topology Database

Deleting a Link from the Topology Database

Managing PNNI Nodes and PNNI Routing

---

This chapter provides procedures that you can use to manage Private Network-to-Network Interface (PNNI) nodes and routes. This chapter includes the following sections:

•Managing PNNI Nodes

•Managing PNNI Routes

•Displaying Node Configuration Information

•Managing CUGs

•Maintaining a Persistent Network Topology for CWM

---

Note The concepts behind the procedures in this chapter are introduced in the Cisco PNNI Network Planning Guide for MGX and SES Products.

---

Managing PNNI Nodes

The following sections describe how to configure upper level peer groups and how to manage the PNNI node.

Creating Upper Level Peer Groups

Upper level peer groups enable routing from one PNNI peer group to another. If you are managing a single peer group WAN, you do not need to create upper level peer groups.

---

Note The "Configuring PNNI Node Parameters" section in Chapter 2, "Configuring General Switch Features," describes how to configure the lowest level peer group parameters, which many upper level peer group parameters are based on. You should configure the basic PNNI node parameters before creating upper level peer groups.

---

After you configure the lowest level PNNI nodes, all nodes within the same peer group can communicate with each other. All you need to do to enable communications between two nodes in a peer group is to add a PNNI trunk between them as described in the "ATM Trunk Configuration Quickstart" section in Chapter 3, "Provisioning PXM1E Communication Links." To enable routing between different peer groups at the same level, you must create one or more upper level peer groups.

The actual procedure for creating an upper level peer group for your WAN depends on the structure of your WAN. This section shows how to create an upper level peer group for the WAN shown in Figure 8-1.

Figure 8-1 Example Hierarchical PNNI Network Topology Showing a Two-Level Hierarchy

In Figure 8-1, the five level-56 peer groups are isolated from each other until the upper level peer group is created. The members of the upper level peer group are the peer group leaders from the lower level peer groups. To create an upper level peer group, you need to configure the peer group leaders and add the upper level PNNI process to each peer group leader (PGL) node. It is also a good practice to configure secondary peer group leaders that can take over if a PGL fails.

To configure peer group leaders, use the following procedure.

---

Step 1 Establish a configuration session using a user name with SUPER_GP privileges or higher.

Add the upper level PNNI logical node that will participate in the higher level PNNI group using the addpnni-node <level> command.

Replace level with the PNNI level for the higher level peer group. The PNNI level value must be smaller than the level value for the lower level peer groups. The following example creates a logical PNNI node at PNNI level 40.

PXM1E_SJ.7.PXM.a > addpnni-node 40

---

Note You need to complete this step for all nodes that will serve as PGLs or backup PGLs.

---

Step 2 Display the current PGL priority of the node that will become PGL or a back up PGL by entering the dsppnni-election command as shown in the following example:

PXM1E_SJ.7.PXM.a > dsppnni-election

node index: 1

   PGL state......      OperNotPgl     Init time(sec).......        15

   Priority.......               0     Override delay(sec)..        30

                                       Re-election time(sec)        15

   Pref PGL................56:160:47.00918100000000036b5e31b3.00036b5e31b3.01

   Pref PGL node name .....M8850_NY

   PGL.....................56:160:47.00918100000000036b5e31b3.00036b5e31b3.01

   PGL node name ..........M8850_NY

   Active parent node id...0:0:00.000000000000000000000000.000000000000.00

   Active parent node name 

node index: 2

   PGL state......        Starting     Init time(sec).......        15

   Priority.......               0     Override delay(sec)..        30

                                       Re-election time(sec)        15

   Pref PGL................0:0:00.000000000000000000000000.000000000000.00

   Pref PGL node name .....

   PGL.....................0:0:00.000000000000000000000000.000000000000.00

   PGL node name ..........

   Active parent node id...0:0:00.000000000000000000000000.000000000000.00

   Active parent node name 

In the example above, the PGL state indicates the PGL status of each of two logical nodes, and the priority value is what is used to determine if the node will become PGL. In this example, both logical nodes are set to the default value 0, and this value prevents a node from becoming a peer group leader.

Step 3 Set the PNNI priority for the node with the cnfpnni-election command as follows:

mgx8830a.1.PXM.a > cnfpnni-election node-index -priority value

Replace node-index with the index that identifies the logical node you are modifying, and replace value with the new priority value. A zero value prevents the node from becoming a PGL. If only one node in a peer group has a non-zero priority, that node will become PGL. If multiple nodes have non-zero priority values, the node with the highest priority value becomes PGL. The following example shows what happens after you set the priority level and view the PGL status.

PXM1E_SJ.7.PXM.a > cnfpnni-election 1 -priority 200

PXM1E_SJ.7.PXM.a > dsppnni-election                

node index: 1

   PGL state......  AwaitUnanimity     Init time(sec).......        15

   Priority.......             200     Override delay(sec)..        30

                                       Re-election time(sec)        15

   Pref PGL................56:160:47.00918100000000001a533377.00001a533377.01

   Pref PGL node name .....PXM1E_SJ

   PGL.....................56:160:47.00918100000000036b5e31b3.00036b5e31b3.01

   PGL node name ..........M8850_NY

   Active parent node id...0:0:00.000000000000000000000000.000000000000.00

   Active parent node name 

node index: 2

   PGL state......        Starting     Init time(sec).......        15

   Priority.......               0     Override delay(sec)..        30

                                       Re-election time(sec)        15

   Pref PGL................0:0:00.000000000000000000000000.000000000000.00

   Pref PGL node name .....

   PGL.....................0:0:00.000000000000000000000000.000000000000.00

   PGL node name ..........

   Active parent node id...0:0:00.000000000000000000000000.000000000000.00

   Active parent node name 

The first time the dsppnni-election command was entered, the PGL state was OperNotPgl, which means that the node is operating, but is not operating as a PGL. After the priority is changed, the PGL state changes to AwaitUnanimity, which means the node is communicating with the other nodes in its peer group to see if it has the highest priority and should be PGL. If you enter the dsppnni-election command again after about 15 seconds, the PGL state changes as shown in the following example:

PXM1E_SJ.7.PXM.a > dsppnni-election

node index: 1

   PGL state......         OperPgl     Init time(sec).......        15

   Priority.......             250     Override delay(sec)..        30

                                       Re-election time(sec)        15

   Pref PGL................56:160:47.00918100000000001a533377.00001a533377.01

   Pref PGL node name .....PXM1E_SJ

   PGL.....................56:160:47.00918100000000001a533377.00001a533377.01

   PGL node name ..........PXM1E_SJ

   Active parent node id...40:56:47.009181000000000000000000.0007856e15e1.00

   Active parent node name PXM1E_SJ-02

node index: 2

   PGL state......      OperNotPgl     Init time(sec).......        15

   Priority.......               0     Override delay(sec)..        30

                                       Re-election time(sec)        15

   Pref PGL................0:0:00.000000000000000000000000.000000000000.00

   Pref PGL node name .....

   PGL.....................0:0:00.000000000000000000000000.000000000000.00

   PGL node name ..........

   Active parent node id...0:0:00.000000000000000000000000.000000000000.00

   Active parent node name 

In the example above, the PGL state changes to show that logical node 1 is now the PGL. Notice that the priority value is 250. An earlier example in this procedure set the priority to 200. When a node is elected PGL, the node adds 50 to its priority value to prevent instability that might be caused by other peer group nodes with a marginally higher priority value.

Step 4 Repeat this procedure for backup peer group leaders and be sure to set their priority value to a lower value so that they operate as backup PGLs.

---

Enabling and Disabling the Complex Node Feature

The complex node feature applies to PGL parent LGNs in MPG networks. When this feature is disabled, parent LGNs present other peer groups to the child peer group using simple node representation. With simple node representation, each external peer group is presented as a simple node with a single cost for routing through the peer group.

When the complex node feature is enabled, a parent LGN presents other peer groups using complex node representation. Complex node representation provides information about multiple paths through external peer groups, and this gives source route nodes more choices when routing through external peer groups.

---

Tip For more information on complex nodes, refer to the Cisco PNNI Network Planning Guide for MGX and SES Products.

---

To enable or disable the complex node feature, enter the following command:

M8850_LA.8.PXM.a > cnfpnni-node <node-index > -complexNode on|off

Replace node-index with the index that identifies the logical node you are modifying, and enter either on or off for the -complexNode parameter. When this parameter is set to on, the node presents external peer groups using complex node representation. When the -complexNode parameter is set to off, the node presents external peer groups using simple node representation.

To view the status of the -complexNode option, enter the dsppnni-node command as shown in the following example:

M8850_LA.8.PXM.a > dsppnni-node

node index: 1                      node name: M8850_LA       

   Level...............        56     Lowest..............      true

   Restricted transit..       off     Complex node........        on

   Branching restricted       off

   Admin status........        up     Operational status..        up

   Non-transit for PGL election..       off

   Node id...............56:160:47.00918100000000036b5e2bb2.00036b5e2bb2.01

   ATM address...........47.00918100000000036b5e2bb2.00036b5e2bb2.01

   Peer group id.........56:47.00.9181.0000.0000.0000.0000.00

Enabling and Disabling Routes Through a Node

The restricted transit option allows you to allow or block call routes that pass through the node and terminate on other nodes. The default setting for this option enables calls to pass through.

To enable or disable PNNI routing through a node, enter the cnfpnni-node command as follows:

mgx8830a.1.PXM.a > cnfpnni-node <node-index > -transitRestricted on|off

Replace node-index with the index that identifies the logical node you are modifying, and enter either on or off for the -transitRestricted parameter. When this parameter is set to on, the node only accepts calls that terminate on this node. When the -transitRestricted parameter is set to off, the node accepts calls that pass through the node and terminate on other nodes.

To view the status of the -transitRestricted option, enter the dsppnni-node command as shown in the following example:

mgx8830a.1.PXM.a >  dsppnni-node

node index: 1                      node name: 8850_LA        

   Level...............        56     Lowest..............      true

   Restricted transit..        on     Complex node........       off

   Branching restricted        on

   Admin status........        up     Operational status..        up

   Non-transit for PGL election..       off

   Node id...............56:160:47.00918100000100001a531c2a.00001a531c2a.01

   ATM address...........47.00918100000100001a531c2a.00001a531c2a.01

   Peer group id.........56:47.00.9181.0000.0100.0000.0000.00

Enabling and Disabling Point-to-Multipoint Branching

The branching restricted option allows you to enable or disable branching for point-to-multipoint calls. When branching is enabled, the node can receive one source connection and branch that connection to multiple cards and ports. When branching is disabled, a separate source connection is required for every destination card or port. The default setting for this option enables branching for point-to-multipoint calls.

To enable or disable branching in a node, enter the cnfpnni-node command as follows:

mgx8830a.1.PXM.a > cnfpnni-node <node-index > -branchingRestricted on|off

Replace node-index with the index that identifies the logical node you are modifying, and enter either on or off for the -branchingRestricted parameter. When this parameter is set to on, the node does not branch connections. When the -branchingRestricted parameter is set to off, the node performs branching.

To view the status of the -branchingRestricted option, enter the dsppnni-node command as shown in the following example:

mgx8830a.1.PXM.a >  dsppnni-node

node index: 1                      node name: 8850_LA        

   Level...............        56     Lowest..............      true

   Restricted transit..       off     Complex node........       off

   Branching restricted        on

   Admin status........        up     Operational status..        up

   Non-transit for PGL election..       off

   Node id...............56:160:47.00918100000100001a531c2a.00001a531c2a.01

   ATM address...........47.00918100000100001a531c2a.00001a531c2a.01

   Peer group id.........56:47.00.9181.0000.0100.0000.0000.00

Adding an ATM Summary Address Prefix

Enter the addpnni-summary-addr command to add an ATM summary address prefix for a PNNI logical node on the switch.

mgx8830a.1.PXM.a > addpnni-summary-addr <node-index> <address-prefix> <prefix-length> [-type] 
[-suppress] [-state]

Table 8-1 lists the parameter descriptions for the addpnni-summary-addr command.

Table 8-1 Parameters for addpnni-summary-addr Command

Parameter	Description
node-index	The node index assigned to a PNNI logical node on a network. Range = 1 - 65535
address-prefix	The ATM address prefix assigned to the network.
prefix-length	The length of the summary address-prefix in number of bits, equal or less than 152 bits. Currently, the zero-length summary address is not supported.
-type	The type of the summary address.
-suppress	true = summary address is not advertised.
-state	The summary address is advertised | notadvertised | inactive.

Configuring SVCC RCC Variables

Configure SVCC-based RCC variables with the cnfpnni-svcc-rcc-timer command as follows:

mgx8830a.1.PXM.a > cnfpnni-svcc-rcc-timer <node-index> [-initTime] [-retryTime] 
[-callingIntegrityTime] [-calledIntegrityTime] 

This defines a node's initial PNNI SVCC-based variables, as shown in Table 8-2.

Table 8-2 Parameters for cnfpnni-svcc-rcc-timer Command

Parameter	Description
node-index	Node index.
-initTime	Time (in seconds) that the node delays establishment of an SVCC to a neighbor with a numerically lower ATM address, after determining that such an SVCC should be established.
-retryTime	Time (in seconds) that the node delays before attempting to re-establish an SVCC-based RCC after the RCC is unexpectedly torn down.
-callingIntegrityTime	Time (in seconds) that the node waits for a sent SVCC to become fully established before giving up and tearing it down.
-calledIntegrityTime	Time (in seconds) that the node waits for a received SVCC to become fully established before giving up and tearing it down.

Configuring Routing Policies for Shortest Path Tables

The shortest path tables (SPTs), which are also called background routing tables, are created by default to store the shortest paths or routes to all destinations. These SPTs can be divided into three groups as described in the Cisco PNNI Network Planning Guide for MGX and SES Products. Each group stores routes that are optimized for one of the following routing metrics: AW, CTD, or CDV. Within each group, tables are created for each CoS that uses the routing metric.

You can use the cnfpnni-routing-policy command to control which SPTs are created, how often they are updated, and other SPT related features. To display the current routing policies for a node, enter the dsppnni-routing-policy command as follows:

M8830_CH.1.PXM.a > dsppnni-routing-policy

   SPT epsilon.........         0     Load balance........    random

   SPT holddown time...         1     On demand routing... first fit

   bn path holddown time        2     AW Background Table         on

   CTD Background Table        on     CDV Background Table       off 

To configure the SPT routing policies, enter the cnfpnni-routing-policy command as follows:

mgx8830a.1.PXM.a > cnfpnni-routing-policy [-sptEpsilon] [-sptHolddown] [-bnPathHolddown] 
[-loadBalance] [-onDemand] [-awBgTable] [-ctdBgTable] [-cdvBgTable]

Table 8-3 lists the parameter descriptions for the cnfpnni-routing-policy command.

Table 8-3 Parameters for cnfpnni-routing-policy Command 

Parameter	Description
-sptEpsilon	The SPT epsilon allows you to specify a percentage range in which shortest path routes to a particular destination are considered equal. For example, you can specify that all routes within 6.25% of the lowest cost route are to be considered equal and considered for placement in the appropriate SPT. The range of 0-20 for this parameter comes from the ATM Forum PNNI specification. However, the percentage applied to this range is determined by individual vendors. Cisco Systems currently maps this range to percentages as follows: 0 = The routing metric (which is AW, CTD, or CDV) value for all SPT routes to a particular destination must be identical. 1-2 = The SPT considers routes within 1.06% of the shortest path to be equal. 3-4 = The SPT considers routes within 3.125% of the shortest path to be equal. 5-9 = The SPT considers routes within 6.25% of the shortest path to be equal. 10-15 = The SPT considers routes within 12.5% of the shortest path to be equal. 16-20 = The SPT considers routes within 25.0% of the shortest path to be equal. Default: 0
-sptHolddown	The SPT holddown timer defines the node's minimum time interval between two consecutive calculations of the SPTs. If a network is stable, it may not be necessary to generate routing tables 10 times per second. In such a case, you can increase the holddown timer value to reclaim CPU time needlessly spent on updating unchanging routing tables. Units: 100 millisecond increments Range: 1-600 (0.1-60 seconds) Default: 1
-bnPathHolddown	The border node holddown timer defines the node's minimum time interval between two consecutive calculations of the border node path tables. If a network is stable, it may not be necessary to generate border node route tables 10 times per second. In such a case, you can increase the value to reclaim CPU time needlessly used to update unchanging routing tables. In such a case, you can increase the holddown timer value to reclaim CPU time needlessly spent on updating unchanging routing tables. Units: 100 millisecond increments Range: 2-600 (0.2-60 seconds) Default: 2
-loadBalance	This parameter defines how routing connections are distributed across the routes stored in the SPTs. For more information, see "Configuring the Load Balance Selection Method," which appears later in this chapter.
-onDemand	This parameter defines how the on-demand routing feature selects routes. For more information, see "Configuring the On-Demand Route Selection Method (First Fit or Best Fit)," which appears later in this chapter. The parameter options are: firstfit = select the first route found bestfit = select the best route Default = firstfit
-awBgTable	This parameter enables or disables generation of the AW SPTs for all classes of service. Enter -awBgTable on to enable AW SPT generation, or enter -awBgTable off to disable it. Default = on
-ctdBgTable	This parameter enables or disables generation of the CTD SPTs for the CBR, rt-VBR, and nrt-VBR classes of service. Enter -ctdBgTable on to enable CTD SPT generation, or enter -ctdBgTable off to disable it. Default = on
-cdvBgTable	This parameter enables or disables generation of the CDV SPTs for the CBR and rt-VBR classes of service. Enter -cdvBgTable on to enable CDV SPT generation, or enter -cdvBgTable off to disable it. Default = on

Configuring PNNI Timers

Configure the PNNI timers with the cnfpnni-timer command.

mgx8830a.1.PXM.a >  cnfpnni-timer <node-index> <options>

You can define the initial PNNI timer values and significant change thresholds of a PNNI logical node. Table 8-4 lists the parameter descriptions for the cnfpnni-timer command.

Table 8-4 Parameters for cnfpnni-timer Command

Parameter	Description
nodeindex	Logical node's node index.
-ptseholddown	This is the holddown time between two consecutive originations of PTSEs on the node. Range: (0.1 through 10) second Default = 1
-helloholddown	Value for the Hello hold down timer that limits the rate at which it sends Hellos.
-hellointerval	Initial value for the Hello timer.
-helloinactivityfactor	Inactivity time factor on a horizontal link between two logical nodes.
-ptserefreshinterval	Time allowed for the PTSE to re-originate.
-ptselifetimefactor	Value for the lifetime multiplier, expressed as a percentage. The product of this value and the ptserefreshinterval is sets the remaining lifetime of a self-originated PTSE.
-retransmitinterval	Period between retransmissions of unacknowledged DS, PTSE request, and PTSP.
-ptsedelayedackinterval	Minimum time allowed between transmissions of delayed PTSE acknowledgment packets.
-avcrpm	Proportional multiplier used in the algorithms that determines significant change for AvCR parameters.
-avcrmt	Minimum threshold used in the algorithms that determine significant change for AvCR parameters.
-cdvpm	Proportional multiplier used in the algorithms that determine significant change for CDV parameters.
-ctdpm	Proportional multiplier used in the algorithms that determine significant change for CTD parameters.

Managing PNNI Routes

The following sections describe how to control route and link selection for the links on each PNNI node.

Configuring the On-Demand Route Selection Method (First Fit or Best Fit)

When the PNNI controller searches for routes, it can choose the first route that meets the call requirements, or it can choose the route that provides the best performance. The first fit method chooses the first available route and reduces call processing time. The best fit method chooses the optimum route, but it takes longer to select the route. The default setting is first fit.

---

Note The route selection process is described in the Cisco PNNI Network Planning Guide for MGX and SES Products.

---

To configure the route selection method, enter the cnfpnni-routing-policy command as follows:

mgx8830a.1.PXM.a > cnfpnni-routing-policy -onDemand firstfit|bestfit

Enter firstfit to select the first route discovered, or enter bestfit to select the optimum route.

To display the route selection method, enter the dsppnni-routing-policy command as follows:

mgx8830a.1.PXM.a > dsppnni-routing-policy

   SPT epsilon.........         0     Load balance........    random

   SPT holddown time...         1     On demand routing... first fit

   SPT path holddown time       2     AW Background Table         on

   CTD Background Table        on     CDV Background Table        on 

The parameter labeled On demand routing shows which route selection method is configured.

Configuring the Load Balance Selection Method

When multiple eligible routes are found in an SPT during call setup, the load balancing feature attempts to balance the load among those routes. The load balance options are random and maxbw. The random option randomly chooses between the eligible routes each time a new call is set up. The maxbw option selects the route with the maximum available bandwidth.

---

Note The route selection process is described in the Cisco PNNI Network Planning Guide for MGX and SES Products.

---

To configure the load balance option, use the cnfpnni-routing-policy command as follows:

mgx8830a.1.PXM.a > cnfpnni-routing-policy -loadBalance random|maxbw

Enter random to randomly choose among the eligible route, or enter maxbw to select the route with the greatest available bandwidth.

To display the route selection method, enter the dsppnni-routing-policy command as follows:

mgx8830a.1.PXM.a > dsppnni-routing-policy

   SPT epsilon.........         0     Load balance........    random

   SPT holddown time...         1     On demand routing... first fit

   SPT path holddown time       2     AW Background Table         on

   CTD Background Table        on     CDV Background Table        on 

The parameter labeled Load balance shows which load balance method is configured.

Managing Preferred Routes

You can manually create a route that is preferred for specific SPVC and SPVP connections. Once a preferred route is created, the associated SPVC or SPVP connections will attempt to route through the preferred route before attempting other routes.

---

Note A preferred route can be assigned to multiple SPVCs or SPVPs.

---

Preferred routes can be configured to be directed or non-directed. A directed route only attempts a connection on the preferred route. If the connection cannot route over the preferred route, that connection will go into a failed state. A non-directed route first attempts to route over the preferred route. If the preferred route is not available, the connection will be attempted over other routes.

Keep the following in mind when planning preferred routes:

•All nodes in the preferred route must exist in the network node table.

•A preferred route can be confined to the same peer group as the source node, or it can go outside the local peer group.

•A preferred route can include non-Cisco nodes.

•A node can appear only once in a preferred route.

•Any preferred routes you defined using Release 3 software will be lost during an upgrade to Release 4. Once you have upgraded to Release 4, you must be manually re-enter your preferred routes. Prior to an upgrade, use the dspprefs command view all the configured preferred routes. Write down any preferred routes you want to re-enter once you have upgraded to Release 4.

•The preferred route feature is not compatible with point-to-multipoint SPVC configuration.

•Connections mastered on an RPM or VISM cannot be associated with a preferred route.

---

Note In Release 4, Cisco MGX switches with PXM45/A, PXM45/B, or PXM1E controllers support up to 5000 preferred routes per switch. When used with PXM45/C controllers, Cisco MGX 8850 (PXM45) and Cisco MGX 8950 switches, and the MGX 8880 Media Gateway, support up to 10000 preferred routes.

---

A preferred route consists of a sequential list of up to 20 nodes, including the local node that hosts the starting point of the preferred route. The destination node can be up to 19 network elements (NEs), or 19 NNI links, away from the local node.

---

Note VISM-PR cards do not support preferred routes in Release 5. Any VISM-PR preferred routes that were configured in a previous release will be lost when the switch is upgraded to Release 4.

---

Maintaining the Network Node Table

To support preferred routes, the network administrator manually creates a node table that contains information about all the nodes in the network. All the nodes that will be in a preferred route must appear in the network node table, and each node in a preferred route must have its own entry in the network table.

Cisco recommends that you keep the same network node table on every node in your network for the purpose of convenience when configuring preferred routes. Once you create the node table on one node, you can to FTP that table to all the other nodes in the network. If you change any information in one of the node tables, you need to update all of the node tables in the network to ensure synchronicity.

Before you can create a preferred route, all the nodes that will be in the preferred route must be in the network node table. Enter the dspnwnodes command to ensure that all the nodes in your planned preferred route are in the network node table, as shown in the following example:

U1.8.PXM.a > dspnwnodes

Node Identifier PXM Pref rte Node name 

     -------------------------------------------------- ----- -------- --------- 

     56:160:47.009181000000003071f80406.003071f80406.01 pxm1 No Fargo 

     56:160:47.009181000000003071f80422.003071f80422.01 pxm45 No Denver 

     56:160:47.339181000000003071f80433.003071f80433.01 pxm1E Yes Chicago 

If one or more nodes in your preferred route does not appear in the network node table, use the following procedure to add the missing nodes to the table.

---

Step 1 Establish a configuration session using a user name with GROUP1 privileges or higher.

Step 2 Enter the addnwnode command as follows to add the a node to the network node table:

U1.8.PXM.a > addnwnode <nodeId> <pxmType> [-name <nodeName>]

Table 8-5 describes the parameters you can configure through the addnwnode command.

Table 8-5 addnwnode Command Parameters

nodeId	This 22-octet uniquely identifies a PNNI node.
pxmType	Type of controller card in the switch. The controller type determines how the software converts between the physical and logical port identifiers. Type one of the following case-sensitive strings: •PXM45 •PXM1 •PXM1E •Others (for non-Cisco nodes) Note If you enter Others as the pxmType, you can not use the portId to build a preferred route. (See the neSyntax parameter in Table 8-6.)
-name	A string of up to 32 case-sensitive IA5 characters (except when empty) describing a PNNI node. If you plan to build a preferred route by using node names, you must include the -name option for entries in the network node table. Default: an empty string

In the following example, the user adds a PXM1E node named LA to the network.

MGX8850.7.PXM1E.a > addnwnode 56:100:47.009181000000003071f80406.003071f80406.01 PXM1E 
-name LA

Step 3 Enter the dspnwnode -id <nodeId> or the dspnwnode -name <nodeName> command to ensure that the node you added in Step 2 appears in the network node table. If you use the dspnwnode -id <nodeId> command, replace <nodeId> with the 22-octet node identifier. If you use the dspnwnode -name <nodeName> command, replace <nodeName> with the name you assigned to the node in Step 2.

---

Enter the cnfndidrtes command to replace a node ID with a different ID for all configured preferred routes. For example, if you remove a node that is a network element (NE) in one or more preferred routes, you can use the cnfndidrtes to enter a different node's name. Providing that the new node's name appears in the network node table, the new node replaces the old node in the preferred route. Enter the cnfndidrtes command as shown in the following example:

cnfndidrtes <oldNodeId> <newNodeId>

Replace <oldNodeId> with the 22-octet identifier for the node you want to replace. Replace <newNodeId> with the 22-octet identifier of the new node that replaces the old node.

Creating a Preferred Route

Use the following procedure to create a preferred route.

---

Step 1 Enter the dspnwnodes command to see the nodes in this database. These are the nodes you can use to set up your preferred route.

U1.8.PXM.a > dspnwnodes

Total Number of Network Nodes : 14 

     Node Identifier PXM Node name 

     --------------- --- --------- 

     56:160:47.0091810000000004c113ba39.0004c113ba39.01 PXM45 p2spvc7 

     56:160:47.00918100000000001a531c41.00001a531c41.01 PXM45 p2spvc14 

     56:160:47.009181000000000142266086.000142266086.01 PXM45 p2spvc15 

     56:160:47.00918100000000001a531c01.00001a531c01.01 PXM45 p2spvc20 

     56:160:47.00918100000000001a531c43.00001a531c43.01 PXM45 pswpop2-1 

     56:160:47.009181000000000164444ae0.000164444ae0.01 PXM45 pswpop2-2 

     56:160:47.00918100000000107be92fde.00107be92fde.01 PXM45 pswpop10 

     56:160:47.00918100000000c043002ddf.00c043002ddf.01 PXM1 pswpop9 

     56:160:47.009181000000003071f81323.003071f81323.01 PXM1 pnnises3 

     56:160:47.009181000000003071f8139d.003071f8139d.01 PXM1 pnnises4 

     56:160:47.00918100000000d058ac28e9.00d058ac28e9.01 PXM1 svcswp13 

     56:160:47.00918100000000c043002dcc.00c043002dcc.01 PXM1 svcswp15 

     56:160:47.0391810000000050e2003e16.0050e03e1600.00 Others svcslt5 

     56:160:47.0391810000000050e2001600.50e000000000.00 Others svcslt6 

Step 2 Enter the addpref command to set up your preferred route as follows:

8850_LA.7.PXM.a > addpref <routeid> <neSyntax> [-dstNEpos <NE>] [-ne1 {<node>/<port>}] 
[-ne2 {<node>/<port>}] ... [-ne20 {<node>/<port>}]

Table 8-6 describes the parameters you can configure for the addpref command.

Table 8-6 addpref Command Parameters

routeid	The preferred route identifier has a range of 1-65535. If a particular ID is in use, the node rejects the command. Check the dspprefs output for available route IDs as needed.
neSyntax	Four ways of identifying the NEs exist. Use the selected form for all NEs in the route Type one of the following keywords: •nodeidPnportid means the node is specified by the 22-octet node ID and the port by the PNNI logical integer pnPortId. •nodenamePortid means the node is specified by the node name and the port by the physical port ID. You can use node names only if the node names were added to the network node table (in addition to the mandatory node IDs). You can not use the physical port ID syntax if the pxmType is provisioned as Others. (See Table 8-5.) •nodeidPortid means the node is specified by the 22-octet node ID and the port by the physical port ID. You can not use the physical port ID syntax if the pxmType is provisioned as Others. (See Table 8-5.) •nodenamePnportid means the node is specified by the node name and the PNNI logical port by the integer pnPortId. You can use node names only if the node names were added to the network node table (in addition to the mandatory node IDs). The nodeID is the 22-octet PNNI node ID. The Portid is the PNNI physical port ID. On a PXM1E, the format is slot.port. On a PXM45, the format is slot:subslot.port:subport. The PnportID is the PNNI logical port identifier. This form of port identifier is an integer in the range 0-4294967295. Default: none
-dstNEpos	This integer identifies the position of the destination node in the NE sequence. For instance, an NE of 4 indicates that the fourth NE represents the destination node. Range: 1-20 Default: none
-ne1 through -ne20	Including the local node, you can specify up to 20 NEs in the preferred route. Each NE is defined by a pairing of a node and a port. The format of these paired elements must conform to the entry for neSyntax. Separate the values in the pairing by a slash and no spaces, but put a space between the keyword and NE, as follows: -ne(n) node/port The NE you specify as the destination node must be the highest numbered keyword, otherwise the switch rejects the command.The port identifier at the destination node must be set to 0. Note that the value 0 actually determines the last NE in the route. This 0 appears in the outputs of the display commands for preferred routes. For example, if a route has 9 NEs, the format would be: -ne9 node/0

Step 3 Enter the dsppref <routeId> command to verify the preferred route was configured correctly. Replace <routeId> with the preferred routes identifier.

Step 4 Associate the appropriate SPVC or SPVP to the preferred route you created in Step 2.

a. If you are associating a new SPVC or SPVP with the preferred route, enter the addcon command as follows:

addcon <ifNum> <vpi> <vci> <serviceType> <mastership> -prefrte <preferredRouteId> [-directrte <directRoute>]

---

Note For PXM1E cards, the addcon command is entered at the PXM card prompt. For all other cards, the addcon command is entered at the service module prompt.

---

Table 8-7 describes the parameters you can configure for the addcon command.

b. If you are associating a previously created SPVC/SPVP with the preferred route, enter the cnfcon command, as follows:

cnfcon <ifNum> <vpi> <vci> <serviceType> <mastership> -rtngprio <routingPriority> -prefrte <preferredRouteId> [-directrte <directRoute>]

---

Note For PXM1E cards, the cnfcon command is entered at the PXM card prompt. For all other cards, the addcon command is entered at the service module prompt.

---

Table 8-7 describes the parameters you can configure for the cnfcon command.

---

Note There are other optional parameters that you can set using the addcon and cnfcon commands, but they do not appear in Table 8-7 because you do not need to set them when you are associating an SPVC or SPVP with a preferred route. For information on all the command parameters for PXM1E cards, see Chapter 3, "Provisioning PXM1E Communication Links." For information on all the addcon and cnfcon command parameters a service module, refer to the appropriate service module guide, all of which are listed in Table 1-1.

---

Table 8-7 addcon and cnfcon Preferred Route Command Parameters 

Parameter	Description
ifNum	Logical interface (or port) number. This ifNum corresponds to the ifNum added through the addport command. The range is 1-31.
vpi	Virtual path identifier value in the range 0-255 (UNI) or 0-4095 (NNI or VNNI). For VNNI, specify one VPI per port.
vci	Virtual connection identifier (VCI): For a VCC on a UNI, the range is 1-4095. On an NNI or VNNI, the VCI range is 1-65535. For MPLS, the recommended minimum VCI is 35. For a VPC, the vci is 0.
mastership	Value to specify the endpoint as master or slave: •1 or `m' specifies the master end. •2 or `s' specifies the slave end.
-prefrte	Associates a preferred route (preferredRouteId) to the connection. Use this optional parameter at the master endpoint only. Range: 0-65535 Default: 0
-directrte	Specifies that the connection can take only the preferred route associated through the -prefrte parameter. Use this optional parameter at the master endpoint only. To remove this requirement from the connection, use the cnfcon command and specify a 0 for the parameter. The possible values are as follows: 1: yes (make the preferred route required) 0: no (do not require the connection to take the preferred route) Default: no (0)

Step 5 Enter the dspcon <portid> <vpi> <vci> command to ensure that the SPVC/SPVP has been configured properly and is associated with the preferred route you set up in Step 1. Replace <portid> with the port identifier in the format slot:bay.line:ifnum. Replace <vpi> with the virtual path identifier for the connection. Replace <vpi> with the virtual circuit identifier for the connection.

---

Modifying a Preferred Route

Use the cnfpref command to modify a preferred route. The cnfpref command lets you re-specify existing NEs in a route, or add one or more NEs to an existing route. You can also change an NE to indicate that it is the destination node. A new destination node must have the highest NE number in the route. (See the detailed usage guidelines for the addpref command for details.)

Enter the cnfpref command as follows:

8850_LA.7.PXM.a > cnfpref <rteId> <neSyntax> [-dstNePos <Ne>] [-ne1 {<node>/<port>}] [-ne2 
{<node>/<port>}] ... [-ne20 {<node>/<port>}]

Table 8-8 describes the cnfpref command parameters.

Table 8-8 Parameters for cnfpref Command 

Parameter	Description
routeid	The preferred route identifier has a range of 1-65535. If a particular ID is in use, the node rejects the command. Check the dspprefs output for available route IDs as needed.
neSyntax	Four ways of identifying the NEs exist. Use the selected form for all NEs in the route Type one of the following keywords: •nodeidPnportid means the node is specified by the 22-octet node ID and the port by the PNNI logical integer pnPortId. •nodenamePortid means the node is specified by the node name and the port by the physical port ID. You can use node names only if the node names were added to the network node table (in addition to the mandatory node IDs). You can not use the physical port ID syntax if the pxmType is provisioned as Others. (See Table 8-5.) •nodeidPortid means the node is specified by the 22-octet node ID and the port by the physical port ID. You can not use the physical port ID syntax if the pxmType is provisioned as Others. (See Table 8-5.) •nodenamePnportid means the node is specified by the node name and the PNNI logical port by the integer pnPortId. You can use node names only if the node names were added to the network node table (in addition to the mandatory node IDs). The nodeid is the 22-octet PNNI node ID. The Portid is the PNNI physical port ID. On a PXM1E, the format is slot.port. On a PXM45, the format is slot:subslot.port:subport. The Pnportid is the PNNI logical port identifier. This form of port identifier is an integer in the range 0-4294967295. Default: none
-dstNEpos	This integer identifies the position of the destination node in the NE sequence. For instance, an NE of 4 indicates that the fourth NE represents the destination node. Range: 1-20 Default: none
-ne1 through -ne20	Including the local node, you can specify up to 20 NEs in the preferred route. Each NE is defined by a pairing of a node and a port. The format of these paired elements must conform to the entry for neSyntax. Separate the values in the pairing by a slash and no spaces, but put a space between the keyword and NE, as follows: -ne(n) node/port The NE you specify as the destination node must be the highest numbered keyword, otherwise the switch rejects the command.The port identifier at the destination node must be set to 0. Note that the value 0 actually determines the last NE in the route. This 0 appears in the outputs of the display commands for preferred routes.For example, if a route has 9 NEs, the format would be: -ne9 node/0

To see a list of all preferred routes and obtain the required route index for the cnfpref command, enter the dspprefs command. To see details about individual preferred route, use the dsppref <routeId> command, and replace <routeId> with the preferred route identifier.

---

Note Preferred routes that were configured on switches running Release 3 will be lost when you upgrade the switch to Release 4. Once you have upgraded the switch to Release 4, you need to re-configure your preferred routes.

---

Deleting a Preferred Route

Enter the delpref <routeId> command to delete a preferred route description.Before you delete a preferred route, you must ensure that no SPVCs/SPVPs have that preferred route currently associated with them. Enter the dspcons -rteid <routeId> command to verify that there are no SPVCs/SPVPs associated with the preferred route you want to delete. Replace <routeId> with the route identifier for the preferred route you want to display.

To disassociated any SPVCs/SPVPs from the preferred route, enter the cnfcon command as follows:

8850_LA.7.PXM.a > cnfcon <ifNum> <vpi> <vci> <serviceType> <mastership> -rtngprio 
<routingPriority> -prefrte 0 

Table 8-7 describes the parameters you need to configure with the addcon command. Note that you must set the -prefrte parameter to 0 to disassociate a connection with a preferred route.

Deleting a Node from the Network Node Table

Before you can delete a node from the network node table, enter the dspnwnode <nodeId> command to ensure that the node is not part of a preferred route.

---

Note You can not delete a node from the network node table if it is currently being used by a preferred route.

---

If the node you want to delete is not being used by a preferred route, enter the delnwnode <nodeId> command to delete the node from the network node table. Replace <nodeId> with the 22-octet node identifier that you set with the addnwnode command, as described in the "Maintaining the Network Node Table" section earlier in this chapter.

Configuring Link Selection for Parallel Links

When parallel links exist between two nodes on a route, the node closest to the originating node selects a link based on one of the following factors:

•lowest administrative weight (minaw)

•maximum available cell rate (maxavcr)

•maximum cell rate configured for the link (maxcr)

•random link selection (loadbalance)

---

Note The route selection process is described in the Cisco PNNI Network Planning Guide for MGX and SES Products.

---

To configure the link selection method, enter the cnfpnni-link-selection command as follows:

mgx8830a.1.PXM.a >  cnfpnni-link-selection pnportid minaw|maxavcr|maxcr|loadbalance

Replace pnportid with the port ID in the format slot[:subslot].port[:subport]. (This is the same format that appears when you display ports with the dsppnport command.) Enter one link selection method after the port ID.

To display the link selection method, enter the dsppnni-link-selection command as follows:

mgx8830a.1.PXM.a > dsppnni-link-selection 1:2.1:1

physical port id:         1:2.1:1     link selection: minaw

 logical port id:        16848897

Configuring the Maximum Bandwidth for a Link

The maximum bandwidth for a link is defined when a PNNI partition is configured for a port. For more information, see Chapter 3, "Provisioning PXM1E Communication Links."

Configuring the Administrative Weight

The link administrative weight (AW) is used to calculate the total cost of a route and can be used by the PNNI controller when it has to choose between multiple parallel links. You can assign different AW values for each ATM class of service.

---

Note The role of AW in route and link selection is described in more detail in the Cisco PNNI Network Planning Guide for MGX and SES Products.

---

To configure the AW for a link, enter the cnfpnni-intf command as follows:

mgx8830a.1.PXM.a > cnfpnni-intf <pnportid> [-awcbr] [-awrtvbr] [-awnrtvbr] [-awabr] 
[-awubr] [-awal]

Replace pnportid with the port ID in the format slot[:subslot].port[:subport]. (This is the same format that appears when you display ports with the dsppnport command.) For each class of service for which you want to change the AW value, enter the appropriate option followed by the new value. For example, the following command sets the AW for CBR calls over the link:

mgx8830a.1.PXM.a > cnfpnni-intf 1:2.1:1 -awcbr 2000

To display the AWs assigned to a PNNI port, enter the dsppnni-intf command as follows:

mgx8830a.1.PXM.a >  dsppnni-intf 1:2.1:1

Physical port id: 1:2.1:1          Logical port id:   16848897

   Aggr token..........         0     AW-NRTVBR...........      5040

   AW-CBR..............      2000     AW-ABR..............      5040

   AW-RTVBR............      5040     AW-UBR..............      5040

Configuring the Aggregation Token

The link aggregation token is used when multiple links connect two nodes. An aggregation token serves as a label that determines if two or more links should be advertised as separate links or as one. For example, if two links connect two nodes and the aggregation node on each link is set to 5, only one link is advertised. The numeric value of the token has no significance. What is important is whether links have the same token value as other links.

If there were two nodes with three OC-3 links and two T3 links between them, you could aggregate the three OC-3 links into one group with a token of 33 and the two T3 links into another group with a token of 3. This approach would result in two link advertisements: one for a single OC-3 link and one for a single T3 link.

---

Note For more information on the aggregation token, refer to the Cisco PNNI Network Planning Guide for MGX and SES Products.

---

To configure the aggregation token for a link, enter the cnfpnni-intf command as follows:

mgx8830a.1.PXM.a > cnfpnni-intf <pnportid> [-aggregationToken token]

Replace pnportid with the port ID in the format slot[:subslot].port[:subport]. (This is the same format that appears when you display ports with the dsppnport command.) Replace token with the value you want to assign to the link. The range is 0 to 4294967295, and the default value is 0. The token value of 0 disables link aggregation for the link. Therefore, to enable two or more links to be advertised as one, you must configure the aggregation token on each link to a matching, nonzero value.

The following command assigns token value 5 to a link:

M8850