2. 7210 SAS Interfaces

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

2.1. 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-M platform and its variants (7210 SAS-M 24F, 7210 SAS-M 24F 2XFP, 7210 SAS-M 24F 2XFP ETR) provide a fixed port configuration and an additional expansion slot that accepts supported MDAs.

7210 SAS software inherits the concept for CPM, IOM, and MDA from the SR OS to represent the hardware logically. 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 two MDAs.

One MDA is a non-removable logical entity and represents the fixed ports available on the platform. The MDA is preprovisioned on bootup.
The other MDA represents the physical removable MDA that is plugged into the available expansion slot and provisioned by the user depending on the MDA they plan to use. See Provisioning of MDAs on the 7210 SAS-M for more information about provisioning MDAs for the expansion slot on the 7210 SAS-M.

Ports and interfaces can also be preprovisioned.

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.

2.1.1. Chassis Slots and Cards

The 7210 SAS-M and its variants are platforms which has a set of fixed ports and supports one expansion slot. Software preprovisions the cards on bootup. The expansion slot is represented as a MDA and supported MDAs can be plugged into the expansion slot. The list of MDAs supported on 7210 SAS-M is available in the 7210 SAS release notes.

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

A:7210# show card state

===============================================================================

Card State

===============================================================================

Slot/ Provisioned Equipped Admin Operational Num Num Comments

Id Type Type State State Ports MDA

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

1 iom-sas iom-sas up up 2

1/1 m24-1gb+2-10gb m24-1gb+2-10gb up up 24

1/2 m4-ds1-ces m4-ds1-ces up up 4

A sfm-sas sfm-sas up up Active

The 7210 SAS-T, 7210 SAS-Mxp, and 7210 SAS-Sx/S 1/10GE 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:

IMMv1 (imm-sas-r) cannot be installed in the same 7210 SAS-R6 chassis as IMMv2 (imm-sas-r-b) cards or IMM-c (imm-sas-r-c) cards. A mix of IMMv1 and any other type of card is not supported.
IMMv1 cards are not supported on 7210 SAS-R12. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information.
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. Refer to the config>system>chassis>allow-imm-family command in the 7210 SAS-M, T, R6, R12, Mxp, Sx, S 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

2.2. 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.

On 7210 SAS-M, as described in the previous section, in addition to the fixed ports, a expansion slot is available. It is represented as a physical MDA and needs to be provisioned. The following section talks about provisioning of MDAs and is applicable only to those platforms where physical MDAs are supported.

A chassis slot and card type must be specified and provisioned before an MDA can be preprovisioned. An MDA is provisioned when a type designated from the allowed MDA types is inserted. A preprovisioned MDA slot can remain empty without conflicting with populated slots. After installed and enabled, the system verifies that the installed MDA type matches the configured parameters. If the parameters do not match, the MDA remains offline. An MDA is provisioned when a type designated from the allowed MDA type is inserted. A preprovisioned MDA slot can remain empty without conflicting with the populated slots.

2.2.1. Provisioning of MDAs on the 7210 SAS-M

This section describes MDA provisioning.

2.2.1.1. Provisioning Guidelines for MDA used with 7210 SAS-M

The device rejects the insertion of a CES card if the slot is provisioned for a 2* 10G MDA and vice versa.
If a 2*10G MDA provisioned, it ensures that the BOF parameter "no-service-ports" is configured to specify two ethernet ports.
Only on 7210 SAS-M 24F variant, the no-service-ports BOF parameter is not available for use.
Change of value assigned to 'use-expansion-card-type' BOF parameter, requires a reboot so that a different MDA type can be used.

2.2.1.2. Provisioning 2 x 10G MDA and 4 x T1/E1 CES MDA on 7210 SAS-M

For 7210 SAS-M devices currently deployed or new deployments, to insert 2*10 MDA perform the following steps:

Configure the BOF parameter "use-expansion-card-type" to m2-xfp. This provisions the system to expect a 2 x 10G MDA for use in the expansion slot.
Configure the BOF parameter "no-service-ports", if using a 7210 SAS-M 24F 2XFP and 7210 SAS-M 24F 2XFP ETR variants.
Reboot the device.
The preceding steps are required for first-time use of 2 x 10G MDA or when changing the MDA type in use. It is not needed, if a MDA is being replaced with a MDA of the same type.

In 7210 SAS devices using 2 x 10G MDA, to insert CES MDA perform the following steps:

Configure the BOF parameter "use-expansion-card-type" to m4-ds1-ces. This will provision the system to expect a 4 x T1/E1 CES MDA for use in the expansion slot.
Configure the BOF parameter "no-service-ports" to default, if using a 7210 SAS-M 24F 2XFP and 7210 SAS-M 24F 2XFP ETR variants.
Reboot the device.
The preceding steps are required when changing the MDA type in use. It is not needed, if a MDA is being replaced with a MDA of the same type.

Note:

Insertion and removal of the CES MDA into the chassis at any point of time is only supported if the BOF parameter configuration is set to default.

2.3. Digital Diagnostics Monitoring

Some Nokia SFP and XFP transponders have Digital Diagnostics Monitoring (DDM) capability. With DDM the transceiver module maintains information about its working status in device registers, such as:

Temperature
Supply voltage
Transmit (TX) bias current
TX output power
Received (RX) optical power

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.

There are no CLI commands required for 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.

Table 5 describes supported real-time DDM features.

Table 5: 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

Table 6 describes supported factory-programmed DDM alarms and warnings.

Table 6: 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

2.3.1. Nokia SFPs and XFPs

The availability of the DDM real-time information and warning or alarm status is based on the transceiver. It may or may not indicate if DDM is supported, although some Nokia SFPs support DDM. Non-DDM and DDM-supported SFPs are distinguished by a specific ICS value.

For Nokia SFPs that do not indicate DDM support in the ICS value, DDM data is available although the accuracy of the information has not been validated or verified.

For non-Nokia transceivers, DDM information may be displayed, but Nokia is not responsible for formatting, accuracy, etc.

2.3.2. 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!
===============================================================================

2.4. Ports

This section describes 7210 SAS ports.

2.4.1. Port Types

Table 7 describes the port types supported on the 7210 SAS platforms.

Table 7: Supported Ethernet Ports and TDM Port Types

7210 SAS Platform	Fixed Copper Ports (10/100/1000 Base-T)	Ethernet SFP Ports	10 Gigabit XFP/SFP+ Ports	100 Gigabit CFP4/QSFP28 Ports	TDM Ports (DS1/E1)
7210 SAS-M		✓	✓ 1		✓ 2
7210 SAS-M 24F 2XFP		✓	✓ 3		✓ 2
7210 SAS-M 24F 2XFP ETR		✓	✓ 3		✓ 2
7210 SAS-T	✓	✓	✓ 3
7210 SAS-R6	✓ 4	✓	✓ 5, 6	✓
7210 SAS-R12	✓ 4	✓	✓ 6	✓
7210 SAS-Mxp	✓	✓	✓ 7
7210 SAS-Sx/S 1/10GE	✓	✓	✓ 7
7210 SAS-Sx 10/100GE	✓ 7	✓ 7	✓ 7	✓

Notes:

with 2 x 10G/XFP MDA
only in network mode and with CES MDA
XFP
IMMv2 with copper ports
IMMv1 (XFP)
IMMv2 (SFP+)
SFP+

The following support guidelines apply to the port types described in Table 7.

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-M, 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 are supported only on the 7210 SAS-M and 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 with full-duplex mode. They do not support speeds of 10 Mb/s with half-duplex mode.
Combo ports on the 7210 SAS-Mxp and 7210 SAS-Sx 1/10GE support speeds of 10 Mbps 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 Mbps with full-duplex mode. They do not support 10 Mbps speed with half-duplex mode.
Fixed copper ports on the 7210 SAS-T support 10 Mbps speed 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 combo port using the config>port>ethernet>connection-type command. By default, the combo 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”.
For TDM ports, only CES services (CESoPSN-based and SAToP-based) are supported for the T1/E1 ports.
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).

2.4.1.1. 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 and/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 since 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.

Table 8 describes the port modes that are supported on each 7210 SAS platform.

Table 8: 7210 SAS Platforms Supporting Port Modes

Port Mode Platforms	Access	Network	Hybrid	Access-uplink
7210 SAS-M	Yes	Yes 1	Yes 2	Yes 3
7210 SAS-T	Yes	Yes 1	Yes 2	Yes 3
7210 SAS-R6 IMM (IMMv1) and 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

Notes:

Network ports can be configured only if the BOF is configured to operate the node in network mode (also known as, MPLS mode).
Hybrid ports are supported only when the node is operating in network mode.
Access-uplink ports can be configured only if the BOF is configured to operate the node in access-uplink mode (also known as, L2 mode).

2.4.1.2. 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.

2.4.1.3. 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).

2.4.2. Support for Power over Ethernet (PoE) on 7210 SAS-T ETR Variant and 7210 SAS-Mxp ETR Variant

The 7210 SAS-T ETR unit and 7210 SAS-Mxp ETR unit supports Power over Ethernet (PoE) as per 802.3af and 802.3at standards. It allows these devices to be used to supply power to connected PoE devices, such as telephones, CCTV cameras, and other PoE standard compliant devices.

