Configuration overview

Note:

  • This document uses the term ‟preprovisioning” in the context of preparing or preconfiguring entities such as chassis slots, cards, Media Dependent Adapters (MDAs), ports, and interfaces, before initialization. These entities can be installed while remaining administratively disabled (shutdown). When the entity is in a no shutdown state (administratively enabled), then the entity is considered to be provisioned.

  • For consistency across platforms, XRS Media Adapters (XMAs) and Compact XMAs (C‑XMAs) are modeled as MDAs.

  • Unless specified otherwise:

    • The term ‟card” is used generically to refer to both Input Output Modules (IOMs) and XCMs.

    • The term ‟MDA” is used generically to refer to both MDAs and XMAs.

Nokia routers provide the capability to configure chassis slots to accept specific card and MDA types and set the relevant configurations before the equipment is actually installed. The preprovisioning capability allows you to plan your configurations as well as monitor and manage your router hardware inventory. Ports and interfaces can also be preprovisioned. When the functionality is needed, the cards can be inserted into the appropriate chassis slots when required.

Chassis slots and card slots

Depending on the chassis type, the relationship between the chassis slot and card slot varies. Chassis slots represent the physical slots in the chassis where modules can be installed. Card slots represent the reference used in management interfaces when provisioning the modules and then using resources of those modules (for example, port references). See the appropriate platform Installation Guide for more information.

To preprovision a card slot, the card type must be specified. Users can enter card type information for each slot. When a card is installed in a slot and enabled, the system verifies that the installed card type matches the provisioned card type. If the command options do not match, the card remains offline. A preprovisioned slot can remain empty without conflicting with populated slots.

The general syntax for the configuration of card slots is similar for all platforms, though the number of available slots varies by platform and chassis model. The supported card-types vary by chassis. See the appropriate platform Installation Guide for more information.

The 7950 XRS platforms accept XCMs in card slots. An XCM has two slots, each of which accept an XMA or C-XMA module. The C-XMA modules require a mechanical adapter to fit in an XMA slot.

7950 XRS card slot and XCM configuration (MD-CLI)

*[ex:/configure]
A:admin@node-2# card 1

*[ex:/configure card 1]
A:admin@cnode-2# card-type xcm-x20

7950 XRS card slot and XCM configuration (classic CLI)

*A:node-2>config# card 1
*A:node-2>config>card# card-type xcm-x20

The 7750 SR-2s/7s/14s platforms accept XCMs in card slots. The XCMs of the 7750 SR-2s/7s platforms have a single slot for an XMA or an XIOM module. The XCM of the 7750-14s have two slots for the XMA or XIOM modules.

The 7750 SR-1s platform supports a single XCM in a dedicated card slot. This XCM has a single XMA module. The type of XMA module is fixed based on the variant of 7750 SR-1s chassis. Both the XCM and the XMA must be provisioned.

The 7450 ESS-7/12, and 7750 SR-7/12, and 7750 SR-12e platforms accept either IMMs or IOMs in card slots. IOMs have two slots for pluggable MDAs. The IOM4-e and IOM4-e-B support MDA-e modules. The IOM5-e supports MDA-e-XP modules.

7450 ESS-7/12 card slot with an IOM configuration (MD-CLI)

*[ex:/configure]
A:admin@node-2# card 1

*[ex:/configure card 1]
A:admin@node-2# card-type iom4-e

7450 ESS-7/12 card slot with an IOM configuration (classic CLI)

*A:node-2>config# card 1
*A:node-2>config>card# card-type iom4-e

IMMs have integrated MDAs. The provisioning requirements depends on the generation of IMM that you use. See the IMM Installation Guide for more information.

The 7750 SR-a platforms support IOM-a cards in dedicated chassis slots. The 7750 SR-a4 supports one physical IOM-a in slot 3. This IOM-a is represented in the CLI as card 1. The 7750 SR-a8 supports two physical IOM-a cards, one in slot 3, the other in slot 6. These IOM-a cards are represented in the CLI as card 1 and card 2 respectively. The IOM-a does not have pluggable MDA slots. Each IOM-a can be configured to support up to four MDA-a or MDA-aXP modules. IOM-a cards are configured in the same manner as IOMs.

