y1731
Load cfm.init.cfg
Set Eth16 and Eth17 on the switch as follows, if not already set:
An EVPN-VPWS service is already configured between CSR5 and CSR6.
Configure CFM as follows on the CE devices (CSR5 and CSR6):
Use EVC mode
You must remove the IP addresses on Gi1 and create an EFP with default encap
Associate this with BD 4100 and move the IP address to this bridge-domain
Use domain CUSTOMER with level 7
Use a service called “service1” and set the direction to down
Set the CSR5 MPID to 5, and CSR6 MPID to 6
Configure y1731 as follows:
Configure two-way delay from CSR5 using an interval of 50msec
Configure loss measurements using synthetic packets on both CSR5 and CSR6 using an interval of 50msec
Answer
Explanation
ITU-T Y.1731 was defined to be able to do performance monitoring on layer 2 Ethernet services. Y.1731 uses CFM to run delay and loss probes that determine loss and delay statistics over time. Y.1731 defines the CFM frame formats for these probes.
To begin, we must setup CFM. Both CEs are placed in the same domain, but this time we use EVC mode instead of port mode. To be able to use Y.1731 operations, we must either use EVC or VLAN mode.
We must remove the IP address from Gi2 and associate the EVC with a service instance.
Interestingly, the CEs do not see each other as remote maintenance-points yet until we add a bridge-domain. When using an EVC, the bridge domain number must be above 4096 so that it is not tied to a VLAN.
Now the CEs have discovered each other via CFM CCMs (continunity check messages).
Measuring Frame Loss
We configure Y.1731 using the IP SLA CLI. When measuring frame loss, we can measure using LMMs (loss measurement messages) or SLMs (synthetic loss messages).
This is a one-way operation, and the remote maintenance-point will automatically respond to the probe as a sort of “ICMP reply.” A reply means no frame loss, and a missing reply means the frame was lost.
The difference between SLMs and LMM is that SLMs supposedly synthesize data traffic. However, in the pcaps, I don’t see a major difference between them. The idea is that LMMs would be used for user data, and SLMs create a separate measurement probe by using synthesized data. But in the pcaps, LMMs seem to use their own frames as well.
This is a LMM (loss measurement message) and LMR (loss measurement reply):
This is a SLM and SLR:
We are asked to configure SLM using a frame interval of 50msec. This means that a probe is sent every 50msec. To create the IP SLA operation, you define the CFM domain, the MPIDs and the CoS value you’d like to use. Note that since we are using an untagged EFP, we must use a CoS of zero (0).
Using the command show ip sla statistics 200 we should see that measurements have been initiated and completed, which indicates that the Y.1731 loss measurement test is working:
Using the detail keyword we can see the loss rate:
If we flap CSR3’s Gi2, we can see some loss:
Measuring Frame Delay
Y.1731 can measure one-way delay or two-way delay. One-way delay requires clock synchronization, while two-way delay does not. A one-way delay operation is configured using 1DM and a two-way delay operation is configured using DMM.
If you using 1DM, you need to use receive on the other end. This is not the case for DMM (two-way delay). The other end automatically timestamps the DMR (delay measurement reply) when using two-way delay. You do not need any sort of “IP sla responder” configuration.
In this lab we configure a single two-way delay operation on CSR5 and specify the interval as 50msec.
The probes use DMMs (delay measurement messages) and DMRs (delay measurement replies):
This does not require clock sync, because the originating node simply subtracts like-values from each other. The node does (T4 - T1) to find the round trip time, and then subtracts (T3 - T2) from that, which is the processing time on the remote node.
Just like the y1731 loss test, we should see measurements initiated and completed:
Using the details keyword shows us the min/avg/max delay we are experiencing on the layer 2 service. In this lab, the average two-way round-trip delay is 55msec.
Notes on 1DM
When performing y1731 one-way delay measurements, one end sends the probes, and one end receives them and calculates the delay. The receiving end does not report the delay values to the sending end.
Above, CSR5 sends the probes, and CSR6 receives them.
On CSR5, it looks like the operation isn’t working:
However, it is actually working. We can only see the stats on CSR6. CSR6 takes the TxTimestampf sent from CSR5, and subtracts this from the RxTimestampf, which is when CSR6 received the frame. (This is T2-T1. T3 and T4 are unused in one-way delay measurements).
Above, there are no actual measurements. Perhaps because the clocks are not synced.
Further Reading
Last updated
