This section provides the configuration guidelines for the testhead OAM tool. It is applicable to all the platforms described in this guide unless a specific platform is called out explicitly:
On the 7210 SAS-Sx 10/100GE platform, the following limitation must be addressed in the testhead configuration: the testhead loopback port and MAC swap loopback port must be configured with the same Ethernet speeds and have the same operational speeds. Failure to do so will cause the testhead session start to fail.
SAPs configured on LAG cannot be configured for testing with testhead tool. Other than the test SAP, other service endpoints (For example: SAPs/SDP-Bindings) configured in the service can be over a LAG.
The user needs to configure the resources of another port for use with the testhead OAM tool. The user can configure the resources of the internal virtual ports (if available) or configure the resources of a front-panel port for use with testhead OAM tool. Please see the CLI command config>system>loopback-no-svc-port in the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guidefor more details. Interfaces to know if front-panel port resources are needed and use the command show>system>internal-loopback-ports [detail] to know if internal port resources are available in use by other applications. The port configured for testhead tool use cannot be shared with other applications that need the loopback port. The resources of the loopback port are used by the testhead tool for traffic generation.
On 7210 SAS-R6 and 7210 SAS-R12, the ports allocated for testhead OAM tool, the MAC swap OAM tool and the test SAP must be on the same line card and cannot be on different line cards.
Port loopback with mac-swap is used at both ends and all services on the port on which the test SAP is configured and SAPs in the VPLS service, other than the test SAP should be shutdown or should not receive any traffic.
The configured CIR/PIR rate is rounded off to the nearest available hardware rates. User is provided with an option to select the adaptation rule to use (similar to support available for QoS policies).
The 7210 SAS supports all port speeds (that is, up to 1G rate). Users need to configure the appropriate loopback port to achieve a desired rate. For example, user must dedicate the resources of a 1G port, if intended to test rates to go up to 1G.
ITU-T Y.1564 recommends to provide an option to configure the CIR step-size and the step-duration for the service configuration tests. This is not supported directly in 7210 SAS. It can be achieved by SAM or a third-party NMS system or an application with configuration of the desired rate and duration to correspond to the CIR step-size and step duration and repeating the test a second time, with a different value of the rate (that is, CIR step size) and duration (that is, step duration) and so on.
Testhead waits for about 5 seconds at the end of the configured test duration before collecting statistics. This allows for all in-flight packets to be received by the node and accounted for in the test measurements. User cannot start another test during this period.
When using testhead to test bandwidth available between SAPs configured in a VPLS service, operators must ensure that no other SAPs in the VPLS service are exchanging any traffic, particularly BUM traffic and unicast traffic destined for either the local test SAP or the remote SAP. BUM traffic eats into the network resources which is also used by testhead traffic.
It is possible that test packets (both data and marker packets) remain in the loop created for testing when the tests are killed. This is highly probable when using QoS policies with very less shaper rates resulting in high latency for packets flowing through the network loop. User must remove the loop at both ends when the test is complete or when the test is stopped and wait for a suitable time before starting the next test for the same service, to ensure that packets drain out of the network for that service. If this is not done, then the subsequent tests may process and account these stale packets, resulting in incorrect results. Software cannot detect stale packets in the loop as it does not associate or check each and every packet with a test session
Traffic received from the remote node and looped back into the test port (where the test SAP is configured) on the local end (that is, the end where the testhead tool is invoked) is dropped by hardware after processing (and is not sent back to the remote end). The SAP ingress QoS policies and SAP ingress filter policies must match the packet header fields specified by the user in the testhead profile, except that the source/destination MAC addresses are swapped.
Latency is not be computed if marker packets are not received by the local node where the test is generated and printed as 0 (zero), in such cases. If jitter = 0 and latency > 0, it means that jitter calculated is less than the precision used for measurement. There is also a small chance that jitter was not actually calculated, that is, only one value of latency has been computed. This typically indicates a network issue, instead of a testhead issue.
When the throughput is not met, FLR cannot be calculated. If the measured throughput is approximately +/-10% of the user configured rate, FLR value is displayed; else software prints ‟Not Applicable”. The percentage of variance of measured bandwidth depends on the packet size in use and the configured rate.
Users must not use the CLI command to clear statistics of the test SAP port, testhead loopback port, or MAC swap loopback port when the testhead tool is running. The port statistics are used by the tool to determine the Tx/Rx frame count.
Testhead tool generates traffic at a rate slightly above the CIR. The additional bandwidth is attributable to the marker packets used for latency measurements. This is not expected to affect the latency measurement or the test results in a significant way.
If the operational throughput is 1kbps and it is achieved in the test loop, the throughput computed could still be printed as 0 if it is less than 1Kb/s (0.99 kb/s, for example). Under such cases, if FLR is PASS, the tool indicates that the throughput has been achieved.
The testhead tool displays a failure result if the received count of frames is less than the injected count of frames, even though the FLR may be displayed as 0. This happens because of truncation of FLR results to 6 decimal places and can happen when the loss is very less.
As the rate approaches 1Gbps or the maximum bandwidth achievable in the loop, user needs to account for the marker packet rate and the meter behavior while configuring the CIR rate. That is, if the user needs to test 1Gbps for 512 bytes frame size, then they will need to configure about 962396Kbps, instead of 962406Kbps, the maximum rate that can be achieved for this frame-size. In general, they would need to configure about 98%-99% (based on packet size) of the maximum possible rate to account for marker packets when they need to test at rates which are closer to bandwidth available in the network. The reason for this is that at the maximum rate, injection of marker packets by CPU will result in drops of either the injected data traffic or the marker packets themselves, as the net rate exceeds the capacity. These drops cause the testhead to always report a failure, unless the rate is marginally reduced.
The testhead uses the Layer 2 rate, which is calculated by subtracting the Layer 1 overhead that is caused when the IFG and Preamble are added to every Ethernet frame (typically about 20 bytes (IFG = 12 bytes and Preamble = 8 bytes)). The testhead tool uses the user-configured frame size to compute the Layer 2 rate and does not allow the user to configure a value greater than that rate. For 512-byte Ethernet frames, the L2 rate is 962406 Kb/s and the Layer 1 rate is 1 Gb/s.
It is not expected that the operator will use the testhead tool to measure the throughput or other performance parameters of the network during the course of network event. The network events could be affecting the other SAP/SDP-Binding/PW configured in the service. Examples are transition of a SAP because of G8032 ring failure, transition of active/ standby SDP-Binding/PW because of link or node failures.
The 2-way delay (also known as ‟latency”) values measured by the testhead tool is more accurate than obtained using OAM tools, as the timestamps are generated in hardware.
The 7210 SAS does not support color-aware metering on access SAP ingress, therefore, any color-aware packets generated by the testhead is ignored on access SAP ingress. 7210 SAS service access port, access-uplink port, or network port can mark the packets appropriately on egress to allow the subsequent nodes in the network to differentiate the in-profile and out-of-profile packets and provide them with appropriate QoS treatment. The 7210 SAS access-uplink ingress and network port ingress is capable of providing appropriate QoS treatment to in-profile and out-of-profile packets.
The marker packets are sent over and above the configured CIR or PIR rate, the tool cannot determine the number of green packets injected and the number of yellow packets injected individually. Therefore, marker packets are not accounted in the injected or received green or in-profile and yellow or out-of-profile packet counts. They are only accounted for the Total Injected and the Total Received counts. So, the FLR metric accounts for marker packet loss (if any), while green or yellow FLR metric does not account for any marker packet loss.
Marker packets are used to measure green or in-profile packets latency and jitter and the yellow or out-of-profile packets latency and jitter. These marker packets are identified as green or yellow based on the packet marking (Example: dot1p). The latency values can be different for green and yellow packets based on the treatment provided to the packets by the network QoS configuration.
The following table describes SAP encapsulation supported by the testhead tool.
| Epipe service configured with svc-sap-type | Test SAP encapsulations |
|---|---|
null-star |
Null, :* , 0.* , Q.* |
Any |
Null , :0 , :Q , :Q1.Q2 |
dot1q-preserve |
:Q |
The following combination of 1G and 10G port can be used, as long as the rate validated is less than or equal to 1Gb/s:
The test SAP is a 10G port, the uplink is 1G port and other ports (that is, uplink, MAC swap, and testhead) are 1G port.
The test SAP is a 10G port, the uplink is a 10G port and other ports (that is, MAC swap and testhead) are 1G port.
The test SAP is a 1G port, the uplink is a 10G port and other ports (that is, MAC swap and testhead) are 1G port.