Note:

On 7210 SAS-T ETR, up to four fixed copper ports are available to connect PoE/PoE+ devices. It can supply a maximum of up to 60W of power.
On 7210 SAS-Mxp ETR unit, up to 2 ports are available to connect PoE/PoE+ devices. It can supply a maximum of up to 60W of power.
On both 7210 SAS-T ETR and 7210 SAS-Mxp ETR, the maximum amount of power available is to be shared among all the PoE/PoE+ devices connected to the node. That is, it is possible to have a mix of PoE devices (using 15W of power) and PoE+ devices (using 30W of power) as long as the total power drawn is within the system limits.

The following functionalities are available:

Supports both 802.3af (PoE) and 802.3at (PoE+) on any of the ports. The ports can be used to connect either PoE devices or PoE+ devices or a combination of both simultaneously, as long as the power drawn is within the device system limits.
Only Alternative A is supported on the supported 7210 SAS devices.
Supports classification of both Type 1 and Type 2 PD using physical layer classification mechanism (using 1-event physical layer classification mechanism for Type 1 PD and 2-event physical layer classification mechanism for Type 2 PD).
Supports allocation of power based on the identified class (called as class-based power allocation method) using physical layer classification mechanism. The 802.3af and 802.3at standards define the power that can be allocated or requested by a particular class. There are four classes defined - Class 1, Class 2, Class 3 and Class 4 by standards. These are used to allow PoE devices to request power based on their needs. If enough power is not available to supply power based on the identified class, then power is denied to the connected PoE device. Each device has limit on the maximum amount of power it can provide. If the total of power requested by the devices connected to PoE enabled ports exceed this threshold, then the device denies power to the device. When power is denied to the PD, the port is operationally up, though power is not supplied to the port. If the power is applied successfully or power is denied to the port, the system logs an event.
Only DC power is supplied to connected PoE devices (PDs). It works with PoE devices that use injectors where a AC/DC wall device is used to power a remote PoE device.
The software monitors the PoE port and detect faults and events and raises traps, along with displaying the same in the status of the port. Events and faults detected and notified to the user are:
1. Supplying power event – This event is generated when power is supplied to a connected PoE device after successful detection and classification.
2. Denied power event – This event is generated when power is denied to a connected PoE device after successful detection and classification.
3. Disconnect event – This event is generated when a connected PoE device is disconnected from the port and, stops drawing power from the node.
4. Fault events are generated for events such as overload, short-circuit, and other events. Software clears the fault when the fault no longer exists.
If a port enabled for PoE is shutdown, then the power supplied to the port is disabled. It restores when the no shutdown command is executed, if the request does not exceed the power budget.

2.4.3. Support for PoE/PoE+ for 7210 SAS-Sx 1/10GE Fiber Variants

Note:

PoE on the 7210 SAS-Sx 1/10GE is only supported in standalone mode.

On the 24-port and 48-port fiber variants of the 7210 SAS-Sx 1/10GE, there are two PoE/PoE+ capable ports, namely, 1/1/1 and 1/1/2, the combo ports. To use PoE/PoE+, these ports must be configured to use the copper interface. The two PoE/PoE+ ports cannot draw more than 60W of power. The ports can be used for either PoE or PoE+ devices or a combination of PoE/PoE+ devices.

2.4.4. Support for PoE/PoE+ for 7210 SAS-Sx 1/10GE Copper PoE Variant

Note:

PoE on the 7210 SAS-Sx 1/10GE is only supported in standalone mode.

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

24Tp 4SFP+ PoE
48Tp 4SFP+ PoE

Both variants support PoE/PoE+ on all the fixed copper ports. For both variants, the ports can draw a maximum of 720 W of power. On the 24-port variant, each port can have up to 15 W of power for PoE or up to 25 W of power for PoE+. On the 48-port variant, each port can have up to 15 W of power for PoE or up to 25 W of power for PoE+, or a combination of PoE and PoE+ ports as long as the total draw across all ports does not exceed 720 W.

2.4.5. Support for PoE/PoE+ for 7210 SAS-S 1/10GE Copper PoE Variant

Note:

PoE on the 7210 SAS-S 1/10GE is only supported in standalone mode.

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

24Tp 4SFP+ AC PoE
48Tp 4SFP+ AC PoE

2.5. 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.

Figure 1 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.

Figure 2 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 Figure 2 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

2.5.1. 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.

2.5.2. 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.

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

Table 9: 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.

2.5.3. 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 additional 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

2.5.3.1. 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).

Figure 3 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

2.5.3.2. 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:

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

2.5.3.3. 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.

2.5.3.4. 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.

2.6. 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.

2.6.1. 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.

2.6.2. 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.

2.7. 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 in the event that 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.

2.7.1. LAG Features

This section describes hardware and software LAG capabilities.

2.7.1.1. Hardware Capabilities

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

2.7.1.2. 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.

2.7.1.2.1. Dynamic Cost

Dynamic cost can be enabled with the config>lag dynamic-cost command 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.

2.7.1.2.2. 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.

2.7.2. 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 and/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.

Figure 4 shows traffic routed between ALA-1 and ALA-2 as a LAG consisting of four ports.

Figure 4: LAG Configuration

2.7.3. 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.

2.7.4. LAG and QoS Policies on 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE

In the 7210 SAS-M, 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-M, 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.

2.7.5. 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.

2.7.6. 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.

2.7.7. 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.

2.7.8. LACP

Generally, link aggregation is used for two purposes: provide an increase in bandwidth and/or 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 desirable. Instead, it desired 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.

2.7.8.1. 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 power-off option for standby-signaling in the CLI command at the LAG level at the port member level. As a consequence, the transmit laser will be switched off for all LAG members in standby mode. On switch over (active-links failed) the laser will be switched on all LAG members will become active.

Note that 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 inherit 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 on the other end.

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

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

2.7.8.2. LAG Sub-groups

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

The 7210 SAS-M, 7210 SAS-T, 7210 SAS-R6, 7210 SAS-R6, and 7210 SAS-Mxp implementation of LACP supports the following:

A specific LAG member can be assigned to sub-groups. The selection algorithm then assures that only members of a single sub-group 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 connected system has also LACP enabled (active or passive mode).
The algorithm will select active links based on following criteria:
1. Depending on selection-criteria setting either the sub-group with the highest number of eligible links or the sub-group with the highest aggregate weight of all eligible members is selected first.
2. If multiple groups satisfy the selection criteria, the sub-group being currently active remains active. Initially, the sub-group containing the highest priority eligible link is selected.
3. Only links pertaining to a single sub-group are active at any time.
4. An eligible member refers to a LAG member link which can potentially become active. This means it is operationally up, and if the slave-to-partner flag is set, the remote system did not disable its use (by signaling stand-by).
The selection algorithm works in a reverting mode. This means that every 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).

2.7.9. LAG and ECMP Hashing

Note:

Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S 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 Link Aggregation (LAG). A 7210 SAS can deploy both at the same time, meaning, using ECMP of two or more Link Aggregation Groups (LAG) and/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 and/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.

2.7.9.1. LAG Hashing for the 7210 SAS-M (Network Mode)

Table 10 describes the packet fields used for hashing for services configured in network mode on the 7210 SAS-M.

Note:

The following notes apply to Table 10.

In the LSR case, incoming labels are used for hashing.
“Learned” corresponds to Destination MAC.
Source/Destination MAC refer to Customer Source/Destination MACs unless otherwise specified
Applicable to non-IP, IP, PBB and MPLS traffic encapsulated in the MPLS packet received on the SDP Binding/SDP.

Table 10: LAG Hashing Algorithm for Services and Traffic Flows Configured on the 7210 SAS-M 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

L4 Ports

VPLS Service

SAP to SAP

IP traffic (learned)

✓

IP traffic (unlearned)

✓

PBB traffic (learned)

✓

PBB traffic (unlearned)

✓

MPLS traffic (learned)

✓

✓ 1

✓

✓ 2

MPLS traffic (unlearned)

✓

✓ 2

✓

✓ 2

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)

✓

✓ 2

MPLS traffic (unlearned)

✓

✓ 2

✓

✓ 2

Non-IP traffic (learned)

✓

Non-IP traffic (unlearned)

✓

VPLS Service

SDP to SAP

All traffic (learned)

✓

✓ 3

✓

✓ 3

All traffic (unlearned)

✓

✓ 3

✓

✓ 3

VPLS Service

SDP to SDP

IP traffic (learned)

✓

✓ 3

✓

✓ 3

IP traffic (unlearned)

✓

✓ 3

✓

✓ 3

PBB traffic (learned)

✓

✓ 3

✓

✓ 3

PBB traffic (unlearned)

✓

✓ 3

✓

✓ 3

Non-IP traffic (learned)

✓

✓ 3

✓

✓ 3

Non-IP traffic (unlearned)

✓

✓ 3

✓

✓ 3

Epipe Service

SAP to SAP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 1

✓

✓ 2

Non-IP traffic

✓

Epipe Service

SAP to SDP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 2

Non-IP traffic

✓

Epipe Service

SDP to SAP

All traffic

✓

✓ 3

✓

✓ 3

