VSM Command Reference

This command controls the administrative state of the ccag-id the command is executed under. Upon creation, the default state of a CCAG is to be administratively up which corresponds to the no shutdown form of the command. If the CCAG must be forced to be operationally down, the shutdown command will place the CCAG into an administratively down state causing the operational state to also be down.

When a CCAG is shutdown, all SAPs associated with the CCAG will be operationally down. An operationally down SAP cannot be used for forwarding packets. If the SAP is part of the VPLS service, all MAC entries associated with the SAP will be removed from the VPLS FDB and the SAP will be removed from the flooding domain of the VPLS. If the SAP is part of an IES service, the associated IP interface will be set to an operationally down state. Network IP interfaces bound to a shutdown CCAG will be operationally down as well.

Executing the no shutdown command sets the CCAG to the default up administrative state. As long as at least one member CCA in the CCAG is active, all SAPs and network IP interfaces associated with the CCAG will be allowed to enter the operationally up state.

This command defines an informational string associated with the CCAG. The description string may be up to 80 characters long and contain only printable ASCII characters. Each time this command is successfully executed, any previous description string will be overwritten. If the command fails due to improper string definition, a previously successful description string will remain.

The no form of the command removes any current description string from the CCAG.

This command changes the current CLI context to the CCA nodal context. The CCA nodal context is where CCAGs are created and maintained.

The CCA nodal context always exists and cannot be removed.

This command creates a Cross Connect Aggregation Group (CCAG). A CCAG represents a group of CCAs as a common forwarding entity. Objects requiring a CCA cross connect function are mapped to a CCAG, not the individual CCAs within the CCAG. The CCAG treats each active member CCA as a possible destination when forwarding packets between the cross connected objects mapped to the CCAG. The system uses both conversation hashing functions and direct service mappings to determine the load sharing distribution between the active CCAs. All packets for a given conversation flow through the same CCA to preserve packet order. Packet ordering may be momentarily affected during convergence events when CCAs are dynamically added or removed from the active list.

The CCAG context is used to manage the following functions per CCAG instance:

The no form of the command removes an existing ccag-id from the system. Once the specified ccag-id is removed from the system, it may not be referenced by any cross connect objects. If the force keyword is not specified, the no ccag ccag-id command will fail if the specified ccag-id has one or more cc-ids associated with it. In the event that the specified ccag-id does not exist, the no ccag ccag-id command will return to the current CLI context without any change to the system.

This command changes the current CLI context to the CCAG access nodal context. The access nodal context contains the qos adaptation command used to control the SAP QoS distribution across the active member CCAs within the CCAG.

The CCAG access nodal context always exists and cannot be removed.

This command controls how the CCAG SAP queue and virtual scheduler buffering and rate parameters are adapted over multiple active CCAs. Two adaptation modes are supported; link and distributed.

The no form of the command returns the CCAG access QoS adaptation rule to the default setting of distribute.

This command defines a maximum forwarding rate for each CCA member within the CCAG. Support of setting a maximum CCA forwarding rate is provided to prevent overrunning the ingress forwarding plane when sub-line rate ingress features are enabled. The primary ingress feature requiring this support is dual ingress access queuing. When dual ingress queuing is enabled on cross connect SAPs, the CCA forwarding rate should be limited to a rate that prevents packet loss due to ingress forwarding congestion. The specified limit is applied to the aggregate alpha and beta path bandwidth. The no form of the command removes CCA bandwidth rate limiting.

This command adds and deletes provisioned CCAs from the CCAG. The only requirement to defining a CCA member is that the defined MDA position be provisioned as type cca. A CCA does not need to be populated in the defined MDA position prior to membership definition. A non-populated CCA member is considered inactive from a CCAG perspective. A populated CCA member will become active once it has been initialized by the system. A CCA member may be removed from the CCAG or depopulated from MDA slot at any time. At least one member CCA must be active on the CCAG for the CCAG to be placed in the operational state. Up to 8 member CCAs can be configured per CCAG. The no form of the command removes a CCA member from the CCAG. If the CCA does not exist or is not currently a member of the CCAG, no error is returned. Once removed from the CCAG, all forwarding through the specified CCA stops.

