7210 SAS interfaces

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

Configuration overview

Note:

This document uses the term preprovisioning in the context of preparing or preconfiguring entities such as chassis slots, 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-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C and the variants are platforms with a fixed port configuration, and no expansion slots. The 7210 SAS software inherits the concept of CPM, IOM and MDA from the 7750 SR to represent the hardware logically. These components are fixed and are not removable. The software creates two logical cards to represent the CPM and IOM and these are preprovisioned on boot-up. The IOM card is modeled with a single MDA, a logical entity to represent the fixed ports on the system. This MDA is auto-provisioned on boot-up and the user does not need to provision it. Ports and interfaces can also be preprovisioned.

Chassis slots and cards

  • The 7210 SAS-D supports the following ports:

    • 6 ✕ 10/100/1000 SFP ports

    • 4 ✕ 10/100/1000 Base-T ports

    • 1 management console port

  • The 7210 SAS-Dxp supports the following ports:

    • 2 ✕ 1GE/10GE SFP+ ports

    • 6 ✕ 10/100/1000 Base-T ports

    • 4 ✕ 100/1000 SFP ports

    • 1 management console port

  • The 7210 SAS-K 2F1C2T supports the following ports:

    • 2 ✕ 10/100/1000 Base-T fixed copper ports

    • 1 management console port

  • The 7210 SAS-K 2F6C4T supports the following ports:

    • 2 ✕ 100/1000 SFP ports

    • 4 ✕ 10/100/1000 Base-T fixed copper ports

    • 6 Combo ports (100/1000 SFP or 10/100/1000 Base-T)

    • 1 management console port

  • The 7210 SAS-K 3SFP+ 8C ports supports the following ports:

    • 3 ✕ 10GE SFP+ ports

    • 8 Combo ports (100/1000 SFP or 10/100/1000 Base-T)

    • 1 management console port

The 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C have a set of fixed ports. The software preprovisions the cards on bootup.

The show card command lists the cards auto-provisioned on 7210 SAS platforms.

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

A:dut-b# 
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:dut-b# 

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

A:dut-m# 
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:dut-m# 

The following show card sample output lists the cards auto-provisioned on the 7210 SAS-K 2F1C2T.

A:dut-i# 
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:dut-i# 

The following show card sample output lists the cards auto-provisioned on the 7210 SAS-K 2F6C4T:

A:dut-k# 
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:dut-k# 

The following show card sample output lists the cards auto-provisioned on the 7210 SAS-K 3SFP+ 8C.

A:dut-l# 
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:dut-l# 

Digital Diagnostics Monitoring

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

  • temperature

  • supply voltage

  • transmit (Tx) bias current

  • Tx output power

  • received (Rx) optical power

Note:

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

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

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

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

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

The following are potential uses of the DDM data:

  • optics degradation monitoring

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

  • link/router fault isolation

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

The following table describes supported real-time DDM features.

Table 1. Real-time DDM information

Parameter

User units

SFP/XFP units

SFP

XFP

MSA DWDM

Temperature

Celsius

C

Supported

Supported

Supported

Supply Voltage

Volts

µV

Supported

Supported

Not supported

TX Bias Current

mA

µA

Supported

Supported

Supported

TX Output Power

dBm (converted from mW)

mW

Supported

Supported

Supported

RX Received Optical Power4

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

mW

Supported

Supported

Supported

AUX1

parameter dependent (embedded in transceiver)

-

Not supported

Supported

Not supported

AUX2

parameter dependent (embedded in transceiver)

-

Not supported

Supported

Not supported

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

Table 2. DDM alarms and warnings

Parameter

SFP/XFP units

SFP

XFP

Required?

MSA DWDM

Temperature

- High Alarm

- Low Alarm

- High Warning

- Low Warning

C

Yes

Yes

Yes

Yes

Supply Voltage

- High Alarm

- Low Alarm

- High Warning

- Low Warning

µV

Yes

Yes

Yes

No

TX Bias Current

- High Alarm

- Low Alarm

- High Warning

- Low Warning

µA

Yes

Yes

Yes

Yes

TX Output Power

- High Alarm

- Low Alarm

- High Warning

- Low Warning

mW

Yes

Yes

Yes

Yes

RX Optical Power

- High Alarm

- Low Alarm

- High Warning

- Low Warning

mW

Yes

Yes

Yes

Yes

AUX1

- High Alarm

- Low Alarm

- High Warning

- Low Warning

parameter dependent (embedded in transceiver)

No

Yes

Yes

No

AUX2

- High Alarm

- Low Alarm

- High Warning

- Low Warning

parameter dependent (embedded in transceiver)

No

Yes

Yes

No

SFPs and XFPs

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

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

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

Statistics collection

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

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.


B:SR7-101# show port 2/1/6 detail
......
===============================================================================
Transceiver Digital Diagnostic Monitoring (DDM), Internally Calibrated
===============================================================================
     Value High Alarm  High Warn   Low Warn  Low Alarm
-------------------------------------------------------------------------------
Temperature (C)       +33.0+98.0   +88.0      -43.0-45.0
Supply Voltage (V)       3.31 4.12    3.60       3.00 2.80
Tx Bias Current (mA)5.7 60.0    50.00.1  0.0
Tx Output Power (dBm)      -5.45 0.00   -2.00     -10.50    -12.50
Rx Optical Power (avg dBm)    -0.65-3.00!   -4.00!    -19.51    -20.51
===============================================================================

Ports

This section describes 7210 SAS ports.

Port types

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

Table 3. Supported Ethernet port types

7210 SAS platforms

Copper ports (10/100/1000 Base-T)

Ethernet SFP ports

10 Gigabit SFP+ ports

7210 SAS-D

7210 SAS-Dxp

1

7210 SAS-K 2F1C2T

7210 SAS-K 2F6C4T

7210 SAS-K 3SFP+ 8C

Port modes

