# 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 int Gi2 service instance 1 frequency ... profile packet outer-vlan 10 profile traffic direction external rate-step duration 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 bridge-domain 10 profile packet outer-vlan 10 profile traffic direction internal rate-step ``` 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 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 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 bridge-domain 10 measurement-type direction internal delay jitter loss reecive throughput profile packet outer-vlan 10 profile traffic direction internal rate-step ``` ### 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 ! 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/ethernet-oam/notes-y1564.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.