7210 SAS interfaces

This chapter provides information about configuring chassis slots, cards, and ports.

Configuration overview

Note:

This guide uses the term ‟preprovisioning” in the context of preparing or preconfiguring entities such as chassis slots, line cards (for example, Switch Fabric and Control Plane Module (SF/CPM) and Integrated Media Modules (IMMs)), and media dependent adapters (MDAs), ports, and interfaces, before initialization. These entities can be installed but not enabled. When the entity is in a no shutdown state (administratively enabled), the entity is considered to be provisioned.

The 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE and its variants, are platforms with a fixed port configuration, and no expansion slots. 7210 SAS software inherits the concept of CPM, IOM, and MDA from the SR OS to represent the hardware logically. These logical cards are fixed and are not removable. The software creates two (2) logical cards to represent the CPM and IOM; the cards are preprovisioned on bootup. The IOM card is modeled with a single MDA that is a logical entity and represents the fixed ports on the system. The MDA is auto-provisioned on bootup and does not need to be provisioned. Ports and interfaces can also be preprovisioned.

The 7210 SAS-R6 is a chassis-based platforms that has 6 IMM slots that can accept media cards used for service delivery and 2 CPM slots that provide control-plane redundancy. The chassis slots must be provisioned to accept a specific line card and set the relevant configurations before the equipment is actually installed. The preprovisioning ability 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.

The 7210 SAS-R12 is a chassis-based platforms that have 12 IMM slots that can accept media cards used for service delivery and 2 CPM slots that provide control-plane redundancy. The chassis slots must be provisioned to accept a specific line card and set the relevant configurations before the equipment is actually installed. The preprovisioning ability 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 cards

The 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE are platforms which have a set of fixed ports. Software preprovisions the cards on bootup. No expansion slots are supported on these platforms.

The show card command lists the cards auto-provisioned on 7210 SAS-T, 7210 SAS-Mxp, and 7210 SAS-Sx/S 1/10GE chassis.

The following show card sample output lists the cards auto-provisioned on 7210 SAS-T chassis.

A:7210SAST>show# card

===============================================================================
Card Summary
===============================================================================
Slot   Provisioned Type                            Admin Operational   Comments
           Equipped Type (if different)            State State
-------------------------------------------------------------------------------
1      iom-sas                                     up    up
A      sfm-sas                                     up    up/active
===============================================================================
A:7210SAST>show#

The following show card sample output lists the cards auto-provisioned on 7210 SAS-Mxp chassis.

*A:sim_dutc>show# card state

===============================================================================
Card State
===============================================================================
Slot/  Provisioned Type                  Admin Operational   Num   Num Comments
Id         Equipped Type (if different)  State State         Ports MDA
-------------------------------------------------------------------------------
1      iom-sas                           up    up                  2
1/1    m22-sfp+2-tx+4-sfpp               up    up            24
A      sfm-sas                           up    up                      Active
===============================================================================
*A:sim_dutc>show#

The following show card sample output lists the cards auto-provisioned on 7210 SAS-Sx/S 1/10GE 48-port 1GE variant chassis.

*A:7210SAS>show# card state

===============================================================================
Card State
===============================================================================
Slot/  Provisioned Type                  Admin Operational   Num   Num Comments
Id         Equipped Type (if different)  State State         Ports MDA
-------------------------------------------------------------------------------
1      iom-sas                           up    up                  2
1/1    s48-t4-sfpp                       up    up            52
A      sfm-sas                           up    up                      Active
===============================================================================
*A:7210SAS>show#
*A:VoyagerDCpemV2# show card state

===============================================================================
Card State
===============================================================================
Slot/  Provisioned Type                  Admin Operational   Num   Num Comments
Id         Equipped Type (if different)  State State         Ports MDA
-------------------------------------------------------------------------------
1      iom-sas                           up    up                  1
1/1    s64-sfpp+4-cfp                    up    up            68
A      sfm-sas                           up    up                      Active
===============================================================================
*A:VoyagerDCpemV2#

The 7210 SAS-R6 is a chassis based platform with 6 IMM slots and 2 CPM slots. On a chassis based platform the slots must be provisioned. To preprovision a chassis slot, the line card type must be specified. System administrators or network operators can enter card type information for each slot, allowing a range of card types in particular slots. From the range of card types, a card and accompanying MDAs (if any) are specified. When a card is installed in a slot and enabled, the system verifies that the installed card type matches the allowed card type. If the parameters do not match, the card remains offline. A preprovisioned slot can remain empty without conflicting with populated slots. 7210 SAS-R6 supports only CPM and IMMs. It does not support any physical removable MDAs. Software uses logical MDAs internally to represent the ports on the IMMs and the MDA type is auto-provisioned by software when the IMMs are provisioned. Check the latest release notes for a list of supported card types (that is, CPM and IMMs). See the 7210 SAS-R6 Chassis Installation Guide for more information about installation of cards.

The 7210 SAS-R12 is a chassis based platform with 12 IMM slots and 2 CPM slots. On a chassis based platform the slots must be provisioned. To preprovision a chassis slot, the line card type must be specified. System administrators or network operators can enter card type information for each slot, allowing a range of card types in particular slots. From the range of card types, a card and accompanying MDAs (if any) are specified. When a card is installed in a slot and enabled, the system verifies that the installed card type matches the allowed card type. If the parameters do not match, the card remains offline. A preprovisioned slot can remain empty without conflicting with populated slots. 7210 SAS-R12 supports only CPM and IMMs. It does not support any physical removable MDAs. Software uses logical MDAs internally to represent the ports on the IMMs and the MDA type is auto-provisioned by software when the IMMs are provisioned. Please check the latest release notes for a list of supported card types (that is, CPM and IMMs). See 7210 SAS-R12 Chassis Installation Guide for more information about installation of cards.

Note:

On the 7210 SAS-R6 and 7210 SAS-R12, the user must preconfigure the type of IMMs that will be populated so that appropriate resources can be allocated on system bootup. See the config>system>chassis>allow-imm-family command in the 7210  SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information.

The following show sample output lists the cards provisioned and equipped in the 7210 SAS-R6 and 7210 SAS-R12 chassis.

*A:sasr_dutb>show# card

===============================================================================
Card Summary
===============================================================================
Slot   Provisioned Type                            Admin Operational   Comments
           Equipped Type (if different)            State State
-------------------------------------------------------------------------------
1      imm-sas-10sfp+1xfp                          up    up
2      imm-sas-10sfp+1xfp                          up    provisioned
           (not equipped)
3      imm-sas-10sfp                               up    up
4      (not provisioned)                           up    unprovisioned
           imm-sas-2xfp
5      imm-sas-2xfp                                up    up
6      imm-sas-2xfp                                up    up
A      cpm-sf-sas-R6                               up    up/active
B      cpm-sf-sas-R6                               up    up/standby
===============================================================================
*A:sasr_dutb>show#
A:A6144909484>show# card

===============================================================================
Card Summary
===============================================================================
Slot   Provisioned Type                            Admin Operational   Comments
           Equipped Type (if different)            State State
-------------------------------------------------------------------------------
8      (not provisioned)                           up    unprovisioned
           imm-sas-b-4sfp+
A      cpm-sf-sas-R12                              up    up/active
B      cpm-sf-sas-R12                              up    up/standby

MDAs

The 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE platforms, as described in the previous section, do not support any physical removable MDAs. Software uses the concept of MDA internally (as a logical entity) to represent the ports and the MDA type is either auto-provisioned on bootup or auto-provisioned automatically based on the configured IMM type.

Digital Diagnostics Monitoring

Some Nokia SFPs, XFPs, and the MSA DWDM transponder support the Digital Diagnostics Monitoring (DDM) capability, which allows the transceiver module to maintain information about its working status in device registers, including:

  • temperature

  • supply voltage

  • transmit (Tx) bias current

  • Tx output power

  • received (Rx) optical power

Note:

The optical transceiver DDM feature provides real-time values for guidance. For the specific values, the optical power data provides an accuracy of ±3 dB or better. The accuracy of this data is defined in the relevant standard for the transceiver type, such as SFF-8472 for SFP+. Use an optical power meter where precise optical power data is required. Contact your Nokia technical support representative for further assistance or clarification.

