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:
Note The concepts behind the procedures in this chapter are introduced in the Cisco MGX and SES PNNI
Network Planning Guide.
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 "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 "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.
Step 2 Add the upper level PNNI logical node that will participate in the higher level PNNI group using the following command.
mgx8830a.1.PXM.a > addpnni-node level
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 48.
mgx8830a.1.PXM.a > addpnni-node 48
Note You need to complete this step for all nodes that will serve as PGLs or backup PGLs.
Step 3 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:
Active parent node id..0:0:00.000000000000000000000000.000000000000.00
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. Since a PGL represents the peer group at a higher level, logical node 1 (node index 1) is the only node that can become a 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 4 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.
Active parent node id..0:0:00.000000000000000000000000.000000000000.00
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:
Active parent node id..0:0:00.000000000000000000000000.000000000000.00
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 5 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 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:
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:
Peer group id.........56:47.00.9181.0000.0100.0000.0000.00
Enabling and Disabling Point-to-Multipoint Routes
The branching restricted option allows you to allow or block point-to-multipoint calls. The default setting for this option enables point-to-multipoint calls.
To enable or disable point-to-multipoint routes through a node, enter the cnfpnni-node command as follows:
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 accept point-to-multipoint calls. When the -branchingRestricted parameter is set to off, the node accepts point-to-multipoint calls.
To view the status of the -branchingRestricted option, enter the dsppnni-node command as shown in the following example:
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 Background Routing Tables
Configure the routing policies used for background routing tables generation with the command cnfpnni-routing-policy.
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
Indicates the node's policy in determining equal-cost path during routes calculation.
-sptHolddown
Defines the node's minimum time interval between two consecutive calculations for generating routing tables.
-bnPathHolddown
Defines the minimum time interval between two consecutive calculations for generating border node path in a peer group for a complex node representation at the next higher level. (Complex nodes are not supported by MGX 8850, Release 2.1 software image.)
-loadBalance
Defines the node's load balancing rule if alternative equal-lose routes exist for the call request.
-onDemand
Defines the node's on-demand routing rule, either to:
firstfit = select the first route found bestfit = select the best route
Default = firstfit
-awBgTable
Enable or disable administrative weight for the background routing table.
Default = off
-ctdBgTable
Enable or disable CTD for the background routing table.
Default = off
-cdvBgTable
Enable or disable CDV for the background routing table.
Default = off
Configuring PNNI Timers
Configure the PNNI timers with the cnfpnni-timer command.
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
The number is used as a multiplier of the Hello interval of the peer neighbor: the product is the maximum time that the neighbor is considered to be alive without the reception of its Hello packets.
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 ptserefreshintervalis 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 Route and Link Selection
The following sections describe how to control route and link selection for the links on each PNNI node.
Configuring the 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 MGX and SES PNNI Network Planning Guide.
To configure the route selection method, enter the cnfpnni-routing-policy command as follows:
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 Best-Fit Route Selection Method
When the PNNI controller is configured to choose the best route and it discovers multiple eligible routes, the load balancing option determines which route to select. The option settings are random and maxbw, which selects the route with the greatest available bandwidth. Random selection is used to balance the load.
Note The route selection process is described in the Cisco MGX and SES PNNI Network Planning Guide.
To configure the best-fit route selection method, use the cnfpnni-routing-policy command as follows:
Enter random to balance route selection, 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 best-fit route selection method is configured.
Configuring Preferred Routes
You can specify a route to be preferred for SPVC and SPVP connections. Once a route is specified as a preferred route, future SPVC connections attempt to route connections via the preferred route before attempting other routes. 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 will only attempt 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 will first attempt to route over the preferred route. If the preferred route is not available, the connection will be attempted over other routes.
Note Release 3 of the MGX switches supports up to 5000 preferred routes per switch.
A preferred route consists of a sequential list of nodes and links between nodes that stretch from the local node to the destination node. Each node and link in the preferred route must be within the same peer group as the originating node. A node can appear only once in the preferred route. Each preferred route supports a maximum of 19 hops away from the local node (up to 20 nodes, including the local node, or 19 NNI links).
Configuring a Preferred Route
Use the following procedure to configure a preferred route.
Step 1 Enter the dsptopondlist command to see the nodes in this database. These are the nodes you can use to set up your preferred route.
Table 8-5 describes the addpref command parameters.
Table 8-5 Parameters for addpref Command
Parameter
Description
-name
Name of the preferred route. To use node names, type -name yes. The choice is yes or no. A no means that the persistent node index is used.
Default = no
For more information on the preferred route naming conventions, see the "Detailed Usage Guidelines for the addpref Command" section in the "MGX 8850 and MGX 8950 Switch Command Reference."
-h1, -h2 ...-h20
Specifies each hop in the preferred route. Including the local node, you can define up to 20 nodes in the preferred route.
Each hop in the preferred route is defined by a pairing of the persistent node index and the PNNI physical port ID. For the last port ID in the route, type a # instead of a numeric value. This # appears in the outputs of the display commands for preferred routes. Separate these values by a slash and no spaces, as follows:
persNodeIndex/portid
The node must exist in the persistent topology database. Enter the dsptopondlist command to see the nodes in this database. (An alternate to using node indexes is using node names.)
The format for portid is slot:subslot.port:subport.
Note After you create a preferred route, the system returns a route index in the range 1to 5000. This route
index is necessary for related commands, such as delpref, dsppref, and modpref. To see a list of route
indexes, enter the dspprefs command.
Step 3 Enter the dsppref <rte_index> [-name {yes|no}] command to verify the preferred route was configured correctly. Replace <rte_index> with the preferred routes index number. To view the preferred route name, include the -name yes option in the command.
Once you set up a preferred route, you can associate it with an SPVC or and SPVP. Each connection can have only one preferred route. If a connection already has a preferred route associated with it, you can replace that route with a new one.
Associating an SPVC or an SPVP with a Preferred Route
Use the following procedure to associate an SPVC or SPVP with a preferred route.
Step 1 Create the preferred route by the addpref command, as shown in the previous section.
Step 3 Enter the cnfconpref <options> command to associate an SPVC or SPVP with a preferred route.
Step 4 Table 8-6 describes the cnfconpref command parameters.
Table 8-6 Parameters for cnfpnni-timer Command
Parameter
Description
portid
Identifies a PNNI physical port, in the format slot:subslot.port:subport
vpi
VPI of the connection.
Range: 0 - 255 on a UNI, 0-4095 on an NNI
Default: none
vci
VCI of the connection. If the VCI is 0, the connection is an SPVP.
Range: 1 - 65535
Default: none
rteID
Route identifier.
Range: 1 - 5000
Default: none
-assoc
The -assoc option either associates (-assoc set) or disassociates (-assoc clr) the specified route to the specified connection. If you type -assoc set to associate a route, the command entry must include the route ID. If you disassociate the route by typing -assoc clr, the route ID is unnecessary. Set is the default. If you type a route ID but do not include -assoc set, the protocol interprets the command as an attempt to associate the specified route to the specified connection.
Possible entries: set or clr (for clear)
Default: set
-direct
Change the directed route status. A directed route means the preferred route associated with the connection is the only route the connection can take. If the preferred route is not available, the connection is failed. Type -direct yes to make the route identified by rteID a directed route for the associated connection. The connection is identified by portidvpivci.
Possible entries: yes or no
Default: no
-onPrefRte
Informs the node that the connection is routed on its associated, preferred route. The purpose is to prevent rerouting of the connection during grooming. The possible entries are yes or no.
Before setting the onPrefRte option to yes, enter the dspcon <portid> <vpi> <vci> command to ensure that the connection is properly routed on the preferred route.
Default: no
Modifying a Preferred Route
Use the modpref command to change a preferred route. You can re-specify existing hops in a route or add one or more hops to an existing route. You can also change a hop to indicate that it is the destination node. A new destination node must have the highest hop number in the route. (See the detailed usage guidelines for the addpref command for details.)
Table 8-7 describes the modpref command parameters.
Table 8-7 Parameters for modpref Command
Parameter
Description
rteID
The preferred route identifier has a range of 1 - 5000.
-name
Enter yes to specify that the node identifier is actually the name of the node. You can see the current choice for node identifier (either by index or name) by using the dsppref command. To identify the name or persistent index number by using the dsptopondlist command.
Default = no
For more information on the preferred route naming conventions, see the "Detailed Usage Guidelines for the addpref Command" section in the "MGX 8850 and MGX 8950 Switch Command Reference."
-h1, -h2 ...-h20
Specifies each hop in the preferred route. Including the local node, you can define up to 20 nodes in the preferred route.
Each hop in the preferred route is defined by a pairing of the persistent node index and the PNNI physical port ID.
The <persNodeIndex> (persistent node index) is a namestring. You need to enter this option only if you include the -name yes option in the modpref command.
Note If you entered modpref -name no command, or if you do not specify the -name option in the command, then<persNodeIndex> refers to a table index derived from the persistent topology database. Enter the dsptopondlist command to view the table index.
For the last port ID in the route, type a # instead of a numeric value. This # appears in the outputs of the display commands for preferred routes. Separate these values by a slash and no spaces, as follows:
persNodeIndex/portid
The node must exist in the persistent topology database. Enter the dsptopondlist command to see the nodes in this database. (An alternate to using node indexes is using node names.)
The format for portid is slot:subslot.port:subport.
The preferred routes are specified by the addpref command. To see a list of all preferred routes and obtain the required route index for the modpref command, enter the dspprefs command. To see details about individual preferred route, use the dsppref command.
Deleting a Preferred Route
Enter the delpref <rteId> command to delete a route. Replace <rteId> with the route identifier for the appropriate route, in the range from 1 to 5000.
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 MGX and SES PNNI Network Planning Guide.
To configure the link selection method, enter the cnfpnni-link-selection command as follows:
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:
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 MGX and SES PNNI
Network Planning Guide.
To configure the AW for a link, enter the cnfpnni-intf command as follows:
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:
The bandwidth overbooking factor represents the percentage of the actual available bandwidth that is advertised for links as the Available Cell Rate (AvCR). The default overbooking factor is 100, and this specifies that 100% of the actual available bandwidth should be advertised as the AvCR. When the overbooking factor is set below 100, a link is oversubscribed because the bandwidth booked for each connection exceeds the configured bandwidth for the connection. When the overbooking factor is set above 100, the link is under subscribed because the bandwidth booked for a connection exceeds the connection's configured bandwidth.
Note For more information on the bandwidth overbooking factor, refer to the Cisco MGX and SES PNNI
Network Planning Guide.
To configure the bandwidth overbooking factor for a PNNI port, enter the cnfpnportcac as follows:
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 service_catogory with the ATM class of service for which you are defining the overbooking factor, and replace utilization-factor with the new overbooking factor. For example:
The following sections describe commands that display PNNI configuration information.
Displaying the PNNI Node Table
Once a PNNI node is configured, enter the dsppnni-node command to show the WAN nodal table. The node list is displayed in ascending order of each node index, all with one setting the node to the lowest PNNI hierarchy.
The significant information that will display is as follows:
Node index
Node name
Node level (56 for all nodes until multiple peer groups are supported)
Restricted transit—a flag that can prevent PNNI routing from transmitting this node
Branching restricted—a flag that can prevent cpu-intensive branching at this node
Admin status—up/down
Operational status—up/down
Nontransit for PGL election—a flag that indicates that node's level of eligibility as a PGL
Node id—The 22-byte PNNI logical identification
ATM address
pg id—Peer group ID
The following example shows the report for this command:
Common peer group id...00:00.00.0000.0000.0000.0000.0000.00
Displaying the PNNI Routing Policy
Enter the dsppnni-routing-policy command to display the routing policies used for background routing tables generation.
mgx8830a.1.PXM.a > dsppnni-routing-policy
The following example shows the report for this command:
mgx8830a.1.PXM.a > dsppnni-routing-policy
SPT epsilon......... 0 Load balance........ random
SPT holddown time... 1 On demand routing... best fit
SPT path holddown time 2 AW Background Table on
CTD Background Table on CDV Background Table on
mgx8830a.1.PXM.a >
Table 8-10 describes the objects displayed for the dsppnni-routing-policy command.
Table 8-10 Objects Displayed for the dsppnni-routing-policy Command
Parameter
Description
SPT epsilon
The tolerance used during route calculation to determine which paths qualify as equal-cost. The range is from 0 - 20.
SPT holddown
The interval between two consecutive calculations for generating routing tables. The range is from 1 (0.1 sec) to 600 (60 sec).
SPT path holddown time
The minimum time that can elapse between consecutive calculations that generate routing tables for border nodes. The range is from 2 (0.2 sec) to 600 (60 sec).
CTD Background Table
Displays whether CDT1 for the background routing table is enabled or disabled. CTD is the time interval between a cell exiting source node and entering the destination node.
Load balance
Defines the load balancing rule if alternative equal-cost routes exist for a given call request.
Ondemand Routing
The on-demand routing rule. On-demand routing is used. Firstfit routing selects the first route found that goes to the selected destination. Firstfit route search time is minimized, but the selected route is not optimum. Bestfit routing selects a route based on the least-cost. The average route- search-time is greater, and more CPU-intensive, but the optimum route is selected.
AW Background Table
Displays whether the administrative weight for the background routing table is enabled or disabled.
CDV Background Table
Displays whether CDV2 for the background routing table is enabled or disabled. CDV is a component of cell transfer delay, and is a quality of service (QoS) delay parameter associated with CBR and VBR service. Cell Delay Variation is the variation of delay between cells, measured peak to peak.
1 CTD = cell transfer delay
2 CDV = cell delay variation
Displaying the SVCC RCC Timer
Enter the dsppnni-svcc-rcc-timer command to display SVCC-based RCC variables.
mgx8830a.1.PXM.a > dsppnni-svcc-rcc-timer
The following example shows the report for this command:
mgx8830a.1.PXM.a > dsppnni-svcc-rcc-timer
node index: 1
Init time........... 4 Retry time.......... 30
Calling party integrity time... 35
Called party integrity time.... 50
Table 8-11 shows the objects displayed for the dsppnni-svcc-rcc-timer command.
Table 8-11 Objects Displayed for the dsppnni-svcc-rcc-timer Command
Parameter
Description
node-index
The node index assigned to a PNNI logical node on a network. The range is from 1 to 65535.
Init time
The amount of time (in seconds) this node will delay advertising its choice of preferred an SVCC to a neighbor with a numerically lower ATM address, after determining that such an SVCC should be established. The range is from 1 to 10.
Retry time
The amount of time (in seconds) this node will delay after an apparently still necessary and viable SVCC-based RCC is unexpectedly torn down, before attempting to re-establish it. The range is from 10 to 60.
Calling party integrity time
The amount of time (in seconds) this node will wait for an SVCC, which it has initiated establishment of as the calling party, to become fully established before giving up and tearing it down. The range is from 5 to 300.
Called party integrity time
The amount of time (in seconds) this node will wait for an SVCC, which it has decided to accept as the called party, to become fully established before giving up and tearing it down. The range is from 10 to 300.
Displaying Routing Policy Parameters
Enter the dsppnni-timer command to display the routing policy parameters.
mgx8830a.1.PXM.a > dsppnni-timer
The following example shows the report for this command:
