Using Ethernet Fault Detection

Different interfaces on the routers nowadays support layer 1 failure detection where the signal loss between two peers is detected and the information is communicated to the control plane to allow a corrective action. POS interfaces detect complex failures in the routers at layer 2 level and use higher level protocols such as Point-to-Point Protocol (PPP) to negotiate the state between peers before the interface is brought up at an layer 2 level in the control plane.

With the proliferation of the pure layer 2 network, ethernet must also detect failures and perform corrective actions. Hence, the Ethernet Fault Detection (EFD) mechanism is used that allows Ethernet OAM protocols, such as CFM, to control the "line protocol" state of an interface so that if a CFM defect is detected, the corrective actions can be performed.

Previously, EFD was used as an event notifier for CFM only. Protocols like G8032 and REP could register to CFM events and could update the protocol (could bring it down or up) accordingly. But now, EFD allows CFM events and the OAM protocols to be used as an layer 2 BFD or line-protocol for Ethernet interfaces.

Information about Ethernet Fault Detection

Ethernet Fault Detection (EFD) is a mechanism that allows Ethernet OAM protocols, such as CFM, to control the “line protocol” state of an interface.Unlike many other interface types, Ethernet interfaces do not have a line protocol, whose state is independent from that of the interface. For Ethernet interfaces, this role is handled by the physical-layer Ethernet protocol itself, and therefore if the interface is physically up, then it is available and traffic can flow.

EFD changes this to allow CFM to act as the line protocol for Ethernet interfaces. This allows CFM to control the interface state so that if a CFM defect (such as AIS or loss of continuity) is detected with an expected peer MEP, the interface can be shut down. This not only stops any traffic flowing, but also triggers actions in any higher-level protocols to route around the problem. For example, in the case of Layer 2 interfaces, the MAC table would be cleared and MSTP would reconverge. For Layer 3 interfaces, the ARP cache would be cleared and potentially the IGP would reconverge.


Note
EFD can only be used for down MEPs. When EFD is used to shut down the interface, the CFM frames continue to flow. This allows CFM to detect when the problem has been resolved, and thus bring the interface backup automatically.
Figure 1. CFM Error Detection and EFD Trigger


The figure shows CFM detection of an error on one of its sessions EFD signaling an error to the corresponding MAC layer for the interface. This triggers the MAC to go to a down state, which further triggers all higher level protocols (Layer 2 pseudowires, IP protocols, and so on) to go down and also trigger a reconvergence where possible. As soon as CFM detects there is no longer any error, it can signal to EFD and all protocols will once again go active.

Prerequisites for EFD

  • EFD should be configured on only one side of the connection. When both sides go down because of EFD, CFM cannot be brought up as CFM frames are not sent by both the nodes.

  • EFD is supported on EFP, port-channel, and port MEPs.

Limitations and Restrictions for EFD

  • EFD is supported only on Down MEPs.

  • When a EFD line-protocol enabled CFM service has down MEPs configured under different interfaces (EFP), EFD events such as CCM interval mismatch, MD level mismatch bring down all the interfaces containing MEPs created for this CFM service.

  • EFD action is not applicable to Trunk EFPs.

  • EFD actions are not successful with a forwarding-loop.

Enabling Ethernet Fault Detection for a Service

To enable Ethernet Fault Detection (EFD) for a service to achieve fast convergence, complete the following steps:

Procedure

Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 3

ethernet cfm global

Example:


Device(config)# ethernet cfm global

Enables Ethernet CFM globally.

Step 4

ethernet cfm domaindomain-name level level-id [direction outward]

Example:


Device(config)# ethernet cfm domain G8032 level 4

Configures the CFM domain for ODU 1 and enters Ethernet CFM configuration mode.

Step 5

service {ma-name | ma-num | vlan-id vlan-id | vpn-id vpn-id} [port | vlan vlan-id [direction down]]

Example:


Device(config-ecfm)# service 8032_service evc 8032-evc vlan 1001 direction down

Defines a maintenance association for ODU 1 and enters Ethernet CFM service instance configuration mode.

Step 6

continuity-check [interval time | loss-threshold threshold | static rmep]

Example:


Device(config-ecfm-srv)# continuity-check interval 3.3ms

Enables the transmission of continuity check messages (CCMs).

Step 7

efd notify g8032

Example:


Device(config-ecfm-srv)# efd notify g8032

Enables CFM to notify registered protocols when a defect is detected or cleared, which matches the current fault alarm priority.

Step 8

efd line-protocol

Example:

Device(config-ecfm-srv)# efd line-protocol

Triggers line-protocol action when the CFM error-database is updated.

Step 9

end

Example:


Device(config-ecfm-srv)# end

Returns to user EXEC mode.

Configuration Example for EFD

The following example shows a sample output of a service instance that is brought down by an EFD action. 
Device#show ethernet ser ins int g0/0/6
Identifier Type Interface State CE-Vlans 
2 Static GigabitEthernet0/0/6 ErrorDis

The following example is a sample of configuration of EFD. 

Device#show ethernet ser ins int g0/0/6
Identifier Type Interface State CE-Vlans
2 Static GigabitEthernet0/0/6 ErrorDis