This command changes the current CLI context to the path nodal context. The CCA path nodal context is where CCA path bandwidth, buffer and accounting parameters are maintained. The path context command must be specified with either the a or b keyword specifying the CCA path context to be entered.

Each CCA is divided into two distinct paths for bandwidth management purposes. One path is identified as alpha (a) and the other beta (b). The significance of each path for bandwidth distribution is dependent on the relative path weights each path is given in relationship to the other. A maximum path rate may also be defined allowing the provisioning of a maximum cap on the aggregate bandwidth allowed to the SAP or IP interface queues associated with the path. Each path is separated into three other contexts; SAP-2-SAP (sap-sap), SAP-2-Net (sap-net) and Net-2-SAP (net-sap). Each path context allows for the definition of the features that are usually associated with physical ports on other MDAs in the system. These include buffer pool management, ingress network queue definitions and accounting policy control.

The CCA path nodal contexts always exist and cannot be removed.

This command defines a specific bandwidth rate limitation for the alpha or beta paths on each member CCA in the CCAG. Use of the rate command is optional. When the rate command is not executed or the no rate command is executed, bandwidth allocated to the path is not limited to a specific rate.

Path limiting on a CCA prevents the aggregate bandwidth for the path from exceeding a certain rate. If the rate is exceeded, the CCA will backpressure all active egress queues sending on that path. Access to the available bandwidth is dependent on the various parameters associated with each object egress queue.

The specified rate may be defined as an aggregate path rate for all CCAs in the CCAG or it may be defined as a per CCA path rate.

The no form of the command removes path rate limiting from all CCAs in the CCAG membership list for the path.

This command defines a scheduling weight to the aggregate output of the alpha and beta paths. The specified weight is used to calculate a scheduling percentage for each path. The percentage for each path is based on:

Alpha scheduling percentage = alpha-path-weight / (alpha-path-weight + beta-path-weight) Beta scheduling percentage = blue-path-weight / (alpha-path-weight + beta-path-weight)

Based on the above calculation, the sum of the alpha and beta scheduling percentage always equals 100 percent. When one path is not using all of its available scheduling bandwidth, the other path may use the remainder.

The no form of the command returns the path-weight for the path to the default value of 50.

This command changes the current CLI context to the path SAP-SAP nodal context. This context contains the ingress and egress buffer pool configuration commands. The sap-sap>path context is associated with all SAPs defined on the CCAG path (alpha or beta depending on the path context) that cross connect to a SAP on the other path.

The CCA path SAP-SAP nodal context always exists and cannot be removed.

This command overrides the default MAC address for the path’s context.

The no form of the command returns the in-use MAC address for the path’s context to the default MAC from the chassis MAC pool.

This command overrides the default port level MTU for the path’s context.

The no form of the command returns the MTU for the path’s sap-sap, sap-net or net-sap context to the default MTU.

This command changes the current CLI context to the path’s context. This context contains the egress buffer pool configuration commands.

The CCA path’s egress nodal context always exists and cannot be removed.

This command changes the current CLI context to the path’s nodal context. This context contains the egress buffer pool configuration commands. The CCA path’s egress or ingress pool nodal context always exists and cannot be removed.

This command defines the percentage of the buffer pool that is considered reserved for the CBS buffer allocation for queues created in the path’s pool context.

The no form of the command returns the reserved portion of the buffer pool to the default percentage.

This command changes the current CLI context to the path’s context. This context contains the ingress buffer pool configuration commands.

The CCA path’s ingress nodal context always exists and cannot be removed.

This command changes the current CLI context to the path sap-net nodal context. This context contains the ingress and egress buffer pool configuration commands. The sap-net>path context is associated with all SAPs defined on the CCAG path (alpha or beta depending on the path context) that cross connect to a network IP interface on the other path.

The CCA path sap-net nodal context always exists and cannot be removed.

This command defines the slope policy used to mange the shared portion of the buffer pools WRED slopes. The commands in the policy control the administrative state of the slopes, the start and knee points of each slope and the time-average-factor for the weighted average buffer utilization calculation.

