802.3ah OAM

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.