> For the complete documentation index, see [llms.txt](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/ethernet-oam/y1731.md).
# y1731
Load **cfm.init.cfg**
```
#IOS-XR
configure
load configs/cfm.init.cfg
commit replace
y
#IOS-XE
config replace flash:cfm.init.cfg
```
Set Eth16 and Eth17 on the switch as follows, if not already set:
```
int eth16
sw mode access
sw acc vlan 3315
int eth17
sw mode access
sw acc vlan 3336
```
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
```
## CFM Config
#CSR5
ethernet cfm ieee
ethernet cfm global
ethernet cfm domain CUSTOMER level 7
service service1 evc EVC1 direction down
continuity-check
exit
exit
int gi2
no ip address
service instance 1 ethernet EVC1
encapsulation default
cfm mep domain CUSTOMER mpid 5
bridge-domain 4100
!
int bdi4100
no shut
ip add 10.0.0.5 255.255.255.0
#CSR6
ethernet cfm ieee
ethernet cfm global
ethernet cfm domain CUSTOMER level 7
service service1 evc EVC1 direction down
continuity-check
exit
exit
int gi2
no ip address
service instance 1 ethernet EVC1
encapsulation default
cfm mep domain CUSTOMER mpid 6
bridge-domain 4100
!
int bdi4100
no shut
ip add 10.0.0.6 255.255.255.0
##y1731 CONFIG
#CSR5
ip sla 100
ethernet y1731 delay DMM domain CUSTOMER evc EVC1 mpid 6 cos 0 source mpid 5
frame interval 50
ip sla schedule 100 life forever start-time now
!
ip sla 200
ethernet y1731 loss SLM domain CUSTOMER evc EVC1 mpid 6 cos 0 source mpid 5
frame interval 50
ip sla schedule 200 life forever start-time now
#CSR6
ip sla 200
ethernet y1731 loss SLM domain CUSTOMER evc EVC1 mpid 5 cos 0 source mpid 6
frame interval 50
ip sla schedule 200 life forever start-time now
```
## 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.
```
ethernet cfm ieee
ethernet cfm global
ethernet cfm domain CUSTOMER level 7
service service1 evc EVC1 direction down
continuity-check
!
int gi2
no ip address
service instance 1 ethernet EVC1
encapsulation default
cfm mep domain CUSTOMER mpid 5
```
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.
```
int gi2
service instance 1 ethernet EVC1
bridge-domain 4100
!
int bdi4100
no shut
ip add 10.0.0.5 255.255.255.0
```
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).
```
ip sla 1
ethernet y1731 loss LMM|SLM
```
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).
```
#CSR5
ip sla 200
ethernet y1731 loss SLM domain CUSTOMER evc EVC1 mpid 6 cos 0 source mpid 5
frame interval 50
ip sla schedule 200 life forever start-time now
```
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**.
```
ip sla 100
ethernet y1731 delay 1DM|DMM|receive
```
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.
```
ip sla 100
ethernet y1731 delay receive
```
In this lab we configure a single two-way delay operation on CSR5 and specify the interval as 50msec.
```
#CSR5
ip sla 100
ethernet y1731 delay DMM domain CUSTOMER evc EVC1 mpid 6 cos 0 source mpid 5
frame interval 50
ip sla schedule 100 life forever start-time now
```
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.
```
#CSR5
ip sla 99
ethernet y1731 delay 1DM domain CUSTOMER evc EVC1 mpid 6 cos 0 source mpid 5
ip sla schedule 99 life forever start-time now
#CSR6
ip sla 99
ethernet y1731 delay receive 1DM domain CUSTOMER evc EVC1 cos 0 mpid 6
ip sla schedule 99 life forever
```
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