The transceiver is also programmed with warning and alarm thresholds for low and high conditions that can generate system events. These thresholds are programmed by the transceiver manufacturer.

No CLI command configuration is required to support DDM operations. However, the show>port port-id detail command displays DDM information in the Transceiver Digital Diagnostics Monitoring output section.

The Tx and Rx power displayed in the DDM output are average optical power in dBm.

DDM information is populated into the router MIBs, so the DDM data can be retrieved by Network Management using SNMP. Also, RMON threshold monitoring can be configured for the DDM MIB variables to set custom event thresholds if the factory-programmed thresholds are not at the desired levels.

The following are potential uses of the DDM data:

  • optics degradation monitoring

    With the information returned by the DDM-capable optics module, degradation in optical performance can be monitored and trigger events based on custom or the factory-programmed warning and alarm thresholds.

  • link/router fault isolation

    With the information returned by the DDM-capable optics module, any optical problem affecting a port can be quickly identified or eliminated as the potential problem source.

The following table describes supported real-time DDM features.

Table 1. Real-time DDM information

Parameter

User units

SFP/XFP units

SFP

XFP

Temperature

Celsius

C

Supported

Supported

Supply Voltage

Volts

µV

Supported

Supported

TX Bias Current

mA

µA

Supported

Supported

TX Output Power

dBm (converted from mW)

mW

Supported

Supported

RX Received Optical Power4

dBm (converted from dBm) (Avg Rx Power or OMA)

mW

Supported

Supported

AUX1

parameter dependent (embedded in transceiver)

-

Not supported

Supported

AUX2

parameter dependent (embedded in transceiver)

-

Not supported

Supported

The following table describes supported factory-programmed DDM alarms and warnings.

Table 2. DDM alarms and warnings

Parameter

SFP/XFP units

SFP

XFP

Required?

Temperature

- High Alarm

- Low Alarm

- High Warning

- Low Warning

C

Yes

Yes

Yes

Supply Voltage

- High Alarm

- Low Alarm

- High Warning

- Low Warning

µV

Yes

Yes

Yes

TX Bias Current

- High Alarm

- Low Alarm

- High Warning

- Low Warning

µA

Yes

Yes

Yes

TX Output Power

- High Alarm

- Low Alarm

- High Warning

- Low Warning

mW

Yes

Yes

Yes

RX Optical Power

- High Alarm

- Low Alarm

- High Warning

- Low Warning

mW

Yes

Yes

Yes

AUX1

- High Alarm

- Low Alarm

- High Warning

- Low Warning

parameter dependent (embedded in transceiver)

No

Yes

Yes

AUX2

- High Alarm

- Low Alarm

- High Warning

- Low Warning

parameter dependent (embedded in transceiver)

No

Yes

Yes

SFPs and XFPs

The availability of the DDM real-time information and the warning and alarm status is based on the transceiver. The transceiver may or may not indicate that DDM is supported. Although some Nokia SFPs support DDM, Nokia SFPs support DDM releases later than Release 2.0. Contact a Nokia technical support representative for more information about DDM support for specific 7210 SAS releases. Non-DDM and DDM-supported SFPs are distinguished by a specific value in their EEPROM.

Although DDM data may be available for SFPs that do not indicate DDM support in their EEPROM, Nokia has not validated or verified the accuracy of this information.

DDM information can be displayed for non-Nokia transceivers, but Nokia is not responsible for the formatting, accuracy, and other informational details.

Statistics collection

The DDM information and warnings/alarms are collected at one minute intervals, so the minimum resolution for any DDM events when correlating with other system events is one minute.

Note that in the Transceiver Digital Diagnostic Monitoring section of the show port port-id detail command output:

  • If the present measured value is higher than the either or both High Alarm, High Warn thresholds, an exclamation mark ‟!” displays along with the threshold value.

  • If the present measured value is lower than the either or both Low Alarm, Low Warn thresholds, an exclamation mark ‟!” displays along with the threshold value.

    A:Dut-A# show port 2/1/6 detail
    
    .........
    
    ===============================================================================
    Transceiver Digital Diagnostic Monitoring (DDM), Internally Calibrated
    ===============================================================================
                                  Value High Alarm  High Warn   Low Warn  Low Alarm
    -------------------------------------------------------------------------------
    Temperature (C)               +39.3     +96.0      +94.0       -7.0      -8.0
    Supply Voltage (V)             3.27      3.51       3.49       3.12      3.10
    Tx Bias Current (mA)           18.8      77.0       70.0        5.5       4.5
    Tx Output Power (dBm)          1.33      5.50       5.00       0.00     -0.50
    Rx Optical Power (avg dBm)   -40.00     -8.50      -9.00     -33.98!   -35.23!
    ===============================================================================
    

Ports

This section describes 7210 SAS ports.

Port types

The following table describes the port types supported on the 7210 SAS platforms.

Table 3. Supported Ethernet ports

7210 SAS platform

Fixed copper ports (10/100/1000 Base-T)

Ethernet SFP ports

10 Gigabit XFP/SFP+ ports

100 Gigabit CFP4/QSFP28 ports

7210 SAS-T

1

7210 SAS-R6

2

3

7210 SAS-R12

2

3

7210 SAS-Mxp

4

7210 SAS-Sx/S 1/10GE

4

7210 SAS-Sx 10/100GE

4

4

4

The following support guidelines apply to the supported Ethernet port types described in the preceding table:

  • 10/100/1000 Base-T copper SFPs can be used in any of the SFP ports.

  • Copper SFPs with speeds of 10 Mb/s and full-duplex are supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-T. Copper SFPs with speeds of 10 Mb/s and half-duplex mode are supported only on the 7210 SAS-T.

  • Fixed copper ports on the 7210 SAS-Sx/S 1/10GE 24-port and 48-port copper variants, including PoE variants, support speeds of 10 Mb/s and 100 Mb/s with full-duplex mode. They do not support half-duplex mode.

  • Combination ports on the 7210 SAS-Mxp and 7210 SAS-Sx 1/10GE support speeds of 10 Mb/s with full-duplex mode when the copper port is used.

  • Fixed copper ports on the 16 x 10/100/1000 Base-T (RJ.5) IMMv2 card on the 7210 SAS-R6 and 7210 SAS-R12 support speeds of 10 Mb/s with full-duplex mode. They do not support speeds of 10 Mb/s with half-duplex mode.

  • Fixed copper ports on the 7210 SAS-T support speeds of 10 Mb/s with full-duplex and half duplex modes.

  • On the 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE, the user can select the fiber interface slot or the copper interfaces slot of the combination port using the config>port>ethernet>connection-type command. By default, the combination port connection-type is set to auto. The auto option allows the software to automatically detect the connection type based on the link availability of the media inserted into the port and set the operational value to either ‟copper” or ‟fiber”.

  • The 7210 SAS-Sx 1/10GE (48-port fiber) supports the use of copper SFP in the SFP slot for combo ports.

    Note:

    Nokia recommends that the user should not plug in the connector for the copper connection while using the SFP port (the opposite also applies). That is, at any point in time, only a single connector must be used.

  • The SFP+ ports on the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE allow the use of 1 GE fiber-optic SFPs or copper SFPs in SFP+ interface slots. Before using the 1 GE SFP, you must configure a speed of 1000 Mb/s on the SFP+ ports using the config port ethernet speed command. Only a speed of 1 Gb/s is supported for copper SFPs; that is, 10 Mb/s and 100 Mb/s speeds are not supported.

Port modes