MPLS – LSR

All traffic

✓

✓ 1

✓

✓ 2

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

—

✓

✓ 4

✓

✓ 4

✓

Notes:

The outer MAC of the Ethernet packet that encapsulates an MPLS packet
Two MPLS labels deep
Outer MACs inside the payload just after the MPLS header
Source and destination IPv6 address

2.7.9.2. LAG Hashing for the 7210 SAS-M (Access-uplink Mode)

Table 11 describes the packet fields used for hashing for services configured on the 7210 SAS-M in access-uplink mode.

Note:

The following notes apply to Table 11.

The term “learned” corresponds to the destination MAC.
The term “Source and Destination MAC” refers to customer source and 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 the outer VLAN tag is used for hashing.

Table 11: LAG Hashing Algorithm for Services Configured on the 7210 SAS-M 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
	BDA	BSA	EtherType	Ingress Port-ID	ISID	MPLS Label Stack	MAC	IP	L4 Ports	VLAN
VPLS Service SAP to SAP
IP traffic (learned)								✓	✓
IP traffic (unlearned)				✓				✓	✓
PBB traffic (learned)	✓	✓								✓
PBB traffic (unlearned)	✓	✓		✓	✓
MPLS traffic (learned)							✓ 1			✓
MPLS traffic (unlearned)				✓		✓ 2
Non-IP traffic (learned)			✓				✓			✓
Non-IP traffic (unlearned)			✓	✓			✓			✓
Epipe Service SAP to SAP
IP traffic				✓				✓	✓
PBB traffic	✓	✓		✓	✓
MPLS traffic				✓		✓ 2
Non-IP traffic			✓	✓			✓			✓
IES Service (IPv4) IES SAP to IES SAP
IPv4 unicast traffic								✓	✓

Notes:

The outer MAC of the Ethernet packet that encapsulates an MPLS packet
Two MPLS labels deep

2.7.9.3. LAG Hashing for the 7210 SAS-T (Network Mode)

Table 12 describes the packet fields used for hashing for services configured on the 7210 SAS-T in network mode.

Note:

The following notes apply to Table 12.

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 12: 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

L4 Ports

VPLS Service

SAP to SAP

IP traffic (learned)

✓

IP traffic (unlearned)

✓

PBB traffic (learned)

✓

PBB traffic (unlearned)

✓

MPLS traffic (learned)

✓

✓ 1

✓

✓ 2

✓

MPLS traffic (unlearned)

✓

✓ 2

✓

✓ 2

✓

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)

✓

✓ 2

✓

MPLS traffic (unlearned)

✓

✓ 2

✓

✓ 2

✓

Non-IP traffic (learned)

✓

Non-IP traffic (unlearned)

✓

VPLS Service

SDP to SAP

IP traffic (learned)

✓

✓ 3

✓

—

PBB traffic (learned)

✓

✓ 3

—

Non-IP traffic (learned)

✓

✓ 3

—

All traffic (learned)

—

✓

✓ 3

All traffic (unlearned)

✓

✓ 3

✓

✓ 3

VPLS Service

SDP to SDP

All traffic (learned)

✓

✓ 3

✓

✓ 3

All traffic (unlearned)

✓

✓ 3

✓

✓ 3

Epipe Service

SAP to SAP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 1

✓

✓ 2

✓

Non-IP traffic

✓

Epipe Service

SAP to SDP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 2

✓

Non-IP traffic

✓

Epipe Service

SDP to SAP

IP traffic

✓

✓ 3

✓

—

PBB traffic

✓

✓ 3

—

Non-IP traffic

✓

✓ 3

—

All traffic

—

✓

✓ 3

MPLS – LSR

All traffic

✓

✓ 1

✓

✓ 2

✓ 5

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

—

✓

✓ 4

✓

✓ 4

✓

Notes:

The outer MAC of the Ethernet packet that encapsulates an MPLS packet
Two MPLS labels deep
Outer MACs inside the payload just after the MPLS header
Source and destination IPv6 address
Applies only when the IP header immediately follows the MPLS header without having a source and destination MAC in between in side the MPLS encapsulation

2.7.9.4. LAG Hashing for the 7210 SAS-T (Access-uplink Mode)

Table 13 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 Table 13

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 13: 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
	BDA	BSA	EtherType	Ingress Port-ID	ISID	MPLS Label Stack	MAC	IP	L4 Ports	VLAN
VPLS Service SAP to SAP
IP traffic (learned)								✓	✓
IP traffic (unlearned)				✓				✓	✓
PBB traffic (learned)	✓	✓
PBB traffic (unlearned)	✓	✓		✓	✓
MPLS traffic (learned)							✓ 1
IP MPLS traffic (unlearned)				✓		✓ 2		✓
L2 MPLS traffic (unlearned)				✓		✓ 2
Non-IP traffic (learned)			✓				✓			✓
Non-IP traffic (unlearned)			✓	✓			✓			✓
Epipe Service SAP to SAP
IP traffic				✓				✓	✓
PBB traffic	✓	✓		✓	✓
IP MPLS traffic				✓		✓ 2		✓
L2 MPLS traffic				✓		✓ 2
Non-IP traffic			✓	✓			✓			✓
IES Service (IPv4) IES SAP to IES SAP
IPv4 unicast traffic								✓	✓

Notes:

The outer MAC of the Ethernet packet that encapsulates an MPLS packet
Two MPLS labels deep

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

Table 14 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 Table 14.

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 14: 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

Hash-2

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and Destination

VLAN

MAC

L4 Ports

VPLS Service

SAP to SAP

IP traffic (learned)

✓

PBB traffic (learned)

✓

MPLS traffic (learned)

✓

✓ 4

✓

✓ 5

Non-IP traffic (learned)

✓

All traffic (unlearned)

See note 1

VPLS Service

SAP to SDP

IP traffic (learned)

✓

IP traffic (unlearned)

✓

PBB traffic (learned)

✓

PBB traffic (unlearned)

✓

MPLS traffic (learned)

✓

✓ 5

✓ 8

MPLS traffic (unlearned)

✓

✓ 5

✓ 8

✓

✓ 5

✓ 8

Non-IP traffic (learned)

✓

Non-IP traffic (unlearned)

✓

VPLS Service

SDP to SAP

IP traffic (learned)

✓

✓ 5

✓

—

All traffic, excluding IP traffic (learned)

✓

✓ 7

—

All traffic (learned)

—

✓

✓ 7

All traffic (unlearned)

See note 1

VPLS Service

SDP to SDP

All traffic (learned)

✓

✓ 7

✓

✓ 7

All traffic (unlearned)

✓

✓ 7

✓

✓ 7

Epipe Service

SAP to SAP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 4

✓

✓ 5

Non-IP traffic

✓

Epipe Service

SAP to SDP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 5

✓ 8

Non-IP traffic

✓

Epipe Service

SDP to SAP

IP traffic

✓

✓ 5

✓

—

All other traffic

✓

✓ 7

—

All traffic

—

✓

✓ 7

MPLS – LSR

All traffic

✓

✓ 4

✓

✓ 2

✓ 3

VPLS (Multicast traffic with IGMP snooping enabled)

SAP to SAP

SDP to SAP

—

See note 6

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

—

✓

✓ 9

✓

✓ 9

✓

Notes:

Based on LAG SAP parameters: service-id, lage_index, encap_value, service_vlan, sap_index, and number of active ports in the LAG. The hash function is implemented in the software and does not use hash-1 and hash-2 functions.
Three MPLS labels deep
Only applies if there are 3 or fewer MPLS labels when an IP header follows the MPLS header
The outer MAC of the Ethernet packet that encapsulates an MPLS packet
Two MPLS labels deep
Based on LAG SAP parameters: service-id, lage_index, encap_value, service_vlan, mgid, sap_index, and number of active ports in the LAG. The hash function is implemented in the software and does not use hash-1 and hash-2 functions.
Outer MACs inside the payload just after the MPLS header
Used when the IP header follows the MPLS header
Source and destination IPv6 addresses

2.7.9.6. LAG Hashing for the 7210 SAS-Mxp

Table 15 describes the packet fields used for hashing for services configured on the 7210 SAS-Mxp.

Note:

The following notes apply to Table 15.

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 15: LAG Hashing Algorithm for Services and Traffic Flows Configured on the 7210 SAS-Mxp

Traffic Type

Hashing Options

Packet Fields Used

Hash-1

Hash-2

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and Destination

VLAN

MAC

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)

✓

✓ 4

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

✓

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

See note 1

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

See note 1

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)

✓

✓ 4

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

✓

✓ 4

✓

✓ 4

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)

✓

✓ 4

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 1

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

See note 1

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

✓

✓ 5

✓

✓ 5

VPLS Service

SDP to SDP

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

✓

✓ 5

✓

✓ 5

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

✓

✓ 5

✓

✓ 5

MPLS – LSR

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

✓

✓ 5

✓

✓ 2

✓ 3

VPLS (Multicast traffic with IGMP snooping enabled)

SAP to SAP

SDP to SAP

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

See note 6

VPRN Service

SAP to SAP

SDP to SAP

All traffic

(SAP-based egress scheduling)

See note 1

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 1

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)

✓

Notes:

Based on LAG SAP parameters: service-id, lag_index, encap_value, service_vlan, sap_index, and number of active ports in the LAG. The hash function is implemented in the software and does not use hash-1 and hash-2 functions.
Three MPLS labels deep
Only applies if there are 3 or fewer MPLS labels when an IP header follows the MPLS header
Two MPLS labels deep
Outer MACs inside the payload just after the MPLS header
Based on LAG SAP parameters: service-id, lag_index, encap_value, service_vlan, mgid, sap_index, and number of active ports in the LAG. The hash function is implemented in the software and does not use hash-1 and hash-2 functions.

2.7.9.7. LAG Hashing Algorithm for the 7210 SAS-Sx/S 1/10GE and 7210 7210 SAS-Sx 10/100GE in Standalone and Standalone-VC Mode

Table 16 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 Table 16.

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 16: 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

Hash-2

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and Destination

VLAN

MAC

L4 Ports

VPLS Service

SAP to SAP

IP traffic (learned)

✓

IP traffic (unlearned)

✓

PBB traffic (learned)

✓

PBB traffic (unlearned)

✓

MPLS traffic (learned)

✓

✓ 3

✓

✓ 1

✓ 2

MPLS traffic (unlearned)

✓

✓ 1

✓ 2

✓

✓ 1

✓ 2

Non-IP traffic (learned)

✓

Non-IP traffic (unlearned)

✓

Epipe Service

SAP to SAP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 3

✓

✓ 1

✓ 2

Non-IP traffic

✓

VPLS Service

SAP to SDP

IP traffic (learned)

✓

IP traffic (unlearned)

✓

PBB traffic (learned)

✓

PBB traffic (unlearned)

✓

MPLS traffic (learned)

✓

✓ 1

✓ 2

MPLS traffic (unlearned)

✓

✓ 1

✓ 2

✓

✓ 1

✓ 2

Non-IP traffic (learned)

✓

Non-IP traffic (unlearned)

✓

Epipe Service

SAP to SDP

IP traffic

✓

PBB traffic

✓

MPLS traffic

✓

✓ 1

✓ 2

Non-IP traffic

✓

VPLS Service

SDP to SAP

IP traffic (learned)

✓ 5

✓ 4

✓

—

PBB traffic (learned)

✓

—

Non-IP traffic (learned)

✓ 6

✓

—

All traffic (learned)

—

✓

✓ 7

All traffic (unlearned)

✓

✓ 7

✓

✓ 7

Epipe Service

SDP to SAP

IP traffic

✓ 5

✓ 4

✓

—

PBB traffic

✓

—

Non-IP traffic

✓ 6

✓

—

All traffic

—

✓

✓ 7

VPLS Service

SDP to SDP

All traffic (learned)

✓

✓ 7

✓

✓ 7

All traffic (unlearned)

✓

✓ 7

✓

✓ 7

MPLS – LSR

All traffic

✓

✓ 3

✓

✓ 1

✓ 8

VPLS IGMP snooping

VPLS (Multicast traffic with IGMP snooping enabled):

SAP to SAP

SAP to SDP

IP multicast traffic

✓

L2 multicast traffic

✓

VPLS IGMP snooping

VPLS (Multicast traffic with IGMP snooping enabled):

SDP to SAP, SDP to SDP

—

✓

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

—

✓

✓ 9

✓

✓ 9

✓

Notes:

Three MPLS labels deep
Only applies if there are 3 or fewer MPLS labels when an IP header follows the MPLS header
The outer MAC of the Ethernet packet that encapsulates an MPLS packet
Two MPLS labels deep
In the standalone-VC mode, the IP traffic packet fields are used for null and dot1q tagged traffic; only source and destination MACs are used for qinq tagged traffic. In the standalone operating mode, source and destination MACs and MPLS label stacks (two labels deep) are used for qinq tagged traffic.
In the standalone-VC operating mode, Ethertype is used only for null and dot1q tagged traffic; it is not used for qinq tagged traffic.
Outer MACs inside the payload just after the MPLS header
Used when the IP header follows the MPLS header
Source and destination IPv6 address

2.7.9.8. PW Hash-label Generation for 7210 SAS-R6 and 7210 SAS-R12

Table 17 describes the packet fields used to generate the hash label for different services and traffic types.

Note:

The following notes apply to Table 17.

Source and destination MAC addresses are from the outermost Ethernet header.
MPLS and PBB traffic always use a fixed hash value. MPLS and PBB traffic encapsulation is identified by the system, only if the outermost Ethernet has two or fewer VLAN tags. If there are more VLAN tags, the system identifies the traffic as “Any other traffic”.
For IP traffic with two or more VLAN tags, Source and Destination MAC and VLAN are used to generate the hash label.
Any other traffic with three or more VLAN tags uses Source and Destination MAC and VLAN to generate the hash label.
The value of a hash label generated for the packet is the same and is not influenced by the configuration of the load-balancing algorithm using the command configure>lag>load-balancing.
Traffic identified as “All Other Traffic” have Ethertype or might not have Ethertype (For example: xSTP traffic does not have Ethertype). Ethertype is used only if available in the outermost Ethernet header for packets with two or fewer VLAN tags.

Table 17: Packet Fields Used for PW Hash-label Generation on the 7210 SAS-R6 and 7210 SAS-R12

Traffic Type	Packet Fields Used
	EtherType	Fixed Label Value	Source and Destination			VLAN
	EtherType	Fixed Label Value	MAC	IP	L4 Ports	VLAN
VPLS and Epipe Services SAP to SDP
IP traffic				✓	✓
PBB traffic		✓
MPLS traffic		✓
Any other traffic	✓		✓			✓
VPLS Service SDP to SDP
IP traffic				✓	✓
PBB traffic		✓
MPLS traffic		✓
Any other traffic	✓		✓ 1			✓

Note:

Outer MACs

2.7.9.9. PW Hash-label – Packet Fields Used for PW Hash-label Generation for 7210 SAS-Mxp

Table 18 describes the packet fields used for different services and different traffic types, to generate the hash-label.

Note:

The following notes apply to Table 18.

Source and destination MAC addresses are from the outermost Ethernet header.
MPLS and PBB traffic encapsulation is identified by the system only if the outermost Ethernet header has two or fewer VLAN tags.
Any traffic with three or more VLAN tags uses Source and Destination MAC and VLAN to generate the hash label.
The value of the hash label generated for the packet is the same and is not influenced by the configuration of the load-balancing algorithm using the command configure>lag>load-balancing.
Traffic identified as “All other traffic” may or may not have the Ethertype packet field (for example: xSTP traffic does not have Ethertype). Ethertype is used only if available in the outermost Ethernet header for packets with two or fewer VLAN tags.

Table 18: Packet Fields Used for PW Hash-label Generation on the 7210 SAS-Mxp

Traffic Type	Packet Fields Used
	BDA	BSA	EtherType	Ingress Port-ID	ISID	MPLS Label Stack	Source and Destination			VLAN
	BDA	BSA	EtherType	Ingress Port-ID	ISID	MPLS Label Stack	MAC	IP	L4 Ports	VLAN
VPLS and Epipe Services SAP to SDP
IP traffic				✓				✓	✓
PBB traffic	✓	✓		✓	✓
MPLS traffic				✓		✓ 1		✓ 2
All other traffic			✓	✓			✓			✓
VPLS Service SDP to SDP
All traffic				✓			✓ 3

Notes:

Three MPLS labels deep
Only applies if there are 3 or fewer MPLS labels when an IP header follows the MPLS header
Outer MACs

2.7.9.10. PW Hash-label – Packet Fields Used for PW Hash-label Generation for 7210 SAS-Sx/S 1/10GE

Table 19 describes the packet fields used for different services and different traffic types, to generate the hash-label.

Note:

The following notes apply to table Table 19.

Source and destination MAC addresses are from the outermost Ethernet header.
MPLS and PBB traffic encapsulation is identified by the system only if the outermost Ethernet has two or fewer VLAN tags.
Any traffic with three or more VLAN tags uses Source and Destination MAC and VLAN to generate the hash label.
The value of the hash label generated for the packet is the same and is not influenced by the configuration of the load-balancing algorithm using the command configure>lag>load-balancing.
Traffic identified as “All other traffic” may or may not have the Ethertype packet field (for example: xSTP traffic does not have Ethertype). Ethertype is used only if available in the outermost Ethernet header for packets with two or fewer VLAN tags.

Table 19: Packet Fields Used for PW Hash-label Generation on the 7210 SAS-Sx/S 1/10GE

Traffic Type	Packet Fields Used
	EtherType	Ingress Port-ID	MPLS Label Stack	Source and Destination			VLAN
	EtherType	Ingress Port-ID	MPLS Label Stack	MAC	IP	L4 Ports	VLAN
VPLS and Epipe Services SAP to SDP
IP traffic		✓			✓	✓
PBB traffic		✓
MPLS traffic		✓	✓ 1		✓ 2
All other traffic	✓	✓		✓			✓
VPLS Service SDP to SDP
All traffic		✓		✓ 3

Notes:

Three MPLS labels deep
Only applies if there are 3 or fewer MPLS labels when an IP header follows the MPLS header
Outer MACs

