Programmable Internetworking & Communication Operating System Docs ... Click Spaces -> Space Directory to see docs for all releases ...
Page tree
Skip to end of metadata
Go to start of metadata

Connectivity Fault Management (CFM) is an IEEE standard, 802.1ag, which specifies protocols, procedures, and managed objects to support transport fault management. CFM is used for detecting link connectivity fault, confirming the fault and locating the fault in the network.



 

The standard, 802.1ag defines:

  • Maintenance domains (MD), their constituent maintenance points (MIP, MEP), and the managed objects (MA) required to create and administer them.
  • The relationship between maintenance domains and the services offered by VLAN-aware bridges and provider bridges.
  • The description of protocols and procedures used by maintenance points to maintain and diagnose connectivity faults within a maintenance domain.
  • Means for future expansion of the capabilities of maintenance points and their protocols.

As illustrated in the above figure, each domain (operator, provider, customer) is allocated. Maintenance association Intermediate endPoint (MIP) and Maintenance domain End Point (MEP) essentially define the domain boundaries and the intermediate elements. Effectively, these end-points define a fault-domain which aids in building a flexible fault-management framework. Network and Service OAM shown above, are typically used to represent faults to a network operator and a service consumer.

 

IEEE 802.1ag Ethernet CFM (Connectivity Fault Management) protocols comprise three protocols that work together to help administrators debug Ethernet networks.They are:

 

Continuity Check Protocol (CCP) - Heartbeat messages for CFM. The Continuity Check Message (CCM) provides a means to detect connectivity failures in an MA. CCMs are multicast messages. CCMs are confined to a domain (MD). These messages are unidirectional and do not solicit a response. Each MEP transmits a periodic multicast Continuity Check Message inward towards the other MEPs.

 

Link Trace (LT) - Link Trace messages otherwise known as Mac Trace Route, are Multicast frames that a MEP transmits to track the path (hop-by-hop) to a destination MEP, which is similar in concept to User Datagram Protocol(UDP) Trace Route. Each receiving MEP sends a Trace Route Reply directly to the Originating MEP, and regenerates the Trace Route Message.

 

Loop-back (LB) - Loop-back messages otherwise known as MAC ping are Unicast frames that a MEP transmits, they are similar in concept to an Internet Control Message Protocol (ICMP) Echo (Ping) messages, sending Loopback to successive MIP's can determine the location of a fault. Sending a high volume of Loopback Messages can test bandwidth, reliability, or jitter of a service, which is similar to flood ping. An MEP can send a Loopback to any MEP or MIP in the service. Unlike CCMs, Loop back messages are administratively initiated and stopped.

Monitor connectivity to a remote maintenance point on ge-1/1/1

Set the MPID of CFM:

admin@PicOS-OVS$ ovs−vsctl set Interface ge-1/1/1 cfm_mpid=2333 

A Maintenance Point ID (MPID) uniquely identifies each endpoint within a Maintenance Association. According to the 802.1ag specification, MPIDs can only range between [1, 8191].

Set extended mode:

admin@PicOS-OVS$ovs−vsctl set Interface ge-1/1/1 other_config:cfm_extended=true

Extended mode increases the accuracy of the cfm_interval configuration parameter by breaking wire compatibility with 802.1ag compliant implementations.  An extended mode allows eight byte MPIDs.

Set demand mode:

admin@PicOS-OVS$ovs−vsctl set Interface ge-1/1/1 other_config:cfm_demand=true

When true, and cfm_extended is true, the CFM module operates in demand mode. By default it is set to false. When in demand mode, traffic received on the Interface is used to indicate liveness. CCMs are still transmitted and received. At least one CCM must be received every 100 * cfm_interval amount of time. Otherwise, even if traffic is received, the CFM module will trigger the connectivity fault. Demand mode disables itself when there are multiple remote maintenance points.

Set the requested transmission interval:

admin@PicOS-OVS$ovs−vsctl set Interface ge-1/1/1 other_config:cfm_interval=10000

In standard mode supports intervals of 3, 10, 100, 1000, 10000,60000, or 600000 ms are supported. Extended mode supports any interval up to 65535 ms and default is 1000 ms. However, we do not recommend intervals less than 100 ms.

Set CCM VLAN tag:

admin@PicOS-OVS$ovs−vsctl set Interface ge-1/1/1 other_config:cfm_ccm_vlan=2000
admin@PicOS-OVS$ovs−vsctl set Interface ge-1/1/1 other_config:cfm_ccm_vlan=random

When set, the CFM module will apply a VLAN tag to all CCMs it generates with the given value.

Set CCM Priority:

admin@PicOS-OVS$ovs−vsctl set Interface ge-1/1/1 other_config:cfm_ccm_pcp=7

When set, the CFM module will apply a VLAN tag to all CCM's, it generates with the given PCP value, the VLAN ID of the tag is governed by the value of "cfm_ccm_vlan". If "cfm_ccm_vlan" is unset, a VLAN ID of zero is used.

 CFM Example

Step 1:  Basic configuration

DUT1:

admin@PicOS-OVS$ovs-vsctl add-br br0 -- set bridge br0 datapath_type=pica8
admin@PicOS-OVS$ovs-vsctl add-port br0 ge-1/1/1 vlan_mode=trunk tag=1  -- set Interface ge-1/1/1 type=pica8
admin@PicOS-OVS$ovs-vsctl add-port br0 ge-1/1/2 vlan_mode=trunk tag=1  -- set Interface ge-1/1/2 type=pica8