In 7210 SAS devices, port must be configured as either access, access uplink or network. The following paragraphs describe the significance of the different port modes and the support available on different platforms.

  • access ports

    Configured for customer facing traffic on which services are configured. If a Service Access Port (SAP) is to be configured on the port, it must be configured as an access port. When a port is configured for access mode, the appropriate encapsulation type must be configured to distinguish the services on the port. After a port has been configured for access mode, one or more services can be configured on the port depending on the encapsulation value. Access ports can be configured on all the 7210 SAS platforms.

  • access-uplink ports

    Access-uplink ports are used to provide native Ethernet connectivity in service provider transport or infrastructure network. This can be achieved by configuring port mode as access uplink. With this option, the encap-type can be configured to only qinq. Access-uplink SAPs, which are QinQ SAPs, can only be configured on an access uplink port to allow the operator to differentiate multiple services being carried over a single access uplink port. This is the default mode when a node is operating in access-uplink mode.

  • network ports

    Configured for network facing traffic. These ports participate in the service provider transport or infrastructure network. Dot1q is supported on network ports. This is default for nodes operating in network mode.

  • hybrid ports

    Configured for access and network facing traffic. While the default mode of an Ethernet port remains network, the mode of a port cannot be changed between the access/network/hybrid values unless the port is shut down and the configured SAPs or interfaces are deleted. Hybrid ports allow a single port to operate in both access and network modes. MTU of port in hybrid mode is the same as in network mode except for the 10/100 MDA. The default encap for hybrid port mode is dot1q, it also supports QinQ encapsulation on the port level. Null hybrid port mode is not supported.

    After the port is changed to hybrid, the default MTU of the port is changed to match the value of 9212 bytes currently used in network mode (higher than an access port); this is to ensure that both SAP and network VLANs can be accommodated.

    The only exception is when the port is a 10/100 fast Ethernet. In those cases, the MTU in hybrid mode is set to 1522 bytes, which corresponds to the default access MTU with QinQ, which is larger than the network dot1q MTU or access dot1q MTU for this type of Ethernet port. The configuration of all parameters in access and network contexts will continue to be done within the port using the same CLI hierarchy as in existing implementation. The difference is that a port configured in mode hybrid allows both ingress and egress contexts to be configured concurrently.

    An Ethernet port configured in hybrid mode can have two values of encapsulation type: dot1q and QinQ. The NULL value is not supported because a single SAP is allowed, and can be achieved by configuring the port in the access mode, or a single network IP interface is allowed, which can be achieved by configuring the port in network mode. Hybrid mode can be enabled on a LAG port when the port is part of a single chassis LAG configuration. When the port is part of a multi-chassis LAG configuration, it can only be configured to access mode as MC-LAG is not supported on a network port and consequently is not supported on a hybrid port.

    The following table describes the port modes that are supported on each 7210 SAS platform.

    Table 4. 7210 SAS platforms supporting port modes

    Port mode platforms

    Access

    Network

    Hybrid

    Access-uplink

    7210 SAS-T

    Yes

    Yes 5

    Yes 6

    Yes 7

    7210 SAS-R6 IMM-b (IMMv2)

    Yes

    Yes

    Yes

    No

    7210 SAS-R6 IMM-c 100GE (IMM-c 1CFP4 or IMM-c 1QSFP28)

    Yes

    Yes

    No

    No

    7210 SAS-R12 IMM-b

    Yes

    Yes

    Yes

    No

    7210 SAS-R12 IMM-c 100GE (IMM-c 1CFP4 or IMM-c 1QSFP28)

    Yes

    Yes

    No

    No

    7210 SAS-Mxp

    Yes

    Yes

    Yes

    No

    7210 SAS-Sx/S 1/10GE

    Yes

    Yes

    Yes

    No

    7210 SAS-Sx 10/100GE

    Yes

    Yes

    Yes

    No

Port dot1q VLAN Etype

7210 SAS supports an option to allow the user to use a different dot1q VLAN Ethernet Type (Etype). It allows for interoperability with third-party switches that use some pre-standard (other than 0x8100) dot1q VLAN etype.

Configuration guidelines for dot1q-etype

The following are the configuration guidelines for dot1q-etype configured for dot1q encap port:

  • Dot1q-etype configuration is supported for all ports - Access, Hybrid and Network ports.

  • Dot1q-preserve SAPs cannot be configured on dot1q encap ports configured to use ethertype other than 0x8100.

  • Priority tagged packet received with etype 0x8100 on a dot1q port configured with etype 0x9100 are classified as priority tagged packet and mapped to a dot1q :0 SAP (if configured) and the priority tag is removed.

  • Priority tagged packets received with etype 0x6666 (any value other than 0x8100) on a dot1q port configured with etype 0x9100 is classified as null-tagged packet and mapped to a dot1q :0 SAP (if configured) and the priority tag is retained and forwarded.

  • The dot1q-etype is modified only for the dot1q encap port (access/hybrid port). The dot1q-etype cannot be modified on Network ports.

  • During the non-default dot1q-rvpls and qinq-rvpls, the extra tagged packets is dropped even for an 0x8100 packets on an RVPLS SAP, this is applicable only for network mode (and not access-uplink mode).

Support for Power over Ethernet

Note:

Power over Ethernet (PoE) is supported only on the 7210 SAS-Mxp ETR, 7210 SAS-Sx/S 1/10GE operating in standalone mode, and 7210 SAS-T ETR.

The 7210 SAS-Mxp ETR, 7210 SAS-Sx/S 1/10GE PoE variants, and 7210 SAS-T ETR support PoE in accordance with the 802.3af and 802.3at standards. This feature allows these platforms to supply power to connected PoE devices, such as telephones, CCTV cameras, and other PoE standard compliant devices.

The 7210 SAS-Sx 1/10GE supports two PoE variants:

  • 24Tp 4SFP+ PoE

  • 48Tp 4SFP+ PoE

In addition to the PoE variants, the following 7210 SAS-Sx 1/10GE fiber variants support two PoE/PoE+ ports:

  • 22F 2C 4SFP+

  • 46F 2C 4SFP+

The 7210 SAS-S 1/10GE supports two PoE variants:

  • 24Tp 4SFP+ AC PoE

  • 48Tp 4SFP+ AC PoE

The following PoE functionalities are available:

  • The 7210 SAS supports both 802.3af (PoE) and 802.3at (PoE+) on all ports. The ports can be used to connect either PoE or PoE+ devices, or a combination of both simultaneously, as long as the power drawn is within the device system limits.

  • Only Alternative A, as described in the 802.3af and 802.3at standards, is supported on the 7210 SAS.

  • The 7210 SAS supports classification of both Type 1 and Type 2 PoE devices (PDs) using the physical layer classification mechanism (using the 1-event physical layer classification mechanism for Type 1 PD and 2-event physical layer classification mechanism for Type 2 PD).

  • The 7210 SAS supports the class-based power allocation method, which allocates power based on the identified class using a physical layer classification mechanism. The 802.3af and 802.3at standards define the power that can be allocated or requested by a particular class. The standards define four classes: Class 1, Class 2, Class 3, and Class 4. These classes are used to allow PoE devices to request power based on their needs. If there is not enough power available to supply the identified class, power is denied to the connected PoE device. Each 7210 SAS device has a limit on the maximum amount of power it can provide. If the total power requested by the PDs connected to PoE-enabled ports exceeds this threshold, the 7210 SAS device denies power to the other PD. When power is denied to the PD, the port is operationally up, even though power is not supplied to the port. If power is applied successfully or denied to the port, the system logs an event.

  • Only DC power is supplied to connected PDs. It is supported for PDs that use injectors where an AC/DC wall device is used to power a remote PoE device.

  • The software monitors the PoE port, detects faults and events, and raises traps. The software displays this information in the status report. The following events and faults are detected and notify the user:

    • supplying power event

      This event is generated when power is supplied to a connected PoE device after successful detection and classification.

    • denied power event

      This event is generated when power is denied to a connected PoE device after successful detection and classification.

    • disconnect event

      This event is generated when a connected PoE device is disconnected from the port and stops drawing power from the node.

    • fault events

      These events are generated for overload, short-circuit, and other events. Software clears the fault when the fault no longer exists.

  • If a port enabled for PoE is shut down, the power supplied to the port is disabled. It restores power when the no shutdown command is executed, if the request does not exceed the power budget.

PoE configuration notes