2.7.9.11. ECMP Hashing for 7210 SAS Devices in Network Mode

Table 20 describes the packet fields used for different services and different traffic types, to generate the hash-label.

Table 20: ECMP Hashing Algorithm for Services Configured on 7210 SAS Devices in Network Mode

Traffic Type	Packet Fields Used
	EtherType	Ingress Port-ID	MPLS Label Stack	Source and Destination			VLAN
				MAC	IP	L4 Ports
Network Port IPv4 Interface
IPv4 traffic		✓			✓	✓
IES Service SAP to SAP
IPv4 traffic		✓			✓	✓

2.7.10. Bidirectional Forwarding Detection Over LAG Links

The 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T, and 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE operating in standalone mode support bidirectional forwarding detection (BFD) to monitor individual LAG link members, which speeds up the detection of link failures. When BFD is associated with an Ethernet LAG, BFD sessions are established over each link member; sessions are called micro-BFD (uBFD) sessions. A link is not operational in the associated LAG until the associated micro-BFD session is fully established. The link member is also removed from the operational state in the LAG if the BFD session fails.

If BFD over LAG links is configured before the LAG is active, a link will not become operational in the associated LAG until the associated BFD session is fully established. If a LAG link is already in a forwarding state when BFD over LAG links is enabled, the forwarding state of the LAG link is not influenced until the uBFD session is fully established. A setup timer is started to remove the link from the LAG in the case where the uBFD session is not set up in time. By default, the setup timer value is set to never expire.

When configuring the local and remote IP addresses for BFD over LAG link sessions, the local-ip parameter must match an IP address associated with the IP interface to which this LAG is bound. In addition, the remote-ip parameter must match an IP address on the remote system, and should also be in the same subnet as the local IP address. If the LAG bundle is reassociated with a different IP interface, the local-ip and remote-ip parameters should be modified to match the new IP subnet.

2.7.10.1. Configuration Guidelines and Restrictions for BFD Over LAG Links

The following guidelines apply for BFD over LAG links.

The local address used for BFD sessions over LAG links cannot be an IP interface address that is associated with R-VPLS services.
When a micro-BFD session is established, resources are allocated per member port of the LAG. These resources are taken from the pool that is used to map packets to SAPs. Therefore, adding ports to the LAG on which the micro-BFD session is configured reduces the number of SAPs.
When configuring a micro-BFD session with dot1q encapsulation, an IP interface with dot1q explicit null SAP (:0 SAP) must be configured on the port for the BFD session to be operational. The local IP address of the BFD session can inherit the IP address of the IP interface that is configured with dot1q explicit null SAP or any other IP interface with the LAG.
The local IP interface address used for micro-BFD sessions must match the address of an IP interface configured on the LAG. If an IP interface is configured with an encapsulation of dot1q explicit null SAP configured on the LAG (lag:0), the uBFD session is not established unless one of the following occurs.
1. The interface using lag:0 also has the same source IP address as the uBFD configuration.
2. There is an operationally up interface with the same source IP address in the same routing instance.
Micro-BFD sessions share the resources from the pool used to identify MAC addresses belonging to the node, and the sessions must be processed by the applications on the node. Establishing a micro-BFD session results in one less resource available for other applications that use the pool, such as an IP interface, which is explicitly configured with a MAC address. On the 7210 SAS-R6 and 7210 SAS-R12, the MAC address resource is allocated per card, and is only allocated on cards with a LAG member port configured.
A remote IP address configured for a micro-BFD session must be the same IP address used to configure the micro-BFD session in the peer node.
The local IP address configured for micro-BFD should belong to the same routing instance as the IP interface configured for :0 LAG.

2.7.11. Multi-Chassis LAG

This section describes the Multi-Chassis LAG (MC-LAG) concept. MC-LAG is an extension of a LAG concept that provides node-level redundancy in addition to link-level redundancy provided by “regular LAG”.

Note:

MC-LAG is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

Typically, MC-LAG is deployed in a network-wide scenario and provides redundant connection between different end points. The whole scenario is then built by a combination of different mechanisms (for example, MC-LAG and redundant pseudowire to provide end-to-end (e2e) redundant point-to-point (p2p) connection or dual homing of CPE devices in Layer 2/3 VPNs).

Note:

The 7210 SAS platforms configured in access-uplink mode cannot peer with an MC-LAG-enabled node since it does not implement MC-LAG protocol; a 7210 SAS-M or 7210 SAS-T in access-uplink mode cannot provide MC-LAG server functionality. Instead they can be used as MC-LAG clients, with the platforms connected to a head-end node that support MC-LAG server functionality. These platforms connect to the head-end node using LAG.

2.7.11.1. Overview

MC-LAG is a method of providing redundant Layer 2/3 access connectivity that extends beyond link level protection by allowing two systems to share a common LAG end point.

The CPE/access node is connected with multiple links toward a redundant pair of Layer 2/3 access aggregation nodes such that both link and node level redundancy is provided. By using a multi-chassis LAG protocol, the paired Layer 2/3 aggregation nodes (referred to as the redundant-pair) appear to be a single node that is utilizing LACP toward the access node. The multi-chassis LAG protocol between the redundant-pair ensures a synchronized forwarding plane to and from the CPE/access node. It is used to synchronize the link state information between the redundant-pair nodes and provide correct LACP messaging to the CPE/access node from both redundant-pair nodes.

To ensure SLAs and deterministic forwarding characteristics between the CPE/access and the redundant-pair node, the multi-chassis LAG function provides an active/standby operation toward/from the CPE/access node. LACP is used to manage the available LAG links into active and standby states so that only links from one aggregation node are active at a time to and from the CPE/access node.

MC-LAG has the following characteristics.

Selection of the common system ID, system-priority, and administrative-key are used in LACP messages to ensure that partner systems consider all links part of the same LAG.
The selection algorithm is extended to allow the selection of the active subgroup.
1. The subgroup definition in the LAG context is still local to the single box. Consequently, even when subgroups configured on two different systems have the same subgroup-id, they are still considered two separate subgroups within the specific LAG.
2. The configuration of multiple subgroups per PE in an MC-LAG is supported.
3. If there is a tie in the selection algorithm, for example, two subgroups with identical aggregate weight (or number of active links), the group that is local to the system with lower system LACP priority and LAG system ID is selected.
Providing an inter-chassis communication channel allows the inter-chassis communication to support LACP on both systems. The communication channel enables the following functionality.
1. It supports connections at the IP level that do not require a direct link between two nodes. The IP address configured at the neighbor system is one of the addresses of the system (interface or loop-back IP address).
2. The communication protocol provides heartbeat mechanism to enhance robustness of the MC-LAG operation and detect node failures.
3. It supports operator actions that force an operational change on nodes.
4. The LAG group-ids do not have to match between neighbor systems. At the same time, multiple LAG groups between the same pair of neighbors is also allowed.
5. It verifies that the physical characteristics, such as speed and auto-negotiation are configured and initiates operator notifications (traps) if errors exist. Consistency of MC-LAG configuration (system-id, administrative-key and system-priority) is provided. Load-balancing must be consistently configured on both nodes.
6. Traffic over the signaling link is encrypted using a user-configurable message digest key.
The MC-LAG function provides active/standby status to other software applications to build reliable solutions.

Figure 5 and Figure 6 show different combinations of supported MC-LAG attachments. The supported configurations can be divided into the following subgroups:

dual-homing to remote PE pairs
1. both end-points attached with MC-LAG
2. one end-point attached
dual-homing to local PE pair
1. both end-points attached with MC-LAG
2. one end-point attached with MC-LAG
3. both end-points attached with MC-LAG to two overlapping pairs

Figure 5 shows dual homing to remote PE pairs.

Figure 5: MC-LAG L2 Dual Homing to Remote PE Pairs

Figure 6 shows dual homing to local PE pairs.

Figure 6: MC-LAG L2 Dual Homing to Local PE-Pairs

The forwarding behavior of the nodes is governed by the following principles. Note that the logical destination (actual forwarding decision) is primarily determined by the service (VPLS or VLL), and the following principle apply only if the destination or source is based on MC-LAG.

Packets received from the network will be forwarded to all local active links of the specific destination-sap based on conversation hashing. If there are no local active links, the packets will be cross-connected to the inter-chassis pseudowire.
Packets received from the MC-LAG sap will be forwarded to the active destination pseudo-wire or active local links of destination-sap. If no such objects are available at the local node, the packets will be cross-connected to inter-chassis pseudowire.

2.7.11.2. Point-to-Point Redundant Connection Across Layer 2/3 VPN Network

Figure 7 shows the connection between two CPE/access nodes across network based on Layer 2/3 VPN pseudo-wires. The connection between a CPE/access node and a pair of access aggregation PE routers is realized by MC-LAG. From the CPE/access node perspective, a redundant pair of access aggregation PE routers acts as a single partner in LACP negotiation. At any point in time, only one of the routers has active links in a specific LAG. The status of LAG links is reflected in the status signaling of pseudowires set between all participating PEs. The combination of active and standby states across LAG links and pseudowires give only one unique path between a pair of MSANs.

