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.cisco.com/c/dam/en/us/products/collateral/routers/asr-920-series-aggregation-services-router/y1564-capabilities-asr920.pdf

https://www.youtube.com/watch?v=j4C7SjyuQds&ab_channel=VanTekConsulting%2CLLC

https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/ipsla/17-1-1/b-ipsla-xe-17-1-asr920/b-ipsla-xe-17-1-asr920_chapter_01000.html

https://xrdocs.io/ncs5500/tutorials/y-1564-sadt-nc5x-part1/

https://xrdocs.io/ncs5500/tutorials/y-1564-sadt-nc5x-part2/

Last updated