On 7210 SAS devices, a port must be configured as one of the following: access, access uplink, network, or hybrid. The following list describes the significance of the different port modes and the support available on different platforms:

  • access ports

    Access ports are 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. When a port has been configured for access mode, one or more services can be configured on the port depending on the encapsulation value.

  • 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 QinQ only. 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.

  • network ports (applicable only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

    Network ports are configured for network-facing traffic. These ports participate in the service provider transport or infrastructure network. Dot1q is supported on network ports.

  • hybrid ports (applicable only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

    Hybrid ports are configured for access and network-facing traffic. The default mode of an Ethernet port is ‟network”. The mode of a port cannot be changed unless the port is shut down and the configured SAPs and interfaces are deleted. Hybrid ports allow a single port to operate in both access and network modes. The MTU of a port in hybrid mode is the same as in network mode. The default encapsulation for ports in hybrid mode is dot1q; QinQ encapsulation is also supported at the port level.

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

    The only exception is when the port is a 10/100 fast Ethernet port. In this case, 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. All parameters in access and network contexts are configured within the port using the same CLI hierarchy as in the existing implementation. A hybrid port allows both ingress and egress contexts to be configured concurrently.

    An Ethernet port configured in hybrid mode can have the following encapsulation type values: dot1q and QinQ. The NULL value is not supported because only a single SAP or network IP interface is allowed, achieved by configuring the port as either access or network, respectively. 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 (MC-LAG) configuration, only access mode can be configured. MC-LAG is not supported on network ports and consequently cannot be supported on hybrid ports.

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

Table 4. 7210 SAS platforms supporting port modes

Port mode platforms

Access

Network

Hybrid

Access-uplink

7210 SAS-D

Yes

No

No

Yes

7210 SAS-Dxp

Yes

No

No

Yes2

7210 SAS-K 2F1C2T

Yes

No

No

Yes

7210 SAS-K 2F6C4T

Yes

Yes

Yes

Yes

7210 SAS-K 3SFP+ 8C

Yes

Yes

Yes

Yes

Port dot1q VLAN Etype on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

The 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 non-standard (other than 0x8100) dot1q VLAN Etype.

Configuration guidelines for dot1q-Etype for 7210 SAS-D and 7210 SAS-Dxp

The following are the configuration guidelines for Dot1q-Etype configured for dot1q encap port on 7210 SAS-D and 7210 SAS-Dxp:

  • Dot1q-Etype configuration is supported for all ports - Access and Access-uplink ports.

  • Dot1q-preserve SAPs cannot be configured on dot1q encap ports configured to use ether type 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 access port.

Support for power over Ethernet

Note:

Power over Ethernet (PoE) is supported only on the 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p.

The 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p support PoE in accordance with the 802.3af, 802.3at, and 802.3bt 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 following PoE functionalities are available:

  • The 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p support 802.3af (PoE), 802.3at (PoE+), and 802.bt (PoE++ and HPoE). All ports support PoE and PoE+. only the first four copper ports support PoE++ and HPoE. The ports can be used to connect PoE, PoE+, PoE++, or HPoE devices, or a combination of both simultaneously, as long as the power drawn is within the device system limits.

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

  • The 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p support classification Type 1, Type 2, Type 3, and Type 4 PoE devices (PDs) using the physical layer classification mechanism. The physical layer classification mechanism supports both the single-signature and dual-signature classification mechanisms.

  • The user must configure the maximum available PoE power budget using the configure system poe max-poe-power-budget command before enabling PoE on any of the ports. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about this command.

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

    Note:

    The software accounts for power requirements based on the PD type and does not consider the PoE class within a type (a PoE device uses 15 W, a PoE+ device uses 30 W, a PoE++ device uses 60 W, and a HPoE device uses 90 W).

    For example, if the user configures one PoE port, the software deducts 15 W from the configured max-poe-power-budget. If the user configures two PoE ports and two PoE + ports, the software deducts 90 W from the configured max-poe-power-budget (assuming the configured value is greater than or equal to 90 W). If the user configures a value of 100 W and attempts to configure four PoE+ ports, the software deducts 30 W from the configured max-poe-power-budget for the first three configured PoE+ ports using a total of 90 W (10 W are remaining). When the user configures the fourth port, the configuration fails because only 10 W are available, which does not meet the power requirement for the fourth PoE+ port.

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

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

    • supplying power event

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

    • denied power event

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

    • disconnect event

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

    • fault events

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

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

PoE configuration notes

The following configuration notes apply for PoE:

  • On the 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p, all ports are available to connect PoE and PoE+ devices, and up to four fixed copper ports are available to connect PoE++ and HPoE devices.

  • The 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p can be equipped with the following external power module types to support required PoE devices:

    • 100 W AC

    • 290 W DC

    • 480 W AC

    • 960 W AC

  • The user can configure the maximum power budget for PoE devices using the config>system>poe>max-poe-power-budget command. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about this command.

MACsec

Note:

  • Media Access Control Security (MACsec) is supported only on the 7210 SAS-K 2F6C4T ETR, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p.
  • On the 7210 SAS-Dxp 24p, MACsec is available on four ports:
    • 1 GE SFP ports 1/1/19 and 1/1/20
    • 1/10 GE SFP+ ports 1/1/17 and 1/1/18

MACsec is a security technology that provides secure communication for almost all types of traffic on Ethernet links. MACsec provides point-to-point and point-to-multipoint security on Ethernet links between directly connected nodes, or nodes connected using a Layer 2 cloud.

MACsec can identify and prevent most security threats, including:

  • denial of service

  • intrusion

  • man-in-the-middle

  • masquerading

  • passive wiretapping

  • playback attacks

MACsec, defined in IEEE 802.1AE, uses Layer 2 to encrypt MACsec to encrypt anything from the 802.1AE header to the end of the payload, including 802.1Q. MACsec leaves the DMAC and SMAC in cleartext.

The following figure shows the 802.1AE LAN-mode structure.

Figure 1. 802.1 AE LAN-MODE

Forwarding a MACsec packet uses the destination MAC address, which is in cleartext.

MACsec 802.1AE header (SecTAG)

The 802.1AE header has a security tag (SecTAG) which includes:

  • the association number within the channel

  • the packet number to provide a unique initialization vector for encryption and authentication algorithms, as well as protection against replay attack

  • an optional LAN-wide secure channel identifier

The SecTAG is identified by the MACsec Ethertype and includes the following fields:

  • TAG Control Information (TCI)

  • Association Number (AN)

  • Short Length (SL)

  • Packet Number (PN)

  • Optionally-encoded Secure Channel Identifier (SCI)

The following figure shows the format of the SecTAG.

Figure 2. SecTAG format

MACsec encryption mode

MACsec uses the following main modes of encryption:

  • VLAN in cleartext (WAN Mode)

  • VLAN encrypted

The 802.1AE standard requires that the 802.1Q VLAN is encrypted. Some vendors provide the option of configuring MACsec on a port with VLAN in cleartext form. The 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p support both modes on both 1GE and 10GE ports.

The following figure shows VLAN in encrypted and cleartext form.

Figure 3. 802.1 AE LAN/WAN modes and VLAN encrypted/clear
MACsec encryption per traffic flow encapsulation matching

MACsec can be applied to a selected subset of the port traffic based on the type and value of the packet encapsulation. The user can configure the system to match and encrypt all encapsulated traffic arriving on a port, including untagged, single-tagged, and double-tagged. This is the default behavior of MACsec and the only option supported.

MKA PDUs are generated specifically for the matched traffic encapsulation type.

MACsec terminology

The following table describes MACsec terminology.

Table 5. MACsec terminology

MACsec term

Description

Connectivity Association (CA)

A security relationship, established and maintained by the MKA, that comprises a fully connected subset of the service access points in stations attached to a single LAN that are to be supported by MACsec.

MACsec Key Agreement Protocol (MKA)

Control protocol between MACsec peers, which is used for peer aliveness and encryption key distribution. MKA is responsible for discovering, authenticating, and authorizing the potential participants in a CA.

MAC Security Entity (SecY)

Operates the MAC security protocol within a system. Manages and identifies the SC and the corresponding active SA.

Port Access Entity (PAE)

The protocol entity associated with a port. May support the functionality of authenticator, supplicant, or both.

Security Channel (SC)

Provides a unidirectional point-to-point or point-to-multipoint communication. Each SC contains a succession of SAs, and each SC has a different SAK.

Security Association Key (SAK)

The key used to encrypt the datapath of MACsec.

Security Association (SA)

A security relationship that provides security guarantees for frames transmitted from one member of a CA to the others.

In the case of two SAs per SC, each with a different SAK, each SC comprises a succession of SAs. Each SA has an SC identifier, concatenated with a two-bit association number. The Secure Association Identifier (SAI) that has been created allows the receiving SecY to identify the SA, and consequently, the SAK used to decrypt and authenticate the received frame. The AN (and the SAI) is only unique for the SAs that can be used or recorded by participating SecYs at any time.

The MKA creates and distributes SAKs to each of the SecYs in a CA. This key creation and distribution is independent of the cryptographic operation of each of the SecYs. The decision to replace one SA with its successor is made by the SecY that transmits using the SC, after the MKA has informed it that all the other SecYs are prepared to receive using that SA. No notification, other than receipt of a secured frame with a different SAI, is sent to the receiver. A SecY must always be capable of storing SAKs for two SAs for each inbound SC, and of swapping from one SA to another without notice. Certain LAN technologies can reorder frames of different priority, so reception of frames on a single SC can use interleaved SA.

MACsec key management modes

The following table describes the key management modes in MACsec.

Table 6. MACsec key management modes

Keying

Explanation

SR OS support

Where used

Static Secure Association Key (SAK)

Manually configures each node with a static SAK using CLI or NSP.

N/A

Switch to switch

Static Connectivity Association Key (CAK) preshared key

Uses dynamic MACsec Key Agreement (MKA) and uses a configured pre-shared key to derive the CAK. The CAK encrypts the SAK between two peers and authenticates the peers.

Supported

Switch to switch

Dynamic CAK EAP Authentication

Uses dynamic MKA and an EAP Master System Key (MSK) to derive the CAK. The CAK encrypts the SAK between two peers and authenticates the peers.

Not Supported

Switch to switch

Dynamic CAK MSK Distribution via RADIUS and EAP-TLS

MSKs are stored in the RADIUS server and distributed to the hosts via EAP-TLS. This is typically used in access networks where there are a large number of hosts using MACsec and connecting to an access switch. MKA uses MSK to derive the CAK. The CAK encrypts the SAK between 2 peers and authenticates the peers.

Not Supported

Host to switch

MACsec static CAK

The following figure shows the main MACsec concepts used in the static CAK scenario.

Figure 4. MACsec concepts for static CAK

MACsec uses SAs to encrypt packets. Each SA has a single SAK that contains the cryptographic operations used to encrypt the datapath PDUs.

The SAK is the secret key used by an SA to encrypt the channel.

When enabled, MACsec uses a static CAK security mode, which has two security keys: a CAK that secures control plane traffic and a randomly generated SAK that secures data plane traffic. Both keys are used to secure the point-to-point or point-to-multipoint Ethernet link and are regularly exchanged between devices on each end of the Ethernet link.

The following figure shows MACsec generating the CAK.

Figure 5. MACsec generating the CAK

The node initially needs to secure the control plane communication to distribute the SAKs between two or more members of a CA domain.

The control plane is secured using a CAK, which is generated using one of the following methods:

  • EAPoL

  • preshared key

    (CAK and CKN values are configured using the CLI). The following CAK and CKN rules apply.

    • CAK uses 32 hexadecimal characters for a 128-bit key, and 64 hexadecimal characters for a 256-bit key, depending on the algorithm used for control plane encryption; for example, aes-128-cmac or aes-256-cmac.

    • CKN is a 32-octet character (64 hex) and is the name that identifies the CAK. This allows each of the MKA participants to select which CAK to use to process a received MKPDU. MKA places the following restrictions on the format of the CKN:

      • it must comprise an integral number of octets, between 1 and 32 (inclusive)

      • all potential members of the CA must use the same CKN

    • CAK and CKN must match on peers to create a MACsec-secure CA.

The following figure shows MACsec control plane authentication and encryption.

Figure 6. MACsec control plane

After the CAK is generated, it can obtain the following additional keys:

  • KEK (Key Encryption Key)

    The KEK is used to wrap and encrypt the SAKs.

  • ICK (Integrity Connection Value (ICV) Key)

    The ICK is used for an integrity check of each MKPDU send between two CAs.

The key server then creates a SAK and shares it with the CAs of the security domain, and that SAK secures all data traffic traversing the link. The key server periodically creates and shares a randomly created SAK over the point-to-point link for as long as MACsec is enabled.

The SAK is encrypted using the AES-CMAC, the KEK as the encryption key, and ICK as the integration key.

SAK rollover

The SAK is regenerated after the following events:

  • when a new host has joined the CA domain and MKA hellos are received from this host

  • when the sliding window is reaching the end of its 32-bit or 64-bit length

  • when a new PSK is configured and a rollover of PSK is executed

MKA

Each MACsec peer operates the MKA. Each node can operate multiple MKAs based on the number of CAs that it belongs to. Each instance of MKA is protected by a distinct secure CAK, that allows each Port Access Entity (PAE), or port, to ensure that information for a specific MKA instance is accepted only from other peers that also possess that CAK, therefore identifying themselves as members or potential members of the same CA. For a description of how the CAK identification is performed using CKN, see MACsec static CAK.

MKA PDU generation

The following table describes the MKA PDUs generated for different traffic encapsulation matches.

Table 7. MKA PDU generation

Configuration

Configuration example (<s-tag>.<c-tag>)

MKA packet generation

Traffic pattern match/behavior

Supported on 7210 SAS

All-encap

config>port>ethernet>dot1x>macsec
      ca-name 10

untagged MKA packet

Matches all traffic on port, including untagged, single-tag, and double-tag.

Default behavior.

Yes

UN-TAG

config>port>ethernet>dot1x>macsec
      sub-port 1
      encap-match untagged
      ca-name 2

untagged MKA packet

Matches only untagged traffic on port

No

802.1Q single S-TAG (specific S-TAG)

config>port>ethernet>dot1x>macsec
      sub-port 2 
      encap-match dot1q 1
      ca-name 3

MKA packet generated with S-TAG=1

Matches only single-tag traffic on port with tagID of 1

No

802.1Q single S-TAG (any S-TAG)

config>port>ethernet>dot1x>macsec
      sub-port 3
      encap-match dot1q *
      ca-name 4

untagged MKA packet

Matches any dot1q single-tag traffic on port

No

802.1ad double tag (both tag have specific TAGs)

config>port>ethernet>dot1x>macsec
      sub-port 4
      encap-match qinq 1.1
      ca-name 5

MKA packet generated with S-tag=1 and C-TAG=1

Matches only double-tag traffic on port with service tag of 1 and customer tag of 1

No

802.1ad double tag (specific S-TAG, any C-TAG)

Config>port>ethernet>dot1x>macsec
      sub-port 6
      encap-match qinq 1.* 
      ca-name 7

MKA packet generated with S-TAG=1

Matches only double-tag traffic on port with service tag of 1 and customer tag of any

No

802.1ad double tag (any S-TAG, any C-TAG)

config>port>ethernet>dot1x>macsec
      sub-port 7
      encap-match qinq *.* 
      ca-name 8

untagged MKA packet

Matches any double-tag traffic on port

No

Tags in clear behavior by traffic encapsulation types

By default, all tags are encrypted in CA. An MKA can be generated without any tags (untagged), but the data being matched can be based on dot1q or q-in-q.

The following table describes how single or double tags in clear configuration under a CA affect different traffic flow encryptions.

Table 8. Tags in clear behavior

Configuration

Traffic pattern match/behavior

CA configuration: no tag in cleartext form

CA configuration: single-tag in cleartext form

CA configuration: double-tag in cleartext form

Port

Matches all traffic on port, including untagged, single-tagged, double-tagged (default behavior)

MKA PDU: untagged

Untagged traffic: encrypted

Single-tagged traffic: encrypted, no tag in clear

Double-tagged traffic: encrypted, no tag in clear

MKA PDU: untagged

Untagged traffic: in clear

Single-tagged traffic: encrypted, single-tag in clear

Double-tagged traffic: encrypted, single-tagged in clear

MKA PDU: untagged

Untagged traffic: in clear

Single-tagged traffic: in clear

Double-tagged traffic: encrypted, double-tagged in clear

PSK

A peer may support the use of one or more preshared keys (PSKs). An instance of MKA operates for each PSK that is administratively configured as active.

A preshared key is either created by NSP or configured using the CLI. Each PSK is configured using the following fields:

  • CKN

  • CAK value

The CKN must be unique for each port among the configured sub-ports, and can be used to identify the key in subsequent management operations.

Each static CAK configuration can have two preshared key entries for rollover. The active PSK index dictates which CAK is being used for encrypting the MKA PDUs.

NSP has additional functionality to rollover and configure the PSK. The rollover using NSP can be based on a configured timer.

MKA hello timer

MKA uses a member identifier (MI) to identify each node in the CA domain.

A participant proves liveness to each of its peers by including the MI, together with an acceptably recent message number (MN), in an MKPDU.

To avoid a new participant having to respond to each MKPDU from each partner as it is received, or trying to delay its reply until it is likely that MI MN tuples have been received from all potential partners, each participant maintains and advertises both a live peers list and a potential peers list.

The live peers list includes peers that have included the participant MI and a recent MN in a recent MKPDU. The potential peers list includes all other peers that have transmitted an MKPDU that has been directly received by the participant or that were included in the live peers list of a MKPDU transmitted by a peer that has proved liveness. Peers are removed from each list when an interval of between MKA lifetime and MKA lifetime plus MKA Hello Time has elapsed since the participant's recent MN was transmitted. This time is sufficient to ensure that two or more MKPDUs will have been lost or delayed before the incorrect removal of a live peer.

Note:
  • The specified use of the live peers and potential peers lists allows rapid removal of participants that are no longer active or attached to the LAN, while reducing the number of MKPDUs transmitted during group formation; for example, a new participant is admitted to an established group after receiving, then transmitting, one MKPDU.

  • MKA Hello packets are sent once every 2 seconds with a timeout interval of 3 packets or 6 seconds. These values are not configurable.

The following table lists the MKA participant timer values.

Table 9. MKA participant timer values

Timer use

Timeout (parameter)

Timeout (parameter)

Per participant periodic transmission, initialized on each transmission on expiry

MKA Hello Time

or

MKA Bounded Hello Time

2.0

0.5

Per peer lifetime, initialized when adding to or refreshing the potential peers list or live peers list, expiry causes removal from the list

MKA Life Time

6.0

Participant lifetime, initialized when participant created or following receipt of an MKPDU, expiry causes participant to be deleted

Delay after last distributing a SAK, before the key server distributes a fresh SAK following a change in the live peers list while the potential peers list is still not empty

MACsec capability, desire, and encryption offset

The IEEE 802.1x-2010 standard identifies the following fields in the MKA PDU:

  • MACsec Capability

  • Desire

MACsec capability signals whether MACsec is capable of integrity and confidentiality. For information about the basic settings for MACsec capability, see the encryption-offset command description.

Encryption offset of 0, 30, or 50 starts from the byte after the SecTAG (802.1AE header). Ideally, the encryption offset should be configured for IPv4 (offset 30) and IPv6 (offset 50) to leave the IP header in cleartext. This allows routers and switches to use the IP header for LAG or ECMP hashing.

Key server

The participants in an MKA instance that agree on a key server are responsible for the following:

  • deciding on the use of MACsec

  • cipher suite selection

  • SAK generation and distribution

  • SA assignment

  • identifying the CA when two or more CAs merge

Each participant in an MKA instance uses the key server priority (an 8-bit integer) encoded in each MKPDU to agree on the key server. Each participant selects the live participant advertising the highest priority as its key server whenever the live peers list changes, provided that highest priority participant has not selected another as its key server or is unwilling to act as the key server.

If a key server cannot be selected, SAKs are not distributed. In the event of a tie for highest priority key server, the member with the highest priority SCI is chosen. For consistency with other uses of the SCI MAC address component as a priority, numerically lower values of the key server priority and SCI receive the highest priority.

Note:

Each SC is identified by an SCI that comprises a globally unique MAC address, and a port identifier unique within the system that has been allocated that address.

SA limits and network design

Each MACsec device supports 64 Tx-SAs and 64 Rx-SAs. An SA (Security Association) is the key to encrypt or decrypt the data.

As defined in IEEE 802.1AE, each SecY contains an SC. An SC is a unidirectional concept; for example, Rx-SC or Tx-SC. Each SC contains at least one SA for encryption on Tx-SC and decryption on Rx-SC. Also, for extra security, each SC should be able to roll over the SA, therefore, Nokia recommends for each SC to have two SAs for rollover purposes.

MACsec PHY is known as a MACsec security zone. Each MACsec security zone supports 64 Tx-SAs and 64 Rx-SAs. Assuming two SAs for each SC for SA rollover, each zone supports 32 Rx-SCs and 32 Tx-SCs.

The following table describes the port mapping to security zones.

Table 10. Port mapping to security zone

Platform

Ports in security zone 1

Ports in security zone 2

Ports in security zone 3

Ports in security zone 5

SA limit per security zone

7210 SAS-K 2F6C4T

Ports 1, 2, 3, 4

Ports 5, 6, 7, 8

Ports 9, 10, 11, 12

Rx-SA = 64

Tx-SA = 64

7210 SAS-K 3SFP+ 8C

Ports 1, 2, 3, 4

(1, 2, and 3 are 10GE ports)

Ports 5, 6, 7, 8

Ports 9, 10, 11

Rx-SA = 64

Tx-SA = 64

7210 SAS-Dxp 24p

Ports 1/1/19 and 1/1/20 (1 GE ports)

Ports 1/1/17 and 1/1/18 (10 GE ports)

Rx-SA = 64

Tx-SA = 64

P2P (switch-to-switch) topology

In a point-to-point topology, each router needs a single security zone, a single Tx-SC for encryption, and a single Rx-SC for decryption. Each SC has two SAs. In total, for point-to-point topology, four SAs are needed: two Rx-SAs for Rx-SC1 and two Tx-SAs for Tx-SC1.

The following figure shows the P2P topology.

Figure 7. P2P (switch-to-switch) topology

P2MP (switch to switch) topology

In a multi-point topology with N nodes, each node needs a single Tx-SC and N Rx-SC, one for each one of the peers. As such, 64 maximum Rx-SAs for each security zone translates to 32 Rx-SCs, which breaks down to only 32 peers; for example, only 33 nodes in the multipoint topology for each security zone. So from the perspective of each node, there is one Tx-SC and 32 Rx-SCs.

As shown in the following figure, when the 34th node joins the multi-point topology, the other 33 nodes that are already part of this domain do not have SAs to create an Rx-SC for this 34th node; however, the 34th node has a Tx-SC and can accept 32 peers. The 34th node starts to transmit and encrypt the PDUs based on its Tx-SC. However, because all other nodes do not have as SC for this SAI, all Rx PDUs are dropped.

Figure 8. P2MP topology

Nokia recommends that a multicast domain, for a single security zone, should not exceed 32 peers, or the summation of all the nodes in a security zone CA domain should not exceed 33. This is the same as if a security zone has four CAs; the summation of all nodes in the four CAs should be 33 or less.

SA exhaustion behavior

A security zone has 64 Rx-SAs and 64 Tx-SAs, as described in SA limits and network design. Two Rx-SAs are used for each Rx-SC for rollover purposes, and two Tx-SAs are used for Tx-SC for rollover purposes. This translates to 32 peers for each security zone.

Under each port, you can configure a max-peer command to assign the number of peers allowed on that port.

Note:

Ensure that the number of peers does not exceed the limit of maximum peers per security zone or maximum peers per port.

If the maximum peer is exceeded, the peer connectivity becomes random. In the case of a node failure or packet loss, peers join the CA randomly, on a first-come-first-served basis.

Caution:

Nokia strongly recommends that the maximum peer value is not exceeded per security zone or port.

Clear tag mode

In most Layer 2 networks, MAC forwarding is done using a destination MAC address. The 802.1AE standard requires that any field after source and destination MAC address and after the SecTAG must be encrypted. This includes the 802.1Q tags. In some VLAN switching networks, it may be needed to leave the 802.1Q tag in cleartext form.

7210 SAS allows the configuration of 802.1Q tag in cleartext form by placing the 802.1Q tag before the SecTAG, or encrypts it by placing it after the SecTAG.

The following table lists the MACsec encryption of 802.1Q tags when the clear-tag is configured.

Table 11. MACsec encryption of 802.1Q tags with clear-tag configured

Unencrypted format

Clear-tag-mode configuration

Pre-encryption (Tx)

Pre-decryption (Rx)

Single tag (dot1q)

Single-tag

DA, SA, TPID, VID, Etype

DA, SA, TPID, VID, SecTAG

Single tag (dot1q)

Double-tag

DA, SA, TPID, VID, Etype

DA, SA, TPID, VID, SecTAG

Double tag (q-in-q)

Single-tag

DA, SA, TPID1, VID1, IPID2, VID2, Etype

DA, SA, TPID1, VID1, SecTAG

Double tag (q-in-q)

Double-tag

DA, SA, TPID1, VID1, IPID2, VID2, Etype

DA, SA, TPID1, VID1, IPID2, VID2, SecTAG

802.1X tunneling and multihop MACsec

MACsec is an Ethernet packet and, as with any Ethernet packet, can be forwarded through multiple switches using Layer 2 forwarding. The encryption and decryption of the packets is done using the 802.1x (MKA) capable ports.

To ensure that the MKA is not terminated on an intermediate switch or router, enable 802.1x tunneling on the corresponding port.

Verify if tunneling is enabled using the following command.

*A:SwSim28>config>port>ethernet>dot1x# info 
----------------------------------------------
      tunneling

By enabling tunneling, the 802.1x MKA packets transit that port without being terminated, because such MKA negotiation does not occur on a port that has 802.1x tunneling enabled.

EAPoL destination address

The MKA packets are transported over EAPoL with a multicast destination MAC address.

In cases where a point-to-point connection from the MKA to a peer node over a Layer 2 multihop cloud is required, you can set the EAPoL destination MAC address to the peer MAC address. This forces the MKA to traverse multiple nodes and establish an MKA session with the specific peer.

Mirroring consideration

Mirroring is performed before MACsec encryption. Therefore, if a port is MACsec-enabled and is also mirrored, all the mirror packets are in cleartext form.

Ethernet combo ports on 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support combo ports. The combo port provides two physical interface options to the user. One option is to configure it as an SFP port allowing for fiber-based connectivity and speeds of 100/1000 Mb/s with the advantages of using suitable optics for longer reach. The other option is to configure it as a fixed copper port, which provides cheaper connectivity for shorter reach. The SFP port support 100/1000 Mb/s speeds and the copper port can support 10/100/1000Mbps speed. The combo port can be configured either as an SFP port or a copper port. Both interfaces cannot be used simultaneously.

  • 7210 SAS-K 2F1C2T provide one Combo port

  • 7210 SAS-K 2F6C4T provides six Combo ports

  • 7210 SAS-K 3SFP+ 8C provides eight Combo ports

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 that suitable for storing connection information about adjacent stations is established.

  • Provides compatibility with a number of MIBs. For more information, see LLDP internal architecture for a network node.

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

Figure 9. LLDP internal architecture for a network node

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

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

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

Figure 10. Generic customer use case for LLDP

LLDP protocol features

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

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

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

  • Type identifies what kind of information is being sent.

  • Length indicates the length of the information string in octets.

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

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

  • Chassis ID TLV

  • Port ID TLV

  • Time To Live TLV

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

  • End Of LLDPDU TLV

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

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

A TTL value of 0 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 properly 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 subtype using the port-id-subtype option. Three options are supported for the port-id-subtype:

  • tx-if-alias — Transmit the ifAlias String (subtype 1) that describes the port as stored in the IFMIB, either user configured description or the default entry (that is,10/100/Gig ethernet SFP)

  • tx-if-name — Transmits the ifName string (subtype 5) that describes the port as stored in the IFMIB, ifName info.

  • tx-local — The interface ifIndex value (subtype 7)

IPv6 (address subtype 2) and IPv4 (address subtype 1) LLDP System Management addresses are supported.

LLDP tunneling for Epipe service

Customers who subscribe to Epipe service consider the Epipe as a wire, and run LLDP between their devices which are located at each end of the Epipe. To facilitate this, the 7210 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 config>port>ethernet>lldp>destmac-nearest-bridge. If the 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 lists 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. It is recommended that the customers use these MAC address where possible to conform to standards. This command allows legacy LLDP implementations that do not support these additional destinations MAC addresses to tunnel LLDP frames that use the nearest-bridge destination MAC address.

LLDP media endpoint discovery

Note:

This feature is only supported on the 7210 SAS-Dxp.

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, which are attached to an Ethernet LAN or WAN, to advertise their supported functionalities to other nodes attached to the same LAN segment. See Link Layer Discovery Protocol for more information about IEEE 802.1AB.

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

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

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

The following TLVs are supported for LLDP-MED:

  • LLDP-MED Capabilities TLV

  • Network Policy TLV

LLDP-MED reference model

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

The 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

The LLDP-MED endpoint devices are composed of three subtypes, as defined in ANSI/TIA-1057:

  • generic endpoints (Class I)

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

  • media endpoints (Class II)

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

  • communication device endpoints (Class III)

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

The following figure shows the LLDP-MED reference model.

Note:

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

Figure 11. LLDP-MED reference model

LLDP-MED network connectivity device functions

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

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

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

Note:

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

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

Note:

See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about configuring network policy parameters using commands in the config>system>lldp>lldp-med context.

LLDP-MED endpoint device move notification

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

Modified use of TLVs defined in LLDP

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

Port loopback for Ethernet ports

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

The following sections describe the port loopback functionality.

Port loopback without MAC swap

Note:

Port loopback without MAC swap is supported on all 7210 SAS platforms as described in this document.

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 Epipe services. This command affects all the services configured on the port, therefore the user is advised to ensure all the configuration guidelines mentioned for this feature in the command description are followed.

Port loopback with MAC swap

Note:

Port loopback with MAC swap is only supported on the 7210 SAS-D and 7210 SAS-Dxp.

The 7210 SAS provides port loopback 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 Epipe 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.

Per-SAP loopback with MAC swap

Note:

Per-SAP loopback with MAC swap is only supported on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C provide per-SAP loopback support with MAC swap. When the SAP loopback command is enabled, all the packets that are sent out the SAP configured with loopback are looped back at the egress of the SAP back into the ingress of the SAP. The node swaps the MAC addresses before the packet hits the ingress of the SAP. After it is received back at SAP ingress, it processes these packets as per the service configuration for the SAP. Only traffic sent out of the test SAP is looped back. The loopback does not affect other SAPs and services configured on the same port. Per-SAP loopback is supported for use with both VPLS and Epipe services.

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 if 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 access uplink and access ports.

LAG features

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

Software capabilities: Conforms to the IEEE LAG implementation.

Configuring LAGs

LAG configuration guidelines include:

  • The 7210 SAS-D and 7210 SAS-Dxp support up to four 1GE ports in a LAG. The 7210 SAS-Dxp also supports up to two 10GE ports in a LAG.

  • The 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T support up to three 1GE ports in a LAG.

  • The 7210 SAS-K 3SFP+ 8C supports up to three 1GE ports or two 10GE ports in a LAG.

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

  • On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, a single set of counters is used to account for the traffic received on the LAG.

  • 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, autonegotiation must be disabled or set to limited mode to ensure only a specific speed is advertised.

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

Figure 12. LAG configuration

LAG and QoS policies on 7210 SAS-D and 7210 SAS-Dxp

On the 7210 SAS-D and 7210 SAS-Dxp, 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 100Mbps, 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 100Mbps.

On the 7210 SAS-D and 7210 SAS-Dxp, 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 100Mbps, 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 200Mbps of traffic out of the LAG. The advantage of this method over a scheme where the PIR is divided equally among all the member ports of the LAG is that, a single flow can use the entire SLA. The disadvantage is that, the overall SLA can be exceeded if the flows span multiple ports.

LAG and QoS policies on 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, an ingress QoS policy is applied to the aggregate traffic that is received through all the member ports of the LAG and mapped to that service entity (for example: access-uplink port). For example, if an ingress policy is configured with a queue shaper rate of PIR 100Mbps for an access-uplink LAG configured with two ports, then the queue shaper limits the traffic received through the two ports to a maximum of 100Mbps.

On the 7210 SAS-K 2F1C2T,7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, 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 100Mbps, and applied to an access-uplink LAG configured with two port members, then each port can send out 100 Mbps of traffic for a total of 200Mbps of traffic out of the LAG (assuming flows are distributed among the 2 ports). 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.

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 port link damping feature guards against excessive port transitions. Any initial port transition is immediately advertised to upper layer protocols, but any subsequent port transitions are not advertised to upper layer protocols until a configured timer has expired.

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

LACP

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

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.

LAG and ECMP hashing

Note:

See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C 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 following methods is applied:

  • equal cost multi-path (ECMP)

  • Link Aggregation (LAG)

A 7210 SAS can deploy both methods at the same time, meaning it can use ECMP of two or more Link Aggregation Groups (LAG) or single links.The Nokia implementation supports per flow hashing used to achieve uniform loadspreading and per service hashing designed to provide consistent per service forwarding. Depending on the type of traffic that needs to be distributed into an ECMP or a LAG, different variables are used as input to the hashing algorithm.

The following tables list the packets used for hashing on 7210 SAS platforms.

LAG hashing algorithm for the 7210 SAS-D

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

Note:

The following notes apply to LAG hashing algorithm for services configured on 7210 SAS-D:

  • 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 VLAN ID is considered for learned PBB and non-IP traffic in the VPLS service only for traffic ingressing at dot1q, Q.*, Q1.Q2 SAPs.

  • Only the outer VLAN tag is used for hashing.

Table 12. LAG hashing algorithm for services configured on 7210 SAS-D

Traffic type

Packet fields used

BDA

BSA

EtherType

Ingress Port-ID

ISID

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)

Non-IP traffic (learned)

Non-IP traffic (unlearned)

Epipe service

SAP to SAP

IP traffic

PBB traffic

Non-IP traffic

IES service (IPv4):

IES SAP to IES SAP

IPv4 unicast traffic

LAG hashing algorithm for the 7210 SAS-Dxp

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

Note:

The following notes apply to LAG hashing algorithm for services configured on 7210 SAS-Dxp:

  • 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 VLAN ID is considered for learned PBB and non-IP traffic in the VPLS service only for traffic ingressing at dot1q, Q.*, Q1.Q2 SAPs.

  • Only the outer VLAN tag is used for hashing.

Table 13. LAG hashing algorithm for services configured on 7210 SAS-Dxp

Traffic type

Packet fields used

BDA

BSA

EtherType

Ingress Port-ID

ISID

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)

Non-IP traffic (learned)

Non-IP traffic (unlearned)

Epipe service

SAP to SAP

IP traffic

PBB traffic

Non-IP traffic

IES service (IPv4):

IES SAP to IES SAP

IPv4 unicast traffic

LAG hashing algorithm for the 7210 SAS-K 2F1C2T

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

Note:

The following notes apply to LAG hashing algorithm for services configured on 7210 SAS-K 2F1C2T:

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

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

Table 14. LAG hashing algorithm for services configured on 7210 SAS-K 2F1C2T

Traffic type

Packet fields used

BDA

BSA

Ingress Port-ID

IP Protocol

Source and destination

VLAN

MAC

IP

L4 Ports

Outer

Inner

VPLS Service

SAP to SAP

IP traffic (learned and unlearned)

PBB traffic (learned and unlearned)

MPLS traffic (learned and unlearned)

Non-IP traffic (learned and unlearned)

Epipe Service

SAP to SAP

IP traffic

PBB traffic

MPLS traffic

3

Non-IP traffic

LAG hashing algorithm for the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following table describes the packet fields used for hashing for services configured on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

Note:

The following notes apply to LAG hashing algorithm for services configured on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C:

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

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

  • SAP to SAP and SAP to SDP: Packet fields for IP traffic are used for hashing only if the number of VLAN tags is two or fewer. IP packets with more than two tags use the same hashing parameters as non-IP traffic.

  • SDP to SAP and SDP to SDP: Packet fields for IP traffic are used for hashing only if the number of VLAN tags is 1 or 0. IP packets with more than one tag use the same hashing parameters as non-IP traffic.

  • RVPLS routed traffic uses the same parameters as traffic in IES service.

  • For IPv6 packets, the source and destination IP addresses are XORed and collapsed into a 32-bit value.