Note that the configuration in Figure 7 shows an example configuration of VLL connections based on MC-LAG. Specifically, it shows a VLL connection where the two ends (SAPs) are located on two different redundant-pairs. However, additional configurations are possible, for example:

both ends of the same VLL connections are local to the same redundant-pair
one end of the VLL endpoint is on a redundant-pair and the other on a single (local or remote) node

Figure 7: P2P Redundant Connection Through a Layer 2 VPN Network

2.7.11.3. DSLAM Dual Homing in Layer 2 Network

Figure 8 shows a network configuration where DSLAM is dual homed to a pair of redundant PEs by using MC-LAG. Inside the aggregation network, a redundant-pair of PEs is connecting to VPLS service, which provides a reliable connection to single or pair of Broadband Service Routers (BSRs).

PE-A and PE-B implement MC-LAG toward access. The active node synchronizes the IGMP snooping state with the standby node, allowing the standby node to forward multicast streams to receivers on the access side, if the active node fails.

Figure 8: DSLAM Dual-Homing Using MC-LAG

2.7.11.4. Configuration Guidelines

The following guidelines apply to MC-LAG configurations.

MC-LAG peer nodes must be of the same platform type. For example, 7210 SAS-M can only peer with another 7210 SAS-M, and 7210 SAS-Sx/S 1/10GE can only peer with another 7210 SAS-Sx/S 1/10GE. 7210 SAS-Sx/S 1/10GE cannot be configured with 7210 SAS-Sx 10/100GE.
MC-LAG is only supported in network mode on 7210 SAS-M, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE. For example, if two MC-LAG peers are set up using 7210 SAS-M, both need to be configured in network mode. It is not possible to have a node operating in network mode to be an MC-LAG peer with a node operating in access-uplink mode. This is true of standalone and standalone-vc modes, as well.
7210 SAS-M and 7210 SAS-T access-uplink mode supports active/standby LAG, which allows it to be used as client in an MC-LAG solution.

2.7.11.5. Configuring Multi-Chassis Redundancy

Note:

When configuring associated LAG ID parameters, the LAG must be in access mode and LACP must be enabled.

Use the following syntax to configure multi-chassis redundancy features.

config>redundancy

multi-chassis

peer ip-address

authentication-key [authentication-key | hash-key][hash | hash2]

description description-string

mc-lag

hold-on-neighbor-failure duration

keep-alive-interval interval

lag lag-id lacp-key admin-key system-id system-id [remotelag lag-

id] system-priority system-priority

no shutdown

source-address ip-address

sync

igmp-snooping

port [port-id | lag-id] [sync-tag]range encap-range sync-tag

no shutdown

config>redundancy# multi-chassis

config>redundancy>multi-chassis# peer 10.10.10.2 create

config>redundancy>multi-chassis>peer# description "Mc-Lag peer 10.10.10.2"

config>redundancy>multi-chassis>peer# mc-lag

config>redundancy>mc>peer>mc-lag# lag 1 lacp-key 32666 system-

id 00:00:00:33:33:33 system-priority 32888

config>redundancy>mc>peer>mc-lag# no shutdown

config>redundancy>mc>peer>mc-lag# exit

config>redundancy>multi-chassis>peer# no shutdown

config>redundancy>multi-chassis>peer# exit

config>redundancy>multi-chassis# exit

config>redundancy#

The following is a sample configuration output.

*7210-SAS>config>redundancy# info

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

multi-chassis

peer 1.1.1.1 create

shutdown

sync

shutdown

port 1/1/1 create

exit

peer 10.20.1.3 create

mc-lag

lag 3 lacp-key 1 system-id 00:00:00:aa:bb:cc remote-

lag 1 system-priority 1

no shutdown

exit

no shutdown

exit

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

*7210-SAS>config>redundancy#

2.8. G.8032 Protected Ethernet Rings

Ethernet ring protection switching provides ITU-T G.8032 specification compliance to achieve resiliency for Ethernet Layer 2 networks. The G.8032 (Eth-ring) specification is built on Ethernet OAM and often referred to as Ring Automatic Protection Switching (R-APS).

Refer to “G.8032 Ethernet Ring Protection Switching” in the 7210 SAS-M, T, Mxp, Sx, S Services Guide and the 7210 SAS-R6, R12 Services Guide.

2.9. 802.1x Network Access Control

The 7210 SAS supports network access control of client devices (PCs, STBs, and others) on an Ethernet network in accordance with the IEEE 802.1x standard (Extensible Authentication Protocol (EAP) over a LAN network or EAPOL).

Layer 2 control protocols affect 802.1x authentication behavior differently depending on the protocol in use; see Layer 2 Control Protocol Interaction with Authentication Methods for more information.

2.9.1. 802.1x Modes

The 7210 SAS supports port-based network access control for Ethernet ports only. Every Ethernet port can be configured to operate in one of three different operation modes, controlled by the port-control parameter:

force-auth
Disables 802.1x authentication and causes the port to transition to the authorized state without requiring any authentication exchange. The port transmits and receives normal traffic without requiring 802.1x-based host authentication. This is the default setting.
force-unauth
Causes the port to remain in the unauthorized state, ignoring all attempts by the hosts to authenticate. The switch cannot provide authentication services to the host through the interface.
auto
Enables 802.1x authentication. The port starts in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. Both the router and the host can initiate an authentication procedure, described as follows. The port will remain in an unauthorized state (no traffic except EAPOL frames is allowed) until the first client is authenticated successfully. After this, traffic is allowed on the port for all connected hosts.

2.9.2. 802.1x Basics

The IEEE 802.1x standard defines three participants in an authentication conversation:

supplicant
This is the end-user device that requests access to the network.
authenticator
This participant controls access to the network. Both the supplicant and the authenticator are referred to as Port Authentication Entities (PAEs).
authentication server
This participant performs the actual processing of the user information.

The authentication exchange is carried out between the supplicant and the authentication server, the authenticator acts only as a bridge. The communication between the supplicant and the authenticator is done through the Extended Authentication Protocol (EAP) over LANs (EAPOL). On the back end, the communication between the authenticator and the authentication server is done with the RADIUS protocol. The authenticator is therefore a RADIUS client, and the authentication server a RADIUS server.

Figure 9 shows the 802.1x architecture.

Figure 9: 802.1x Architecture

Figure 10 shows the messages involved in the authentication procedure.

Figure 10: 802.1x Authentication Scenario

The router will initiate the procedure when the Ethernet port becomes operationally up, by sending a special PDU called EAP-Request/ID to the client. The client can also initiate the exchange by sending an EAPOL-start PDU, if it doesn't receive the EAP-Request/ID frame during bootup. The client responds on the EAP-Request/ID with a EAP-Response/ID frame, containing its identity (typically username + password).

After receiving the EAP-Response/ID frame, the router will encapsulate the identity information into a RADIUS AccessRequest packet, and send it off to the configured RADIUS server.

The RADIUS server checks the supplied credentials, and if approved will return an Access Accept message to the router. The router notifies the client with an EAP-Success PDU and puts the port in authorized state.

2.9.3. 802.1x Timers

The 802.1x authentication procedure is controlled by a number of configurable timers and scalars. There are two separate sets, one for the EAPOL message exchange and one for the RADIUS message exchange.

EAPOL timers:

transit-period
Indicates how many seconds the Authenticator will listen for an EAP-Response/ID frame. If the timer expires, a new EAP-Request/ID frame will be sent and the timer restarted. The default value is 60. The range is 1 to 3600 seconds.
supplicant-timeout
This timer is started at the beginning of a new authentication procedure (transmission of first EAP-Request/ID frame). If the timer expires before an EAP-Response/ID frame is received, the 802.1x authentication session is considered as having failed. The default value is 30. The range is 1 to 300.
quiet-period
Indicates number of seconds between authentication sessions It is started after logoff, after sending an EAP-Failure message or after expiry of the supplicant-timeout timer. The default value is 60. The range is 1 to 3600.

RADIUS timer and scaler:

max-auth-req
Indicates the maximum number of times that the router will send an authentication request to the RADIUS server before the procedure is considered as having failed. The default value is value 2. The range is 1 to 10.
server-timeout
Indicates how many seconds the authenticator will wait for a RADIUS response message. If the timer expires, the access request message is sent again, up to max-auth-req times. The default value is 60. The range is 1 to 3600 seconds.

Figure 11 shows sample EAPOL and RADIUS timers on the 7210 SAS.

Figure 11: 802.1x EAPOL Timers (left) and RADIUS Timers (right)

The router can also be configured to periodically trigger the authentication procedure automatically. This is controlled by the enable re-authentication and reauth-period parameters. Reauth-period indicates the period in seconds (since the last time that the authorization state was confirmed) before a new authentication procedure is started. The range of reauth-period is 1 to 9000 seconds (the default is 3600 seconds, one hour). Note that the port stays in an authorized state during the re-authentication procedure.

2.9.4. 802.1x Configuration and Limitations

Configuration of 802.1x network access control on the router consists of two parts:

Generic parameters, which are configured under config>security>dot1x
Port-specific parameters, which are configured under config>port>ethernet>dot1x

801.x authentication:

Provides access to the port for any device, even if only a single client has been authenticated.
Can only be used to gain access to a predefined Service Access Point (SAP). It is not possible to dynamically select a service (such as a VPLS service) depending on the 802.1x authentication information.