The 7750 SR-e platforms support the IOM-e modules in dedicated slots in the rear of each chassis. The 7750 SR-1e supports one physical IOM-e module. This IOM-e is represented in the CLI as card 1. The 7750 SR-2e supports two physical IOM-e cards. These IOM-e cards are represented in the CLI as card 1 and card 2 respectively. The 7750 SR-3e supports three physical IOM-e cards. These IOM-e cards are represented in the CLI as card 1, card 2, and card 3 respectively. The IOM-e does not have pluggable MDA slots. An IOM-e can be configured to support up to four MDA-e modules. IOM-e cards are configured in the same manner as IOMs.

XIOM modules

XIOM modules are modules that are used in 7750 SR-1s/2s/7s/14s platforms. These can be installed into an XCM instead of installing an XMA module. The XIOMs have two slots that support MDA-s modules (see MDA-a, MDA-aXP, MDA, MDA-e, and MDA-s modules).

The use of an XIOM introduces an additional index into the reference hierarchy. For example, a 7750 SR-14s with an XCM in card slot 1 can have an XMA in the first slot and an XIOM in the second slot.

The following example shows a 7750 SR-14s with an XCM in card with an XMA in the first slot and an XIOM in the second slot.

MD-CLI

[ex:/configure card 1]
A:admin@node-2# info
    card-type xcm-14s
    mda 1 {
            mda-type s36-100gb-qsfp28
            level cr1600g
        }
        xiom "x2" {
            level cr1600g+
            xiom-type iom-s-3.0t
            mda 1 {
                mda-type ms2-400gb-qsfpdd+2-100gb-qsfp28
            }
            mda 2 {
                mda-type ms16-100gb-sfpdd+4-100gb-qsfp28
            }
        }
    }

classic CLI

A:node-2>config>card# info
----------------------------------------------
        card-type xcm-14s
        xiom x2
            xiom-type iom-s-3.0t level cr1600g+
            mda 1
                mda-type ms2-400gb-qsfpdd+2-100gb-qsfp28
                no shutdown
            exit
            mda 2
                mda-type ms16-100gb-sfpdd+4-100gb-qsfp28
                no shutdown
            exit
            no shutdown
        exit
        mda 1
            mda-type s36-100gb-qsfp28 level cr1600g
            no shutdown
        exit
        no shutdown
----------------------------------------------

On the 7750 SR-1s/2s/7s/14s, the MDA-s modules are supported when an XIOM is installed into a slot within an XCM. Up to two MDA-s can be installed in an XIOM. MDA-s names in CLI start with the letters "ms" (for example, ms16-100g-sfpdd+4-100g-qsfp28).

MDA-a, MDA-aXP, MDA, MDA-e, and MDA-s modules

MDAs are pluggable adapter cards that provide physical interface connectivity. MDAs are available in a variety of interface and density configurations. MDA modules differ by chassis. See the individual chassis guide and the individual MDA installation guides for more information about specific MDAs.

On the 7450 ESS-7/12, 7750 SR-7/12, and 7750 SR-12e, MDAs plug into IOMs. (MDA-e modules plug into the IOM4-e and IOM4-e-B, MDA-e-XP modules plug into the IOM5-e). Up to two MDAs can be provisioned on an IOM.

IMMs are designed with fixed integrated media cards, which may require provisioning, depending on the generation of the IMM.

MDA-a and MDA-aXP modules are used in the 7750 SR-a and the MDA-e and ISA2 modules are used in the 7750 SR-e chassis. Up to four MDAs can be provisioned for each IOM.

In all cases, the card slot and IOM or IMM card-type must be provisioned before an MDA can be provisioned. A preprovisioned MDA slot can remain empty without interfering with services on populated equipment. When an MDA is installed and enabled, the system verifies that the MDA type matches the provisioned type. If the command options do not match, the MDA remains offline.