Table 15. LAG hashing algorithm for services configured on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Traffic type

Packet fields used

Ingress Port-ID

IP Protocol

MPLS Label Stack

Source and destination

VLAN

MAC

IP

L4 Ports

Outer

Inner

VPLS Service

SAP to SAP

IP traffic (learned and unlearned)

MPLS traffic (learned and unlearned)

4

Non-IP traffic (learned and unlearned)

VPLS Service

SAP to SDP

IP traffic (learned and unlearned)

MPLS traffic

4

Non-IP traffic (learned and unlearned)

VPLS Service

SDP to SAP5

IP traffic (learned and unlearned)

Non-IP traffic (learned and unlearned)

VPLS Service

SDP to SDP5

IP traffic (learned and unlearned)

Non-IP traffic (learned and unlearned)

Epipe Service

SAP to SAP

IP traffic

MPLS traffic

4

Non-IP traffic

Epipe Service

SAP to SDP

IP traffic

MPLS traffic

4

Non-IP traffic

Epipe Service

SDP to SAP5

IP traffic (learned and unlearned)

Non-IP traffic (learned and unlearned)

MPLS - LSR

All traffic

6

IES Service (IPv4)

IES SAP to IES SAP

7

IES Service (IPv6)

IES SAP to IES SAP

7

IES Service (IPv4)

IES SAP to IPv4 network port interface

7

IES Service (IPv6)

IES SAP to IPv6 network port interface

7

IES Service (IPv4) interface

IPv4 network port interface to IES SAP

7

IES Service (IPv6)

IPv6 network port interface to IES SAP

7

Network port (IPv4) interface

IPv4 network interface to IPv4 network interface

7

Network port (IPv6) interface

IPv6 network interface to IPv6 network interface

7

VPRN

SAP to SAP, SDP to SAP, SAP to SDP

7

Packet fields used for pseudowire hash-label generation on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following table describes the packet fields used by different services and traffic types to generate the PW hash label.

Table 16. Packet fields used for PW hash-label generation on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Traffic type

Packet fields used

Ingress Port-ID

IP Protocol

Source and destination

VLAN

MAC

IP

L4 Ports

Outer

Inner

VPLS and Epipes services

SAP to SDP

IP traffic (learned and unlearned)

MPLS traffic (learned and unlearned)

8

Non-IP traffic (learned and unlearned)

VPLS services

SDP to SDP

IP traffic (learned and unlearned)

Non-IP traffic (learned and unlearned)

LDP ECMP hashing algorithm for the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The following table describes the packet fields used for LDP ECMP hashing for label edge router (LER) and label switching router (LSR) devices on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

Table 17. LDP ECMP hashing algorithm for LER and LSR on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Traffic type

Packet fields used

Ingress Port-ID

IP Protocol

MPLS Label Stack

Source and destination

VLAN

MAC

IP

L4 Ports

Outer

Inner

VPLS and Epipe services

SAP to SDP (iLER)

IP traffic

MPLS traffic

9

Non-IP traffic

LSR

MPLS traffic

10

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 the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

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

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.

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

    • The configuration of multiple subgroups per PE in an MC-LAG is supported.

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

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

    • The communication protocol provides heartbeat mechanism to enhance robustness of the MC-LAG operation and detect node failures.

    • It supports operator actions that force an operational change on nodes.

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

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

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

MC-LAG L2 dual homing to remote PE pairs and MC-LAG L2 dual homing to local PE-pairs show different combinations of supported MC-LAG attachments. The supported configurations can be divided into the following subgroups:

  • dual-homing to remote PE pairs

    • both end-points attached with MC-LAG

    • one end-point attached

  • dual-homing to local PE pair

    • both end-points attached with MC-LAG

    • one end-point attached with MC-LAG

    • both end-points attached with MC-LAG to two overlapping pairs

The following figure shows dual homing to remote PE pairs.

Figure 13. MC-LAG L2 dual homing to remote PE pairs

The following figure shows dual homing to local PE pairs.

Figure 14. 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 pseudowire 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.

Point-to-point redundant connection across Layer 2/3 VPN network

The following figure shows the connection between two CPE/access nodes across network based on Layer 2/3 VPN pseudowires. 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 the following figure 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 15. P2P redundant connection through a Layer 2 VPN network

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-K 2F6C4T can only peer with another 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C can only peer with another 7210 SAS-K 3SFP+ 8C. 7210 SAS-K 2F6C4T cannot be configured with 7210 SAS-K 3SFP+ 8C as its MC-LAG peer.

  • MC-LAG is only supported when using MPLS uplinks with network ports. It is not supported with access-uplink ports.

  • The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C can also be MC-LAG clients, with an active/standby LAG configuration used to dual-home to access-aggregation routers when using access-uplink ports. In this scenario the user has an option to provision the uplinks as access-uplink ports to dual-home into two aggregation PE routers that are configured as MC-LAG peers.

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
        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
                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
        exit
----------------------------------------------
*7210-SAS>config>redundancy#

MC-LAG support on 7210 SAS-D and 7210 SAS-K 2F1C2T

Multi-Chassis LAG (MC-LAG) is an extension of a LAG concept that provides node-level redundancy in addition to the link-level redundancy provided by ‟regular LAG”. Typically, MC-LAG is deployed network-wide, along with IP/MPLS, providing redundant connections between different access end points. In a typical MC-LAG deployment, a pair of nodes are configured to be MC-LAG peers (also referred to as MC-LAG servers), and access devices are connected to the MC-LAG peers using LAGs with active/standby LAG groups.

The 7210 SAS-D, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C platforms can be connected to an MC-LAG-enabled node, such as an MC-LAG server. In particular, these platforms allow for provisioning of links into subgroups in a LAG and support active/standby links. The MC-LAG solution can be achieved with or without subgroups configured.

G.8032 protected Ethernet rings

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

See ‟G.8032 Protected Ethernet Rings” in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Services Guide for more information about Ethernet rings.

802.1x network access control

The Nokia 7210 SAS supports network access control of client devices (PCs, STBs, and so on) on an Ethernet network using the IEEE. 802.1x standard. 802.1x is known as Extensible Authentication Protocol (EAP) over a LAN network or EAPOL.

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 that is 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.

802.1x basics

  • The supplicant — This is the end-user device that requests access to the network.

  • The authenticator — Controls access to the network. Both the supplicant and the authenticator are referred to as PAEs.

  • The authentication server — 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.

The router initiates 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 does not 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.

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 logout, 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.

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.

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.

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 applies only to port-based Epipe SAPs because 802.1x runs at the port level not the 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).

Enabling 802.1x tunneling requires the 802.1x mode to be set to force-auth. Enforcement is performed at the CLI level.

802.3ah OAM

802.3ah Clause 57 (EFM OAM) defines the Operations, Administration, and Maintenance (OAM) sublayer, 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 therefore 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, critical event, 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.

  • Generation of dying gasp message on access uplink ports on power failure.

  • EFM OAMPDU tunneling.

  • Timer for EFM OAM in 500ms interval (minimum).

OAM events

EFM OAM defines a set of events that may impact link operation. The following critical link events (defined in 802.3ah clause 57.2.10.1) are supported:

  • Link fault: the PHY has determined a fault has occurred in the receive direction of the local DTE.

  • Dying gasp: an unrecoverable local failure condition has occurred.

  • Critical event: an unspecified critical event has occurred.

Note:

The dying gasp event is not supported on the 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p.

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.

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.

Note that when a port is in loopback mode, service mirroring will not work if the port is a mirror-source or a mirror-destination.

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 port level not 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 enabling 802.3ah for a port and enabling OAM PDU tunneling for the same port are mutually exclusive. That is, on a specific port either 802.3ah tunneling can be enabled or 802.3ah can be enabled, but both cannot be enabled together.

MTU configuration guidelines

Observe the following general rules when planning your physical MTU configurations:

The 7210 SAS must contend with MTU limitations at many service points. The physical (access and access uplink) port, MTU values must be individually defined.

  • Identify the ports that are designated as access uplink ports as these are intended to carry service traffic.

  • MTU values should not be modified frequently.

  • The access uplink port MTU on the 7210 SAS-D and 7210 SAS-Dxp must be greater than or equal to the access port MTU plus the overhead added by the system (for example, typically 4 bytes of VLAN tag are added when a packet is transmitted using the QinQ access uplink).

  • The 7210 SAS-K 2F1C2T supports service-mtu. The service MTU values must conform to the following conditions:

    • The service MTU must be less than or equal to the access-uplink port MTU.

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

  • The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support service-mtu. The service MTU values must conform to the following conditions:

    • The service MTU must be less than or equal to the access-uplink port MTU.

    • The service MTU must be less than or equal to the SDP path MTU when the service is configured to use MPLS SDPs.

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

Default MTU values

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

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

uplink

1522

Other Ethernet

uplink

9212

Ethernet

hybrid

9212

Modifying MTU defaults on 7210 SAS-D and 7210 SAS-Dxp

On the 7210 SAS-D and 7210 SAS-Dxp, MTU parameters can be modified only on the port level.

The port-level MTU parameters configure the maximum payload MTU size for an Ethernet port that is part of a multilink bundle or LAG.

The default MTU values should be modified to ensure that packets are not dropped because of frame size limitations.

Modifying MTU defaults on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

MTU parameters can be modified on the port level and at the service level.

  • The port-level MTU parameters configure the maximum payload MTU size for an Ethernet port that is part of a multi-link bundle or LAG.

  • The service-level MTU parameters configure the service payload (Maximum Transmission Unit – MTU) in bytes for the service ID overriding the service-type default MTU.

The default MTU values should be modified to ensure that packets are not dropped because of frame size limitations.

The service MTU must be less than or equal to both the access SAP port MTU and the access-uplink port MTU values. If the service from the 7210 SAS-K 2F1C2T is transported over an SDP in the IP/MPLS network (the SDP is not originating or terminating on the node), the operational path MTU can be less than the service MTU. In this case, user may need to modify the MTU value accordingly.

Configuration example for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C using SAPs in the service

In order for the maximum length service frame to successfully travel from a local ingress SAP to a remote egress SAP, the MTU values configured on the port on which the local ingress SAP is provisioned and the port on which the egress SAP is provisioned must be coordinated to accept the maximum frame size the service can forward.

The following figure shows an example of the targeted MTU values to configure for an Epipe service (ALA-A and ALA-B).

Figure 16. MTU configuration example

Because ALA-A uses Dot1q encapsulation, the port 1/1/1 MTU must be set to 1518 to be able to accept a 1514-byte service frame (see the following table for MTU default values). Each of the access uplink port MTU must be set to at least 1518 as well. Finally, the MTU of ALA-B SAP (access port 1/1/2) must be at least 1514, as it uses null encapsulation.

The following table describes sample MTU configuration values.

Table 19. MTU configuration example values (ALA-A with dot1q SAP type, ALA-B with null encap)

ALA-A

ALA-B

Access (SAP)

Access Uplink (SAP)

Access Uplink (SAP)

Access (SAP)

Port (slot/MDA/port)

1/1/1

1/1/24

1/1/18

1/1/2

Mode type

access (dot1q)

access-uplink (QinQ)

access-uplink (QinQ)

access (null)

MTU

1518

1518

1518

1514

Instead, if ALA-A uses a dot1q-preserve SAP on port 1/1/1, then port 1/1/1 MTU must be set to 1518 to be able to accept a 1514-byte service frame (see the following table for MTU default values). Each of the access uplink port MTU must be set to at least 1522 as well. Finally, the MTU of ALA-B SAP (access port 1/1/2) must be at least 1518, as it uses Dot1q encapsulation.

The following table describes sample MTU configuration values.

Table 20. MTU configuration example Values (ALA-A with dot1q-preserve SAP type, ALA-B with dot1Q encap)

ALA-A

ALA-B

Access (SAP)

Access Uplink (SAP)

Access Uplink (SAP)

Access (SAP)

Port (slot/MDA/port)

1/1/1

1/1/24

1/1/18

1/1/2

Mode type

access (dot1q-preserve)

access-uplink (QinQ)

access-uplink (QinQ)

access (dot1q-preserve)

MTU

1518

1522

1522

1518

Modifying MTU defaults on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C when using SDP in the service

MTU parameters must be modified on the service level as well as the port level.

  • The service-level MTU parameters configure the service payload (Maximum Transmission Unit – MTU) in bytes for the service ID overriding the service-type default MTU.

  • The port-level MTU parameters configure the maximum payload MTU size for an Ethernet port or LAG.

The default MTU values must be modified to ensure that packets are not dropped because of frame size limitations.

In a service configured to use access SAPs and access-uplinks SAPs, the service MTU must be less than or equal to both the access SAP port MTU and the access uplink port MTU values. If the service from the 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C is transported over an SDP in the IP/MPLS network (the SDP is not originating or terminating on the node), the operational path MTU can be less than the service MTU. In this case, the user may need to modify the MTU value accordingly.

In a service configured to use access SAPs and MPLS SDPs, the service MTU must be less than or equal to both the SAP port MTU and the SDP path MTU values. When an SDP is configured on a network port using default port MTU values, the operational path MTU can be less than the service MTU. In this case, enter the show service sdp command to check the operational state. If the operational state is down, modify the MTU value accordingly.

Deploying preprovisioned components

Cards and MDAs are auto-provisioned by the system and do not need to be provisioned by the user.

MAC authentication

Note:

MAC authentication is only supported on 7210 SAS-Dxp.

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.

MAC authentication basics

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

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

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

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

    • User-Name

      This attribute specifies the source MAC address of the client device.

    • User-Password

      This attribute specifies the source MAC address of the client device in an encrypted format.

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

    • Calling-Station-Id

      This attribute specifies the source MAC address of the client device.

    • NAS-IP-Address

      This attribute specifies the IP address of the device acting as the authenticator.

    • NAS-Port

      This attribute specifies the physical port of the device acting as the authenticator.

    • Message-Authenticator

      This attribute is used to authenticate and protect the integrity of Access Request messages to prevent spoofing attacks.

  4. 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 step3 and reattempts approval of the MAC address.

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

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.

VLAN authentication

Note:

VLAN authentication is only supported on 7210 SAS-Dxp.

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.

VLAN authentication basics

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

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

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

  3. 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 step1.

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

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.

Layer 2 control protocol interaction with authentication methods

The following table 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

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

Configuration process overview

The following figure shows the process to provision chassis slots, line cards, MDAs, and ports.

Figure 17. Slot, card, MDA, and port configuration and implementation flow

Configuring physical ports with CLI

This section provides information to configure cards, MDAs, and ports.

Preprovisioning guidelines

7210 SAS routers have a console port to connect terminals to the router. The 7210 SAS does not support a management port.

Configure parameters from a system console connected to a console port, using Telnet to access a the device remotely or SSH to open a secure shell connection.

Predefining entities

The 7210 SAS auto-provisions card and MDA types.

On 7210 SAS platforms, where cards/MDAs are not auto-provisioned, to initialize a card, the chassis slot, line card type, and MDA type must match the preprovisioned parameters. In this context, preprovisioning means to configure the entity type (such as the line card type, MDA type, port, and interface) that is planned for a chassis slot, line card, or MDA. Preprovisioned entities can be installed but not enabled or the slots can be configured but remain empty until populated. Provisioning means that the preprovisioned entity is installed and enabled.

You can:

  • Preprovision ports and interfaces after the line card and MDA types are specified.

  • Install line cards in slots with no preconfiguration parameters specified. When the card is installed, the card and MDA types must be specified. This is required on 7210 SAS chassis based platforms or on those platforms that support expansion slots. Typically, on 7210 SAS platforms that do not support any removable cards and MDAs, the cards are preprovisioned for fixed ports.

  • Install a line card in a slot provisioned for a different card type (the card will not initialize). The existing card and MDA configuration must be deleted and replaced with the current information. This is required on 7210 SAS chassis based platforms or on those platforms that support expansion slots. Typically, on 7210 SAS platforms that do not support any removable cards and MDAs, the MDAs are preprovisioned for all fixed ports.

Preprovisioning a port

It is recommended to configure an access Ethernet port for customer-facing traffic on which services are configured.

An encapsulation type may be specified to distinguish services on the port or channel. Encapsulation types are not required for network ports.

To configure an Ethernet access port, see Configuring Ethernet port parameters.

Basic configuration

On 7210 SAS platforms that do not support any removable cards and MDAs, the most basic configuration must have the following:

  • Identify chassis slot.

  • Specify line card type (must be an allowed card type).

  • Identify MDA slot.

  • Specify MDA type (must be an allowed MDA type).

  • Identify specific port to configure.

Common configuration tasks

This section describes common configuration tasks.

Configuring Ethernet port parameters

This section describes Ethernet port configuration.

Ethernet network port

A network port is network facing and participates in the service provider transport or infrastructure network processes.

The following is a sample network port configuration output.

A:ALA-B>config>port# info
----------------------------------------------
description ‟Ethernet network port”
ethernet
exit
no shutdown
----------------------------------------------
A:ALA-B>config>port#

Ethernet network port configuration is supported only on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

Ethernet access-uplink port

An access-uplink port is network facing and participates in the service provider transport or infrastructure network processes. This is similar to a network port concept.

A SAP can be created when a port is configured in access uplink mode. When a port is configured in access uplink mode, then the encapsulation type of the port is set to QinQ.

The following is a sample network port configuration output.

A:ALA-B>config>port# info
----------------------------------------------
description "Ethernet Access Uplink port"
----------------------------------------------
        ethernet
            mode access uplink
        exit
        no shutdown
----------------------------------------------------
A:ALA-B>config>port#

Access uplink port configuration is supported on the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

Ethernet access port

Services are configured on access ports used for customer-facing traffic. If a Service Access Port (SAP) is to be configured on a port, it must be configured as access mode or access uplink mode. When a port is configured for access mode, the appropriate encapsulation type can be specified to distinguish the services on the port. When a port has been configured for access mode, multiple services may be configured on the port.

The following is a sample Ethernet access port configuration (for 7210 SAS-D) output.

*A:7210-SAS>config>port# info 
----------------------------------------------
        ethernet
            mode access 
            access
                egress
                exit
            exit
            encap-type dot1q
            mtu 9212
        exit
        no shutdown
----------------------------------------------
*A:7210-SAS>

Access port configuration is supported on the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.

Configuring 802.1x authentication port parameters

The following is a sample of an 802.1x port configuration output.

A:ALA-A>config>port>ethernet>dot1x# info detail
----------------------------------------------
                port-control auto
                radius-plcy dot1xpolicy
                re-authentication
                re-auth-period 3600
                max-auth-req 2
                transmit-period 30
                quiet-period 60
                supplicant-timeout 30
                server-timeout 30 
----------------------------------------------

Configuring MAC authentication port parameters

Note:

MAC authentication is only supported on 7210 SAS-Dxp.

The 7210 SAS supports a fallback MAC authentication mechanism for client devices (for example, PCs and cameras) on an Ethernet network that do not support 802.1x EAP.

MAC authentication provides protection against unauthorized access by forcing the device connected to the 7210 SAS to have its MAC address authenticated by a RADIUS server before the device is able to transmit packets through the 7210 SAS.

Use the following CLI syntax to configure MAC authentication for an Ethernet port.

port port-id ethernet
         dot1x
             mac-auth
             mac-auth-wait seconds
             port-control auto
             quiet-period seconds
             radius-plcy name
Command usage to configure MAC authentication for an Ethernet port
config# port 1/1/2 ethernet dot1x
config>port>ethernet>dot1x# mac-auth
config>port>ethernet>dot1x# mac-auth-wait 20
config>port>ethernet>dot1x# port-control auto
config>port>ethernet>dot1x# quiet-period 60
config>port>ethernet>dot1x# radius-plcy dot1xpolicy
Sample port configuration output

Use the info detail command to display port configuration information.

SAS-T>config>port>ethernet>dot1x# info detail
----------------------------------------------
             port-control auto
             radius-plcy dot1xpolicy
             re-authentication
             re-auth-period 3600
             max-auth-req 2
             transmit-period 30
             quiet-period 60
             supplicant-timeout 30
             server-timeout 30
             mac-auth
             mac-auth-wait 20
----------------------------------------------
SAS-T>config>port>ethernet>dot1x#

Configuring VLAN authentication port parameters

Note:

VLAN authentication is only supported on 7210 SAS-Dxp.

The 7210 SAS supports VLAN authentication for client devices (for example, PCs and STBs) on an Ethernet network.

VLAN authentication provides protection against unauthorized access by forcing the device connected to the 7210 SAS to be authenticated by a RADIUS server before the device is able to transmit packets through the 7210 SAS.

Use the following CLI syntax to configure VLAN authentication for an Ethernet port.

port port-id ethernet
         dot1x
             vlan-auth
             port-control auto
             quiet-period seconds
             radius-plcy name
Command usage to configure VLAN authentication for an Ethernet port
config# port 1/1/2 ethernet dot1x
config>port>ethernet>dot1x# vlan-auth
config>port>ethernet>dot1x# port-control auto
config>port>ethernet>dot1x# quiet-period 60
config>port>ethernet>dot1x# radius-plcy dot1xpolicy
Sample port configureation output

Use the info detail command to display port configuration information.