The following configuration notes apply for PoE:

  • On the 7210 SAS-T ETR, up to four fixed copper ports are available to connect PoE/PoE+ devices. The 7210 SAS-T ETR can supply a maximum of 60 W.

  • On the 7210 SAS-Mxp ETR, up to 2 ports are available to connect PoE/PoE+ devices. The 7210 SAS-Mxp ETR can supply a maximum of 60 W.

  • On the 7210 SAS-T ETR and 7210 SAS-Mxp ETR, the maximum available power must be shared among all PoE/PoE+ devices connected to the node. That is, the node can support a mix of PoE devices (using 15 W) and PoE+ devices (using 30 W) as long as the total power drawn is within the system limits.

  • The 7210 SAS-Sx 1/10GE 24-port and 48-port fiber variants provide two PoE/PoE+ capable combo ports: 1/1/1 and 1/1/2. To use PoE/PoE+, these combo ports must be configured to use the copper interface and can draw maximum of 60 W. The ports can be used for either PoE or PoE+ devices, or a combination.

  • On the 7210 SAS-Sx 1/10GE and 7210 SAS-S 1/10GE, the 24-port and 48-port copper PoE variants support PoE/PoE+ on all fixed copper ports. On both variants, the PoE ports can draw maximum of 720 W. On the 24-port PoE variant, each port can draw up to 15 W for PoE or up to 25 W for PoE+. On the 48-port PoE variant, each port can draw up to 15 W for PoE or up to 25 W for PoE+, or a combination of PoE and PoE+ devices can be connected to the ports, as long as the total power drawn across all ports does not exceed 720 W.

Link Layer Discovery Protocol

The IEEE 802.1ab Link Layer Discovery Protocol (LLDP) standard defines protocol and management elements suitable for advertising information to stations attached to the same IEEE 802 LAN. The protocol facilitates the identification of stations connected by IEEE 802 LANs or MANs, their points of interconnection, and access points for management protocols.

The LLDP helps the network operators to discover topology information. This information is used to detect and resolve network problems and inconsistencies in the configuration.

The following list is the information included in the protocol defined by the IEEE 802.1ab standard:

  • Connectivity and management information about the local station to adjacent stations on the same IEEE 802 LAN is advertised.

  • Network management information from adjacent stations on the same IEEE 802 LAN is received.

  • Operates with all IEEE 802 access protocols and network media.

  • Network management information schema and object definitions suitable for storing connection information about adjacent stations is established.

  • Provides compatibility with a number of MIBs.

The following figure shows the internal architecture for a network node.

Figure 1. LLDP internal architecture for a network node

To detect and address network problems and inconsistencies in the configuration, the network operators can discover the topology information using LLDP. The Standard-based tools address the complex network scenarios where multiple devices from different vendors are interconnected using Ethernet interfaces.

The following figure shows an MPLS network that uses Ethernet interfaces in the core or as an access/handoff interfaces to connect to different kind of Ethernet enabled devices such as service gateway/routers, QinQ switches DSLAMs or customer equipment.

The topology information of the network in the following figure can be discovered if, IEEE 802.1ab LLDP is running on each of the Ethernet interfaces in network.

Figure 2. Generic customer use case for LLDP

LLDP protocol features

LLDP is an unidirectional protocol that uses the MAC layer to transmit specific information related to the capabilities and status of the local device. Separately from the transmit direction, the LLDP agent can also receive the same kind of information for a remote device which is stored in the related MIBs.

LLDP does not contain a mechanism for soliciting specific information from other LLDP agents, nor does it provide a specific means of confirming the receipt of information. LLDP allows the transmitter and the receiver to be separately enabled, making it possible to configure an implementation so the local LLDP agent can either transmit only or receive only, or can transmit and receive LLDP information.

The information fields in each LLDP frame are contained in a LLDP Data Unit (LLDPDU) as a sequence of variable length information elements, that each include type, length, and value fields (known as TLVs), where:

  • type identifies what kind of information is being sent

  • length indicates the length of the information string in octets

  • value is the actual information that needs to be sent (for example, a binary bit map or an alphanumeric string that can contain one or more fields)

Each LLDPDU contains four mandatory TLVs and can contain optional TLVs as selected by network management:

  • Chassis ID TLV

  • Port ID TLV

  • Time To Live TLV

  • Zero or more optional TLVs, as allowed by the maximum size of the LLDPDU

  • End Of LLDPDU TLV

The chassis ID and the port ID values are concatenated to form a logical identifier that is used by the recipient to identify the sending LLDP agent/port. Both the chassis ID and port ID values can be defined in a number of convenient forms. When selected however, the chassis ID/port ID value combination remains the same as long as the particular port remains operable.

A non-zero value in the TTL field of the Time To Live TLV tells the receiving LLDP agent how long all information pertaining to this LLDPDU identifier will be valid so that all the associated information can later be automatically discarded by the receiving LLDP agent if the sender fails to update it in a timely manner. A zero value indicates that any information pertaining to this LLDPDU identifier is to be discarded immediately.

Note that a TTL value of zero can be used, for example, to signal that the sending port has initiated a port shutdown procedure. The End Of LLDPDU TLV marks the end of the LLDPDU.

The implementation defaults to setting the port-id field in the LLDP OAMPDU to tx-local. This encodes the port-id field as ifIndex (sub-type 7) of the associated port. This is required to support some releases of SAM. SAM may use the ifIndex value to correctly build the Layer Two Topology Network Map. However, this numerical value is difficult to interpret or readily identify the LLDP peer when reading the CLI or MIB value without SAM. Including the port-desc option as part of the tx-tlv configuration allows an ALU remote peer supporting port-desc preferred display logic to display the value in the port description TLV instead of the port-id field value. This does not change the encoding of the port-id field. That value continues to represent the ifIndex. In some environments, it may be important to select the specific port information that is carried in the port-id field. The operator has the ability to control the encoding of the port-id information and the associated sub-type using the port-id-sub-type option. Three options are supported for the port-idsub-type:

  • tx-if-alias

    Transmit the ifAlias String (sub-type 1) that describes the port as stored in the IFMIB, either user configured description or the default entry (ie 10/100/Gig Ethernet SFP)

  • tx-if-name

    Transmits the ifName string (sub-type 5) that describes the port as stored in the IFMIB, ifName info

  • tx-local

    The interface ifIndex value (sub-type 7)

IPv6 (address sub-type 2) and IPv4 (address sub-type 1) LLDP System Management addresses are supported.

LLDP tunneling for Epipe service

Customers who subscribe to Epipe service consider the Epipe as a wire, and run LLDP between their devices which are located at each end of the Epipe. To facilitate this, the 7210 SAS devices support tunneling of LLDP frames that use the nearest bridge destination MAC address.

If enabled using the command tunnel-nearest-bridge-dest-mac, all frames received with the matching LLDP destination MAC address are forwarded transparently to the remote end of the Epipe service. To forward these frames transparently, the port on which tunneling is enabled must be configured with NULL SAP and the NULL SAP must be configured in an Epipe service. Tunneling is not supported for any other port encapsulation or other services.

Additionally, before enabling tunneling, admin status for LLDP dest-mac nearest-bridge must be set to disabled or Tx only, using the command admin-status available under configure>port>ethernet>lldp>destmac-nearest-bridge. If admin-status for dest-mac nearest-bridge is set to receive and process nearest-bridge LLDPDUs (that is, if either rx or tx-rx is set) then it overrides the tunnel-nearest-bridge-dest-mac command.

The following table describes the behavior for LLDP with different values set in use for admin-status and when tunneling is enabled or disabled.

Table 5. Behavior for LLDP with different values

Nearest-bridge-mac admin status

Tunneling enabled

Tunneling disabled

Rx

Process/Peer

Process/Peer

Tx

Tunnel

Drop

Rx-Tx

Process/Peer

Process/Peer

Disabled

Process/Peer

Drop

Note:

Transparent forwarding of LLDP frames can be achieved using the standard defined mechanism when using the either nearest-non-tmpr or the nearest-customer as the destination MAC address in the LLDP frames. Nokia recommends that the customers use these MAC address where possible to conform to standards. This command allows legacy LLDP implementations that do not support these additional destinations MAC addresses to tunnel LLDP frames that use the nearest-bridge destination MAC address.

LLDP media endpoint discovery

Note:

This feature is only supported on the 7210 SAS-Sx/S 1/10GE operating in the standalone or standalone-VC mode.

The IEEE standard 802.1AB is designed to provide a multivendor solution for the discovery of elements on an Ethernet Layer 2 data network. The LLDP standard allows nodes attached to an Ethernet LAN/WAN to advertise functionalities provided by that node to other nodes attached to the same LAN segment. See Link Layer Discovery Protocol for more information about IEEE 802.1AB.