On the 7450 ESS-7/12, 7750 SR-7/12, and 7750 SR-12e platforms, MDA names in the CLI start with the letter 'm' (for example, m10-1gb-xp-sfp).

The following example displays the card, card-type, mda, and mda-type command usage in the 7750 SR-12.

7750 SR-12 configuration (MD-CLI)

*[ex:/configure]
A:admin@node-2# card 6

*[ex:/configure card 6]
A:admin@node-2# card-type iom4-e

*[ex:/configure card 6]
A:admin@node-2# mda 1

*[ex:/configure card 6 mda 1]
A:admin@node-2# mda-type me1-100gb-cfp2

*[ex:/configure card 6 mda 1]
A:admin@node-2# admin-state enable

*[ex:/configure card 6 mda 1]
A:admin@node-2# exit

*[ex:/configure card 6]
A:admin@node-2# mda 2

*[ex:/configure card 6 mda 2]
A:admin@node-2# mda-type me10-10gb-sfp+

*[ex:/configure card 6 mda 2]
A:admin@node-2# admin-state enable

*[ex:/configure card 6 mda 2]
A:admin@node-2# exit

*[ex:/configure card 6]
A:admin@node-2# admin-state enable

7750 SR-12 configuration output (MD-CLI)

[ex:/configure]
A:admin@node-2# info
...
 card 6 {
        admin-state enable
        card-type iom4-e
        mda 1 {
            admin-state enable
            mda-type me1-100gb-cfp2
        }
        mda 2 {
            admin-state enable
            mda-type me10-10gb-sfp+
        }
    }

7750 SR-12 configuration (classic CLI)

*A:node-2# configure card 6                 
*A:node-2>config>card# card-type "iom4-e" 
*A:node-2>config>card# mda 1 
*A:node-2>config>card>mda# mda-type me1-100gb-cfp2
*A:node-2>config>card>mda# no shutdown 
*A:node-2>config>card>mda# exit 
*A:node-2>config>card# mda 2 
*A:node-2>config>card>mda# mda-type "me10-10gb-sfp+" 
*A:node-2>config>card>mda# no shutdown 
*A:node-2>config>card>mda# exit 
*A:node-2>config>card# no shutdown

7750 SR-12 configuration output (classic CLI)

A:node-2>config>card# info
----------------------------------------------
        card-type iom4-e
        mda 1
            mda-type me1-100gb-cfp2
            no shutdown
        exit
        mda 2
            mda-type me10-10gb-sfp+
            no shutdown
        exit
        no shutdown
----------------------------------------------

The 7750 SR-a4 and 7750 SR-a8 support only MDA-a and MDA-aXP modules, which are identified in the CLI with an ‟ma” prefix (for example, ma4-10gb-sfp+), or ‟max” prefix (for example, maxp10-10gb-sfp+). Likewise, the 7750 SR-1e, 7750 SR-2e, and 7750 SR-3e support only MDA-e modules, which are identified in the CLI with an ‟me” prefix, such as me1-100gb-cfp2.

The following example shows the card, card-type, mda, and mda-type command usage in the 7750 SR-1e.

7750 SR-1e configuration (MD-CLI)

*[ex:/configure]
A:admin@node-2# card 1

[ex:/configure card 1]
A:admin@node-2# card-type iom-e

*[ex:/configure card 1]
A:admin@node-2# mda 1

*[ex:/configure card 1 mda 1]
A:admin@node-2# mda-type me10-10gb-sfp+

*[ex:/configure card 1 mda 1]
A:admin@node-2# exit

*[ex:/configure card 1]
A:admin@node-2# mda 4

*[ex:/configure card 1 mda 4]
A:admin@node-2# mda-type me1-100gb-cfp2

*[ex:/configure card 1 mda 4]
A:admin@node-2# exit

7750 SR-1e configuration output (MD-CLI)

[ex:/configure]
A:admin@node-2# info
    card 1 {
        card-type iom-e
        mda 1 {
            mda-type me10-10gb-sfp+
        }
        mda 4 {
            mda-type me1-100gb-cfp2
        }
    }

7750 SR-1e configuration (classic CLI)

