7210 SAS interfaces

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

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# 

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# 

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# 

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# 

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# 

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.

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
===============================================================================

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

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.

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.

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

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

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.

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:

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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

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

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

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