The ANSI/TIA-1057 standard, Link Layer Discovery Protocol for Media Endpoint Devices, provides extensions to IEEE 802.1AB that are specific to media endpoint devices (MEDs), for example, voice phone and video terminal, in an IEEE 802 LAN environment. This standard defines specific usage of the IEEE 802.1AB LLDP base specification and interaction behavior between MEDs and LAN infrastructure elements.

LLDP media endpoint discovery (LLDP-MED) is an extension of LLDP that provides basic provisioning information to connected media endpoint devices. LLDP-MED extends LLDP protocol messages with more information to support voice over IP (VoIP) applications.

On the 7210 SAS, LLDP-MED supports the exchange of network policy information to provide the VLAN ID, dot1p bits, and IP DSCP value to media endpoint devices such as a VoIP phone.

The following TLVs are supported for LLDP-MED:

  • LLDP-MED Capabilities TLV

  • Network Policy TLV

LLDP-MED reference model

LLDP-MED devices are composed of two primary device types: network connectivity devices and endpoint devices.

LLDP-MED network connectivity devices provide access to the IEEE 802 LAN infrastructure for LLDP-MED endpoint devices. An LLDP-MED network connectivity device is a LAN access device based on any of the following technologies:

  • LAN switch or router

  • IEEE 802.1 bridge

  • IEEE 802.3 repeater

  • IEEE 802.11 wireless access point

  • any device that supports the IEEE 802.1AB and MED extensions defined by the standard and that can relay IEEE 802 frames using any method

Endpoint devices are composed of three sub-types, as defined in ANSI/TIA-1057:

  • generic endpoints (Class I)

    This endpoint device class is for basic endpoints in LLDP-MED (for example, IP communications controllers).

  • media endpoints (Class II)

    This endpoint device class supports IP media streams (for example, media gateways and conference bridges).

  • communication device endpoints (Class III)

    This endpoint device class support the IP communication system end user (for example, IP telephones and softphones).

The following figure shows the LLDP-MED reference model.

Note:

Acting as the network connectivity device, the 7210 SAS only supports the configuration of LLDP-MED communication device endpoints (Class III), such as VoIP phone, using the Network Policy TLV.

Figure 3. LLDP-MED reference model

LLDP-MED network connectivity device functions

To enable LLDP-MED network connectivity device functions, configure the config port ethernet lldp dest-mac lldp-med admin-status command. When this command is configured, the behavior of the node is as follows:

  • If admin-status is set to rx-tx, the LLDP agent transmits and receives LLDP-MED TLVs on the port. The 7210 SAS node includes the LLDP-MED Capabilities TLV and the Network Policy TLV (if configured) in the LLDP message that is generated in response to an LLDP message with the LLDP-MED Capabilities TLV received on the port.

  • If admin-status is set to disabled, the 7210 SAS ignores and does not process the LLDP-MED Capabilities TLV in the LLDP message received on the port.

Note:

The configure port ethernet lldp admin-status command must be enabled for LLDP-MED TLV processing. The admin-status configuration in the lldp context must not conflict with the admin-status configuration in the lldp-med context.

When LLDP-MED is enabled on the port, the Network Policy TLV is sent out of the port using the parameters configured for the network policy that is associated with the port.

Note:

See the 7210  SAS-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about configuring network policy parameters using commands in the config>system>lldp>lldp-med context.

LLDP-MED endpoint device move notification

The endpoint move detection notification enables VoIP management systems to track the movement of VoIP phones. On the 7210 SAS, the user has the option to generate the lldpXMedTopologyChangeDetected event on detection of movement of the endpoint device. By default, the event is disabled. To enable the event, configure the config>log>event-control lldp generate and config>port>ethernet>lldp> dest-mac>nearest-bridge>notification commands.

Modified use of TLVs defined in LLDP

LLDP-MED modifies the usage of some LLDP base TLVs for network connectivity devices. Specifically, the 7210 SAS supports the transmission of the MAC/PHY Configuration Status TLV when LLDP-MED is enabled. The transmission of this TLV is enabled using the config>port>ethernet>lldp>dest-mac>lldp-med>tx-tlvs mac-phy-config-status CLI command option.

Port loopback for Ethernet ports

7210 SAS devices support port loopback for Ethernet ports. There are two flavors of port loopback commands - port loopback without mac-swap and port loopback with mac-swap. Both these commands are helpful for testing the service configuration and measuring performance parameters such as throughput, delay, and jitter on service turn-up. Typically, a third-party external test device is used to inject packets at desired rate into the service at a central office location.

The following sections describe the port loopback functionality.

Port loopback without MAC swap

When the port loopback command is enabled, the system enables PHY/MAC loopback on the specified port. All the packets are sent out the port configured for loopback and received back by the system. On ingress to the system after the loopback, the node processes the packets as per the service configuration for the SAP.

This is recommended for use with only VLL services. This command affects all the services configured on the port, therefore the user is advised to ensure all the configuration guidelines mentioned for this feature in the command description are followed.

Port loopback with MAC swap

Note:

Port loopback with MAC swap is not supported on100GE IMM-c cards for the 7210 SAS-R6 and 7210 SAS-R12.

The 7210 SAS provides port loop back support with MAC swap. When the port loopback command is enabled, the system enables PHY/MAC loopback on the specified port. All the packets are sent out the port configured for loopback and received back by the system. On ingress to the system after the loopback, the node swaps the MAC addresses for the specified SAP and the service. It only processes packets that match the specified source MAC address and destination MAC address, while dropping packets that do not match. It processes these packets as per the service configuration for the SAP.

This is recommended for use with only VPLS and VLL services. This command affects all the services configured on the port, therefore the user is advised to ensure all the configuration guidelines mentioned for this feature in the command description are followed.

LAG

Based on the IEEE 802.3ax standard (formerly 802.3ad), Link Aggregation Groups (LAGs) can be configured to increase the bandwidth available between two network devices, depending on the number of links installed. LAG also provides redundancy when one or more links participating in the LAG fail. All physical links in a specific LAG links combine to form one logical interface.

Packet sequencing must be maintained for any specific session. The hashing algorithm deployed by Nokia routers is based on the type of traffic transported to ensure that all traffic in a flow remains in sequence while providing effective load sharing across the links in the LAG.

LAGs must be statically configured or formed dynamically with Link Aggregation Control Protocol (LACP). The optional marker protocol described in IEEE 802.3ax is not implemented. LAGs can be configured on network and access ports.

Note:

For details on LAG scale per platform, contact your Nokia technical support representative.

LAG features

This section describes hardware and software LAG capabilities.

Hardware capabilities

The LAG load sharing is executed in hardware, which provides line rate forwarding for all port types.

Software capabilities

The Nokia solution conforms to the IEEE LAG implementation, including dynamic costing and LAG port threshold features. The dynamic cost and LAG port threshold features can be enabled even if the second node is not a Nokia router.

Dynamic cost

Dynamic cost can be enabled with the config>lag dynamic-costcommand or by the action specified in the config>lag>port-threshold command.

If dynamic cost is enabled and the number of active links is greater than the port threshold value (0-7 or 0-15), depending on chassis-mode and IOM type), then the path cost is dynamically calculated whenever there is a change in the number of active links regardless of the specified port threshold action. If the port-threshold is met and the action is set to dynamic cost, then the path cost is dynamically recalculated regardless of the global dynamic cost configuration.

Enabling dynamic costing causes the physical link metrics used by OSPF to be applied based on the operational or aggregate link bandwidth in the LAG that is available at the time, providing the number of links that are up exceeds the configured LAG port threshold value. If the number of available links falls below the configured threshold, the configured threshold action determines if and at what cost this LAG will be advertised.

For example, assume a single link in OSPF has an associated cost of 100 and the LAG consists of four physical links. The cost associated with the logical link is 25. If one link fails then the cost would automatically be adjusted to 33.

If dynamic cost is not configured then costing is applied based on the total number of links configured. The cost would be calculated at 25. This will remain static provided the number of links that are up exceeds the configured LAG threshold.

LAG port threshold