2.9.5. 802.1x Tunneling for Epipe Service

Customers who subscribe to Epipe service considers the Epipe as a wire, and run 802.1x between their devices which are located at each end of the Epipe.

Note: This feature only applies to port-based Epipe SAPs because 802.1x runs at port level not VLAN level. Therefore such ports must be configured as null encapsulated SAPs.

When 802.1x tunneling is enabled, the 802.1x messages received at one end of an Epipe are forwarded through the Epipe. When 802.1x tunneling is disabled (by default), 802.1x messages are dropped or processed locally according to the 802.1x configuration (shutdown or no shutdown).

Note that enabling 802.1x tunneling requires the 802.1x mode to be set to force-auth. Enforcement is performed on the CLI level.

2.9.6. MAC Authentication

Note:

MAC authentication is only supported on 7210 SAS-M, 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-T.

The 7210 SAS supports the 802.1x EAP standard for authenticating Ethernet devices before they can access the network. However, if a client device does not support 802.1x EAP, MAC authentication can be used to prevent unauthorized traffic from being transmitted through the 7210 SAS.

Because MAC authentication is a fallback mechanism, the user must first enable 802.1x EAP to use MAC authentication on the 7210 SAS. To authenticate a port using MAC authentication, first configure 802.1x authentication on the 7210 SAS by enabling port-control auto, and then configure mac-auth on the 7210 SAS to enable MAC authentication.

Layer 2 control protocols affect MAC authentication behavior differently depending on the protocol in use; see Layer 2 Control Protocol Interaction with Authentication Methods for more information.

2.9.6.1. MAC Authentication Basics

When a port becomes operationally up with MAC authentication enabled, the 7210 SAS (as the authenticator) performs the following steps.

After transmission of the first EAP-Request/ID PDU, the 7210 SAS starts the mac-auth-wait timer and begins listening on the port for EAP-Response/ID PDUs. At this point, the 7210 SAS only listens to EAPOL frames. If EAPOL frames are received, 802.1x authentication is chosen.
Note:
If it is known that the attached equipment does not support EAP, you can configure no mac-auth-wait so that MAC authentication is used as soon as the port is operationally up.
If the mac-auth-wait timer expires, and no EAPOL frames have been received, the 7210 SAS begins listening on the port for any Ethernet frames.
If the 7210 SAS receives an Ethernet frame, the 7210 SAS scans the client source MAC address in the frame and transmits the MAC address to the configured RADIUS server for comparison against the MAC addresses configured in its database.
The following attributes are contained in the RADIUS message:
1. User-Name
  This attribute specifies the source MAC address of the client device.
2. User-Password
  This attribute specifies the source MAC address of the client device in an encrypted format.
3. Service-Type
  This attribute specifies the type of service that the client has requested; the value is set to 10 (call-check) for MAC authentication requests.
4. Calling-Station-Id
  This attribute specifies the source MAC address of the client device.
5. NAS-IP-Address
  This attribute specifies the IP address of the device acting as the authenticator.
6. NAS-Port
  This attribute specifies the physical port of the device acting as the authenticator.
7. Message-Authenticator
  This attribute is used to authenticate and protect the integrity of Access Request messages in order to prevent spoofing attacks.
If the MAC address is approved by the RADIUS server, the 7210 SAS enables the port for traffic transmission by that particular MAC address, which is successfully authenticated.
If the MAC address is rejected by the RADIUS server, the 7210 SAS will not authenticate the port using either 802.1x or MAC authentication. If an Ethernet frame with the same MAC address is received, the 7210 SAS returns to step 3 and reattempts approval of the MAC address.
If a port that was previously authenticated with MAC authentication receives an EAPOL-Start frame, the port will not reauthenticate using 802.1x EAPOL.

While the port is unauthenticated, the port will be down to all upper layer protocols or services.

When a MAC address is authenticated, only packets whose source MAC address matches the authenticated MAC address are forwarded when the packets are received on the port, and only packets whose destination MAC address matches the authenticated MAC address are forwarded out of the port.

Broadcast and multicast packets at ingress are sent for source MAC address authentication. Broadcast and multicast packets at egress are forwarded as normal.

Unknown destination packets at ingress are copied to the CPU and MAC authentication is attempted. Unknown destination packets at egress are dropped.

2.9.6.2. MAC Authentication Limitations

MAC authentication is subject to the following limitations.

If MAC authentication is configured on ports that are part of a LAG, the authenticated MAC address is forwarded in the egress direction out of any port in the LAG.
If MAC authentication is configured on a port and the port is added to or removed from a LAG, all previously authenticated MACs are reauthenticated by the system.
Caution:
A small amount of traffic loss may occur while MAC reauthentication is in progress.

2.9.7. VLAN Authentication

Note:

VLAN authentication is only supported on 7210 SAS-M, 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-T.

The 7210 SAS supports VLAN authentication, which operates similarly to 802.1x network access control but only uses VLAN-tagged EAPOL frames to trigger the authentication process on a per-VLAN basis, or uses null-tagged EAPOL frames to authenticate and authorize processing of service traffic received in the context of a Dot1q explicit null SAP. See 802.1x Network Access Control for information about 802.1x network access control and authentication.

To authenticate a port using VLAN authentication, you must first configure 802.1x authentication on the 7210 SAS by enabling port-control auto, and then configure vlan-auth on the 7210 SAS to enable VLAN authentication and allow VLAN authentication functionality to supersede that of basic 802.1x authentication.

VLAN authentication and MAC authentication are mutually exclusive. MAC authentication cannot be configured on a port while VLAN authentication is already configured on the same port. See MAC Authentication for information about MAC authentication.

Layer 2 control protocols affect VLAN authentication behavior differently depending on the protocol in use; see Layer 2 Control Protocol Interaction with Authentication Methods for more information.

2.9.7.1. VLAN Authentication Basics

When a port becomes operationally up with VLAN authentication enabled, the 7210 SAS (as the authenticator) performs the following steps.

After transmission of the first EAP-Request/ID PDU, the 7210 SAS begins listening on the port for VLAN-tagged EAPOL Start, Request-Identity frames from the access device connected to the port. Null-tagged EAPOL frames also trigger the authentication process if a Dot1q explicit null SAP is configured.
If the 7210 SAS receives a VLAN-tagged EAPOL frame (or a null-tagged EAPOL frame if a Dot1q explicit null SAP is configured), the 7210 SAS transmits the frame to the configured RADIUS server for comparison of the VLAN against the usernames configured in its database.
The User-Name attribute is contained in the RADIUS message. This attribute specifies the username received in the EAPOL frame from the client device.
If the VLAN is approved by the RADIUS server, the 7210 SAS maps all traffic received from the VLAN to a SAP and processes it in the context of the configured service.
If the VLAN is rejected by the RADIUS server, all traffic from the VLAN is dropped. The 7210 SAS enters a quiet period, configured using the quiet-period command, and will not authenticate the port using VLAN authentication. After the quiet period expires, the 7210 SAS returns to step 1.

While the port is unauthenticated, the port will be down to all upper layer protocols or services.

2.9.7.2. VLAN Authentication Limitations

VLAN authentication is subject to the following limitations.

VLAN authentication is only supported on Dot1q-encapsulated ports. It is not supported on NULL or QinQ-encapsulated ports.
VLAN authentication only uses the outermost VLAN tag received in the packets. Packets with more than one tag are processed only if the outermost tag matches the SAP tag.
Restrictions on processing of SAP tags also apply to VLAN authenticated frames. VLAN authentication does not change the current behavior for frames mapped to different SAPs and services.
VLAN range SAPs are not supported on a port with VLAN authentication enabled.
Dot1q default SAPs configured on a port with Dot1q encapsulation do not support VLAN authentication.
Dot1q explicit null SAPs can be configured on a port with Dot1q encapsulation, which requires authentication of null-tagged EAPOL frames.

2.9.8. Layer 2 Control Protocol Interaction with Authentication Methods

Table 21 describes the interactions of Layer 2 control protocols with 802.1x authentication, MAC authentication, and VLAN authentication.

Table 21: Layer 2 Control Protocol Interaction with Authentication Methods

Layer 2 Control Protocol	802.1x Port Authentication Enabled	MAC Authentication Enabled	VLAN Authentication Enabled
Layer 2 Control Protocol	802.1x Port Authentication Enabled	MAC Authentication Enabled	Dot1q Explicit Null SAP Not Configured	Dot1q Explicit Null SAP Configured
EFM OAM	Allow	Allow	Allow	Allow
LLDP	Block if port is unauthenticated Allow if port is authenticated	Block if MAC is unauthenticated Allow if MAC is authenticated	Allow	Allow
LACP	Block if port is unauthenticated Allow if port is authenticated	Block if MAC is unauthenticated Allow if MAC is authenticated	LAG and LACP are not supported on ports with VLAN authentication enabled	LAG and LACP are not supported on ports with VLAN authentication enabled
CFM	Block if port is unauthenticated Allow if port is authenticated	Block if MAC is unauthenticated Allow if MAC is authenticated	Block if VLAN (SAP) is unauthenticated Allow only if specific VLAN is authenticated	Block if null SAP is unauthenticated Allow if null SAP is authenticated
xSTP (STP/RSTP/MSTP)	Block if port is unauthenticated Allow if port is authenticated	Block if MAC is unauthenticated Allow if MAC is authenticated	Block if VLAN (SAP) is unauthenticated Allow if VLAN (SAP) is authenticated	Block if null SAP is unauthenticated Allow if null SAP is authenticated