*A:node-2# config# card 1
*A:node-2>config>card# card-type iom-e
*A:node-2>config>card# mda 1
*A:node-2>config>card>mda# mda-type me10-10gb-sfp+
*A:node-2>config>card>mda# exit
*A:node-2config>card# mda 4
*A:node-2>config>card>mda# mda-type me1-100gb-cfp2
*A:node-2config>card>mda# exit

7750 SR-1e configuration output (classic CLI)

A:node-2>config>card# info
----------------------------------------------
        card-type iom-e
        mda 1
            mda-type me10-10gb-sfp+
        exit
        mda 4
            mda-type me1-100gb-cfp2
        exit
     exit

XMAs/C-XMAs

Note: For consistency across platforms, XMAs are modeled in the system as MDAs, and unless specified otherwise, the term MDA is used generically in this document to refer to both MDAs and C-XMA/XMAs. When the term XMA is used, it refers to both XMAs and C-XMAs unless specified otherwise.

XMAs are supported on the 7750 SR-1s/2s/7s/14s and 7950 XRS platforms. XMAs plug into XCMs. XCMs must be provisioned before an XMA can be provisioned with a type.

The XMA information must be configured before ports can be configured. After you configure the XCM, use the following CLI commands to provision XMAs.

A maximum of two XMAs can be configured on an XCM. The following example displays the card slot, card type, MDA slot, and MDA type command usage.

XMA configuration on an XCM (MD-CLI)

*[ex:/configure]
A:admin@node-2# card 1

*[ex:/configure card 1]
A:admin@node-2# card-type xcm-x20

*[ex:/configure card 1]
A:admin@node-2# mda 1

*[ex:/configure card 1 mda 1]
A:admin@node-2# mda-type cx2-100g-cfp

*[ex:/configure card 1 mda 1]
A:admin@node-2# power-priority-level 130

*[ex:/configure card 1 mda 1]
A:admin@node-2# exit

*[ex:/configure card 1]
A:admin@node-2# mda 2

*[ex:/configure card 1]
A:admin@node-2# mda-type cx20-10g-sfp
                  
*[ex:/configure card 1 mda 2]
A:admin@node-2# power-priority-level 135

*[ex:/configure card 1 mda 2]
A:admin@node-2# exit

XMA configuration output (MD-CLI)

[ex:/configure]
A:admin@node-2# info
    card 1 {
        card-type xcm-x20
        mda 1 {
            mda-type cx2-100g-cfp
            power-priority-level 130
        }
        mda 2 {
            mda-type cx20-10g-sfp
            power-priority-level 135
        }
    }

XMA configuration on an XCM (classic CLI)

*A:node-2>config# card 1
*A:node-2>config>card# card-type xcm-x20
*A:node-2>config>card# mda 1
*A:node-2>config>card>mda# mda-type cx2-100g-cfp
*A:node-2>config>card>mda# power-priority-level 130
*A:node-2>config>card>mda# exit
*A:node-2>config>card# mda 2
*A:node-2>config>card>mda# mda-type cx20-10g-sfp
*A:node-2>config>card>mda# power-priority-level 135
*A:node-2>config>card>mda# exit

XMA configuration output (classic CLI)

A:node-2>config>card# info
----------------------------------------------
        card-type xcm-x20
        mda 1
            power-priority-level 130
            mda-type cx2-100g-cfp
            no shutdown
        exit
        mda 2
            power-priority-level 135
            mda-type cx20-10g-sfp
            no shutdown
        exit
        no shutdown
----------------------------------------------

On the 7950 XRS, the show card state output displays an ‟x” in the name of the XMA and ‟cx” in the name of a C-XMA. Use the following command to display the XMA and C-XMA information.

show card state
===============================================================================
Card State
===============================================================================
Slot/  Provisioned Type                  Admin Operational   Num   Num Comments
Id         Equipped Type (if different)  State State         Ports MDA 
-------------------------------------------------------------------------------
1      xcm-x20                           up    up                  2   
1/1    cx20-10g-sfp                      up    up            20        
1/2    cx20-10g-sfp                      up    up            20        
2      xcm-x20                           up    up                  2   
2/1    cx20-10g-sfp                      up    up            20        
A      cpm-x20                           up    up                      Active
B      cpm-x20                           up    up                      Standby
===============================================================================

