It is expected that the user will configure the appropriate ACL and QoS policies to ensure that the testhead traffic is processed as desired by the local and remote node/SAP. In particular, QoS policies in use must ensure that the rate in use for the SAP ingress meters exceed or are equal to the user configured rate for testhead tests and the classification policies map the testhead packets to the appropriate FCs/queues (the FC classification must match the FC specified in the CLI command testhead-test) using the packet header fields configured in the frame-payload. Similarly, ACL policies must ensure that testhead traffic is not blocked.
The testhead OAM tool does not check the state of the service or the SAPs on the local endpoint before initiating the tests. The operator must ensure that the service and SAPs used for the test are UP before the tests are started. If they are not, the testhead tool will report a failure.
The port configuration of the ports used for validation (For example: access port on which the test SAP is configured and access-uplink/network port) must not be modified after the testhead tool is invoked. Any modifications can be made only when the testhead tool is not running.
Testhead tool can be used to test only unicast traffic flows. It must not be used to test BUM traffic flows.
Only out-of-service performance metrics can be measured using testhead OAM tool. For in-service performance metrics, user has the option to use SAA-based Y.1731/CFM tools or OAM-PM-based tools.
The following list describes some prerequisites for using the testhead tool on the 7210 SAS-D and 7210 SAS-Dxp:
The configuration guidelines and prerequisites that are to be followed when the port loopback with MAC swap feature is used standalone, applies to its use along with testhead tool. For more information, see the description in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide.
User must configure resources for ACL MAC criteria in ingress-internal-tcam using the config>system>resource-profile>ingress-internal-tcam>acl-sap-ingress>mac-match-enable command. Additionally they must allocate resources to egress ACL MAC or IPv4 or IPv6 64-bit criteria (using the config>system>resource-profile>egress-internal-tcam>acl-sap-egress>mac-ipv4-match-enable or mac-ipv6-64bit-enable or mac-ipv4-match-enable commands). Testhead tool uses resources from these resource pools. If no resources are allocated to these pools or no resources are available for use in these pools, then testhead fails to function. Testhead needs a minimum of about 6 entries from the ingress-internal-tcam pool and 2 entries from the egress-internal-tcam pool. If user allocates resources to egress ACLs IPv6 128-bit match criteria (using the config>system>resource-profile>egress-internal-tcam>acl-sap-egress>ipv6-128bit-match-enable command), then testhead fails to function.
For both Epipe and VPLS service, the test can be used to perform only a point-to-point test between the specific source and destination MAC address. Port loopback MAC swap functionality must be used for both Epipe and VPLS services. The configured source and destination MAC address is associated with the two SAPs configured in the service and used as the two endpoints. In other words, the user configured source MAC and destination MAC addresses are used by the testhead tool on the local node to identify the packets as belonging to testhead application and are processed appropriately at the local end and at the remote end these packets are processed by the port loopback with MAC swap application.
Configure the MACs (source and destination) statically for VPLS service.
Port loopback must be in use on both the endpoints (that is, the local node, the port on which the test SAP is configured and the remote node, the port on which the remote SAP is configured for both Epipe and VPLS services. Port loopback with MAC swap must be set up by the user on both the local end and the remote end before invoking the testhead tool. These must match appropriately for traffic to flow, else there will be no traffic flow and the testhead tool reports a failure at the end of the completion of the test run.
Additionally, port loopback with MAC swap must be used at both the ends and if any services/SAPs are configured on the test port, they need to be shutdown to avoid packets being dropped on the non-test SAP. The frames generated by the testhead tool will egress the access SAP and ingress back on the same port, using the resources of the loopback ports configured for use with this tool (one for testhead and another for MAC swap functionality), before being sent out to the network side (typically an access-uplink SAP) to the remote end”. At the remote end, it is expected that the frames will egress the SAP under test and ingress back in again through the same port, going through another loopback (with MAC swap) before being sent back to the local node where the testhead application is running.
The FC specified is used to determine the queue to enqueue the marker packets generated by testhead application on the egress of the test SAP on the local node.
The use of port loopback is service affecting. It affects all the services configured on the port. It is not recommended to use a SAP, if the port on which they are configured, is used to transport the service packets toward the core. As, a port loopback is required for the testhead to function correctly, doing so might result in loss of connectivity to the node when in-band management is in use. Additionally, all services being transported to the core will be affected.
It also affects service being delivered on that SAP. Only out-of-service performance metrics can be measured using testhead OAM tool. For in-service performance metrics, user has the option to use SAA based Y.1731/CFM tools.
The testhead tool uses marker packets with special header values. The QoS policies and ACL policies need to ensure that same treatment as accorded to testhead traffic is given to marker packets. Marker packets are IPv4 packet with IP option set and IP protocol set to 252. It uses the src and dst MAC addresses, Dot1p, IP ToS, IP DSCP, IP TTL, IP source address and destination address as configured in the frame-payload. It does not use the IP protocol and TCP/UDP port numbers from the frame-payload configured. If the payload-type is ‟l2”, IP addresses are set to 0.0.0.0, IP TTL is set to 0, IP TOS is set to 0 and DSCP is set to be, if these values are not explicitly configured in the frame-payload. Ethertype configured in the frame-payload is not used for marker packets, it is always set to Ethertype = 0x0800 (Ethertype for IPv4) as marker packets are IPv4 packets. QoS policies applied in the network needs to configured such that the classification for marker packets is similar to service packets. An easy way to do this is by using the header fields that are common across marker packets and service packets, such as MAC (src and dst) addresses, VLAN ID, Dot1p, IPv4 (src and dst) addresses, IP DSCP, and IP ToS. Use of other fields which are different for marker packets and service packets is not recommended. ACL policies in the network must ensure that marker packets are not dropped.
The MAC swap loopback port, the testhead loopback port and the uplink port must not be modified after the testhead tool is invoked. Any modifications can be made only when the testhead tool is not running.
Link-level protocols (For example: LLDP, EFM, and other protocols) must not be enabled on the port on which the test SAP is configured. In general, no other traffic must be sent out of the test SAP when the testhead tool is running.
The frame payload must be configured such that number of tags match the number of SAP tags. For example: For 0.* SAP, the frame payload must be untagged or priority tagged and it cannot contain another tag following the priority tag.
The following list describes the prerequisites for using Y,1564 testhead OAM functionality on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.
For both Epipe and VPLS service, the test can be used to perform only a point-to-point test between the specific source and destination MAC address. SAP loopback MAC swap functionality must be used for both Epipe and VPLS services. The configured source and destination MAC address is associated with the two SAPs configured in the service and used as the two endpoints.
It is recommended to configure the MACs (source and destination) statically for VPLS service.
Software validates the frame payload to ensure the VLAN tag matches the SAP configuration used for the test. The VLAN tag (or untagged) is the only field validated by the software. No other fields are validated by software.
SAP loopback needs to be configured only on the remote endpoint, that is, on the remote node on which the remote SAP is configured in both Epipe and VPLS services. SAP loopback with MAC swap must be set up by the user on the remote end before invoking the testhead tool. The testhead tool injects packets on SAP ingress; therefore, a SAP loopback on the local endpoint (where the test SAP is located) is not required.
Use of per-SAP loopback does not affect other services configured on the same port. It does affect service being delivered on that SAP.
A cookie used to identify testhead packets is added after the protocol headers for every frame generated by the testhead tool. This cookie is used to identify testhead generated frames. The cookie follows immediately after the protocol header configured by the user (for example, in a TCP/IP packet configured by the user, the cookie is added immediately after the TCP/IP header, and forms the first 8 bytes of the payload, after which the data pattern specified by the user is added to the packet).
The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C do not require any loopback ports to be assigned for the testhead OAM tool.