The no form of the command configures the default slope policy as the managing policy for the buffer pool.

This command changes the current CLI context to the path net-sap nodal context. The net-sap nodal context contains the network accounting and queue policies and the egress buffer pool configuration commands. The net-sap path context is associated with all network IP interfaces bound to the CCAG path (alpha or beta depending on the path context) that cross connects to a SAP on the other path.

The CCA path net-sap nodal context always exists and cannot be removed.

This command defines the network accounting policy that will be used to define which statistics will be collected when the collect-stats command is enabled in the path’s net-sap context.

The no form of the command reverts the path’s net-sap context statistics billing collection to the statistics defined in the default network accounting policy.

This command enables collecting stats on the path’s net-sap context. When enabled the statistics defined in the accounting-policy accounting-policy command will be collected according to the specifications in the policy.

The no form of the command disables network billing statistics collection on the net-sap context.

This command defines the egress network queues used by IP interfaces bound to the path’s net-sap context. The specified queue-policy-name defines the number of queues, the rate and buffering parameters for the queues and the forwarding class mappings to the queues.

The no form of the command reverts the path’s net-sap network IP interface queues to the systems default queue policy.

This command changes the current CLI context to the path>net-sap>egress nodal context. This context contains the egress buffer pool configuration commands.

The CCA path net-sap egress nodal context always exists and cannot be removed.

This command changes the current CLI context to the path>net-sap>egress pool>nodal context. This context contains the egress buffer pool configuration commands.

The CCA path net-sap egress pool nodal context always exists and cannot be removed.

This command provisions an adapter into an MDA position on an IOM slot. The provisioned MDA may or may not exist in the system at the time of provisioning. If the provisioned MDA does not currently exist in the specified MDA position number, it is considered to be a ‘ghost’ MDA. Ports and other resources on a ghost MDA may be configured once the MDA is provisioned. When a proper MDA matching the provisioned MDA type is inserted into the IOM MDA position, forwarding though the MDA based on configured services or network interface will be available once the MDA has been properly initialized.

A Versatile Service Module (VSM) is provisioned into the system in the same manner as all other adapters using MDA slots. Once a VSM is provisioned, independent of it actually existing in the system on the specified slot and MDA position, the VSM may be defined as a member of a CCAG (Cross Connect Adapter Group). A VSM inserted into the system prior to provisioning is not available for CCAG membership and will be treated as an unprovisioned MDA.

Once a VSM is provisioned and populated in the system, it cannot be used until it has been defined membership into a CCAG. When the CCAG membership has been defined for the VSM, the various internal resources of the VSM will be configured according to the CCAG bandwidth control parameters. This includes the alpha and beta path weights, the alpha and beta path maximum rates and the aggregate alpha and beta maximum rate. A VSM-CCA-XP may be configured as either a VSM-CCA MDA or a VSM-CCA-XP MDA. When configured as a VSM-CCA-XP it is not a member of a CCA Group (ref VSM-CCA-XP).

The no form of the command unprovisions an MDA from the system. For a VSM to be unprovisioned, the VSM must not be a member of a CCAG. If the VSM is a member of a CCAG, the no cca slot-number/mda-number command must be used in the CCAG member-list context. Once a CCA is unprovisioned from the system; it cannot be made a member of a CCAG until it has been reprovisioned.

This command cross connects a network IP interface to a CCAG SAP using the referenced ccag-id. A CCAG network IP interface binding is identified by four items; the ccag-id, the CCAG path, the pairing type and the cc-id. A network IP interface CCAG port binding supports all the available features as port binding using a Dot1Q virtual interface.

To support cross connection between services and network IP interfaces, the network interface port command allows the binding of the IP interface to a ccag cc-id. Similar to service CCAG SAPs, the network IP interface port binding command must reference the ccag-id, the CCA path (.a or .b) and the cc-id used by the service CCAG SAP on the other CCA path. The pairing type is optional as only .net-sap is supported.

The no form of the command removes the CCAG binding from the network IP interface.