SAS-T>config>port>ethernet>dot1x# info detail
----------------------------------------------
             port-control auto
             radius-plcy dot1xpolicy
             re-authentication
             re-auth-period 3600
             max-auth-req 2
             transmit-period 30
             quiet-period 60
             supplicant-timeout 30
             server-timeout 30
             vlan-auth
----------------------------------------------
SAS-T>config>port>ethernet>dot1x#

Configuring LAG parameters

The following are general rules for configuring LAGs:

  • The 7210 SAS-D and 7210 SAS-Dxp support up to four 1GE ports in a LAG. The 7210 SAS-Dxp also supports up to two 10GE ports in a LAG.

  • The 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T support up to three 1GE ports in a LAG.

  • The 7210 SAS-K 3SFP+ 8C supports up to three 1GE ports or two 10GE ports in a LAG.

  • All ports in the LAG must share the same characteristics (speed, duplex, hold-timer, and so on). The port characteristics are inherited from the primary port.

  • Autonegotiation must be disabled or set to limited mode for ports that are part of a LAG to guarantee a specific port speed.

  • Ports in a LAG must be configured as full duplex.

The following is a sample LAG configuration output.

A:ALA-A>config>lag# info detail
----------------------------------------------
        description "LAG2"
        mac 04:68:ff:00:00:01
        port  1/1/1
        port  1/3/1
----------------------------------------------
A:ALA-A>config>lag#
A:ALA-A>config>lag# info detail
----------------------------------------------
description "LAG2"
mac 04:68:ff:00:00:01
port 1/1/1
port 1/1/2
port 1/1/3
dynamic-cost
port-threshold 2 action down
----------------------------------------------
A:ALA-A>config>lag#

CRC error monitoring

Note:

This feature is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-K 2F1C2T.

This feature allows the user to track CRC (cyclic redundancy check) errors received on a specific port and notify them. The detection mechanism is based around a configurable threshold specified by the administrator. Two thresholds are configurable, one for CRC degrade and one for CRC signal fail. The first threshold crossing generates an alarm, log entry, trap, but does not bring the physical port down, while the second (signal fail) threshold crossing logs an alarm, trap generation, and brings the port operationally down.

The thresholds are configurable with the following CLI command config>port>ethernet crc-monitor.

This behavior is enabled on a per-port basis. By default, the command and functionality is disabled for the signal degrade and the signal fail.

The user can configure different values for the sf-threshold and the sd-threshold. However, sf-threshold value must be less than or equal to the sd-threshold value.

The values provided by the user for threshold and multiplier is used to compute the error ratio as (Multiplier * (10 ^ - (threshold value)). Port Stats are collected once per second and accumulated over the configured window size. Each second, the oldest sample is discarded and the new sample is added to a running total. If the error ratio exceeds the configured threshold (the preceding computation) over the window size for two consecutive seconds, appropriate actions are taken as follows:

  • If the number of CRC errors exceeds the signal degrade threshold value, a log warning message, syslog event and SNMP trap with the message ‟CRC errors in excess of the configured degrade threshold <M>*10e-<N> Set” is raised.

  • If the CRC error rate increases further and exceeds configured the signal fail threshold value, an alarm log message, syslog event and SNMP trap should be raised, and the port should be brought operationally down.

When the condition is cleared, a SNMP trap message to clear the event is sent out.

Service management tasks

This section describes basic procedures of the service management tasks:

To change an MDA type already provisioned for a specific slot/card, first you must shut down the slot/MDA/port configuration and then delete the MDA from the configuration. Modify and delete operations can be performed only on the MDAs that are not auto equipped or auto provisioned.

Use the following syntax to modify an MDA.

config> port port-id
     shutdown
config> card slot-number
     shutdown
     [no] mda mda-number
     [no] mda-type mda-type
     shutdown

Modifying a card type

The modify operation cannot be performed on an IOM card that is auto equipped and auto provisioned during bootup and is fixed.

Deleting a card

The delete operation cannot be performed on an IOM card that is auto equipped and auto provisioned during bootup and is fixed.

Deleting port parameters

Use the following syntax to delete a port provisioned for a specific card.

config>port port-id
     shutdown
     no port port-id

Card, MDA, and port command reference

Command hierarchies

Configuration commands

MACsec commands for 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p
config 
    - macsec 
        - connectivity-association ca-name [create]
        - no connectivity-association ca-name
            - cipher-suite {cipher-suite}
            - no cipher-suite
            - clear-tag-mode clear-tag-mode
            - no clear-tag-mode 
            - description description-string
            - no description 
            - encryption-offset encryption-offset
            - no encryption-offset 
            - [no] macsec-encrypt
            - [no] replay-protection 
            - replay-window-size number-of-packets
            - no replay-window-size 
            - [no] shutdown
            - [no] static-cak
                - active-psk active-pre-shared-key
                - no active-psk
                - mka-key-server-priority priority
                - no mka-key-server-priority
                - pre-shared-key pre-shared-key-index [encryption-type encryption-type] [create]
                - no pre-shared-key pre-shared-key-index 
                    - cak hex-string [hash | hash2]
                    - no cak
                    - ckn hex-string
                    - no ckn
Ethernet commands
Port Ethernet QoS commands
config 
    - [no] port {port-id}
        - ethernet
            - access
                - accounting-policy acct-policy-id
                - no accounting-policy
                - [no] collect-stats
                - egress
                    - qos policy-id
                    - no qos
                - uplink
                    - accounting-policy acct-policy-id
                    - no accounting-policy
                    - [no] collect-stats
                    - qos policy-id 
                    - no qos
                    - queue-policy name
                    - no queue-policy
            - egress-rate sub-rate [max-burst size-in-kbits]
            - no egress-rate
            - egress-scheduler-policy port-scheduler-policy-name
            -  no egress-scheduler-policy
            - [no] enable-dei
            - network
                - accounting-policy policy-id
                - no accounting-policy
                - [no] collect-stats
                - nw-egr-agg-shaper-rate rate
                - no nw-egr-agg-shaper-rate
                - qos policy-id
                - no qos
                - queue-policy name
                - no queue-policy
            - statistics
                - egress
Port Ethernet commands
config 
    - [no] port {port-id}
        - ethernet
            - autonegotiate [limited]
            - [no] autonegotiate
            - connection-type connection-type
            - down-on-internal-error
            - no down-on-internal-error
            - duplex {full | half}
            - dot1q-etype value
            - no dot1q-etype
            - encap-type {dot1q | null | qinq}
            - no encap-type
            - [no] eth-bn-egress-rate-changes
            - eth-cfm
                - [no] mep mep-id domain md-index association ma-index
                    - eth-bn
                        - [no] receive
                        - rx-update-pacing seconds
            - frame-based-accounting
            - no frame-based-accounting
            - hold-time {[up hold-time up] [down hold-time down] [seconds| centiseconds]}
            - no hold-time
            - [no] lacp-tunnel
            - [no] loopback {internal} [service svc-id sap sap-id src-mac SA dst-mac DA]
            - mac ieee-address
            - no mac
            - mode access [uplink]
            - mode hybrid
            - mode network
            - no mode
            - monitor-oper-group name
            - no monitor-oper-group
            - mtu mtu-bytes
            - no mtu
            - no oper-group
            - oper-group name
            - poe [plus] [plusplus] [hpoe]
            - no poe
            - qinq-etype value
            - no qinq-etype
            - speed {10 | 100 | 1000}
            - [no] shutdown
Port Ethernet CRC monitoring commands for 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
config 
    - [no] port {port-id}
        - ethernet
            - crc-monitor
                - [no] sd-threshold threshold [multiplier multiplier]
                - [no] sf-threshold threshold [multiplier multiplier]
                - [no] window-size seconds
Port Ethernet LLDP commands
config 
    - [no] port {port-id}
        - ethernet
            - lldp
                - [no] tunnel-nearest-bridge-dest-mac
                - dest-mac {nearest-bridge | nearest-non-tpmr | nearest-customer}
                    - admin-status {rx | tx | tx-rx | disabled}
                    - lldp-med 
                        - admin-status {tx-rx | disabled} 
                        - no admin-status 
                        - network-policy policy-id [policy-id...(up to 4 max)]  
                        - no network-policy 
                        - tx-tlvs [network-policy] [mac-phy-config-status] 
                        - no tx-tlvs 
                    - [no] notification
                    - port-id-subtype {tx-if-alias | tx-if-name | tx-local}
                    - no port-id-subtype
                    - tx-mgmt-address [system] [system-ipv6]
                    - no tx-mgmt-address
                    - tx-tlvs [port-desc] [sys-name] [sys-desc] [sys-cap]
                    - no tx-tlvs
Port Ethernet sync commands for 7210 SAS-D ETR, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
config 
    - [no] port {port-id}
        - ethernet
            - no port-clock 
            - port-clock {master | slave | automatic}
            - ssm
                - [no] shutdown
                - [no] code-type sonet | sdh
                - [no] tx-dus
LAG commands for 7210 SAS-D and 7210 SAS-Dxp
config
    - [no] lag [lag-id]
        - description long-description-string
        - no description
        - [no] enable-dei
        - encap-type {dot1q | null | qinq}
        - no encap-type
        - hold-time down hold-down-time
        - no hold-time
        - lacp [mode] [administrative-key admin-key] [system-id system-id] [system-priority priority]
        - lacp-xmit-interval {slow | fast}
        - no lacp-xmit-interval
        - [no] lacp-xmit-stdby
        - mac ieee-address
        - no mac
        - mode access [uplink]
        - no mode
        - port port-id [port-id …up to N total] [priority priority] [sub-group sub-group-id]
        - no port port-id [port-id up to N total] 
        - port-threshold value [action {down}]
        - no port-threshold
        - selection-criteria [{highest-count | highest-weight | best-port}] [slave-to-partner]
        - no selection-criteria
        - standby-signalling {lacp | power-off}
        - no standby-signalling
        - [no] shutdown 
LAG commands for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
config
    - [no] lag [lag-id]
        - description long-description-string
        - no description
        - [no] dynamic-cost
        - encap-type {dot1q|null|qinq}
        - no encap-type
        - hold-time down hold-down-time
        - no hold-time
        - lacp [mode] [administrative-key admin-key] [system-id system-id] [system-priority priority]
        - lacp-xmit-interval {slow | fast}
        - no lacp-xmit-interval
        - mac ieee-address
        - no mac
        - mode access [uplink] 
        - mode network
        - no mode
        - port port-id [port-id up to 4 total] [priority priority]
        - no port port-id [port-id up to 4 total] 
        - port-threshold value [action {down}]
        - no port-threshold
        - selection-criteria [{highest-count| highest-weight | best-port}] [slave-to-partner]
        - no selection-criteria
        - standby-signalling {lacp | power-off}
        - no standby-signalling
        - [no] shutdown 
Multi-chassis redundancy commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
config 
    - redundancy 
        - multi-chassis 
            - [no] peer ip-address [create]
                - authentication-key [authentication-key | hash-key] [hash | hash2] 
                - no authentication-key 
                - description description-string 
                - no description 
                - [no] mc-lag 
                    - hold-on-neighbor-failure multiplier 
                    - no hold-on-neighbor-failure 
                    - keep-alive-interval interval 
                    - no keep-alive-interval 
                    - lag lag-id lacp-key admin-key system-id system-id [remote-lag remote-lag-id] system-priority system-priority 
                    - lag remote-lag remote-lag-id] 
                    - no lag lag-id 
                    - [no] shutdown 
                - peer-name 
                - no peer-name 
                - [no] shutdown 
                - source-address ip-address 
                - no source-address 
                - [no] sync 
                    - [no] igmp-snooping 
                    - port [port-id | lag-id] [sync-tag sync-tag] [create] 
                    - no port [port-id | lag-id] 
                    - range encap-range [sync-tag sync-tag] 
                    - no range encap-range 
                    - [no] shutdown 
Ethernet ring commands
config
    - eth-ring ring-id
    - no eth-ring
        - [no] ccm-hold-time {down down-timeout | up up-timeout}
        - [no] compatible-version version
        - description description-string
        - no description
        - [no] guard-time time
        - [no] revert-time time
        - [no] rpl-node {owner | nbr}
        - [no] node-id mac
        - [no] sub-ring {virtual-link | non-virtual-link}
        - [no] path {a | b} [{port-id} raps-tag qtag[.qtag] ]
            - description description-string
            - [no] rpl-end
            - eth-cfm
                - [no] mep mep-id domain md-index association ma-index
                    - [no] ccm-enable
                    - [no] ccm-ltm-priority priority
                    - [no] control-mep
                    - [no] description description-string
                    - [no] eth-test-enable
                        - [no] test-pattern {all-zeros | all-ones} [crc-enable]
                        - bit-error-threshold bit-errors
                    - mac-address mac-address
                    - one-way-delay-threshold seconds
                    - [no] shutdown
            - [no] shutdown

Show commands

show 
    - chassis [environment] [power-supply]
    - card [slot-number] [detail]
    - card state
    - pools mda-id[/port] [access-app [pool-name]]
    - pools mda-id[/port] [network-app [pool-name]]
    - lag [lag-id] [detail] [statistics] 
    - lag lag-id associations
    - lag [lag-id] description
    - lag [lag-id] port
    - port port-id [count] [statistics] [detail] 
    - port port-id description 
    - port port-id associations
    - port port-id dot1x [detail]
    - port port-id ethernet [efm-oam | detail]
    - port port-id optical
    - port [A1] [detail] [statistics] [description]
        - ethernet 
            - lldp [nearest-bridge | nearest-non-tpmr | nearest-customer] [remote-info] [detail] [lldp-med]
    - redundancy 
        - multi-chassis all 
            - mc-lag peer ip-address [lag lag-id] 
            - mc-lag [peer ip-address [lag lag-id]] statistics 
            - sync peer [ip-address] 
            - sync peer [ip-address] detail 
    - sync peer [ip-address] statistics 
    - system
        - internal-loopback-ports [detail] 
        - lldp
        - lldp neighbor
        - poe [detail] 

Monitor commands

Monitor
    - port port-id [port-id...(up to 5 max)] [interval seconds] [repeat repeat] [absolute | rate]

Clear commands

clear
    - lag lag-id statistics
    - port port-id statistics

Debug commands

debug
    - lag [lag-id lag-id port port-id] [all]
    - lag [lag-id lag-id port port-id] [sm] [pkt] [cfg] [red] [iom-upd] [port-state] [timers] [sel-logic]
    - no lag [lag-id lag-id]

Command descriptions

Configuration commands

Generic commands
description
Syntax

description long description-string

no description

Context

config>port

config>lag

config>split-horizon-group

config>macsec>connectivity-association

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command creates a text description for a configuration context to help identify the content in the configuration file.

The no form of this command removes any description string from the context.

Parameters
long-description-string

The description character string. Strings can be up to 160 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

shutdown
Syntax

[no] shutdown

Context

config>card

config>card>mda

config>port

config>port>ethernet

config>lag

config>port>ethernet>ssm

config>redundancy>multi-chassis>peer

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

config>redundancy>multi-chassis>peer>sync

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. The operational state of the entity is disabled as well as the operational state of any entities contained within.

The no form of this command administratively enables an entity.

Default

the default state for a card is no shutdown

the default state for an mda is no shutdown

the default state for a Link Aggregation Group (LAG) is shutdown

the default state for a port is shutdown

Card commands
card
Syntax

card slot-number

Context

config

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This mandatory command enables the context to access the chassis card Input/Output Module (IOM), slot, and MDA CLI context.

The no form of this command cannot be used on fixed IOM and MDA cards that are auto equipped and auto provisioned. The IOM card is equipped and provisioned for slot 1.

Parameters
slot-number

Specifies the slot number of the card in the chassis.

card-type
Syntax

card-type card-type

Context

config>card

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This mandatory command adds a card type to the device configuration for the slot. The card type can be preprovisioned, meaning that the card does not need to be installed in the chassis.

A card must be provisioned before an MDA or port can be configured.

A card can only be provisioned in a slot that is vacant, meaning no other card can be provisioned (configured) for that particular slot.

A card can only be provisioned in a slot if the card type is allowed in the slot. An error message is generated if an attempt is made to provision a card type that is not allowed.

A high severity alarm is raised if an administratively enabled card is removed from the chassis. The alarm is cleared when the correct card type is installed or the configuration is modified. A low severity trap is issued when a card is removed that is administratively disabled.

An appropriate alarm is raised if a partial or complete card failure is detected. The alarm is cleared when the error condition ceases.

The no form of this command cannot be used as the card is fixed.

Default

the card is equipped and preprovisioned for slot 1

Parameters
card-type

Specifies the type of card to be configured and installed in that slot.

MDA commands
mda
Syntax

mda mda-slot

no mda mda-slot

Context

config>card

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This mandatory command enables the MDA CLI context to configure MDAs.

Default

1

Parameters
mda-slot

Specifies the MDA slot number to be configured. Fixed ports on the panel of the chassis belong to MDA 1.

mda-type
Syntax

mda-type mda-type

no mda-type

Context

config>card>mda

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This mandatory command provisions a specific MDA type to the device configuration for the slot. The MDA can be preprovisioned but an MDA must be provisioned before ports can be configured. Ports can be configured when the MDA is properly provisioned.

7210 SAS-D and 7210 SAS-Dxp (all platform variants) support only a fixed MDA. These platforms do not support an expansion slot. The fixed MDA (addressed as mda 1) is auto-equipped and auto-provisioned on bootup. It cannot be deleted.

The no form of this command displays an error message if performed on fixed MDAs.

Default

MDA 1 is auto-equipped and auto-provisioned by default during bootup.

Parameters
mda-type

Specifies the type of MDA selected for the slot position.

Values

m4-tx+6-sfp (7210 SAS-D)

m6-tx+4-sfp+2-sfpp (7210 SAS-Dxp)

m2-tx+2-sfp+1-combo (7210 SAS-K 2F1C2T)

m4-tx+2-sfp+6-combo (7210 SAS-K 2F6C4T)

m3-10gb-sfp+8-combo (7210 SAS-K 3SFP+ 8C)

sync-e
Syntax

[no] sync-e

Context

config>card>mda

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables Synchronous Ethernet on the Ethernet ports that support Synchronous Ethernet. When Synchronous Ethernet is enabled, the timing information is derived from the Ethernet ports.

Synchronous Ethernet is supported for both Ethernet SFP ports and fixed copper ports.

See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about Synchronous Ethernet.

The no form of this command disables Synchronous Ethernet on the MDA.

Default

no sync-e

Interface QoS commands
access
Syntax

access

Context

config>port

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure QoS policy parameters on an access port.

uplink
Syntax

uplink

Context

config>port>access

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure QoS policy parameters on an access-uplink port.

egress
Syntax

egress

Context

config>port>access

config>port>access>uplink

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure QoS egress policy parameters for the access port on 7210 SAS-D and 7210 SAS-Dxp, and for the access-uplink port on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C respectively.

pool
Syntax

[no] pool [name]

Context

config>port>access>egress

config>port>access>uplink>egress

Platforms

7210 SAS-D, 7210 SAS-Dxp

Description

This command configures pool policies.

Note:

The default pool cannot be modified, deleted or created.

Default

default

Parameters
name

Specifies the pool name, a string up to 32 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

slope-policy
Syntax

slope-policy name

no slope-policy

Context

config>port>access>egress>pool

config>port>access>uplink>egress>pool

Platforms

7210 SAS-D, 7210 SAS-Dxp

Description

This command specifies an existing slope policy which defines high and low priority RED slope parameters. The policy is defined in the config>qos>slope-policy context.

Parameters
name

Specifies the policy name, a string up to 32 characters.

qos
Syntax

qos policy-id

no qos

Context

config>port>ethernet>access>egress

Platforms

7210 SAS-D, 7210 SAS-Dxp

Description

This command associates a access-egress QoS policy to the access port.

The no form of this policy removes the explicit association of a user configured QoS policy and associates a default QoS policy with the port.

Parameters
policy-id

Specifies an existing QoS policy to be assigned to the port.

Values

1 to 65535

qos
Syntax

qos policy-id

no qos

Context

config>port>ethernet>access>uplink

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command associates a network QoS policy with the access-uplink port.

Parameters
policy-id

Specifies an existing QoS policy to be assigned to the port.

Values

1 to 65535

nw-egr-agg-shaper-rate
Syntax

nw-egr-agg-shaper-rate rate

no nw-egr-agg-shaper-rate

Context

config>port>ethernet>network

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the network egress aggregate shaper rate for port queues. The shaper value limits the maximum bandwidth that port queues can receive from the total port bandwidth, with remaining port bandwidth shared by SAPs on the port. This command is only supported on hybrid ports.

The no form of this command removes the configured egress aggregate shaper rate.

Default

no nw-egr-agg-shaper-rate

Parameters
rate

Specifies the egress aggregate shaper rate in kb/s.

Values

64 to 1000000 (7210 SAS-K 2F6C4T)

64 to 10000000 (7210 SAS-K 3SFP+ 8C)

qos
Syntax

qos policy-id

no qos

Context

config>port>ethernet>network

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command associates a network QoS policy to a network port.

Parameters
policy-id

Specifies an existing QoS policy to be assigned to the port.

Values

1, 3 to 65535

General port commands
port
Syntax

port port-id

no port