DUT2:

admin@PicOS-OVS$ovs-vsctl add-br br0 -- set bridge br0 datapath_type=pica8
admin@PicOS-OVS$ovs-vsctl add-port br0 ge-1/1/1 vlan_mode=trunk tag=1  -- set Interface ge-1/1/1 type=pica8
admin@PicOS-OVS$ovs-vsctl add-port br0 ge-1/1/2 vlan_mode=trunk tag=1  -- set Interface ge-1/1/2 type=pica8

Step 2:  Configure cfm:

DUT1:

admin@PicOS-OVS$ovs-vsctl set interface ge-1/1/2 cfm-mpid=8999
admin@PicOS-OVS$ovs-vsctl set interface ge-1/1/2 other_config:cfm_extended=true

DUT2:

admin@PicOS-OVS$ovs-vsctl set interface ge-1/1/1 cfm-mpid=9000
admin@PicOS-OVS$ovs-vsctl set interface ge-1/1/1 other_config:cfm_extended=true

Step 3:  Check packets

DUT1:

Check list interface:

admin@PicOS-OVS$ovs-vsctl list interface ge-1/1/2
_uuid : 94942d57-d9a8-4030-ad3b-483dadbd7926
admin_state : up
bfd : {}
bfd_status : {}
cfm_fault : false
cfm_fault_status : []
cfm_flap_count : 2
cfm_health : []
cfm_mpid : 8999
cfm_remote_mpids : [9000]
cfm_remote_opstate : up
duplex : full
external_ids : {}
ifindex : 13
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : 1000000000
link_state : up
mac : []
mac_in_use : "00:e0:ec:25:2d:5e"
mtu : 9212
name : "ge-1/1/2"
ofport : 13
ofport_request : []
options : {}
other_config : {cfm_extended="true"}
statistics : {collisions=0, rx_bytes=3255, rx_crc_err=0, rx_dropped=28, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=35, tx_bytes=1395, tx_dropped=0, tx_errors=0, tx_packets=15}
status : {}
type : "pica8"
wred_queues : {}

Check cfm/show:

admin@PicOS-OVS$ovs-appctl  cfm/show 
---- ge-1/1/2 ----
MPID 8999: extended
                average health: undefined
                opstate: up
                remote_opstate: up
                interval: 1000ms
                next CCM tx: 481ms
                next fault check: 973ms
Remote MPID 9000
                recv since check: true
                opstate: up
admin@PicOS-OVS$

Check hardware table:

admin@PicOS-OVS$ovs-appctl pica/dump-flows
#168 normal permanent priority=18000000,in_port=2,dl_dst=01:23:20:00:00:30,dl_type=0x8902, actions:userspace(pid=0,slow_path(cfm))
#167 normal permanent priority=0, actions:drop
Total 2 flows in HW.

DUT2:

Check list interface:

admin@PicOS-OVS$ovs-vsctl list interface ge-1/1/1
_uuid : 61bb8ef5-30f9-4855-8cfa-f1ee0bc5b154
admin_state : up
bfd : {}
bfd_status : {}
cfm_fault : false
cfm_fault_status : []
cfm_flap_count : 0
cfm_health : []
cfm_mpid : 9000
cfm_remote_mpids : [8999]
cfm_remote_opstate : up
duplex : full
external_ids : {}
ifindex : 11
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : 1000000000
link_state : up
mac : []
mac_in_use : "08:9e:01:a8:00:49"
mtu : 9212
name : "ge-1/1/11"
ofport : 11
ofport_request : []
options : {}
other_config : {cfm_extended="true"}
statistics : {collisions=0, rx_bytes=1302, rx_crc_err=0, rx_dropped=8, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=14, tx_bytes=558, tx_dropped=0, tx_errors=0, tx_packets=6}
status : {}
type : "pica8"
wred_queues : {}
admin@PicOS-OVS$

Check cfm/show:

admin@PicOS-OVS$ovs-appctl  cfm/show 
---- ge-1/1/1 ----
MPID 9000: extended
                average health: undefined
                opstate: up
                remote_opstate: up
                interval : 1000ms
                next CCM tx: 802ms
                next fault check: 1254ms
Remote MPID 8999
                recv since check: true
                opstate: up
admin@PicOS-OVS$

Check hardware table:

admin@PicOS-OVS$ovs-appctl pica/dump-flows
#168 normal permanent priority=18000000,in_port=1,dl_dst=01:23:20:00:00:30,dl_type=0x8902, actions:userspace(pid=0,slow_path(cfm))
#167 normal permanent priority=0, actions:drop
Total 2 flows in HW.

Standard mode, dl_mac is 01:80:c2:00:00:30; when extended mode,the dst mac is 01:23:20:00:00:30.

Configue cfm on port ge-1/1/13, if delete cfm

admin@PicOS-OVS$ovs-vsctl clear interface ge-1/1/13 cfm_mpid
admin@PicOS-OVS$ovs-vsctl remove interface ge-1/1/13 other_config cfm_interval="10000"
admin@PicOS-OVS$ovs-vsctl remove interface ge-1/1/13 other_config cfm_extended="true"
admin@PicOS-OVS$ovs-vsctl remove interface ge-1/1/13 other_config cfm_ccm_vlan=random

 

 


 

  • No labels