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