Context

config

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures ports. Before a port can be configured, the chassis slot must be provisioned with a valid card type and the MDA parameter must be provisioned with a valid MDA type. (See card and mda commands.) All ports must be explicitly configured and enabled

Parameters
port-id

Specifies the physical port ID in the slot/mda/port format.

enable-dei
Syntax

[no] enable-dei

Context

config>port>ethernet

config>lag

Platforms

7210 SAS-D, 7210 SAS-Dxp

Description

This command enables DEI-based classification on access ports, network ports, access-uplink or hybrid ports.

If enabled, DEI value in the Ethernet packet header is used to determine the initial profile/color of the packet when the meter/policer used to police the FC is configured in color-aware mode. If the meter used to police the FC is configured in color-blind mode, then the DEI value of the packet has no effect. When in color-aware mode, DEI value of 0 is interpreted as in-profile or green packet and DEI value of 1 is interpreted as out-of-profile or yellow packet. In color-aware mode, the following behavior is accorded to packets classified with initial profile/color as in-profile/green and out-of-profile/yellow:

  • If a green packet is received and the color-aware meter is within the CIR rate, then packet is assigned a final profile of green and it is assigned a final profile of yellow if the meter exceeds the CIR rate and is within the PIR rate.

  • If a yellow packet is received and the color-aware meter is above the CIR rate and within the PIR rate, then the packet is assigned a final profile of yellow.

That is, in color-aware mode, yellow/out-of-profile packets cannot eat into the CIR bandwidth. It is exclusively reserved for green/in-profile packets.

The final profile assigned at ingress is used by egress to determine the WRED slope to use. The WRED slope determines whether the packet is eligible to be assigned a buffer and can be queued up on egress queue for transmission.

See the 7210 SAS-D, Dxp Quality of Service Guide for more information.

Default

no enable-dei

egress-scheduler-policy
Syntax

egress-scheduler-policy port-scheduler-policy-name

no egress-scheduler-policy

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp

Description

This command configures the scheduling behavior to the one specified in the policy (Strict, RR, WRR, WDRR, WRR/WDRR + Strict).

The no form of this command removes the policy from the port and makes the scheduling scheme of the port to strict.

Parameters
port-scheduler-policy-name

Specifies a port scheduler policy for the port.

mode
Syntax

mode access [uplink]

mode hybrid

mode network

no mode

Context

config>port>ethernet

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures an Ethernet port for access mode, access-uplink mode, hybrid mode, or network mode of operation.

The following modes are supported on the 7210 SAS platforms:

  • The 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T support only access and access-uplink mode.

  • The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support access, access-uplink, hybrid, and network mode.

The functionality of the different modes is as follows:

  • Access — An access port is used for customer facing traffic on which services are configured. A Service Access Point (SAP) can only be configured on an access port. When a port is configured for access mode, the appropriate encap-type must be specified to distinguish the services on the port. When an Ethernet port has been configured for access mode, multiple services can be configured on the Ethernet port.

  • Access-uplink — 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.

  • Network — A network port participates in the service provider transport or infrastructure network when a network mode is selected. When the network option is configured, the encap-type can be configured to either null or dot1q.

  • Hybrid — A hybrid Ethernet port allows the combination of network and access modes of operation on a per-VLAN basis and must be configured as either dot1q or QinQ encapsulation. When the hybrid port is configured with dot1q encapsulation, SAPs are configured in a service by providing the SAP ID, which must include the port-id value of the hybrid port and an unused VLAN tag value in the format port-id:qtag1. A SAP with the format port-id:* is also supported. Network IP interfaces are configured in the config>router>interface>port context by providing the port name, which consists of the port-id value of the hybrid port and an unused VLAN tag value in the format port-id:qtag1.

    A valid value must be entered for qtag1. The port-id:* format is not supported on a network IP interface. The 4096 VLAN tag space on the port is shared among VLAN SAPs and VLAN network IP interfaces. When the hybrid port is configured with QinQ encapsulation, SAPs are configured in a service by providing the SAP ID, which must include the port-id value of the hybrid port and the outer and inner VLAN tag values in the format port-id:qtag1.qtag2. SAPS with the format port-id:qtag1.* are also supported. The outer VLAN tag value must not have been used to create an IP network interface on this port. In addition, the qtag1.qtag2 value combination must not have been used by another SAP on this port.

    Network IP interfaces are configured in the config>router>interface>port context by providing the port name, which consists of the port-id value of the hybrid port and a VLAN tag value in the format port-id:qtag1.*. An outer VLAN tag qtag2 of * is used to create a network IP interface. In addition, the qtag1.qtag2 value combination must not have been used by another SAP or network IP interface on this port.

The no form of this command reverts to the default value.

Default

access (7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T)

