Notes - y1564
ITU-T Y.1564 is a standard for performance testing of an Ethernet service. This is generally done by the provider before handing off the service to the customer. In the past, RFC2544 has been used, but it has its drawbacks. RFC2544 was created to test specific device throughput in a lab, not to test an end-to-end Ethernet service. RFC2544 also only tests one frame size at a time and needs to run for a very long time to ensure the service is acceptable.
Y.1564 testing is generally done with an external tester, but you can use the ASR920 itself as a Y.1564 traffic generator. This is done in two modes:
One-way testing, in which one ASR920 generates the traffic, and the remote ASR920 runs in passive mode, collecting statistics.
Two-way testing, in which one ASR920 generates the traffic, and the remote ASR920 loops the traffic back. The ASR920 generating the traffic also collects the statistics.
When traffic is generated, it can be generated internal from the UNI and bridged out the NNI, or external which means the traffic is generated directly out the NNI. Likewise, the responder can do an internal loopback which means the traffic is bridged to the UNI and then looped back, or do an external loopback in which the traffic is directly looped back at the NNI.

When generating the traffic, you must specify a target type.
Layer 2 target types:
bridge-domain
service instance
Layer 3 target types
physical interface
service instance
bridge-domain
VRF
All target types support an internal direction. Only a layer 2 service instance supports an external direction as well.
Y.1564 testing uses the IP SLA CLI configuration. The general syntax looks like this for an external test with a target of a service instance
ip sla 1
service-performance type ethernet dest-mac-addr <mac> int Gi2 service instance 1
frequency ...
profile packet
outer-vlan 10
profile traffic direction external
rate-step <rate>
duration time <time>
An internal test with a target of a bridge-domain looks like this:
int Gi1
description UNI
service instance 10 ethernet
encap dot1q 10
bridge-domain 10
!
int Gi2
description NNI
service instance 10 ethernet
encap dot1q 10
bridge-domain 10
!
ip sla 1
service-performance type ethernet dest-mac-addr <mac> bridge-domain 10
profile packet
outer-vlan 10
profile traffic direction internal
rate-step <rate>
The remote node would either need to loopback the traffic (two-way mode) or passively measure the traffic (one-way mode).
One-way mode looks like this:
! External measurement (measure incoming on the NNI)
ip sla 1
service-performance type thernet dest-mac-addr <mac> int Gi2 service instance 1
measurement-type direction external
receive
! Internal measurement (measure incoming on the NNI and then bridged to the UNI)
ip sla 1
service-performance type thernet dest-mac-addr <mac> int Gi1 service instance 1
measurement-type direction internal
receive
Two-way mode using an internal direction looks like this:
int Gi1
description NNI
service instance 10 eth
encap dot1q 10
bridge-domain 10
!
int Gi2
description UNI
service instance 10 eth
encap dot1q 10
bridge-domain 10
ethernet loopback permit internal
!
end
!
ethernet loopback start local int Gi2 ser inst 10 internal dot1q 10 timeout none
The traffic generator has an additional config for “measurement-type” which matches the received traffic that is looped back from the remote note. Below is the config:
ip sla 1
service-performance type ethernet dest-mac-addr <mac> bridge-domain 10
measurement-type direction internal
delay
jitter
loss
reecive
throughput
profile packet
outer-vlan 10
profile traffic direction internal
rate-step <rate>
Layer 3 Two-Way Mode
With a layer 3 test, the loopback on the remote node is configured under IP SLA, it is not a hard loopback on the interface like we use for a layer 2 test.
The ASR920 generating a layer 3 test looks like this:
ip sla 1
service-performance type ip dest-ip-addr 20.1.1.1 int Gi1 service instance 10
measurement-type direction internal
delay
jitter
loss
reecive
throughput
profile packet
source-ip-addr 30.1.1.1
outer-vlan 10
profile traffic direction internal
rate-step <rate>
!
int BDI10
ip add 30.1.1.1 255.255.255.0
The remote ASR920 in “loopback” mode looks like this:
ip sla 1
service-performance type ip dest-ip-addr 20.1.1.1 int Gi1 service instance 10
loopback direction internal
profile packet
source-ip-addr 30.1.1.1
outer-vlan 10
!
int BDI10
ip add 20.1.1.1 255.255.255.0
Further Reading
https://www.youtube.com/watch?v=j4C7SjyuQds&ab_channel=VanTekConsulting%2CLLC
Last updated