Oct 252011
CFM connectivity cheatsheet
As i mentioned in the previous chapter, it takes few steps to ensure the CFM connectivity is going to be established. It is quite easy, ordinary and straight forward process. It goes like this:
- First. MEPs should see each other physically. e.g. The links between (1) and (6) (see diagram below) should be all Up.
- Second. They should be in the same domain and MA. All ports (1)-(6) in the diagram below should be MEPs or MIPs in the same Maintenance association. If ONE of them is not – CFM connectivity will fail.
- Third. MEPs should face each other. UP MEP (1) will see UP MEP (6), but if (6) was DOWN mep, connectivity would fail. (e.g. (6) would send CCM packets OUTSIDE of the margins of this network, and (1) would never hear them.)
- Fourth. Hello interval should be the same. This is valid for (1) and (6). The MIP ports will simply pass the CCM messages to the next MIP or MEP. But if the End points are not sending the messages in the same interval – the connectivity will fail. It is not just the frequency, because the CCM packet is having a flag, that says what “hello-interval” is the CFM sending it was set to work on. MEPs set on hello interval 1 second, will not connect to MEPs set to generate CCMs every 10ms.
CFM connectivity
- Fifth. There must be MIPs in between them, so the CCMs are transferred. If any of the ports (2)-(5) is not a valid MIP port (e.g. In some of the intermediate points, you forgot to enable MIP creation policy or simply the port is not in the same L2 VLAN or L3 service)
- Sixth. All of the MEPs should generate CCMs. If only (1) is generating CCMs, there will be partial connectivity. (6) will see (1), but (1) will not see (6).
- Seventh. No higher level MEPs should be staying in the way. If MEPs (1) and (6) are level 4 CFM domain and somewhere in (2)-(5) there is MEP of domain level 5,6 or 7 – the higher level MEP will filter the CCMs of domain level 4. It is by design. No high level CFM (e.g. user level) should hear management traffic from the core network. This is designed for security and optimization reasons.
- Eight. There should not be MEPs in the same domain in the way, facing oposite direction. If in port (3) or (5) there is Down MEP in the same MA, connectivity between (1) and (6) will not happen, because the MEP will filter the CCMs coming from the direction It is facing. (MEP means End Point) Instead of this, connectivity between (1) and (3) or (5) will hapen.
- Ninth. MEP IDs should be unique in the MA. *(not necessary in different MD/MA cases). In case MEP id in (1) is equal to MEP id in (6) connectivity will not happen. MEP id should be unique in the MA in the range 1 – 8192.
That’s basically all you need to be aware, when creating OAM monitored VLAN or Service. Mep connectivity is very important for building higher scale OAM monitored networks, as Rings, Meshes or Ladder networks with mixed Layer 2 and Layer 3 parts, as this example:
R-APS and MPLS
10 Responses to “OAM CFM connectivity cheatsheet”
Sorry, the comment form is closed at this time.
Shouldn’t this:
MEPs should face each other. UP MEP (1) will see UP MEP (6), but if (6) was UP mep, connectivity would fail.
Be:
MEPs should face each other. UP MEP (1) will see UP MEP (6), but if (6) was DOWN mep, connectivity would fail.
?
Yes, you are absolutely right. I misplaced DOWN with UP. Fixing It accordingly.
according third, both (1) and (6) should be UP MEPs, then connectivity happen, if (6) is down, and (1) is up, connectivity fails. but in Eight, why connectivity is OK between (1) and (3) or (5)–(1) is UP, and (3) or (5) is down
?
If MEP (6) id down MEP, it will send CCMs to the outside of this small topology. If there are no other MEPs to reply with CCMs – connectivity will not happen at all.
If port (3) or (5) were Down MEP, they would face MEP (1) and connectivity would also happen.
See the other diagram here, for reference -> https://www.m0rd0r.eu/ccms-and-mep-types/ (Just imagine the box is a real device 🙂 )
one more question, in which scenario, DOWN MEP could be used, it seems all MEP should be UP
Down MEPs are useful between back-to-back connections, because the CCMs are send only to the monitored line between the 2 devices. This will spare you a lot of monitoring traffic, because down MEPs will allow it just inside the monitored line.
thx a lot, i got it
Hi,
Can you please explain the scenario in an ERS,EWS environment and configurations required on the PE’s and the UPE’s.
My present setup is like below
(Up direction Mep)PE(L2 Switchport trunk)====(L2 Switchport trunk)PE L2 VPN————PE L2VPN=======UPE(Up Direction mep)
But i am not able to discover the remote Mep’s and is it mandate to have a MIP in all these PE’s since there has been a few limitations considering 7600 boxes for pseudowire endpoints to act as MIP’s.
Regards
Karthik
It shouldn’t. Connectivity must be established. This is very straight-forward setup.
There are 2 possible issues with your setup.
1. The CCMs are rewritten by some access-list (either PRIority byte or the VLAN ID / Service ID).
2. Some of the middle devices is filtering Multicast packets for some reason.
Case 1: Sniff the traffic and isolate the CCMs. If the header is rewritten – check what breaks it.
Case 2: Check port statistics for Discarded multicast packets.
Case 3: Send me the configurations (my Email is in the “About” Page) and I will try to check it for you.
@m0rd0r, Thanks for explaining these CFM concepts like you did. It was so easy and comfortable to understand.