The LAG port threshold feature allows configuration of the behavior, when the number of available links in a LAG falls below or is equal to the specified threshold. Two options are available:

  • If the number of links available (up) in a LAG is less than the configured threshold, then the LAG is regarded as operationally down. For example, assume a LAG consists of four physical links. The threshold is set to two and dynamic costing is not configured. If the operational links is equal to or drops below two, the link is regarded as operationally down until the number of operational links is two or more.

  • When the number of links available in a LAG is less than the configured threshold, the LAG starts using the dynamic-cost allowing other nodes to adjust their routing tables according to the revised costs. In this case, when the threshold is not crossed, a fixed metric (all links operational) is advertised.

Configuring LAGs

The following are guidelines for configuring LAGs:

  • Ports can be added or removed from the LAG while the LAG and its ports (other than the port being removed) remain operational. When ports to or from the LAG are added or removed, the hashing algorithm is adjusted for the new port count.

  • The show commands display physical port statistics on a port-by-port basis or the entire LAG can be displayed.

  • LAG is supported on Ethernet ports.

  • Ports of a particular LAG can be of different types but they must be the same speed and duplex. To guarantee the same port speed is used for all ports in a LAG, auto-negotiation must be disabled or in limited mode to ensure only a specific speed is advertised.

The following figure shows traffic routed between ALA-1 and ALA-2 as a LAG consisting of four ports.

Figure 4. LAG configuration

LAG on access

Link Aggregation Groups (LAG) is supported on access ports and access-uplink ports. This is treated the same as LAG on network ports which provides a standard method to aggregate Ethernet links. The difference lies in how QoS is handled.

LAG and QoS policies on 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE

In the 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE an ingress QoS policy is applied to the aggregate traffic that is received on all the member ports of the LAG. For example, if an ingress policy is configured with a policer of PIR 100 Mbps, for a SAP configured on a LAG with two ports, then the policer limits the traffic received through the two ports to a maximum of 100 Mbps.

In the 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE an egress QoS policy parameters are applied to all the ports that are members of the LAG (all ports get the full SLA). For example, if an egress policy is configured with a queue shaper rate of PIR 100 Mbps, and applied to an access-uplink or access LAG configured with two port members, then each port would send out 100 Mbps of traffic for a total of 200 Mbps of traffic out of the LAG. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that, a single flow can use the entire SLA. The disadvantage is that, the overall SLA can be exceeded if the flows span multiple ports.

LAG and QoS policies on 7210 SAS-Mxp

In 7210 SAS-Mxp, a SAP ingress QoS policy or network port ingress QoS policy or network IP interface ingress QoS policy is applied to the aggregate traffic that enters the traffic through all the ports of the system. For example, if an ingress policy is configured with a policer of PIR 100 Mbps, for a SAP configured on a LAG with two ports, then the policer limits the traffic entering the system through the two ports to a maximum of 100 Mbps.

In 7210 SAS-Mxp, SAP egress QoS policy shaper parameters are applied to all the ports that are members of the LAG (all ports get the full SLA). For example, if an SAP egress policy is configured with a shaper of PIR 100 Mbps, each port would get a PIR of 100 Mbps. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that, a single flow can uses the entire SLA. The disadvantage is that the overall SLA can be exceeded if the flows span multiple ports.

In 7210 SAS-Mxp, network port egress QoS policy shaper parameters are applied to all the ports that are members of the LAG (all ports get the full SLA). For example, if an network port egress policy is configured with a shaper of PIR 100 Mbps, each port would get a PIR of 100 Mbps. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that, a single flow can uses the entire SLA. The disadvantage is that the overall SLA can be exceeded if the flows span multiple ports.

In 7210 SAS-Mxp, when operating in port-based queuing mode, the access egress QoS policy is applied to access ports and the policy parameters are applied to all the ports that are members of the LAG (all access ports get the full SLA). For example, if an access egress policy is configured with a shaper of PIR 100 Mbps, each port gets a PIR of 100 Mbps. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that a single flow can use the entire SLA. The disadvantage is that the overall SLA can be exceeded if the flows span multiple ports. Access egress policy override parameters configured for the primary port of the LAG are applied to all the member ports of the LAG.

LAG and QoS policies on 7210 SAS-R6 and 7210 SAS-R12

In 7210 SAS-R6 and 7210 SAS-R12, a SAP ingress QoS policy or network port ingress QoS policy or network IP interface ingress QoS policy is applied to the aggregate traffic that enters through all the ports on a IMM. If the LAG has member ports on different IMMs, then the policy is created for each IMM and is applied to the aggregate traffic that enters through all the ports on a specific IMM. For example, if an ingress policy is configured with a policer of PIR 100 Mbps, for a SAP configured on a LAG with two ports, then the policer limits the traffic entering through the two ports of the IMM to a maximum of 100 Mbps. If the LAG has two ports on 2 different IMMs, then policy is applied each IMM individually, and the policer on each IMM allows a maximum of 100 Mbps for a total of 200 Mbps.

In 7210 SAS-R6 and 7210 SAS-R12, SAP egress QoS policy shaper parameters are applied to all the ports that are members of the LAG (all ports get the full SLA), irrespective of whether they are located on a single IMM or two different IMMs. For example, if an SAP egress policy is configured with a shaper of PIR 100 Mbps, each port would get a PIR of 100 Mbps. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that, a single flow can uses the entire SLA. The disadvantage is that the overall SLA can be exceeded if the flows span multiple ports.

In 7210 SAS-R6 and 7210 SAS-R12, network port egress QoS policy shaper parameters are applied to all the ports that are members of the LAG (all ports get the full SLA), irrespective of whether they are located on a single IMM or two different IMMs. For example, if an network port egress policy is configured with a shaper of PIR 100 Mbps, each port would get a PIR of 100 Mbps. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that, a single flow can uses the entire SLA. The disadvantage is that the overall SLA can be exceeded if the flows span multiple ports.

In 7210 SAS-R6 and 7210 SAS-R12, when operating in port-based queuing mode, the access egress QoS policy is applied to access ports and the policy parameters are applied to all the ports that are members of the LAG (all access ports get the full SLA). For example, if an access egress policy is configured with a shaper of PIR 100 Mbps, each port gets a PIR of 100 Mbps. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that a single flow can use the entire SLA. The disadvantage is that the overall SLA can be exceeded if the flows span multiple ports. Access egress policy override parameters configured for the primary port of the LAG are applied to all the member ports of the LAG.

Port link damping

Hold time controls enable port link damping timers that reduce the number of link transitions reported to upper layer protocols.

The 7210 SAS OS port link damping feature guards against excessive port transitions. Any initial port transition is immediately advertised to upper layer protocols, but any subsequent port transitions are not advertised to upper layer protocols until a configured timer has expired.

An ‟up” timer controls the dampening timer for link up transitions, and a ‟down” timer controls the dampening timer for link down transitions.

LACP

Generally, link aggregation is used for two purposes: provide an increase in bandwidth and provide redundancy. Both aspects are addressed by aggregating several Ethernet links in a single LAG.

Under normal operation, all non-failing links in a specific LAG will become active and traffic is load balanced across all active links. In some circumstances, however, this is not wanted. Instead, it may be wanted that only some of the links are active and the other links be kept in stand-by condition.

LACP enhancements allow active lag-member selection based on particular constrains. The mechanism is based on the IEEE 802.3ax standard so interoperability is ensured.

Active-standby LAG operation without LACP

Active/standby LAG is used to provide redundancy while keeping consistency of QOS enforcement. Some devices do not support LACP and therefore an alternative solution is required.

The active/standby decision for LAG member links is local decision driven by preconfigured selection-criteria. This decision was communicated to remote system using LACP signaling.

As an alternative, the operator can disable the signal transmitted by using the power-off option for standby-signaling in the CLI command at the LAG level at the port member level. The transmit laser is switched off for all LAG members in standby mode. On switch over (active-links failed), the laser is switched on and all LAG members become active.

Note:

This mode of operation cannot detect physical failures on the standby link, which means that the network operator cannot be certain that the standby links are capable to take over in case of active-links failure. This is an inherent limitation of this operational mode.

When LACP goes down on a standby link, a warning message announcing that LACP has expired on the corresponding member port is printed in log 99 at the other end.