Hardware licensing

With the introduction of pay-as-you-grow licensing, level-based hardware assemblies (for example, FP4 and FP5 IOMs and XMAs) now include variants with license levels. These levels define the capacity and functionality of the assembly. The capacity controls aspects such as the number and types of connectors and breakout options that can be configured, as well as the total connector bandwidth. Licensing also controls the number of user (based on configuration) hardware egress queues and egress policers that are available per forwarding plane. For a more complete description of the levels available for a particular assembly, see the associated installation guide.

The license level must be provisioned for the assembly at the same time as the card type or MDA type is provisioned. Each assembly has a set of levels applicable to that particular IOM or XMA that are defined using mnemonic strings. For example, an assembly may have a level 'cr1200g' which refers to a functional level of 'core routing' and a capacity maximum bandwidth of 1.2 Tb/s. A second example of a license level is 'he2400g+', which refers to a functional level of 'high scale edge routing' and a capacity level of a bandwidth of 2.4 Tb/s but with Intelligent Aggregation (formerly known as Fan In/Out) to a higher bandwidth.

When an assembly is installed in the chassis, the license level encoded into the equipped assembly must match the value provisioned for the assembly. If they do not match, the assembly cannot become active in the chassis. The only exception is that a variant of the assembly with the maximum functional and capacity level is allowed to come up in a slot provisioned as any level; the restrictions in effect are at the provisioned level, but this allows this specific assembly to be used to replace any other level of that assembly if necessary.

The following example shows the provisioning of an XCM with two XMAs. The first XMA is a two complex, 2.4T 24-connector QSFP28 XMA with a license level of er2400g (edge routing, 2.4 Tb/s) and the second XMA is a two complex, 2.4T 6-connector CFP8 XMA with a license level of he1600g (high scale edge routing, 4 connector 1.2Tbps):

XCM configuration with two XMAs (MD-CLI)

*[ex:/configure]
A:admin@node-2# card 4

*[ex:/configure card 4]
A:admin@node-2# card-type xcm-x20

*[ex:/configure card 4]
A:admin@node-2# mda 1

*[ex:/configure card 4 mda 1]
A:admin@node-2# mda-type x24-100g-qsfp28

*[ex:/configure card 4 mda 1]
A:admin@node-2# level er2400g

*[ex:/configure card 4 mda 1]
A:admin@node-2# exit

*[ex:/configure card 4]
A:admin@node-2# mda 2

*[ex:/configure card 4 mda 2]
A:admin@node-2# mda-type x6-400g-cfp8

*[ex:/configure card 4 mda 2]
A:admin@node-2# level he1600g

XCM configuration with two XMAs (classic CLI)

*A:node-2# configure card 4 card-type "xcm2-x20"
*A:node-2# configure card 4 mda 1 mda-type "x24-100g-qsfp28" level "er2400g"
*A:node-2# configure card 4 mda 2 mda-type "x6-400g-cfp8" level "he1600g"

Use the following command to display the configuration information.

show mda
===============================================================================
MDA Summary
===============================================================================
Slot  Mda   Provisioned Type                            Admin     Operational
                Equipped Type (if different)            State     State
-------------------------------------------------------------------------------
4     1     x24-100g-qsfp28:er2400g                     up        up
      2     x6-400g-cfp8:he1600g                        up        up
===============================================================================

The show card and show mda output display both the type and level of the assembly and indicates when there is a difference between the provisioned and installed levels. In the following example, the first XMA has a provisioned value matching the installed assembly and the second XMA has a difference in the provisioned and installed assembly. Use the following command to show detailed XMA information.

show mda 4/1 detail
===============================================================================
MDA 4/1 detail
===============================================================================
Slot  Mda   Provisioned Type                            Admin     Operational
                Equipped Type (if different)            State     State
