The following describes the generic prerequisites for the use of the Testhead tool:
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 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 the testhead OAM tool. For in-service performance metrics, user has the option to use SAA based Y.1731/CFM tools.
The following describes some prerequisites to use the testhead tool:
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 the testhead tool. For more information, see the description in the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide.
Users must configure resources for ACL MAC criteria in ingress-internal-tcam using the command config>system>resource-profile>ingress-internal-tcam>cl-sap-ingress>mac-match-enable. Additionally users must allocate resources to egress ACL MAC or IPv4 or IPv6 64-bit criteria using the command config>system>resource-profile>egress-internal-tcam>acl-sap-egress>mac-ipv4-match-enable or mac-ipv6-64bit-enable or mac-ipv4-match-enable). The 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 the 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 users allocate resources to egress ACLs IPv6 128-bit match criteria (using the command config> system> resource-profile> egress-internal-tcam>acl-sap-egress> ipv6-128bit-match-enable), then the testhead tool 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. That is, 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 setup 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 2 internal loopback ports (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.
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 source and destination 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 (source and destination) 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.