network (7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

Parameters
access

Specifies the Ethernet port as service access.

access uplink

Specifies the Ethernet port for transport (Ethernet uplinks available only in access-uplink mode). A limited number of ports can be configured as access-uplink ports at any specified time on the 7210 SAS-Dxp.

hybrid

Specifies the Ethernet port for hybrid use (available only in network mode).

network

Specifies the Ethernet port as service access (available only in network mode).

monitor-oper-group
Syntax

monitor-oper-group name

no monitor-oper-group

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the operational group to be monitored by the object under which it is configured. The oper-group name must be already configured under the config>system context before its name is referenced in this command.

The no form of this command removes the association from the configuration.

Default

no monitor-oper-group

Parameters
name

Specifies a character string of maximum 32 ASCII characters identifying the group instance.

Values

32 chars maximum

mac
Syntax

mac ieee-address

no mac

Context

config>port>ethernet

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command assigns a specific MAC address to an Ethernet port, Link Aggregation Group (LAG).

Only one MAC address can be assigned to a port. When multiple mac commands are entered, the last command overwrites the previous command. When the command is issued while the port is operational, IP will issue an ARP, if appropriate, and BPDUs are sent with the new MAC address. A default MAC address is assigned by the system from the chassis MAC address pool.

The no form of this command reverts the MAC address to the default value.

Parameters
ieee-address

Specifies the 48-bit MAC address in the form aa:bb:cc:dd:ee:ff or aa-bb-cc-dd-ee-ff where aa, bb, cc, dd, ee and ff are hexadecimal numbers. Allowed values are any non-broadcast, non-multicast MAC and non-IEEE reserved MAC addresses.

mtu
Syntax

mtu mtu-bytes

no mtu

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the maximum transmission unit (MTU) size for an Ethernet port. The Ethernet port level MTU parameter indirectly defines the largest physical packet the port can transmit or the far-end Ethernet port can receive. Packets received that are larger than the MTU value are discarded. Packets that cannot be fragmented at egress and exceed the MTU are discarded.

The value specified for the MTU includes the destination MAC address, source MAC address, the Ethertype or Length field and the complete Ethernet payload. The MTU value does not include the preamble, start of frame delimiter, or the trailing CRC.

The no form of this command reverts to the default values.

Default

The following table describes the default MTU values that are dependent on the (sub-)port type, mode, and encapsulation.

Table 22. Default MTU values

Type

Mode

Encap type

Default (bytes)

10/100, Gig

Access

null

1514

10/100, Gig

Access

dot1q

1518

10/100, Gig

Access

q-in-q

1522

Parameters
mtu-bytes

Specifies the maximum allowable size of the MTU, expressed as an integer.

Values

512 to 9212

ptp-hw-timestamp
Syntax

[no] ptp-hw-timestamp

Context

config>port

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Description

This command enables Precision Time Protocol (PTP) port-based hardware timestamping on the port in both egress and ingress directions. For more information about PTP port-based hardware timestamping, including configuration guidelines, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide.

The no version of this command disables PTP port-based hardware timestamping on the port.

Default

ptp-hw-timestamp

Port loopback commands
loopback-no-svc-port
Syntax

[no] loopback-no-svc-port [mirror | mac-swap | testhead] port-id

Context

config>system

Platforms

7210 SAS-Dxp

Description

This command specifies the port to assign for system use when using port loopback or for the mac-swap, mirroring, or testhead OAM tools. The system uses the resources of the port and the port is not available for configuring services.

The user cannot share a single port between multiple tools or applications if they intend to use the tools simultaneously. The system displays an error if the user tries to configure the same port for use with multiple OAM tools or if the user tries to use the tool without first configuring the port resources to be used by the tool.

The system verifies if any services are configured on the port specified with this command and if services are configured the command fails.

The no form of this command disables the use of this port by the specified OAM tool.

Note:

  • On 7210 SAS-Dxp, this command must be used and the user needs to dedicate one front-panel port for use with the mirroring applications.

  • On 7210 SAS-D (ETR and non-ETR variants), the user can use the 3 available internal ports (that is, port 1/1/11, 1/1/12, and 1/1/13) for use with either mac-swap or mirroring or testhead OAM tool. The user does not need to use this command and the internal port resources are automatically allocated to the ports by software to different OAM tools.

  • On 7210 SAS-Dxp, the three internal ports (ports 1/1/13, 1/1/14, and 1/1/15) can be used for mac-swap, mirroring, or testhead OAM tools. Port 1/1/13 is a 1GE port and is recommended for applications with traffic up to 1Gbps. Ports 1/1/14 and 1/1/15 are 10GE ports and are recommended for applications with traffic greater than 1Gbps but less than 10Gbps. The loopback-no-svc-port command must be used to associate the port resources with the applications. A port can be used with a single application and cannot be shared by multiple applications.

Parameters
mac-swap

Specifies that the port is dedicated for use by the mac-swap application/OAM tool.

mirror

Specifies that the port is dedicated for use by the mirroring application/OAM tool.

testhead

Specifies that the port is dedicated for use by the testhead application/OAM tool.

port-id

Specifies the physical port ID in the slot/mda/port format.

MACsec commands for 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p
macsec
Syntax

macsec

Context

config

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command enables the context for MACsec configuration. The MACsec MKA profile can be configured in this context.

Note: See SA limits and network design for more information about security zones and ports where MACsec can be enabled.
connectivity-association
Syntax

connectivity-association ca-name [create]

no connectivity-association ca-name

Context

config>macsec

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command configures a connectivity association (CA). MACsec CAs are applied to a port dot1x configuration to enable MACsec on that port.

The no form of this command removes the CA.

Parameters
ca-name

Specifies the name of the CA using a string of up to 32 characters.

create

Specifies a mandatory keyword when creating an entry.

cipher-suite
Syntax

cipher-suite cipher-suite

no cipher-suite

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command configures encryption of datapath PDUs. When all parties in the CA have the security association key (SAK), they use the algorithm specified by the cipher-suite parameter, in conjunction with the SAK, to encrypt the datapath PDUs.

The no form of this command disables encryption of datapath PDUs.

Default

cipher-suite gcm-aes-128

Parameters
cipher-suite

Specifies the algorithm to use for control plane encryption.

Values

gcm-aes-128

gcm-aes-256

clear-tag-mode
Syntax

clear-tag-mode clear-tag-mode

no clear-tag-mode

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command puts 802.1Q tags in clear before SecTAG. The following modes are available: single-tag and dual-tag.

The following table describes the encrypted dot1q and QinQ packet format when clear-tag-mode (single-tag or dual-tag) is configured.

Table 23. Encrypted dot1q and QinQ packet format

Unencrypted format

Clear-tag-mode

Pre-encryption (Tx)

Pre-decryption (Rx)

Single tag (dot1q)

single-tag

DA, SA, TPID, VID, Etype

DA, SA, TPID, VID, SecTag

Single tag (dot1q)

dual-tag

DA, SA, TPID, VID, Etype

DA, SA, TPID, VID, SecTag

Double tag (q-in-q)

single-tag

DA, SA, TPID1, VID1, IPID2, VID2, Etype

DA, SA, TPID1, VID1, SecTag

Double tag (QinQ)

dual-tag

DA, SA, TPID1, VID1, IPID2, VID2, Etype

DA, SA, TPID1, VID1, IPID2, VID2, SecTag

The no form of this command puts all dot1q tags after SecTAG and encrypts the tags.

Default

no clear-tag-mode

Parameters
clear-tag-mode

Specifies the clear tag mode.

Values

single-tag, dual-tag

description
Syntax

description description-string

no description

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command enters a description for the CA.

The no form of this command removes the CA description.

Parameters
description-string

Specifies a brief description of the CA using a string of up to 80 characters.

encryption-offset
Syntax

encryption-offset encryption-offset

no encryption-offset

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command specifies the offset of the encryption in MACsec packets.

The encryption offset is distributed by the MKA to all parties and is signaled via MACsec capabilities.

The following table describes the basic settings.

Table 24. MACsec basic settings

Setting

Description

0

MACsec is not implemented

1

Integrity without confidentiality

2

The following are supported:

  • integrity without confidentiality

  • integrity and confidentiality with a confidentiality offset of 0

3

11

The following are supported:

  • integrity without confidentiality

  • integrity and confidentiality with a confidentiality offset of 0, 30, or 50

The no form of this command rejects all arriving traffic regardless of whether it is MACsec-secured.

Default

encryption-offset 0

Parameters
encryption-offset

Specifies the encryption offset.

Values

0 — encrypts the entire payload

30 — leaves the IPv4 header in clear

50 — leaves the IPv6 header in clear

macsec-encrypt
Syntax

[no] macsec-encrypt

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command enables encryption and authentication (ICV payload) for all PDUs.

The no form of this command specifies that all PDUs are transmitted in cleartext form but still authenticated and have the trailing ICV.

Default

macsec-encrypt

replay-protection
Syntax

[no] replay-protection

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command configures the size of the replay protection window.

This command must be configured to force packet discard when the system detects a packet that is not within the parameters configured for the replay-window-size command.

When this command is enabled, the sequence of the ID number of the received packets is checked. If the packet arrives out of sequence, and the difference between the packet numbers exceeds the replay window size, the packet is counted by the receiving port and then discarded. For example, if the replay protection window size is set to 5 and a packet assigned the ID of 1006 arrives on the receiving link immediately after the packet assigned the ID of 1000, the packet that is assigned the ID of 1006 is counted and discarded because it falls outside the parameters of the replay-window-size command.

Replay protection is especially useful for fighting man-in-the-middle attacks. A packet that is replayed by a man-in-the-middle attacker on the Ethernet link arrives on the receiving link out of sequence, so replay protection helps ensure the replayed packet is dropped instead of forwarded through the network.

Note:

Replay protection should not be enabled in cases where packets are expected to arrive out of order.

Default

replay-protection

replay-window-size
Syntax

replay-window-size number-of-packets

no replay-window-size

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command specifies the size of the replay protection window.

This command must be configured to enable the replay-protection command.

When the number-of-packets parameter is set to 0, all packets that arrive out of order are dropped.

The no form of this command reverts to the default value.

Default

replay-window-size 0

Parameters
number-of-packets

Specifies the window that the packets can arrive out of order.

Values

0 to 4294967294

shutdown
Syntax

[no] shutdown

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command shuts down the CA profile. All ports using this profile do not transmit PDUs because this command shuts down MACsec for this profile.

The no form of this command enables the CA profile.

Default

shutdown

static-cak
Syntax

[no] static-cak

Context

config>macsec>connectivity-association

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

Commands in this context configure a Connectivity Association Key (CAK). A CAK is responsible for managing the MACsec key agreement (MKA).

active-psk
Syntax

active-psk active-pre-shared-key

no active-psk

Context

config>macsec>conn-assoc>static-cak

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command specifies which preshared key is the active transmitting preshared key. If there are two preshared keys configured, the arriving MACsec MKA can be decrypted using CAKs of both preshared keys; however, only the active PSK is used for Tx encryption of MKA PDUs.

Default

active-psk 1

Parameters
active-pre-shared-key

Specifies the value of the preshared key.

Values

1 or 2

mka-key-server-priority
Syntax

mka-key-server-priority priority

no mka-key-server-priority

Context

config>macsec>conn-associ>static-cak

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command specifies the key server priority used by the MKA protocol to select the key server when MACsec is enabled using the static CAK security mode.

The no form of this command disables this command.

Default

mka-key-server-priority 16

Parameters
priority

Specifies the priority of the server.

Values

0 to 255

pre-shared-key
Syntax

pre-shared-key pre-shared-key-index [encryption-type encryption-type] [create]

no pre-shared-key pre-shared-key-index

Context

config>macsec>conn-assoc>static-cak

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command specifies the preshared key used to enable MACsec using the static CAK security mode. This command also specifies the encryption algorithm used for encrypting the SAK.

A preshared key includes a connectivity association key name (CKN) and a CAK. The preshared key (the CKN and CAK) must match on both ends of a link.

A preshared key is configured on both devices at each end of a point-to-point link to enable MACsec using static CAK security mode. The MKA protocol is enabled after the successful MKA liveliness negotiation.

The encryption-type parameter is used to encrypt SAK and authentication of the MKA packet. The symmetric encryption key SAK needs to be encrypted (wrapped) using the encryption algorithm specified with the encryption-type parameter. The AES key is derived using the preshared key.

The no form of this command removes the index.

Parameters
pre-shared-key-index

Specifies the index of this preshared key.

Values

1, 2

encryption-type

Specifies the type of encryption.

Values

aes-128-cmac, aes-256-cmac

create

Specifies a mandatory keyword when creating an entry.

cak
Syntax

cak hex-string [hash | hash2]

no cak

Context

config>macsec>conn-assoc>static-cak>pre-shared-key

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command configures the CAK for a preshared key. The following values are derived from the CAK:

  • KEK (Key Encryption Key)

    KEK is used to encrypt the MKA and SAK (symmetric key used for datapath PDUs) to be distributed between all members.

  • ICK (Integrity Check Value)

    ICK is used to authenticate the MKA and SAK PDUs to be distributed between all members.

The no form of this command removes the CAK hexidecimal string value.

Parameters
hex-string

Specifies the value of the CAK using up to 64 hexadecimal characters, 32 hexadecimal characters for a 128-bit key, and 64 hexadecimal characters for a 256-bit key.

hash

Specifies the hash scheme.

hash2

Specifies the hash scheme.

ckn
Syntax

ckn hex-string

no ckn

Context

config>macsec>conn-assoc>static-cak>pre-shared-key

Platforms

7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p

Description

This command specifies the connectivity association key name (CKN) for a preshared key.

The CKN is appended to the MKA for identification of the CAK by the peer.

The no form of this command removes the CKN.

Parameters
hex-string

Specifies the value of the CKN.

Values

32 octets char (64 hex)

Ethernet port commands
ethernet
Syntax

ethernet

Context

config>port

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure access parameters.

This context can only be used when configuring Ethernet LAN ports on an appropriate MDA.

autonegotiate
Syntax

autonegotiate [limited]

no autonegotiate

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables speed and duplex autonegotiation on Fast Ethernet ports and enables far-end fault indicator support on gigabit ports.

There are three possible settings for autonegotiation:

  • ‟on” or enabled with full port capabilities advertised

  • ‟off” or disabled where there are no autonegotiation advertisements

  • ‟limited” where a single speed/duplex is advertised.

When autonegotiation is enabled on a port, the link attempts to automatically negotiate the link speed and duplex parameters. If autonegotiation is enabled, the configured duplex and speed parameters are ignored.

When autonegotiation is disabled on a port, the port does not attempt to autonegotiate and will only operate at the speed and duplex settings configured for the port. Note that disabling autonegotiation on gigabit ports is not allowed as the IEEE 802.3 specification for gigabit Ethernet requires autonegotiation be enabled for far end fault indication.

If the autonegotiate limited keyword option is specified, the port will autonegotiate but will only advertise a specific speed and duplex. The speed and duplex advertised are the speed and duplex settings configured for the port. One use for limited mode is for multispeed gigabit ports to force gigabit operation while keeping autonegotiation enabled for compliance with IEEE 801.3.

7210 SAS requires that autonegotiation be disabled or limited for ports in a Link Aggregation Group to guarantee a specific port speed.

The no form of this command disables autonegotiation on this port.

Default

autonegotiate

Parameters
limited

Specifies tht the Ethernet interface will automatically negotiate link parameters with the far end, but will only advertise the speed and duplex mode specified by the Ethernet and commands.

connection-type
Syntax

connection-type connection-type

Context

config>port>ethernet

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures the connection type on the Ethernet combo port. The combo port provides two physical interface options to the user, SFP or copper. This command allows the user specify the physical interface that will be used.

When configured as SFP port it allows for fiber based connectivity with the flexibility of using suitable optics for longer reach. When configured as a fixed copper port it provides cheaper connectivity for shorter reach. The SFP port support 100/1000 speeds and the copper port can support 10/100/1000Mbps speed.

When configured as 'auto', software will attempt to detect the type of interface in use based on whether the copper cable is plugged in or the SFP optic is plugged in. It is not allowed to plug in copper cable and SFP optics into the Ethernet combo port at the same time.

When combo port is used for SyncE, the connection type has to be set to either sfp or copper. SyncE is not supported with connection-type as auto.

The combo port can be configured either as a SFP port or a copper port or set for automatic detection. That is, both the interfaces cannot be used simultaneously (even when 'auto' is set, software selects one of the ports based on the interface plugged in).

Default

sfp (7210 SAS-K 2F1C2T)

auto (7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

Parameters
connection-type

Specifies the type of Ethernet combo port.

Values

sfp, copper, auto

crc-monitor
Syntax

crc-monitor

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures Ethernet CRC Monitoring parameters.

sd-threshold
Syntax

[no] sd-threshold threshold [multiplier multiplier]

Context

config>port>ethernet>crc-monitor

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command specifies the error rate at which to declare the Signal Failure condition on an Ethernet interface.

The value represents a ratio of errored frames over total frames received over seconds of the sliding window. The CRC errors on the interface are sampled once per second. A default of 10 seconds is used when there is no additional window-size configured. The multiplier keyword is optional.

The no form of this command reverts to the default value of 1. If the multiplier keyword is omitted, the multiplier will return to the default value of 1.

Default

no sd-threshold

Parameters
threshold

Specifies the rate of CRC errored Ethernet frames.

Values

1 to 9

multiplier

Specifies the multiplier used to scale the CRC error ratio.

Values

1 to 9

sf-threshold
Syntax

[no] sf-threshold threshold [multiplier multiplier]

Context

config>port>ethernet>crc-monitor

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command specifies the error rate at which to declare the Signal Degrade condition on an Ethernet interface.

The value represents a ratio of errored frames over total frames received over seconds of the sliding window. The CRC errors on the interface are sampled once per second. A default of 10 seconds is used when there is no additional window-size configured.

The no form of this command reverts to the default value of 1. If the multiplier keyword is omitted, the multiplier will return to the default value of 1.

Default

no sf-threshold

Parameters
threshold

Specifies the rate of CRC errored Ethernet frames.

Values

1 to 9

multiplier

Specifies the multiplier used to scale the CRC error ratio.

Values

1 to 9

window-size
Syntax

[no] window-size seconds

Context

config>port>ethernet>crc-monitor

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command specifies sliding window size over which the Ethernet frames are sampled to detect signal fail or signal degrade conditions. The command is used jointly with the sf-threshold and the sd-threshold to configure the sliding window size.

Default

10

Parameters
seconds

Specifies the size of the sliding window in seconds over which the errors are measured.

Values

5 to 60

down-on-internal-error
Syntax

[no] down-on-internal-error

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command brings a port operationally down in the event the systems has detected internal max transmit errors.

Default

no down-on-internal-error

dot1q-etype
Syntax

dot1q-etype value

no dot1q-etype

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command specifies the Ethertype expected when the port's encapsulation type is dot1q. Dot1q encapsulation is supported only on Ethernet interfaces.

When the dot1-etype is configured to a value other than 0x8100 (the default value) on a port, the outermost tag in the received packet is matched against the configured value and if there is a match then it is treated as a Dot1q packet and the VLAN ID is used to match against the configured Dot1q SAPs on the port to find the Dot1q SAP the packet should be matched to.

Note:

  • This command does not change the etype used to match the inner tag for a QinQ SAP. The 7210 SAS devices always uses 0x8100 for matching the inner tag etype. That is, if this command is configured on a port configured for QinQ encapsulation, then it is ignored and 0x8100 is used always.

  • This command is supported only for access ports and hybrid ports. On hybrid ports, it applies to all traffic (that is, traffic mapped to SAPs and network IP interfaces). It is not supported for 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 is classified as a 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 as expected.

  • The maximum number of unique dot1q-etypes configurable per node is limited. The resources needed for configuration of dot1q-etype is shared by the default dot1q-etype, default qinq-etype and user configured values for qinq-etype. That is, the number of unique dot1q-etypes allowed decreases, if the number of unique qinq-etype configured is more. The converse is also true.

The no form of this command reverts the dot1q-etype value to the default.

Parameters
value

Specifies the Ethertype to expect, in decimal or hexadecimal format.

Default

If the encap-type is dot1p, the default is 0x8100.

If the encap-type is qinq, the default is 0x8100.

Values

1536 to 65535, or 0x0600 to 0xffff

duplex
Syntax

duplex {full | half}

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables the context for the configuration of the duplex mode of a Fast Ethernet port. If the port is configured to autonegotiate, this parameter is ignored.

Default

full

Parameters
full

Sets the link to full duplex mode.

half

Sets the link to half duplex mode.

egress-rate
Syntax

egress-rate sub-rate [max-burst size-in-kbits]

no egress-rate

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the rate of traffic leaving the network.

The no form of this command reverts to the default value.

Note:

For 7210 SAS-D and 7210 SAS-Dxp devices, the max-burst parameter configures a maximum-burst (in kilobits) associated with the egress-rate. This is an optional parameter; if not defined then, by default, it is set to 64 kbits for a 1G port and 98 kbits for a 10G port. The user cannot configure max-burst without configuring egress-rate. 7210 SAS-D devices do not support 10G ports. See the 7210 SAS-D, Dxp Quality of Service Guide for more information.

Default

no egress-rate

Parameters
sub-rate

The egress rate in Kbps.

Values

1 to 10000000

max-burst size-in-kbits

Specifies the maximum egress burst in kilobits. This parameter is configurable only on 7210 SAS-D and 7210 SAS-Dxp.

Values

32 to 16384, default

efm-oam
Syntax

efm-oam

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure EFM-OAM attributes.

accept-remote-loopback
Syntax

[no] accept-remote-loopback

Context

config>port>ethernet>efm-oam

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables reactions to loopback control OAM PDUs from peers.

The no form of this command disables reactions to loopback control OAM PDUs.

Default

no accept-remote-loopback

mode
Syntax

mode {active | passive}

Context

config>port>ethernet>efm-oam

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the mode of OAM operation for this Ethernet port. These two modes differ in that active mode causes the port to continually send out efm-oam info PDUs while passive mode waits for the peer to initiate the negotiation process. A passive mode port cannot initiate monitoring activities (such as loopback) with the peer.

Default

active

Parameters
active

Specifies that the port has the capability to initiate negotiation and monitoring activities.

passive

Specifies that the port relies on peer to initiate negotiation and monitoring activities.

transmit-interval
Syntax

[no] transmit-interval interval [multiplier multiplier]

Context

config>port>ethernet>efm-oam

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the transmit interval of OAM PDUs.

The minimum efm-oam session time-out value supported is 300 milliseconds. That is, user can configure transmit-interval 1 multiplier 3 as the minimum value. This is applicable to all platforms except for the 7210 SAS-D. On the 7210 SAS-D, the minimum transmit interval is 500 msec and multiplier is 4.

Default

transmit-interval 10 multiplier 5

Parameters
interval

Specifies the transmit interval, in 100 milliseconds.

Values

1 to 600

multiplier multiplier

Specifies the multiplier for transmit-interval to set local link down timer.

Values

2 to 5

tunneling
Syntax

[no] tunneling

Context

config>port>ethernet>efm-oam

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables EFM OAM PDU tunneling. Enabling tunneling will allow a port mode Epipe SAP to pass OAM frames through the pipe to the far end.

The no form of this command disables tunneling.

Default

no tunneling

encap-type
Syntax

encap-type {dot1q | null | qinq}

no encap-type

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the encapsulation method used to distinguish customer traffic on an Ethernet access port, or different VLANs on a port.

Note:

  • On the 7210 SAS-D ETR, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, the qinq encapsulation type can be configured for both access and access-uplink ports. The null and dot1q encapsulation types can be specified only for access ports.

  • On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the null and dot1q encapsulation types can be specified for network ports. The dot1q and qinq encapsulation types can be specified for hybrid ports.

The no form of this command reverts to the default.

Default

encap-type null

Parameters
dot1q

Specifies that the ingress frames carry 802.1Q tags where each tag signifies a different service.

null

Specifies that the ingress frames will not use any tags to delineate a service. As a result, only one service can be configured on a port with a null encapsulation type.

qinq

Specifies QinQ encapsulation for QinQ access SAPs.

eth-bn-egress-rate-changes
Syntax

[no] eth-bn-egress-rate-changes

Context

config>port>ethernet

Platforms

7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T

Description

This command allows rate changes received in ETH-BN messages on a port-based MEP to update the egress rate used on the port. The egress rate is capped by the minimum of the configured egress-rate and the maximum port rate.

The no form of this command reverts to the default value.

Default

no eth-bn-egress-rate-changes

eth-cfm
Syntax

eth-cfm

Context

config>port>ethernet

Platforms

7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T

Description

Commands in this context configure 802.1ag CFM parameters.

mep
Syntax

[no] mep mep-id domain md-index association ma-index

Context

config>port>ethernet>eth-cfm

Platforms

7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T

Description

This command provisions the maintenance endpoint (MEP).

The no form of this command removes the configuration.

Default

no mep

Parameters
mep-id

Specifies the maintenance association endpoint identifier.

Values

1 to 8191

md-index

Specifies the maintenance domain (MD) index value.

Values

1 to 4294967295

ma-index

Specifies the MA index value.

Values

1 to 4294967295

eth-bn
Syntax

eth-bn

Context

config>port>ethernet>eth-cfm>mep

Platforms

7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T

Description

Commands in this context configure ETH-BN message handling.

receive
Syntax

[no] receive

Context

config>port>ethernet>eth-cfm>mep>eth-bn

Platforms

7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T

Description

This command enables the reception and processing of ETH-BN messages, and the retrieval and processing of the current bandwidth field for inclusion in dynamic egress rate adjustments.

The received rate is a Layer 2 rate, and is expected to be in Mb/s. If this rate is a link rate (including preamble, start frame delimiter, and inter-frame gap), it requires the configuration of frame-based accounting in the config>port>ethernet context.

The no form of this command disables the reception and processing of ETH-BN messages.

Default

no receive

rx-update-pacing
Syntax

rx-update-pacing seconds

Context

config>port>ethernet>eth-cfm>mep>eth-bn

Platforms

7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T

Description

This command sets the pace for update messages to and from the ETH-CFM subsystem to the QoS subsystem. The most recent update messages are held by the ETH-CFM subsystem, but the most recent update is held until the expiration of the pacing timer.

Default

rx-update-pacing 5

Parameters
seconds

Specifies the time to wait before sending subsequent updates (in seconds).

Values

1 to 600

frame-based-accounting
Syntax

frame-based-accounting

no frame-based-accounting

Context

config>port>ethernet

Platforms

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures per port frame-based accounting. It can be enabled or disabled on each port. When enabled, all the shapers rates and queues statistics on that port also account for the Ethernet Layer 1 overhead (of 20 bytes) in both ingress and egress direction. That is all ingress queue shaper rates, egress queue shaper rates and aggregate SAP shaper rate account for the Ethernet overhead.

The no form of this command disables frame-based-accounting.

Default

no frame-based-accounting

hold-time
Syntax

hold-time {[up hold-time up] [down hold-time] [seconds | centiseconds]}

no hold-time

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures port link dampening timers which reduce the number of link transitions reported to upper layer protocols. The hold-time value is used to dampen interface transitions.

When an interface transitions from an up state to a down state, it is immediately advertised to the rest of the system if the hold-time down interval is zero, but if the hold-time down interval is greater than zero, interface down transitions are not advertised to upper layers until the hold-time down interval has expired. Likewise, an interface is immediately advertised as up to the rest of the system if the hold-time up interval is zero, but if the hold-time up interval is greater than zero, up transitions are not advertised until the hold-time up interval has expired.

The no form of this command reverts to the default values.

Default

hold-time up 0 down 0 seconds

Parameters
up hold-timeup

Specifies the delay, in seconds or centiseconds, to notify the upper layers after an interface transitions from a down state to an up state.

Values

0 to 900 (seconds)

0, 10 to 90000 (centiseconds in 5-centisecond increments)

Values

0 to 900

down hold-time down

Specifies the delay, in seconds or centiseconds, to notify the upper layers after an interface transitions from an up state to a down state.

Values

0 to 900 (seconds)

0, 10 to 90000 (centiseconds in 5-centisecond increments)

seconds | centiseconds

Specifies the units of the hold time in seconds or centiseconds.

Values

0 to 900

lacp-tunnel
Syntax

[no] lacp-tunnel

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command enables LACP packet tunneling for the Ethernet port. When tunneling is enabled, the port will not process any LACP packets but will tunnel them instead. The port cannot be added as a member to a LAG group.

The no form of this command disables LACP packet tunneling for the Ethernet port.

Default

no lacp-tunnel

oper-group
Syntax

no oper-group

oper-group name

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command associates the context to which it is configured to the operational group specified in the group-name. The oper-group group-name must be already configured under config>system context before its name is referenced in this command.

The no form of this command removes the association.

Parameters
name

Specifies a character string of maximum 32 ASCII characters identifying the group instance.

Values

32 chars maximum

poe
Syntax

poe [plus] [plusplus] [hpoe]

no poe

Context

config>port>ethernet

Platforms

7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p

Description

This command enables PoE on the specified port and allows the user to configure the PoE device (PD) type that can be connected to the port.

This command must be used to enable PoE on a port before connecting a PD to the port. When a PD is connected to an enabled port, the software attempts to detect the type of device (that is, PoE, PoE+, PoE++, or HPoE) and the power it is requesting. If the detection is successful and the power request is within the maximum PoE power budget configured, power is supplied to the connected device. Otherwise, the request is denied and no power is provided to the port.

Note:

The user must configure the maximum PoE power budget for the system using the configure system poe max-poe-power-budget command before enabling PoE on any port. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about this command.

The no form of this command disables PoE, PoE+, PoE++, and HPoE capabilities on the specified port. If PoE is disabled, the software does not attempt to detect the characteristics of the connected PD.

Default

poe

Parameters
plus

Keyword to support PoE+ and allow 802.3at (Type-2) PoE devices to be connected to the port and request up to 30 W.

plusplus

Keyword to support PoE++ and allow 802.3bt (Type-3) PoE devices to be connected to the port and request up to 60 W.

hpoe

Keyword to support HPoE and allow 802.3bt (Type-4) PoE devices to be connected to the port and request up to 90 W.

qinq-etype
Syntax

qinq-etype value

no qinq-etype

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the Ethertype used for Q-in-Q encapsulation.

When the qinq-etype is configured to a value other than the default value on a port, the outermost tag in the received packet is matched against the configured value and the inner tag's etype is matched against the default value. If there is a match, it is treated as a QinQ packet and the outer VLAN ID and inner VLAN ID is used to match against the configured Q1.Q2 SAPs on the port to find the QinQ SAP the packet should be matched to. If only the outermost tag's etype matches the qinq-etype configured on the port and the VLAN ID matches any of the Q1.* SAP configured on the port, the packet is processed in the context of that SAP. If the outermost tag's etype does not match the configured qinq-etype, then the packet is considered to be a untagged packet.

Note:

  • This command is supported only for access ports and hybrid ports. On hybrid ports, it applies to all traffic (that is, traffic mapped to SAPs and network IP interfaces). It is not supported for network ports.

  • The maximum number of unique qinq-etypes configurable per node is limited. The resources needed for configuration of qinq-etype is shared by the default dot1q-etype, default qinq-etype and user configured values for qinq-etype. That is, the number of unique dot1q-etypes allowed decreases if the number of unique qinq-etype configured is more. The reverse is also true.

  • The qinq-etype change is not allowed on hybrid port, if there is an interface or a SAP configured on the port.

The no form of this command reverts the qinq-etype value to the default value. The default value is not user configurable.

Default

0x8100

Parameters
value

Specifies the qinq-etype to expect, in hexadecimal or decimal notation.

Values

1536 to 65535, or 0x0600 to 0xffff. Ensure that the values do not match any of the IEEE reserved Ethertype values such as 0x8a88, 0x9100, and 0x9200.

statistics
Syntax

statistics

Context

config>port>ethernet

Platforms

7210 SAS-D, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure the counters associated with the egress port.

egress
Syntax

egress

Context

config>port>ethernet>statistics

Platforms

7210 SAS-D, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure egress per queue statistics counter, which counts the total number of packets forwarded.

port-clock
Syntax

port-clock {master | slave | automatic}

Context

config>port>ethernet

Platforms

7210 SAS-D ETR, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command forces the copper port to be a master or slave or set it for automatic detection. Using a value of master ensures that the local node is the SyncE master. A SyncE master port distributes the system timing over the copper port to the remote peer node. Using a value of slave ensures that the local node is a SyncE slave. A SyncE slave port uses the incoming timing information.

With copper ports using 1G speed, the nodes need to determine who will be the master and slave with respect to clock used for transmission and reception. The master-slave relationship between the two ports of the nodes is determined during autonegotiation of the link parameters and is automated; there is no management intervention in this process. When this process is complete, the master port transmit clock will be used for receiving the packets on the slave port. However, when SyncE is in use, to maintain clock distribution hierarchy (for example, master will be synchronized to a stable reference and will distribute this clock to the slave) one needs to make sure that one of the ports behave as a master while the remote port of the link in question behaves as a slave.

For copper ports, when port-clock is set to automatic, the Ethernet interface will automatically negotiate clock mastership along with other link parameters with the far end. Depending upon the capabilities of the two ends, one will be master the other will be slave for clocking.

Note:

This command is ignored for all ports, other than copper ports that support SyncE.

The no form of this command allows the node to automatically determine the master or slave status for the copper port based on the nodes capabilities exchanged during auto-negotiation. That is, depending on the peer setting, the local end could end up as either a master or a slave when the no form of this command is used.

The following conditions must be met before using SyncE on the fixed port copper ports:

  • Autonegotiation (or autonegotiation limited) must be turned on. This command is required only when the copper port speed is set to 1Gbps. This CLI command is not supported for fiber ports or for fiber ports that use copper SFPs.

  • The port clock must be set to slave, if the port is used as a source-port for any reference. On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platform, when using combo ports, the connection-type must be set to copper. The port-clock parameter is ignored if the connection-type is set to sfp or auto.

Default

automatic

Parameters
master

Specifies that the local node is the synchronous Ethernet master. A synchronous Ethernet master port distributes the system timing over the copper port to the remote peer node.

slave

Specifies that the local node is a synchronous Ethernet slave. A synchronous Ethernet slave port uses the incoming timing information.

automatic

Specifies that the Ethernet interface will automatically negotiate clock mastership along with other link parameters with the far end. Depending upon the capabilities of the two ends, one will be master the other will be slave for clocking.

speed
Syntax

speed {10 | 100 | 1000}

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the port speed of a fast Ethernet port when autonegotiation is disabled. If the port is configured to autonegotiate, the speed parameter is ignored. Speed cannot be configured for ports that are part of a LAG.

Note:

On the 7210 SAS-Dxp, the 10 Mb/s port speed is not supported for an SFP port using a copper SFP.

Default

speed 100

Parameters
10

Keyword to set the link to 10 Mb/s.

100

Keyword to set the link to 100 Mb/s.

1000

Keyword to set the link to 1000 Mb/s.

loopback
Syntax

[no] loopback {internal} [service svc-id sap sap-id src-mac SA dst-mac DA]

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This configures simple port loopback and port loopback with MAC swap. When the optional parameter internal is specified, it provides the port loopback without the mac-swap functionality. It enables physical layer loopback of the packets that egress on the SAPs created on an Ethernet port. The packets that egress are looped back into the node instead of being transmitted on to the line. After loopback, the packets ingress the system and are mapped to the same SAP from which they were egressed. The packets that are looped back are processed as per the service configuration of the SAP.

Note:

The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C only support port loopback without MAC swap (that is, only the config>port>ethernet> loopback internal command applies). Port loopback with MAC swap is not supported on these platforms.

This command, when used with service-id and MAC address, provides the port loopback with mac-swap functionality. It enables a physical layer loopback, so that packets which egress on the SAPs created on an Ethernet port are looped back into the system. After loopback, on ingress to the system, the MAC addresses in the Ethernet header are swapped (that is the source MAC address and destination MAC address is exchanged with each other) by the system before being processed as per the service configuration of the SAP.

On 7210 SAS platforms, use of port loopback with mac-swap, requires resources of another port to be assigned for system use. Users need to assign the resources of either internal virtual port or the resource of the front panel port for use with this OAM tool using the command configure> system> loopback-no-svc-port {mirror | mac-swap| testhead} port-id. The number of internal virtual port resources available for use is different for different platforms and can be obtained using the command show> system> internal-loopback-ports detail. Based on the number of internal virtual port resources and the use of other OAM tool that require the resources of another port, the user may need to assign the resources of a front-panel port if the internal virtual port resources are not available.

Note:

Port loopback without mac-swap does not require another port to be assigned for system use on any of the 7210 SAS platforms.

The following information describes guidelines for port loopback without mac-swap.

  • Use this command for testing VLL services.

  • Enabling this command for testing VPLS services leads to rapid MAC address movement to another port, as source or destination MAC address swap is not performed.

  • This command affects all services provisioned on the port.

  • Before enabling this command, turn off all Layer 2 and IP control protocols (such as LACP, EFM, 802.1x and so on) on the device and its peer to prevent errors such as protocol flaps caused by timeout and so on.When port loopback feature is to be used for multicast traffic with IGMP snooping enabled in the service, the corresponding datapath has to be statically created using static IGMP groups.

  • For loopback to be functional, the following are not required:

    • SFP or XFPs need not be inserted into the device.

    • Ethernet cables need not be plugged in for copper ports.

  • When the loopback command is enabled, ensure that Ethernet parameters such as speed, duplex, autonegotiation and so on are not modified.

The following information describes guidelines for port loopback with mac-swap:

  • This command is available for testing VLL services and VPLS services only.

  • When enabled, the command affects all services provisioned on the port.

  • Before enabling this command, turn off all Layer 2 and IP control protocols (such as LACP, EFM, 802.1x and so on) on the device and its peer to prevent errors such as protocol flaps caused by timeout and so on.When port loopback feature is to be used for multicast traffic with IGMP snooping enabled in the service, the corresponding datapath has to be statically created using static IGMP groups.

  • When using port loopback with mac-swap enabled, for unicast and unknown-unicast packets, if the packet matches the configured source and destination MAC address it will be swapped and looped back in the service. For broadcast and multicast packets, if the packet matches the configured source MAC address, its source MAC address will be used as the destination MAC address and the system MAC address will be the source MAC address. The packet is looped back in the service as a unicast packet. All other packets sent to the loopback port will be dropped as the forwarding of these packets after loopback can potentially cause network wide problems.

  • For loopback to be functional, the following are not required:

    • SFP or XFPs need not be inserted into the device.

    • Ethernet cables need not be plugged in for copper ports.

  • When the loopback is enabled, ensure that Ethernet parameters such as, speed, duplex, autonegotiation and so on are not modified.

  • When the loopback is enabled, ensure that service parameter and attributes such as ingress qos policy, accounting records, ingress/egress ACLs, and so on are not modified.

    With port loopback in use, the SAP ingress ACLs with IP-criteria is not recommended for use because only MAC addresses are swapped.

The recommended procedure for using port loopback with mac-swap is:

  • Configure the service and SAP on which loopback is to be enabled.

  • Configure the assigned loopback port to be used.

  • Send bidirectional learning frames on the SAP under test and spoke or uplink from a traffic tester or one can install static MAC for this purpose. Installing a static MAC is highly recommended because the recommended procedure for enabling port loopback is to shutdown the port –> enable loopback and then execute no shutdown the port.

  • Enable port loopback and specify the service, SAP, and the source MAC address (SA) and the destination MAC address (DA). All packets with source MAC matching SA are the only ones processed in the context of the SAP on ingress after the loopback. Any other traffic, is dropped on ingress, to avoid issues caused by MAC movement and flooding issues in other services/SAPs, since the whole port is in loopback.

  • When the port is in loopback, software disable learning and aging on the specified SAP. When the loopback configuration is removed for the port, then the software enables learning and aging for specified SAP. Therefore, port loopback with mac-swap cannot be used for learning or aging.

  • It is not recommend to change the service parameters for the SAP and the service when loopback is active. Additionally use of commands which clears the FDB, and so on is highly discouraged.

  • Remove the loopback on the SAP port to bring the sap out of MAC swap with loopback mode.

The no form of this command disables physical layer loopback on the Ethernet port.

Note:

The loopback command is not saved in the configuration file across a reboot.

The following list is the recommended sequence of commands to be executed to perform loopback:

  1. Disable the port, execute the config>port>shutdown command.

  2. Enable loopback, execute the config>port>ethernet>loopback internal command

  3. Enable the port, execute the config>port>no shutdown command.

  4. Perform the required tests.

  5. Disable the port, execute the config>port>shutdown command.

  6. Disable loopback, execute the config>port>ethernet>no loopback internal command

Enable the port, execute the command config>port> no shutdown.Enable the required services. The following list is the recommended sequence of commands to be executed to perform loopback when SFP or XFPs are inserted into the device:

  1. Insert SFP or XFPs. SFP or XFPs are not required in case of fixed copper ports.

  2. Enable the port and execute the config>port>no shutdown command.

  3. Disable the port and execute the config>port>shutdown command. Enable loopback and execute the config>port>ethernet>loopback internal command.

  4. Enable the port and execute the config>port>no shutdown command.Perform the required tests.

  5. Disable the port and execute the config>port>shutdown command. Disable loopback and execute the config>port>ethernet>no loopback internal command.

  6. Enable the port and execute the config>port>no shutdown command.Enable the required services.

The following list is the sequence of commands to be executed to perform loopback when SFP or XFPs are changed:

  1. Disable the port, execute the config>port>shutdown command.

  2. Insert the new SFP or XFP.

  3. Enable the port and execute the config>port>no shutdown command. Disable the port and execute the config>port>shutdown command. Enable loopback and execute the config>port>ethernet>loopback internal command.

  4. Enable the port and execute the config>port>no shutdown command.

  5. Perform the required tests.

  6. Disable the port and execute the config>port>shutdown command.

  7. Disable loopback and execute the config>port>ethernet>no loopback internal command.

  8. Enable the port and execute the config>port>no shutdown command.

  9. Enable the required services.

  10. Enable loopback and execute the config>port>ethernet>loopback internal command.

  11. Perform the required tests.

  12. Disable loopback and execute the config>port>ethernet>no loopback internal command.

  13. Enable the required services.

Parameters
internal

Sets the associated port or channel into a internal loopback mode. A internal loopback loops the frames from the local router back at the framer.

service svc-id

Specifies the unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every on which this service is defined.

Values

1 to 2147483648

sap sap-id

Specifies the physical port identifier portion of the SAP.

Values

nullport-id

dot1qport-id:qtag1

qinqport-id:qtag1.qtag2

port-idslot/mda/port[.channel]

id — 1 to 1000

qtag1 — 0 to 4094

qtag2 — *, 1 to 4094

src-mac SA

Specifies the source MAC address.

Values

SA 6-byte unicast mac-address (xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx).

dst-mac DA

Specifies the destination MAC address.

Values

DA 6-byte unicast mac-address (xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx).

ssm
Syntax

ssm

Context

config>port>ethernet

Platforms

7210 SAS-D ETR, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command enables Ethernet Synchronous Status Message (SSM) capability on a synchronous Ethernet port. Synchronous Ethernet must be enabled on the MDA (using the sync-e command) before SSM can be enabled.

code-type
Syntax

code-type [sonet | sdh]

Context

config>port>ethernet>ssm

Platforms

7210 SAS-D ETR, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures the encoding of synchronous status messages, that is, to select either SDH or SONET set of values. Configuring the code-type is only applicable to Synchronous Ethernet ports. For the code-type, SDH refers to ITU-T G.781 Option-1,while SONET refers to G.781 Option 2 (equivalent to Telcordia GR-253-CORE).

Default

sdh

Parameters
sdh

Specifies the values used on a G.781 Option 1 compliant network.

sonet

Specifies the values used on a G.781 Option 2 compliant network.

tx-dus
Syntax

[no] tx-dus

Context

config>port>ethernet>ssm

config>port>sonet-sdh (not supported on 7210 SAS-Dxp)

Platforms

7210 SAS-D ETR, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command forces the QL value transmitted from the SSM channel of the SONET/SDH port or the Synchronous Ethernet port to be set to QL-DUS/QL-DNU. This capability is provided to block the use of the interface for timing purposes from the 7210 SAS.

Default

no tx-dus

802.1x port commands
dot1x
Syntax

dot1x

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure port-specific 802.1x authentication attributes. This context can only be used when configuring Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet LAN ports on an appropriate MDA.

mac-auth
Syntax

[no] mac-auth

Context

config>port>ethernet>dot1x

Platforms

7210 SAS-Dxp

Description

This command enables MAC-based authentication. To use MAC-based authentication, 802.1x authentication must first be enabled using the port-control auto command.

When MAC-based authentication is enabled, and the mac-auth-wait timer expires, the 7210 SAS begins listening on the port for valid Ethernet frames. The source MAC address of a received frame is used for MAC-based authentication.

MAC authentication and Dot1x authentication or VLAN authentication are mutually exclusive and cannot be configured on the same port.

The no form of this command disables MAC-based authentication.

Default

no mac-auth

mac-auth-wait
Syntax

mac-auth-wait seconds

no mac-auth-wait

Context

config>port>ethernet>dot1x

Platforms

7210 SAS-Dxp

Description

This command configures the delay period before MAC authentication is activated.

The no form of this command disables the delay and allows MAC authentication to be used immediately.

Default

no mac-auth-wait

Parameters
seconds

Specifies the MAC authentication delay period, in seconds.

Values

1 to 3600

max-auth-req
Syntax

max-auth-req max-auth-request

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the maximum number of times that the 7210 SAS will send an access request RADIUS message to the RADIUS server. If a reply is not received from the RADIUS server after the specified number attempts, the 802.1x authentication procedure is considered to have failed.

The no form of this command reverts to the default value.

Default

2

Parameters
max-auth-request

Specifies the maximum number of RADIUS retries.

Values

1 to 10

port-control
Syntax

port-control [auto | force-auth | force-unauth]

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the 802.1x authentication mode.

The no form of this command reverts to the default value.

Default

force-auth

Parameters
force-auth

Specifies that 802.1x authentication will be disabled 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.

force-unauth

Specifies that the port will 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

Specifies that 802.1x authentication will be enabled. The port starts in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. Both the 7210 SAS and the host can initiate an authentication procedure. 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.

quiet-period
Syntax

quiet-period seconds

no quiet-period

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the period between two authentication sessions during which no EAPOL frames are sent by the 7210 SAS.

The no form of this command reverts to the default value.

Default

30

Parameters
seconds

Specifies the quiet period in seconds.

Values

1 to 3600

radius-plcy
Syntax

radius-plcy name

no radius-plcy

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the RADIUS policy to be used for 802.1x authentication. An 802.1x RADIUS policy must be configured (under config>security>dot1x) before it can be associated with a port. If the RADIUS policy-id does not exist, an error is returned. Only one 802.1x RADIUS policy can be associated with a port at a time.

The no form of this command removes the RADIUS policy association.

Default

no radius-plcy

Parameters
name

Specifies an existing 802.1x RADIUS policy name.

re-auth-period
Syntax

re-auth-period seconds

no re-auth-period

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the period after which re-authentication is performed. This value is only relevant if re-authentication is enabled.

The no form of this command reverts to the default value.

Default

3600

Parameters
seconds

Specifies the re-authentication delay period in seconds.

Values

1 to 9000

re-authentication
Syntax

[no] re-authentication

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables or disables periodic 802.1x re-authentication.

When re-authentication is enabled, the 7210 SAS will re-authenticate clients on the port every re-auth-period seconds.

The no form of this command reverts to the default value.

Default

re-authentication

server-timeout
Syntax

server-timeout seconds

no server-timeout

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the period during which the 7210 SAS waits for the RADIUS server to responds to its access request message. When this timer expires, the 7210 SAS will re-send the access request message, up to the specified number times.

The no form of this command reverts to the default value.

Default

30

Parameters
seconds

Specifies the server timeout period in seconds.

Values

1 to 300

supplicant-timeout
Syntax

supplicant-timeout seconds

no supplicant-timeout

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the period during which the 7210 SAS waits for a client to respond to its EAPOL messages. When the supplicant-timeout expires, the 802.1x authentication session is considered to have failed.

The no form of this command reverts to the default value.

Default

30

Parameters
seconds

Specifies the server timeout period in seconds.

Values

1 to 300

transmit-period
Syntax

transmit-period seconds

no transmit-period

Context

config>port>ethernet>dot1x

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the period after which the 7210 SAS sends a new EAPOL request message.

The no form of this command reverts to the default value.

Default

30

Parameters
seconds

Specifies the server transmit period in seconds.

Values

1 to 3600

tunneling
Syntax

[no] tunneling

Context

config>port>ethernet>dot1x

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command enables tunneling of dot1x frames. With dot1x tunneling enabled, dot1x frames received on the port are transparently forwarded to the remote end of the service. To forwards dot1x 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 when using any other service.

Additionally, dot1x protocol must be disabled on the port (using the command configure> port> ethernet> dot1x> port-control force-auth) before dot1x tunneling can be enabled using this command. If dot1x is configured to use either force-unauath or auto, then dot1x tunneling cannot be enabled. If dot1x tunneling is enabled, then the user cannot configure either force-unauth or auto.

The no form of this command disables dot1x tunneling.

Default

no tunneling

vlan-auth
Syntax

[no] vlan-auth

Context

config>port>ethernet>dot1x

Platforms

7210 SAS-Dxp

Description

This command enables VLAN-based authentication. To use VLAN-based authentication, 802.1x authentication must first be enabled using the port-control auto command.

When VLAN-based authentication is enabled, all traffic for all VLANs on the port is blocked. VLAN-tagged EAPOL messages are forwarded to the RADIUS server for authentication. If authentication is successful, the VLAN corresponding to the successfully authenticated VLAN-tagged EAPOL message is unblocked and traffic is processed for the configured service. If authentication fails, the VLAN continues to be blocked.

VLAN authentication and MAC authentication are mutually exclusive and cannot be configured on the same port.

The no form of this command disables VLAN-based authentication.

Default

no vlan-auth

down-when-looped
Syntax

down-when-looped

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures Ethernet loop detection attributes.

keep-alive
Syntax

keep-alive timer

no keep-alive

Context

config>port>ethernet>dwl

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the time interval between keep-alive PDUs.

Default

no keep-alive

Parameters
timer

Specifies the time interval, in seconds, between keep-alive PDUs.

Values

1 to 120

retry-timeout
Syntax

retry-timeout timer

no retry-timeout

Context

config>port>ethernet>dwl

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the minimum wait time before re-enabling the port after loop detection.

Default

no retry-timeout

Parameters
timer

Specifies the minimum wait time before re-enabling port after loop detection.

Values

0, 10 to 160

802.1x port MACsec commands
macsec
Syntax

[no] macsec

Context

config>port>ethernet>dot1x

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures MACsec functionality for the port.

Note:

When MACsec is configured on an Ethernet port, the oper MTU of the port is reduced by 32 bytes; for example, a configured MTU of 9212 results in an oper MTU of 9180 for a MACsec-enabled port. When a service or IP interface uses a MACsec-enabled port, an appropriate MTU value must be manually configured.

The no form of this command disables MACsec functionality for the port.

ca-name
Syntax

ca-name ca-name

no ca-name

Context

config>port>ethernet>dot1x>macsec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the CA linked to the MACsec port. The CA provides the MACsec parameter that is used or is negotiated with other peers.

The no form of this command removes the CA from the MACsec port.

Parameters
ca-name

Specifies the CA to use for the MACsec port, up to 32 characters.

eapol-destination-address
Syntax

eapol-destination-address mac

no eapol-destination-address

Context

config>port>ethernet>dot1x>macsec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the destination MAC address of the EAPoL to the unicast address of the MACsec peer, so that the EAPoL and MKA signaling is unicast between two peers.

The EAPoL destination MAC address uses a destination multicast MAC address of 01:80:C2:00:00:03. Some networks cannot tunnel these packets over the network or consume them, causing the MKA session to fail.

The no form of this command reverts to the default value.

Default

no eapol-destination-address

Parameters
mac

Specifies the destination MAC address used by the EAPoL MKA packets of the specified port. The 48-bit MAC address is in the form aa:bb:cc:dd:ee:ff or aa-bb-cc-dd-ee-ff, where aa, bb, cc, dd, ee, and ff are hexadecimal numbers.

exclude-protocol
Syntax

[no] exclude-protocol {protocol-name}

Context

config>port>ethernet>dot1x>macsec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the protocols for which packets are not secured with MACsec when MACsec is enabled on a port. When this command is enabled in a CA that is attached to an interface, MACsec is not enabled for all packets of the specified protocols that are sent and received on the link.

When this command is enabled on a port where MACsec is configured, packets of the specified protocols are sent and received in clear text.

Default

no exclude-protocol

Parameters
protocol-name

Specifies the protocol name.

Values

cdp, lacp, lldp, eapol-start

max-peer
Syntax

max-peer max-peer

no max-peer

Context

config>port>ethernet>dot1x>macsec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the maximum number of peers allowed for the specified MACsec instance.

Note:

The peer establishment is a race condition and operates on a first-come-first-served basis. For a security zone, only 32 peers are supported.

The no form of this command reverts to the default value.

Default

no max-peer

Parameters
max-peer

Specifies the maximum number of peers supported on this port.

Values

0 to 32

rx-must-be-encrypted
Syntax

[no] rx-must-be-encrypted

Context

config>port>ethernet>dot1x>macsec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies that all non-MACsec-secured traffic that is received on the port is dropped.

When this command is disabled, all arriving traffic is accepted, regardless of whether traffic is MACsec-secured.

Note:

This command is available only at the NULL port level and does not have per-VLAN granularity.

The no form of this command disables the command.

Default

rx-must-be-encrypted

shutdown
Syntax

[no] shutdown

Context

config>port>ethernet>dot1x>macsec

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command shuts down MACsec functionality, including MKA negotiation, for the port. In the shutdown state, the port is not MACsec capable and all PDUs are transmitted and expected without encryption and authentication.

A valid CA that is different from another CA configured on a sub-port of this port, and also a max-peer value larger than 0, must be configured. In MACsec-enabled mode, packets are sent in clear text until the MKA session is up, and if the rx-must-be-encrypted command is configured on the port, all incoming packets without MACsec are dropped.

The no form of this command sets the port to MACsec-enabled mode.

Default

shutdown

LLDP port commands
lldp
Syntax

lldp

Context

config>port>ethernet

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

Commands in this context configure Link Layer Discovery Protocol (LLDP) parameters on the specified port.

tunnel-nearest-bridge-dest-mac
Syntax

[no] tunnel-nearest-bridge-dest-mac

Context

config>port>ethernet>lldp

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command configures tunneling for LLDP frames that use the nearest-bridge-dest-mac as destination MAC address. If enabled using the tunnel-nearest-bridge-dest-mac command, all frames received with the appropriate destination MAC address are forwarded transparently to the remote end of the 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 when using any other service.

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> dest-mac nearest-bridge. If admin-status for dest-mac nearest-bridge is set to receive and process nearest-bridge LLDPDUs (that is, if either rx or tx-rx is set) then it overrides the tunnel-nearest-bridge-dest-mac command.

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

Table 25. LLDP behavior

Nearest-bridge MAC

Admin status

Tunneling

enabled

Tunneling

disabled

Rx

Process/Peer

Process/Peer

Tx

Tunnel

Drop

Rx-Tx

Process/Peer

Process/Peer

Disabled

Tunnel

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. It is recommended 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.

The no form of this command disable LLDP tunneling for frames using nearest-bridge destination MAC address.

Default

no tunnel-nearest-bridge-dest-mac

dest-mac
Syntax

dest-mac {nearest-bridge | nearest-non-tpmr | nearest-customer}

Context

config>port>ethernet>lldp

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures destination MAC address parameters to use by LLDP.

Parameters
nearest-bridge

Specifies to use the nearest bridge

nearest-non-tmpr

Specifies to use the nearest non-Two-Port MAC Relay (TPMR).

nearest-customer

Specifies to use the nearest customer.

admin-status
Syntax

admin-status {rx | tx | tx-rx | disabled}

Context

config>port>ethernet>lldp>dstmac

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies the desired administrative status of the local LLDP agent.

Parameters
rx

Specifies that the LLDP agent receives LLDP frames on this port, also indicates that the LLDP agent does not transmit LLDP frames.

tx

Specifies that the LLDP agent transmits LLDP frames on this port and does not store any information about the remote systems connected.

tx-rx

Specifies that the LLDP agent transmits and receives LLDP frames on this port.

disabled

Specifies that the LLDP agent does not transmit or receive LLDP frames on this port. If there is remote systems information which is received on this port and stored in other tables, before the port's admin status becomes disabled, then the information will naturally age out.

lldp-med
Syntax

lldp-med

Context

config>port>ethernet>lldp>dest-mac

Platforms

7210 SAS-Dxp

Description

Commands in this context configure the administrative status of the local LLDP-MED agent.

admin-status
Syntax

admin-status {tx-rx | disabled}

no admin-status

Context

config>port>ethernet>lldp>dest-mac>lldp-med

Platforms

7210 SAS-Dxp

Description

This command configures the administrative status of the local LLDP-MED agent.

The no form of this command disables the ability to specify the administrative status of the local LLDP-MED agent.

Default

admin-status disabled

Parameters
tx-rx

Keyword to configure the LLDP agent to transmit and receive LLDP-MED TLVs on the configured port.

disabled

Keyword to indicate that the LLDP-MED agent does not transmit or receive LLDP frames with LLDP-MED TLVs on the configured port. If no remote systems information is received on the configured port and stored in other tables before the port administrative status becomes disabled, the information ages out.

network-policy
Syntax

network-policy policy-id [policy-id...(up to 4 max)]

no network-policy

Context

config>port>ethernet>lldp>dest-mac>lldp-med

Platforms

7210 SAS-Dxp

Description

This command configures the network policy information that the node transmits in the Network Policy TLV.

Up to four policies can be configured, as long as the configured application-type for each policy is different. The system includes multiple Network Policy TLVs (if multiple policies are configured), with the policy for each application-type included in its own Network Policy TLV. The Network Policy TLV order in the LLDP message matches the policy order configured in the CLI. If the system cannot fit all configured Network Policy TLVs into the LLDP frame because of size constraints, a log message is generated for the last network policy that exceeds the frame size. The error notification allows the user to adjust the configuration appropriately.

The user must explicitly configure a network policy (with values assigned to the endpoint device) before the transmission and reception of LLDP-MED TLVs on the port is allowed. If a port is configured to transmit the LLDP-MED Network Policy TLV but the user has not configured a network policy, the node will not transmit the Network Policy TLV. The node processes the received Network Policy TLV and displays the TLV values in the LLDP message received from the peer provided that the LLDP-MED receiving processing and Network Policy TLV processing is enabled, regardless of whether network-policy is configured.

The no form of this command removes the association of all network policies with the port.

Default

no network-policy

Parameters
policy-id

Specifies network policy ID.

Values

1 to 65535

tx-tlvs
Syntax

tx-tlvs [network-policy] [mac-phy-config-status]

no tx-tlvs

Context

config>port>ethernet>lldp>dest-mac>lldp-med

Platforms

7210 SAS-Dxp

Description

This command configures the specific transmit TLV from the network connectivity TLV set to be transmitted on the port if LLDP-MED TLV transmission is enabled on the port.

The no form of this command removes the configuration.

Default

no tx-tlvs

Parameters
network-policy

Keyword to enable the transmission of the network policy TLV.

mac-phy-config-status

Keyword to enable the transmission of the MAC-PHY Configuration and Status TLV.

notification
Syntax

[no] notification

Context

config>port>ethernet>lldp>dstmac

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables LLDP notifications.

The no form of this command disables LLDP notifications.

port-id-subtype
Syntax

port-id-subtype {tx-if-alias | tx-if-name | tx-local}

no port-id-subtype

Context

config>port>ethernet>lldp>dest-mac

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command specifies how to encode the PortID TLV transmit to the peer. Some versions of the NSP NFM-P require the default tx-local (if Index value) setting to properly build the Layer Two topology map using LLDP. Changing this setting to transmit the ifName (tx-if-name) or ifAlias (tx-if-alias), instead of the ifIndex (tx-local), may affect the ability of the NSP NFM-P to build the Layer 2 topology map using LLDP.

The no form of this command reverts to the default value.

Default

portid-subtype tx-local

Parameters
tx-if-alias

Keyword to transmit the ifAlias String (subtype 1) that describes the port as stored in the IF-MIB, either user configured or the default entry (for example, 10/100/Gig Ethernet SFP).

tx-if-name

Keyword to transmit the ifName string (subtype 5) that describes the port as stored in the IF-MIB ifName information.

tx-local

Keyword to specify the interface ifIndex value (subtype 7) as the PortID.

tx-mgmt-address
Syntax

tx-mgmt-address [system] [system-ipv6]

no tx-mgmt-address

Context

config>port>ethernet>lldp>dstmac

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

This command specifies which management address to transmit. The operator can choose to send the system IPv4 IP Address, system IPv6 address, or both.

Note:

The system address is sent only once. When both options are configured, both system addresses are sent. The system address must be configured for the specific version of the protocol to send the management address.

Default

no tx-mgmt-address

Parameters
system

Keyword to transmit the system IPv4 address.

system-ipv6

Keyword to transmit the system IPv6 address. This parameter can only be used on platforms that support IPv6.

tx-tlvs
Syntax

tx-tlvs [port-desc] [sys-name] [sys-desc] [sys-cap]

no tx-tlvs

Context

config>port>ethernet>lldp>dstmac

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies which LLDP TLVs to transmit.

The no form of this command reverts to the default value.

Default

no tx-tlvs

Parameters
port-desc

Specifies that the LLDP agent should transmit port description TLVs.

sys-name

Specifies that the LLDP agent should transmit system name TLVs.

sys-desc

Specifies that the LLDP agent should transmit system description TLVs.

sys-cap

Specifie that the LLDP agent should transmit system capabilities TLVs.

Access-uplink port commands
network
Syntax

network

Context

config>port>ethernet

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure network port parameters.

uplink
Syntax

uplink

Context

config>port>access

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure access uplink egress port parameters.

accounting-policy
Syntax

accounting-policy policy-id

no accounting-policy

Context

config>port>ethernet>network

config>port>ethernet>access>uplink

config>port>ethernet>access

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C; the network context applies only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures an accounting policy that can apply to an interface.

An accounting policy must be configured before it can be associated with an interface. If the accounting policy-id does not exist, an error is returned.

Accounting policies associated with service billing can only be applied to SAPs. Accounting policies associated with network ports can only be associated with interfaces. Only one accounting policy can be associated with an interface at a time.

The no form of this command removes the accounting policy association from the network interface, and the accounting policy reverts to the default. No accounting policies are specified by default. You must explicitly specify a policy. If configured, the accounting policy configured as the default is used.

Parameters
policy-id

Specifies the accounting policy-id of an existing policy. Accounting policies record either service (access) or network information. A network accounting policy can only be associated with the network port configurations. Accounting policies are configured in the config>log>accounting-policy context.

Values

1 to 99

collect-stats
Syntax

[no] collect-stats

Context

config>port>ethernet>access>uplink

config>port>ethernet>access

config>port>ethernet>network

Platforms

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C; the network context applies only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables the collection of accounting and statistical data for the network interface. When applying accounting policies, the data, by default, is collected in the appropriate records and written to the designated billing file.

The no form of this command ensures that the statistics are still accumulated by the IOM cards, however, the CPU does not obtain the results and write them to the billing file.

If the collect-stats command is issued again (enabled), then the counters written to the billing file will include the traffic collected while the no collect-stats command was in effect.

Default

no collect-stats

queue-policy
Syntax

queue-policy name

no queue-policy

Context

config>port>ethernet>network

config>port>ethernet>access>uplink

Platforms

7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C; the network context applies only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the existing network queue policy which defines queue parameters such as CIR and PIR rates, as well as forwarding-class to queue mappings. The network-queue policy is defined in the config>qos>network-queue context.

A default CBS is defined for the queues and this is not configurable.

Default

default

Parameters
name

Specifies an existing network-queue policy name.

LAG commands
lag
Syntax

[no] lag [lag-id]

Context

config

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables the context for configuring Link Aggregation Group (LAG) attributes.

A LAG can be used to group multiple ports into one logical link. The aggregation of multiple physical links allows for load sharing and provides seamless redundancy. If one of the links fails, traffic will be redistributed over the remaining links.

There are three possible settings for autonegotiation:

  • ‟on” or enabled with full port capabilities advertised

  • ‟off” or disabled where there is no autonegotiation advertisements

  • ‟limited” where a single speed/duplex is advertised.

When autonegotiation is enabled on a port, the link attempts to automatically negotiate the link speed and duplex parameters. If autonegotiation is enabled, the configured duplex and speed parameters are ignored.

When autonegotiation is disabled on a port, the port does not attempt to autonegotiate and will only operate at the speed and duplex settings configured for the port. Note that disabling autonegotiation on gigabit ports is not allowed as the IEEE 802.3 specification for gigabit Ethernet requires autonegotiation be enabled for far end fault indication.

If the autonegotiate limited keyword option is specified the port will autonegotiate but will only advertise a specific speed and duplex. The speed and duplex advertised are the speed and duplex settings configured for the port. One use for limited mode is for multispeed gigabit ports to force gigabit operation while keeping autonegotiation is enabled for compliance with IEEE 801.3.

The system requires that autonegotiation be disabled or limited for ports in a LAG to guarantee a specific port speed.

The no form of this command deletes the LAG from the configuration. Deleting a LAG can only be performed while the LAG is administratively shut down. Any dependencies such as IP-Interfaces configurations must be removed from the configuration before issuing the no lag command.

Parameters
lag-id

The LAG identifier, expressed as a decimal integer.

Values

1 to 3 (7210 SAS-K 2F1C2T)

1 to 5 (7210 SAS-D)

1 to 6 (7210 SAS-Dxp, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C)

dynamic-cost
Syntax

[no] dynamic-cost

Context

config>lag

Platforms

Supported on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command enables OSPF costing of a Link Aggregation Group (LAG) based on the available aggregated operational bandwidth.

The path cost is dynamically calculated based on the interface bandwidth. OSPF path cost can be changed through the interface metric or the reference bandwidth.

If dynamic cost is configured, then costing is applied based on the total number of links configured and the cost advertised is inversely proportional to the number of links available at the time. This is provided that the number of links that are up exceeds the configured LAG threshold value at which time the configured threshold action determines if, and at what cost, this LAG will be advertised.

For example:

Assume a physical link in OSPF has a cost associated with it 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 and OSPF autocost is configured, then costing is applied based on the total number of links configured. This cost will remain static provided the number of links that are up exceeds the configured LAG threshold value at which time the configured threshold action determines if and at what cost this LAG will be advertised.

If dynamic cost is configured and OSPF autocost is not configured, the cost is determined by the cost configured on the OSPF metric provided the number of links available exceeds the configured LAG threshold value at which time the configured threshold action determines if this LAG will be advertised.

If neither dynamic-cost nor OSPF autocost are configured, the cost advertised is determined by the cost configured on the OSPF metric provided the number of links available exceeds the configured LAG threshold value at which time the configured threshold action determines if this LAG will be advertised.

The no form of this command removes dynamic costing from the LAG.

Default

no dynamic-cost

encap-type
Syntax

encap-type {dot1q | null | qinq}

no encap-type

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the encapsulation method used to distinguish customer traffic on a LAG. The encapsulation type is configurable on a LAG port. The LAG port and the port member encapsulation types must match when adding a port member.

If the encapsulation type of the LAG port is changed, the encapsulation type on all the port members will also change. The encapsulation type can be changed on the LAG port only if there is no interface associated with it. If the MTU is set to a non default value, it will be reset to the default value when the encap type is changed. All traffic on the port belongs to a single service or VLAN.

Note:

  • On the 7210 SAS-D ETR, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, the qinq encapsulation type can be configured for both access and access-uplink port LAGs. The null and dot1q encapsulation types can be specified only for access port LAGs.

  • On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the null and dot1q encapsulation types can be specified for network port LAGs. The dot1q and qinq encapsulation types can be specified for hybrid port LAGs.

The no form of this command reverts the default.

Default

null

Parameters
dot1q

Specifies that the ingress frames will carry 802.1Q tags where each tag signifies a different service.

null

Specifies that the ingress frames will not use any tags to delineate a service. As a result, only one service can be configured on a port with a null encapsulation type.

qinq

Specifies QinQ encapsulation.

hold-time
Syntax

hold-time down hold-down-time

no hold-time

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies the timer, in tenths of seconds, which controls the delay between detecting that a LAG is down (all active ports are down) and reporting it to the higher levels.

A non-zero value can be configured, for example, when active/standby signaling is used in a 1:1 fashion to avoid informing higher levels during the small time interval between detecting that the LAG is down and the time needed to activate the standby link.

Default

0

Parameters
down hold-down-time

Specifies the hold-time for event reporting.

Values

0 to 2000

lacp
Syntax

lacp [mode] [administrative-key admin-key] [system-id system-id] [system-priority priority]

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables the Link Aggregation Control Protocol (LACP) mode for aggregated Ethernet interfaces only. Per the IEEE 802.3ax standard (formerly 802.3ad), the LACP provides a standardized means for exchanging information between Partner Systems on a link. This allow their Link Aggregation Control instances to reach agreement on the identity of the Link Aggregation Group to which the link belongs, move the link to that Link Aggregation Group, and enable its transmission and reception functions in an orderly manner. LACP can be enabled on a maximum of 256 ports.

Default

no lacp

Parameters
mode

Specifies the mode in which LACP will operate.

Values

passive — Starts transmitting LACP packets only after receiving packets.

active — Initiates the transmission of LACP packets.

power-off — Disables transmitter of standby ports.

admin-key

Specifies an administrative key value to identify the channel group on each port configured to use LACP. This value should be configured only in exceptional cases. If it is not specified, a random key is assigned.

Values

1 to 65535

system-id

Specifies a 6 byte value expressed in the same notation as MAC address

Values

xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx

priority

Specifies the system priority to be used for the LAG in the context of the MC-LAG.

Values

0 to 65535

lacp-xmit-interval
Syntax

[no] lacp-xmit-interval {slow | fast}

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies the interval signaled to the peer and tells the peer at which rate it should transmit.

Default

fast

Parameters
slow

Specifies that packets will transmit every 30 seconds.

fast

Specifies that packets will transmit every second.

lacp-xmit-stdby
Syntax

[no] lacp-xmit-stdby

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command enables LACP message transmission on standby links.

The no form of this command disables LACP message transmission. This command should be disabled for compatibility when using active/standby groups. This forces a timeout of the standby links by the peer. Use the no form if the peer does not implement the correct behavior regarding the lacp sync bit.

Default

lacp-xmit-stdby

port
Syntax

port port-id [port-id up to n total] [priority priority] [subgroup sub-group-id]

no port port-id [port-id up to n total]

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command adds ports (links) to a Link Aggregation Group (LAG).

The port configuration of the first port added to the LAG is used as a basis to compare to subsequently added ports. If a discrepancy is found with a newly added port, that port is not added to the LAG.

The maximum number of ports allowed in a LAG depends on the platform. The following are the limits per platform:

  • On the 7210 SAS-D and 7210 SAS-Dxp, a maximum of four 1 GE ports can be added to or removed from the LAG. The 7210 SAS-Dxp also supports up to two 10 GE ports in a LAG.

  • On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, a maximum of three 1 GE ports can be added to or removed from the LAG.

  • On the 7210 SAS-K 3SFP+ 8C, a maximum of two 10 GE ports can be added to or removed from a LAG.

All ports added to a LAG must share the same characteristics (speed, duplex, and so on). An error message is displayed when adding ports that do not share the same characteristics. Hold timers must be 0. Ports that are part of a LAG must be configured with autonegotiation set to limited mode or disabled. No ports are defined as members of a LAG.

The no form of this command removes ports from the LAG.

Parameters
port-id

Specifies the port ID configured or displayed in the slot/mda/port format.

priority priority

Specifies the port priority used by LACP. The port priority is also used to determine the primary port. The port with the lowest priority is the primary port. In the event of a tie, the smallest port ID becomes the primary port.

Values

1 to 65535

subgroup sub-group-id

Specifies a LAG subgroup. Subgroups in a LAG must be configured on only one side of the LAG, not both. Having only one side perform the active/standby selection guarantees a consistent selection and fast convergence. The active/standby selection is signaled through LACP to the other side. The hold time should be configured when using subgroups to prevent the LAG going down when switching between active and standby links, in the case where no links are usable for a short time, especially in case a subgroup consists of one member.

Values

1 to 2

port-threshold
Syntax

port-threshold value[action {down}]

no port-threshold

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command configures the behavior for the Link Aggregation Group (LAG) if the number of operational links is equal to or below a threshold level.

The no form of this command reverts to the default values.

Default

‟0” action down

Parameters
value

Specifies the decimal integer threshold number of operational links for the LAG at or below which the configured action will be invoked. If the number of operational links exceeds the port-threshold value, any action taken for being below the threshold value will cease.

Values

0 to 3

action [{down}]

Specifies the action to take if the number of active links in the LAG is at or below the threshold value.

If the number of operational links is equal to or less than the configured threshold value and action down is specified, the LAG is brought to an operationally down state. The LAG is considered as operationally up only when the number of operational links exceeds the configured threshold value.

selection-criteria
Syntax

selection-criteria [{highest-count | highest-weight | best-port}] [slave-to-partner]

no selection-criteria

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies which selection criteria should be used to select the active sub-group.

Default

highest-count

Parameters
highest-count

Specifies sub-group with the highest number of eligible members.

highest-weight

Specifies sub-group with the highest aggregate weight.

best-port

Specifies the selection criteria used with ‟power-off” mode of operation. The sub-group containing the port with highest priority port. In case of equal port priorities the sub-group containing the port with the lowest port-id is taken

slave-to-partner

Specifies that, together with the selection criteria, the slave-to-partner keyword should be used to select the active sub-group. An eligible member is a lag-member link which can potentially become active. This means it is operationally up (not disabled) for use by the remote side. The slave-to-partner parameter can be used to control whether or not this latter condition is taken into account.

standby-signalling
Syntax

standby-signalling {lacp | power-off}

no standby-signalling

Context

config>lag

Platforms

Supported on all 7210 SAS platforms as described in this document

Description

This command specifies how the state of a member port is signaled to the remote side when the status corresponding to this member port has the standby value.

Default

lacp

Parameters
lacp

Specifies that LACP protocol is used to signal standby links of the LAG.

power-off

The laser of the standby links in the LAG are shutoff to indicate standby status. It allows user to use LAG standby link feature without LACP, if the peer node does not support LACP.

Multi-chassis redundancy commands
redundancy
Syntax

redundancy

Context

config

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure redundancy operations.

multi-chassis
Syntax

multi-chassis

Context

config>redundancy

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure multi-chassis parameters.

peer
Syntax

[no] peer ip-address create

Context

config>redundancy>multi-chassis

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the MC-LAG peer.

Parameters
ip-address

Specifies the IP address.

Values

ipv4-address: a.b.c.d

create

Specifies the mandatory keyword to create the peer.

authentication-key
Syntax

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

no authentication-key

Context

config>redundancy>multi-chassis>peer

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command configures the authentication key used between this node and the multi-chassis peer. The authentication key can be any combination of letters or numbers.

Parameters
authentication-key

Specifies the authentication key. Allowed values are any string up to 20 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.

hash-key

Specifies the hash key. The key can be any combination of ASCII characters up to 33 (hash1-key) or 55 (hash2-key) characters (encrypted). If spaces are used in the string, enclose the entire string in quotation marks.

hash

Specifies that the key is entered in an encrypted form. If the hash or hash2 parameter is not used, the key is assumed to be in a non-encrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.

hash2

Specifies that the key is entered in a more complex encrypted form that involves more variables then the key value alone, this means that the hash2 encrypted variable cannot be copied and pasted. If the hash or hash2 parameter is not used, the key is assumed to be in a non-encrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash or hash2 parameter specified.

description
Syntax

description long-description-string

no description

Context

config>redundancy>multi-chassis>peer

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command adds a text description for the ring path.

The no form of this command removes the text description.

Default

‟”

Parameters
string

Specifies the text description up to 160 characters.

MC Endpoint commands
hold-on-neighbor-failure
Syntax

hold-on-neighbor-failure multiplier

no hold-on-neighbor-failure

Context

config>redundancy>multi-chassis>peer>mc-ep

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the number of keep-alive intervals that the local node waits for packets from the MC-EP peer before assuming failure. After this time interval, all the mc-endpoints configured in the service revert to single chassis behavior, activating the best local pseudowire.

The no form of this command reverts the multiplier to the default value.

Default

3

Parameters
multiplier

Specifies the hold time applied on neighbor failure.

Values

2 to 25

MC-LAG commands
mc-lag
Syntax

[no] mc-lag

Context

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

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

Commands in this context configure multi-chassis LAG operations and related parameters.

The no form of this command administratively disables multi-chassis LAG. MC-LAG can be issued only when MC-LAG is shutdown.

hold-on-neighbor-failure
Syntax

hold-on-neighbor-failure multiplier

no hold-on-neighbor-failure

Context

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

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command specifies the standby node wait interval to receive packets from the active node before assuming a redundant-neighbor node failure. This delay in switchover operation is required to accommodate different factors influencing node failure detection rate, such as IGP convergence or HA switch-over times, and to prevent the standby node from taking action prematurely.

The no form of this command reverts the multiplier to the default value.

Default

3

Parameters
multiplier

Specifies the time interval that the standby node waits for packets from the active node before assuming a redundant-neighbor node failure.

Values

2 to 25

keep-alive-interval
Syntax

keep-alive-interval interval

no keep-alive-interval

Context

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

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command sets the interval at which keep-alive messages are exchanged between two systems participating in MC-LAG. These keep-alive messages are used to determine remote-node failure and the interval is set in deciseconds.

The no form of this command reverts the interval to the default value.

Default

10

Parameters
interval

Specifies the time interval expressed in deciseconds.

Values

5 to 500

lag
Syntax

lag lag-id lacp-key admin-key system-id system-id [remote-lag remote-lag-id] system-priority system-priority

lag [remote-lag remote-lag-id]

no lag lag-id

Context

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

Platforms

7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Description

This command defines a LAG that forms a redundant-pair for MC-LAG with a LAG configured on the specific peer. The same LAG group can be defined only in the scope of 1 peer. In order for MC-LAG to become operational, all configured parameters (lacp-key, system-id, system-priority) must be the same on both nodes of the same redundant pair.

In the partner system (the system connected to all links forming MC-LAG), all ports using the same lacp-key, system-id, system-priority are considered part of the same LAG. To achieve this in MC operation, both redundant-pair nodes must be configured with the same values. In case of a mismatch, MC-LAG is kept in the oper-down state.

The no form of this command disables MC-LAG for the specific LAG (regardless of the mode).

Note:

The correct CLI command to enable MC-LAG for a LAG in standby-signaling power-off mode is lag lag-id [remote-lag remote-lag-id]. In the CLI help output, the first three forms are used to enable MC-LAG for a LAG in LACP mode.

Parameters
lag-id

Specifies the LAG identifier, expressed as a decimal integer. Specifying the lag-id allows mismatch between lag-id on a redundant-pair. If no lag-id is specified, it is assumed that the neighbor system uses the same lag-id as a part of the specific MC-LAG. If no matching MC-LAG group can be found between neighbor systems, the individual LAGs will operate as usual (no MC-LAG operation is established).

Values

1 to 6 (for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

lacp-key