-------------------------------------------------------------------------------
4     1     x24-100g-qsfp28:er2400g                     up        up
MDA Licensing Data
    Licensed Level                : er2400g
    Description                   : 2.4T, 24c, Edge Routing

Use the following command to show detailed XMA information.

show mda 4/2 detail
===============================================================================
MDA 4/2 detail
===============================================================================
Slot  Mda   Provisioned Type                            Admin     Operational
                Equipped Type (if different)            State     State
-------------------------------------------------------------------------------
4     2     x6-400g-cfp8:he2400g                        up        provisioned
            x6-400g-cfp8:he1600g
MDA Licensing Data
    Licensed Level                : he1600g
    Description                   : 1.6T, 4c, High Scale Edge Routing
Use the following command to view the connector and bandwidth constraints of a card or MDA.
show licensing 1/1
===============================================================================
Connector           MAC  Licensed  Restrictions
-------------------------------------------------------------------------------
1/1/c1              1    Yes       None
1/1/c2              1    Yes       None
1/1/c3              1    Yes       None
1/1/c4              1    Yes       None
1/1/c5              1    No        No Breakout Allowed
1/1/c6              1    No        No Breakout Allowed
1/1/c7              2    Yes       None
1/1/c8              2    Yes       None
1/1/c9              2    Yes       None
1/1/c10             2    Yes       None
1/1/c11             2    No        No Breakout Allowed
1/1/c12             2    No        No Breakout Allowed
1/1/c13             3    Yes       None
...
Use the following command to display the number of hardware egress user queues and egress user policers (total, allocated, and free), which are dependent on the operational license level of the card, XIOM, or MDA containing the FP.
tools dump resource-usage card 1 fp 1
===============================================================================
Resource Usage Information for Card Slot #1 FP #1
===============================================================================
                                                    Total  Allocated       Free
-------------------------------------------------------------------------------
...
                          Egress User Queues |     131072        384     130688
...
                        Egress User Policers |     393215          0     393215
...
===============================================================================

The tools dump resource-usage card fp command also displays the number of hardware egress queues available on the related FP that is dependent on the configured allocation of the percentage of ingress queues.

Software license activation

The pay-as-you-grow licensing of the 7750 SR hardware platforms includes the ability to distribute software based licenses to operational systems in a live network. This is done by the creation of a license key file containing various individual licenses, making this file available to a system, and then activating that license key file on the system. Nokia provides the Configuration License Manager (CLM) tool to assist in this process. Normally, the CLM would perform all the steps in license distribution to a target system and only the assignment of individual licenses within a system itself need to be managed using the management mechanism for the system itself.

The license key file is a secure distribution mechanism for the licenses. Within the license key file, are one or more license keys. Each license key is assigned for a particular target system identified using a UUID. This UUID is tied to the chassis of the system and therefore the license key can only be validated on the system with that chassis. Each license key is also tied to a specific major software release of SR OS.

When a license key file is available to a target system and is activated it is first validated to ensure it is applicable for the specified target. For the license key of the SR OS hardware platform to be valid, the user must ensure that the:

  • license is for a 7xxx platform

  • UUID of the system matches the one encoded in the "UUID-locked" license key

  • SR OS software version (the major release number) matches the one encoded in the license key

  • license file is not expired

Validation or activation of the license key file results in zero or one license key that is valid for the running software on the target. If there is a valid license key, the records contained in that key are read and made available to the system (see Software license records).

