2.1.1. Chassis slots and cards

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

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

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

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

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

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

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

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

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

2.3.1. SFPs and XFPs

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

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

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

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:

2.4.1. Port types

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

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

2.4.2. Support for power over Ethernet

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

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

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

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

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

The following PoE functionalities are available:

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:

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

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:

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.

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

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:

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:

1. LAN switch or router
2. IEEE 802.1 bridge
3. IEEE 802.3 repeater
4. IEEE 802.11 wireless access point
5. 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:

1. generic endpoints (Class I)
   This endpoint device class is for basic endpoints in LLDP-MED (for example, IP communications controllers).
2. media endpoints (Class II)
   This endpoint device class supports IP media streams (for example, media gateways and conference bridges).
3. communication device endpoints (Class III)
   This endpoint device class support the IP communication system end user (for example, IP telephones and softphones).

The following figure shows the LLDP-MED reference model.

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

Figure 3:  LLDP-MED reference model 

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:

1. 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.
2. 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-Mxp, R6, R12, S, Sx, T Basic System Configuration Guide for more information about configuring network policy parameters using commands in the config>system>lldp>lldp-med context.

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.1. LAG features

This section describes hardware and software LAG capabilities.

2.7.2. Configuring LAGs

The following are guidelines for configuring LAGs:

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

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

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

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

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

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

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

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

2.7.9. LAG and ECMP hashing

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

When a requirement exists to increase the available bandwidth for a logical link that exceeds the physical bandwidth or add redundancy for a physical link, typically one of the methods is applied; equal cost multi-path (ECMP) or LAG. A 7210 SAS can deploy both at the same time, meaning, using ECMP of two or more LAGs 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-T (network mode)

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

Note: The following notes apply to Table 10. 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 10:  LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-T configured in the network operating mode 

Traffic type

Hashing options

Packet fields used

Hash-1

Hash-2

BDA

BSA

CDA

CSA

EtherType

Ingress Port-ID

ISID

MPLS label stack

Source and destination

VLAN

MAC

IP

L4 ports

VPLS service SAP to SAP

IP traffic (learned)

✓

✓

✓

✓

✓

✓

✓

IP traffic (unlearned)

✓

✓

✓

✓

✓

✓

✓

✓

PBB traffic (learned)

✓

✓

✓

✓

✓

✓

✓

✓

✓

PBB traffic (unlearned)

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

MPLS traffic (learned)

✓

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

1. The outer MAC of the Ethernet packet that encapsulates an MPLS packet
2. Two MPLS labels deep
3. Outer MACs inside the payload just after the MPLS header
4. Source and destination IPv6 address
5. 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.2. LAG hashing for the 7210 SAS-T (access-uplink mode)

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

Note: The following notes apply to Table 11: 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 11:  LAG hashing algorithm for services configured on the 7210 SAS-T in the access-uplink operating mode 

Traffic type	Packet fields used
	BDA	BSA	EtherType	Ingress Port-ID	ISID	MPLS Label Stack	Source and destination			VLAN
							MAC	IP	L4 Ports
VPLS service SAP to SAP
IP traffic (learned)								✓	✓
IP traffic (unlearned)				✓				✓	✓
PBB traffic (learned)	✓	✓
PBB traffic (unlearned)	✓	✓		✓	✓
MPLS traffic (learned)							✓ 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:

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

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

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

Note: The following notes apply to Table 12: 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 12:  LAG hashing algorithm for services and traffic flows configured on the 7210 SAS-R6 and 7210 SAS-R12 

Traffic type

Hashing options

Packet fields used

Hash-1 Version 1

Hash-1 Version 2

Hash-2

BDA

BSA

EtherType

Ingress Port-ID

ISID

MPLS Label Stack

Source and destination

VLAN

MAC

IP

L4 Ports

VPLS service SAP to SAP

IP traffic (learned)

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

PBB traffic (learned)

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

MPLS traffic (learned)

✓

✓ 4

✓

✓

✓ 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

✓

✓

✓ 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

✓

✓

✓ 7

—

All traffic (learned)

—

—

✓

✓

✓ 7

All traffic (unlearned)

See note 1

VPLS service SDP to SDP

All traffic (learned)

✓

✓ 7

✓

✓ 7

✓

✓

✓ 7

All traffic (unlearned)

✓

✓

✓ 7

✓

✓

✓ 7

✓

✓

✓ 7

Epipe service SAP to SAP

IP traffic

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

PBB traffic

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

MPLS traffic

✓

✓ 4

✓

✓

✓ 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

✓

✓

✓ 7

—

All traffic

—

—

✓

✓

✓ 7

MPLS – LSR

All traffic

✓

✓ 4

✓

✓ 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

✓

✓

✓

✓ 9

✓

Notes:

1. 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.
2. Three MPLS labels deep
3. Only applies if there are 3 or fewer MPLS labels when an IP header follows the MPLS header
4. The outer MAC of the Ethernet packet that encapsulates an MPLS packet
5. Two MPLS labels deep
6. 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.
7. Outer MACs inside the payload just after the MPLS header
8. Used when the IP header follows the MPLS header
9. Source and destination IPv6 addresses