2.10. 802.3ah OAM

802.3ah Clause 57 (EFM OAM) defines the Operations, Administration, and Maintenance (OAM) sub-layer, which provides mechanisms useful for monitoring link operation such as remote fault indication and remote loopback control. In general, OAM provides network operators the ability to monitor the health of the network and quickly determine the location of failing links or fault conditions. EFM OAM described in this clause provides data link layer mechanisms that complement applications that may reside in higher layers.

OAM information is conveyed in slow protocol frames called OAM protocol data units (OAMPDUs). OAMPDUs contain the appropriate control and status information used to monitor, test and troubleshoot OAM-enabled links. OAMPDUs traverse a single link, being passed between peer OAM entities, and as such, are not forwarded by MAC clients (like bridges or switches).

The following EFM OAM functions are supported:

EFM OAM capability discovery
active and passive modes
remote failure indication — Handling of critical link events (for example, link fault, dying gasp)
loopback — A mechanism is provided to support a data link layer frame-level loopback mode. Both remote and local loopback modes are supported.
dying gasp support on 7210 SAS platforms:
1. 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE generate EFM OAM dying gasp messages on loss of power. EFM OAM dying gasp messages are generated on either Network ports or Access uplink ports based on the mode in which the device is operating. They are not generated on access ports. These platforms also support generation of SNMP dying gasp messages on power failure and it is mutually exclusive to generation of EFM OAM dying gasp messages. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S System Management Guide for more information about support for SNMP dying gasp.
2. 7210 SAS-R6 and 7210 SAS-R12 devices do not generate SNMP or EFM OAM dying gasp.
3. All 7210 SAS platforms, process the received EFM OAM dying gasp, on a port enabled for EFM and generate a SNMP trap.
EFM OAMPDU tunneling.
high resolution timer for EFM OAM in 500ms interval (minimum)

2.10.1. OAM Events

EFM OAM defines a set of events that may impact link operation. The following events are supported:

critical link events (as defined in 802.3ah clause 57.2.10.1):
1. link fault
  The PHY has determined a fault has occurred in the receive direction of the local DTE.
2. dying gasp
  An unrecoverable local failure condition has occurred.
3. critical event
  An unspecified critical event has occurred.

These critical link events are signaled to the remote DTE by the flag field in OAM PDUs.

The 7210 SAS does not generate EFM OAM PDUs with these flags except for the dying gasp flag. However, it supports processing of these flags in EFM OAM PDUs received from the peer.

2.10.2. Remote Loopback

EFM OAM provides a link-layer frame loopback mode that can be remotely controlled.

To initiate remote loopback, the local EFM OAM client sends a loopback control OAM PDU by enabling the OAM remote-loopback command. After receiving the loopback control OAM PDU, the remote OAM client puts the remote port into local loopback mode.

To exit remote loopback, the local EFM OAM client sends a loopback control OAM PDU by disabling the OAM remote-loopback command. After receiving the loopback control OAM PDU, the remote OAM client puts the port back into normal forwarding mode.

Note that during remote loopback test operation, all frames except EFM OAM PDUs are dropped at the local port for the receive direction, where remote loopback is enabled. If local loopback is enabled, then all frames except EFM OAM PDUs are dropped at the local port for both the receive and transmit directions. This behavior may result in many protocols (such as STP or LAG) resetting their state machines.

2.10.3. 802.3ah OAM PDU Tunneling for Epipe Service

The 7210 SAS routers support 802.3ah. Customers who subscribe to Epipe service treat the Epipe as a wire, so they demand the ability to run 802.3ah between their devices which are located at each end of the Epipe.

Note:

This feature only applies to port-based Epipe SAPs because 802.3ah runs at the port level, not at the VLAN level. Therefore, such ports must be configured as null encapsulated SAPs.

When OAM PDU tunneling is enabled, 802.3ah OAM PDUs received at one end of an Epipe are forwarded through the Epipe. 802.3ah can run between devices that are located at each end of the Epipe. When OAM PDU tunneling is disabled (by default), OAM PDUs are dropped or processed locally according to the efm-oam configuration (shutdown or no shutdown).

Note that by enabling 802.3ah for a specific port and enabling OAM PDU tunneling for the same port are mutually exclusive.

2.11. MTU Configuration Guidelines

The 7210 SAS devices provide the option to configure MTU limitations at many service points. The physical (access and network) port, service, and SDP MTU values must be individually defined.

MTU values must conform to both of the following conditions.

The service MTU must be less than or equal to the SDP path MTU.
The service MTU must be less than or equal to the access port (SAP) MTU.

2.11.1. Default MTU Values

Table 22 describes the default MTU values that are dependent upon the (sub-) port type, mode, and encapsulation.

Table 22: MTU Default Values

Port Type	Mode	Encap Type	Default (bytes)
Ethernet	access	null	1514
Ethernet	access	dot1q	1518
Port mode	access	qinq	1522
Fast Ethernet	network	—	1514
Other Ethernet	network	—	9212
Ethernet	hybrid	—	9212

Notes:

The no service-mtu-check command disables service MTU check. Disabling the service MTU check allows packets to pass to the egress if the packet length is less than or equal to the MTU configured on the port. The length of the packet sent from a SAP is limited only by the access port MTU. In case of a pseudowire, the length of the packet is limited by the network port MTU (including the MPLS encapsulation).
In 7210 SAS, length of the SAP tag (or service-delimiting tag, for a packet received over a pseudowire) is included in the computation of the packet length before comparing it with the service-MTU configured for the service. Packet length= Length of IP packet + L2 header + length of SAP tag
For example, if the IP packet received over a dot1q SAP is 1500 and the service-MTU configured is 1514, the service MTU validation check fails as:

Packet length=1500 (Length of IP packet) +14 (L2 header) +4 (length of SAP tag) =1518. The packet is dropped as packet length is greater than the service MTU configured.

Note:

Refer to the 7210 SAS release notes for other restrictions with regards to MTU checking and processing on each of the platforms.

2.12. Deploying Preprovisioned Components on 7210 SAS

This section describes the deployment of preprovisioned components on 7210 SAS platforms.

2.12.1. Deploying Preprovisioned Components for 7210 SAS-M, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE.

Appropriate MDAs are auto-provisioned on the 7210 SAS-M, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE. The user is not required to provision the slots or MDA on these platforms.

2.12.2. Deploying Preprovisioned Components for 7210 SAS-R6 and 7210 SAS-R12

When a line card or MDA is installed in a preprovisioned slot, the device detects discrepancies between the preprovisioned card and MDA type configurations and the types actually installed. Error messages display if there are inconsistencies and the card does not initialize.

When the correct preprovisioned cards are installed in the appropriate chassis slot, alarm, status, and performance details display.

The 7210 SAS-R6 has 6 IMM slots and 2 SF/CPM slots, which are not auto-provisioned and need to be provisioned by the user.

The 7210 SAS-R12 has 12 IMM slots and 2 SF/CPM slots, which are not auto-provisioned and need to be provisioned by the user.

Note:

IMMv1 (imm-sas-r) cards cannot be installed in the same 7210 SAS-R6 chassis as IMMv2 (imm-sas-r-b) cards or IMM-c (imm-sas-r-c) cards. A mix of IMMv1 and any other type of card is not supported.

The 7210 SAS-R6 allows the user to preprovision the chassis to accept either IMMv1 or IMMv2/IMM-c cards. By default, without any configuration, the chassis accepts only IMMv1 cards. Use the configure>system>allow-imm-family command to configure the type of card the chassis can accept and reboot the device for the value to take effect. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information about this command.

The 7210 SAS-R12 allows the user to preprovision the chassis to accept either IMMv2 or IMM-c cards. By default, without any configuration, the chassis accepts IMMv2 cards. Use the configure>system>allow-imm-family command to configure the type of card the chassis can accept and reboot the device for the value to take effect. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information about this command.

The 7210 SAS-R12 does not support IMMv1 (imm-sas-r) cards.

2.13. Configuration Process Overview

Figure 12 shows the process to provision chassis slots (if any), line cards (if any), MDAs (if any), and ports.

Figure 12: Slot, Card, MDA, and Port Configuration and Implementation Flow

Note:

Specifying the chassis slot and card type is not needed for fixed platforms such as 7210 SAS-M, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE; these platforms do not support removable cards. On fixed platforms, the card type is auto-provisioned. It is typically used only on chassis-based platforms that support slots for inserting cards, such as the 7210 SAS-R6 and 7210 SAS-R12.
Specifying the MDA type is required only if the platform supports use of physical MDAs, such as the 7210 SAS-M. It is not required on platforms that do not support an MDA, such as 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, 7210 SAS-R6, and 7210 SAS-R12. 7210 SAS-Mxp does not have a expansion slot and therefore does not support MDAs.