There may be additional license keys in the file that are for the target system but for a different software release. This is the case when an upgrade of the system is planned. Those license keys shall be considered available however, the feature licenses contained within them are not available for use. Use the following command to see the feature licenses. 
show system license available-licenses
===============================================================================
Available Licenses
===============================================================================
License name   : sr-regress@list.nokia.com
License uuid   : ab516e50-2413-44aa-9f7c-34b4e5b64d19
Machine uuid   : ab516e50-2413-44aa-9f7c-34b4e5b64d19
License desc   : 7xxx Platform
License prod   : 7xxx Platform
License sros   : TiMOS-[BC]-16.0.*
Current date   : FRI NOV 03 15:53:54 UTC 2017
Issue   date   : FRI SEP 22 20:55:14 UTC 2017
Start   date   : FRI SEP 15 00:00:00 UTC 2017
End     date   : THU MAR 15 00:00:00 UTC 2018
-------------------------------------------------------------------------------
License name   : sr-regress@list.nokia.com
License uuid   : ab516e50-2413-44aa-9f7c-34b4e5b64d19
Machine uuid   : ab516e50-2413-44aa-9f7c-34b4e5b64d19
License desc   : 7xxx Platform
License prod   : 7xxx Platform
License sros   : TiMOS-[BC]-17.0.*
Current date   : FRI NOV 03 15:53:54 UTC 2017
Issue   date   : FRI SEP 22 20:55:14 UTC 2017
Start   date   : FRI SEP 15 00:00:00 UTC 2017
End     date   : THU MAR 15 00:00:00 UTC 2018
-------------------------------------------------------------------------------
2 license(s) available.
===============================================================================

On a system boot, the license key file pointed to by the BOF is activated. If new license key files are activated on a system, the BOF should be updated to point to the new license key file. If there are active licenses in system that are in use and the node reboots and the license key file pointed to by the BOF either fails to validate or does not contain the in-use license records, the system is considered to be in unlicensed state. In this state, the node reboots every 60 minutes until the records are no longer in-use or a valid license key is provided that includes all the in use license records.

Software license records

The activate license key shall unlock a set of license records for use within the system. In Release 16.0, only Hardware Upgrade license records are distributed in the license keys. These can be used to upgrade the hardware capacity or the hardware functional level of a card or an XMA. These upgrades define a starting level and an upgraded level for the target assembly. Multiple instances of the same upgrade can be assigned to a system in the license key. Use the following command to check the list of license records, the number in use, and the number available.
show licensing entitlements

========================================================================
License                              Available      In-Use       State
------------------------------------------------------------------------
...
MDA Upgrades
  cr1200g-cr1600g                            1           1        VALID
  cr1200g-er1200g                            1           0        VALID
  cr1600g-cr2400g                            1           0        VALID
  cr1600g-er1600g                            2           0        VALID
  cr2400g-er2400g                            1           0        VALID
  er1200g-er1600g                            4           2        VALID
  er1200g-he1200g                            1           0        VALID
  er1600g-er2400g                            1           0        VALID
  er1600g-he1600g                            1           0        VALID
  er2400g-he2400g                            1           0        VALID
  he1200g-he1600g                            1           0        VALID
  he1600g-he2400g                            1           0        VALID
========================================================================

An upgrade can be assigned to a particular card or XMA using the upgrade command within the configure card or configure card mda context. Multiple upgrades can be assigned to the same card or XMA if needed to gradually augment the base card. In the following example, four upgrades have been applied in sequence to the base level of cr1600g to bring the XMA from CR to ER then ER to HE then to increase capacity first from 1600 Gb/s to 2400 Gb/s and then from 2400 Gb/s to 2400 Gb/s with aggregation to 3600 Gb/s.

Use the following command to show the upgraded configuration.
show mda 1/1 detail
===============================================================================
MDA 1/1 detail
===============================================================================
Slot  Mda   Provisioned Type                            Admin     Operational
                Equipped Type (if different)            State     State
-------------------------------------------------------------------------------
1     1     s36-100gb-qsfp28:cr1600g                    up        provisioned
                (not equipped)

MDA Licensing Data
    Licensed Level                : he2400g+
    Description                   : 2.4T /w agg to 3.6T, 36p, High Scale Edge
                                    Routing
    Upgrade 1                     : cr1600g-er1600g
    Upgrade 2                     : er1600g-he1600g
    Upgrade 3                     : he1600g-he2400g
    Upgrade 4                     : any2400g-2400g+

Oversubscribed Ethernet MDAs and Intelligent Aggregation

The 7750 SR and 7450 ESS support oversubscribed Ethernet MDAs. These have more bandwidth toward the user than the capacity between the MDA and IOM. This concept has continued with the MDA, IOM, XMA, XIOM, and MDA-s of the FP4 and FP5 generations, where it applies on assemblies labeled as using "Intelligent Aggregation".