The operation where standby ports are powered down is mutually exclusive with LACP and, therefore, is modeled as a separate mode of LACP operation of power-off. For this mode, the best-port selection criteria can be used. This criteria ensures that a subgroup with the best-port (the highest priority port) is always chosen to be used as the active subgroup.

It is not possible to have an active LACP in the power-off mode before the correct selection criteria is selected.

LAG subgroups

LACP is used to make a selection of active links predictable and compatible with any vendor equipment. See IEEE STD 802.3-2002, Section 3, Clause 43.6.1, which describes how LACP allows standby and active signaling.

The 7210 SAS-T, 7210 SAS-R6, 7210 SAS-R6, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode), and 7210 SAS-Sx 10/100GE (operating in standalone mode) implementation of LACP supports the following:

  • A specific LAG member can be assigned to subgroups. The selection algorithm then assures that only members of a single subgroup are selected as active links.

  • The selection algorithm is effective only if LACP is enabled on a specific LAG. At the same time, it is assumed that the connected system also has LACP enabled (active or passive mode).

  • The algorithm selects active links based on following criteria:

    • Depending on the selection-criteria settings either the subgroup with the highest number of eligible links or the subgroup with the highest aggregate weight of all eligible members is selected first.

    • If multiple groups satisfy the selection criteria, the currently active subgroup remains active. Initially, the subgroup containing the highest priority eligible link is selected.

    • Only links pertaining to a single subgroup are active at any time.

    • An eligible member refers to a LAG member link that can potentially become active; that is, it is operationally up. If the slave-to-partner flag is set, the remote system does not disable its use (by signaling the ‟Standby” bit using LACP).

  • The selection algorithm works in a reverting mode. Each time the configuration or status of any link in a LAG changes, the selection algorithm is rerun. In case of a tie between two groups (one of them being currently active), the active group remains active (no reverting).

LAG and ECMP hashing

Note:

See the 7210 SAS-Mxp, R6, R12, S, Sx, T Router Configuration Guide for more information about ECMP support for 7210 SAS platforms.

When a requirement exists to increase the available bandwidth for a logical link that exceeds the physical bandwidth or add redundancy for a physical link, typically one of the methods is applied; equal cost multi-path (ECMP) or LAG. A 7210 SAS can deploy both at the same time, meaning, using ECMP of two or more LAGs or single links.The Nokia implementation supports per flow hashing used to achieve uniform loadspreading and per service hashing designed to provide consistent per service forwarding. Depending on the type of traffic that needs to be distributed into an ECMP or a LAG, different variables are used as input to the hashing algorithm.

An option is provided per LAG to select the hashing function to be used for load-balancing flows on the member ports of the LAG. Users can use one of the available options based on the flows they have in their network and select an option that helps improve the load-balancing of flows in their network. The packets fields selected by the hashing function is different for some flows with the two hashing functions and is provided in the following tables.

LAG hashing for the 7210 SAS-T (network mode)

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-T in network mode.

Note:

The following notes apply to LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-T configured in the network operating mode.

  • In the case of LSR, incoming labels are used for hashing.

  • The term ‟learned” corresponds to destination MAC.

  • The term ‟source and destination MAC” refers to customer source and destination MACs unless otherwise specified.

Table 6. LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-T configured in the network operating mode

Traffic type

Hashing options

Packet fields used

Hash-1

Hash-2

BDA

BSA

CDA

CSA

EtherType

Ingress Port-ID

ISID

MPLS label stack

Source and destination

VLAN

MAC

IP

L4 ports

VPLS service

SAP to SAP

IP traffic (learned)

IP traffic (unlearned)

PBB traffic (learned)

PBB traffic (unlearned)

MPLS traffic (learned)

8

9

MPLS traffic (unlearned)

9

9

Non-IP traffic (learned)

Non-IP traffic (unlearned)

VPLS service

SAP to SDP

IP traffic (learned)

IP traffic (unlearned)

PBB traffic (learned)

PBB traffic (unlearned)

MPLS traffic (learned)

9

MPLS traffic (unlearned)

9

9

Non-IP traffic (learned)

Non-IP traffic (unlearned)

VPLS service

SDP to SAP

IP traffic (learned)

10

PBB traffic (learned)

10

Non-IP traffic (learned)

10

All traffic (learned)

10

All traffic (unlearned)

10

10

VPLS service

SDP to SDP

All traffic (learned)

10

10

All traffic (unlearned)

10

10

Epipe service

SAP to SAP

IP traffic

PBB traffic

MPLS traffic

8

9

Non-IP traffic

Epipe service

SAP to SDP

IP traffic

PBB traffic

MPLS traffic

9

Non-IP traffic

Epipe service

SDP to SAP

IP traffic

10

PBB traffic

10

Non-IP traffic

10

All traffic

10

MPLS – LSR

All traffic

8

9

11

PBB VPLS service

B-SAP to B-SAP (PBB BCB traffic)

IP traffic (learned)

IP traffic (unlearned)

L2 and non-IP traffic (learned)

L2 and non-IP traffic (unlearned)

PBB VPLS service

I-SAP to B-SAP (originating PBB BEB traffic)

IP traffic (learned)

IP traffic (unlearned)

L2 and non-IP traffic (learned)

L2 and non-IP traffic (unlearned)

PBB VPLS service

B-SAP to I-SAP (terminating PBB BEB traffic)

IP traffic (learned)

IP traffic (unlearned)

L2 and non-IP traffic (learned)

L2 and non-IP traffic (unlearned)

PBB Epipe service

PBB Epipe I-SAP to B-SAP (originating PBB BEB traffic)

IP traffic

L2 and non-IP traffic

PBB Epipe service

PBB Epipe SAP to B-SAP (terminating PBB BEB traffic)

IP traffic

L2 and non-IP traffic

VPRN service

SAP to SAP

SAP to SDP

SDP to SAP

IES service (IPv4)

IES SAP to IES SAP

IES service (IPv4)

IES SAP to IPv4 network port interface

Network port IPv4 interface

IPv4 network interface to IPv4 network interface

Network port IPv6 interface

IPv6 network interface to IPv6 network interface

12

12

LAG hashing for the 7210 SAS-T (access-uplink mode)

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-T in access-uplink mode.

Note:

The following notes apply to LAG hashing algorithm for services configured on the 7210 SAS-T in the access-uplink operating mode:

  • The term ‟Learned” corresponds to destination MAC.

  • Source/destination MAC refers to customer source/destination MACs unless otherwise specified.

  • VLAN ID is considered for Learned - PBB, MPLS, Non-IP traffic in VPLS service only for traffic ingressing at dot1q, Q.*, Q1.Q2 SAPs.

  • Only outer VLAN tag is used for hashing.

Table 7. LAG hashing algorithm for services configured on the 7210 SAS-T in the access-uplink operating mode

Traffic type

Packet fields used

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and destination

VLAN

MAC

IP

L4 Ports

VPLS service

SAP to SAP

IP traffic (learned)

IP traffic (unlearned)

PBB traffic (learned)

PBB traffic (unlearned)

MPLS traffic (learned)

13

IP MPLS traffic (unlearned)

14

L2 MPLS traffic (unlearned)

14

Non-IP traffic (learned)

Non-IP traffic (unlearned)

Epipe service

SAP to SAP

IP traffic

PBB traffic

IP MPLS traffic

14

L2 MPLS traffic

14

Non-IP traffic

IES service (IPv4)

IES SAP to IES SAP

IPv4 unicast traffic

LAG Hashing for the 7210 SAS-R6 and 7210 SAS-R12

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-R6 and 7210 SAS-R12.

Note:

The following notes apply to LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-R6 and 7210 SAS-R12:

  • The term ‟service_id” refers to the service ID of the egressing VPLS, Epipe, IES, or VPRN service.

  • The term ‟lag_index” refers to the Lag-IfIndex of the egressing lag.

  • the terms ‟encap_value” and ‟service_vlan” are based on the inner and outer VLAN values of the egressing LAG SAP.

  • The term ‟sap_index” is a value assigned uniquely for each SAP internally.

  • Parameters used for LAG hashing are the same in both SAP egress queue mode (SAP-based egress scheduling) or port egress queue mode (port-based egress scheduling), unless otherwise specified.

  • The term ‟learned” corresponds to the destination MAC.

  • The term ‟source and destination MAC” refers to customer source and destination MACs, unless otherwise specified.

  • In the case of a LAG with two ports at egress, different ingress port IDs may result in the same hash index, which causes traffic to always get hashed to only one of the ports. Load balancing is expected to occur when there are more than 2 ports in the lag.

  • The term ‟mgid” is the multicast group ID and is a software-allocated number. A unique number is allocated for each Layer-2 multicast MAC address.

  • The 7210 SAS supports Layer-2 multicast in a VPLS service. A group of 32 multicast IP addresses map to a single Layer-2 multicast MAC address. The ‟mgid” parameter remains the same for all IP multicast addresses that map to the same Layer-2 multicast MAC address.

Table 8. LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-R6 and 7210 SAS-R12

Traffic type

Hashing options

Packet fields used

Hash-1 Version 1

Hash-1 Version 2

Hash-2

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and destination

VLAN

MAC

IP

L4 Ports

VPLS service

SAP to SAP

IP traffic (learned)

PBB traffic (learned)

MPLS traffic (learned)

15

15

16

Non-IP traffic (learned)

All traffic (unlearned)

See note 17

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

VPLS service

SAP to SDP

IP traffic (learned)

IP traffic (unlearned)

PBB traffic (learned)

PBB traffic (unlearned)

MPLS traffic (learned)

16

18

MPLS traffic (unlearned)

16

18

16

18

16

18

Non-IP traffic (learned)

Non-IP traffic (unlearned)

VPLS service

SDP to SAP

IP traffic (learned)

16

All traffic, excluding IP traffic (learned)

19

19

All traffic (learned)

19

All traffic (unlearned)

See note 17

 

 

 

 

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

VPLS service

SDP to SDP

All traffic (learned)

19

19

19

All traffic (unlearned)

19

19

19

Epipe service

SAP to SAP

IP traffic

PBB traffic

MPLS traffic

15

15

16

Non-IP traffic

Epipe service

SAP to SDP

IP traffic

PBB traffic

MPLS traffic

16

18

Non-IP traffic

Epipe service

SDP to SAP

IP traffic

16

All other traffic

19

19

All traffic

19

MPLS – LSR

All traffic

15

15

20

21

VPLS (Multicast traffic with IGMP snooping enabled)

SAP to SAP

SDP to SAP

See note 22

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

VPRN service

SAP to SAP

SAP to SDP

SDP to SAP

IES service (IPv4)

IES SAP to IES SAP

IES service (IPv4)

IES SAP to IPv4 network port interface

Network port IPv4 interface

IPv4 network interface to IPv4 network interface

Network port IPv6 interface

IPv6 network interface to IPv6 network interface

23

23

23

LAG hashing for the 7210 SAS-Mxp

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-Mxp.

Note:

The following notes apply to LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-Mxp :

  • In the case of LSR, incoming labels are used for hashing.

  • The term ‟learned” corresponds to the destination MAC.

  • The term ‟source and destination MAC” refers to customer source and destination MACs unless otherwise specified.

  • The term ‟service_id” refers to the service ID of the egressing VPLS, Epipe, IES, or VPRN service.

  • The term ‟lag_index” refers to the Lag-IfIndex of the egressing lag.

  • The terms ‟encap_value” and ‟service_vlan” are based on the inner/outer VLAN values of the egressing LAG SAP.

  • The term ‟sap_index” is a value assigned uniquely for each SAP internally.

  • Parameters used for LAG hashing are the same in both SAP egress queue mode (SAP-based egress scheduling) or port egress queue mode (port-based egress scheduling mode), unless otherwise specified previously.

  • The term ‟mgid” is the multicast group ID and is a software-allocated number. A unique number is allocated for each Layer-2 multicast MAC address.

  • The 7210 SAS supports Layer-2 multicast in a VPLS service. A group of 32 multicast IP addresses map to a single Layer-2 multicast MAC address. The ‟mgid” parameter remains the same for all IP multicast addresses that map to the same Layer-2 multicast MAC address.

Table 9. LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-Mxp

Traffic type

Hashing options

Packet fields used

Hash-1 Version 1

Hash-1 Version 2

Hash-2

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and destination

VLAN

MAC

IP

L4 Ports

VPLS and Epipe services

SAP to SAP

IP traffic (VPLS learned and Epipe; port-based egress scheduling)

MPLS traffic (VPLS learned and Epipe; port-based egress scheduling)

24

Non-IP traffic (VPLS learned and Epipe; port-based egress scheduling)

All traffic (learned and unlearned; SAP-based egress scheduling)

See note 25

 

 

 

All traffic (VPLS unlearned; port-based egress scheduling)

See note 25

 

 

 

VPLS service

SAP to SDP

IP traffic (learned; SAP-based and port-based egress sheduling)

IP traffic (unlearned; SAP-based and port-based egress sheduling)

MPLS traffic (learned; SAP-based and port-based egress sheduling)

24

MPLS traffic (unlearned; SAP-based and port-based egress sheduling)

24

24

24

Non-IP traffic (learned; SAP-based and port-based egress sheduling)

Non-IP traffic (unlearned; SAP-based and port-based egress sheduling)

Epipe service

SAP to SDP

IP traffic (SAP-based and port-based egress sheduling)

MPLS traffic (SAP-based and port-based egress sheduling)

24

Non-IP traffic (SAP-based and port-based egress sheduling)

VPLS and Epipe services

SDP to SAP

All traffic (including VPLS learned and unlearned; SAP-based egress scheduling)

See note 25

 

 

 

All traffic (VPLS unlearned; port-based egress scheduling)

See note 25

 

 

 

All other traffic (VPLS learned and Epipe; port-based egress scheduling)

26

26

VPLS service

SDP to SDP

All traffic (learned; SAP-based and port-based egress sheduling)

26

26

26

All traffic (unlearned; SAP-based and port-based egress sheduling)

26

26

26

MPLS – LSR

All traffic (SAP-based and port-based egress sheduling)

26

26

27

28

VPLS (Multicast traffic with IGMP snooping enabled)

SAP to SAP

SDP to SAP

— (SAP-based and port-based egress sheduling)

See note 29

 

 

 

VPRN service

SAP to SAP

SDP to SAP

All traffic

(SAP-based egress scheduling)

See note 25

 

 

 

All traffic (Port-based egress scheduling)

VPRN service

SAP to SDP

All traffic (SAP-based and port-based egress sheduling)

IES service (IPv4)

IES SAP to IES SAP

All traffic

(SAP-based egress scheduling)

See note 25

 

 

 

All traffic (Port-based egress scheduling)

IES service (IPv4)

IES SAP to IPv4 network port interface

— (SAP-based and port-based egress sheduling)

Network port IPv4 interface

IPv4 network interface to IPv4 network interface

— (SAP-based and port-based egress sheduling)

Network port IPv6 interface

IPv6 network interface to IPv6 network interface

— (SAP-based and port-based egress sheduling)

LAG hashing algorithm for the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE in standalone and standalone-VC mode

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE operating in the standalone and standalone-VC modes.

Note:

The following terms are use in LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE in standalone and standalone-VC Mode:

  • The term ‟learned” corresponds to the destination MAC.

  • The term ‟source and destination MAC” refers to the customer source and destination MACs unless otherwise specified.

Table 10. LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE in standalone and standalone-VC Mode

Traffic type

Hashing options

Packet fields used

Hash-1 Version 1

Hash-1 Version 2

Hash-2

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and destination

VLAN

MAC

IP

L4 Ports

VPLS service

SAP to SAP

IP traffic (learned)

IP traffic (unlearned)

PBB traffic (learned)

PBB traffic (unlearned)

MPLS traffic (learned)

30

30

31

32

MPLS traffic (unlearned)

31

32

31

32

31

32

Non-IP traffic (learned)

Non-IP traffic (unlearned)

Epipe service

SAP to SAP

IP traffic

PBB traffic

MPLS traffic

30

30

31

32

Non-IP traffic

VPLS service

SAP to SDP

IP traffic (learned)