A traffic management function is implemented on the MDA to control the data entering the IOM. This function consists of two parts:

  • rate limiting

  • packet classification and scheduling

Rate limiting

The oversubscribed MDA limits the rate at which traffic can enter the MDA on a per-port basis. If a port exceeds its configured limits then the excess traffic is discarded, and 802.3x flow control frames (pause frames) are generated.

Packet classification and scheduling

The classification and scheduling function implemented on the oversubscribed MDA, including assemblies using Intelligent Aggregation, ensures that traffic is correctly prioritized when the bus from the MDA to the IOM is overcommitted. This could occur if the policing command options configured are such that the sum of the traffic being admitted into the MDA is greater than the capacity between the MDA and the IOM.

The classification function uses the bits set in the DSCP or Dot1p fields of the customer packets to perform classification. It can also identify locally addressed traffic arriving on network ports as Network Control packets. This classification on the oversubscribed MDA uses the following rules:

  • If the service QoS policy for the SAP (port or VLAN) uses the default classification policy, all traffic is classified as Best Effort (be).

  • If the service QoS policy for the SAP contains a Dot1p classification, the Dot1p field in the customer packets is used for classification on the MDA.

  • If the service QoS policy for the SAP contains a DSCP classification, the DSCP field in the customer packets is used for classification on the MDA.

  • If a mix of Dot1p and DSCP classification definitions are present in the service QoS policy, then the field used to perform classification is the type used for the highest priority definition. For example, if High Priority 1 is the highest priority definition and it specifies that the DSCP field should be used, then the DSCP field is used for classification on the MDA and the Dot1p field is ignored.

  • If the service QoS policy for the SAP specifies IP or MAC filters for forwarding class identification, then traffic is treated as Best Effort. Full MAC or IP classification is not possible on the MDA (but is possible on the IOM).

  • The packet is classified into 16 classes. Typically, these are the eight forwarding classes and each packet is assigned one priority per forwarding class. After classification, the packet is offered to the queuing model. This queuing model is limited to three queues each having four thresholds. These thresholds define whether an incoming packet, after classification, is accepted in the queue or not. Typical mapping of classes onto queues/threshold shows typical mapping of classes onto queues and thresholds.

    Table 1. Typical mapping of classes onto queues/threshold
    Counter {Queue Threshold Traffic class}

    0

    {2

    3

    ‟fc-nc / in-profile”}

    1

    {2

    2

    ‟fc-nc / out-profile”}

    2

    {2

    1

    ‟fc-h1 / in-profile”}

    3

    {2

    0

    ‟fc-h1 / out-profile”}

    4

    {1

    3

    ‟fc-ef / in-profile”}

    5

    {1

    2

    ‟fc-ef / out-profile”}

    6

    {1

    1

    ‟fc-h2 / in-profile”}

    7

    {1

    0

    ‟fc-h2 / out-profile”}

    8

    {0

    3

    ‟fc-l1 / in-profile”}

    9

    {0

    3

    ‟fc-l1 / out-profile”}

    10

    {0

    2

    ‟fc-af / in-profile”}

    11

    {0

    2

    ‟fc-af / out-profile”}

    12

    {0

    1

    ‟fc-l2 / in-profile”}

    13

    {0

    1

    ‟fc-l2 / out-profile”}

    14

    {0

    0

    ‟fc-be / in-profile”}

    15

    {0

    0

    ‟fc-be / out-profile”}

A counter is associated with each mapping. The above is an example and is dependent on the type of classification (such as dscp-exp, dot1p, and so on). When the threshold of a particular class is reached, packets belonging to that class are not accepted in the queue. The packets are dropped and the associated counter is incremented.

The scheduling of the three queues is done in a strict priority, highest priority basis is associated with queue 2. This means that scheduling is done at queue level, not on the class that resulted from the classification. As soon as a packet has been accepted by the queue there is no way to differentiate it from other packets in the same queue (for example, another classification result not exceeding its threshold). All packets queued in the same queue, have the same priority from a scheduling point of view.