C RFC2544 User Guide
C RFC2544 User Guide
(EtherSAT)
User Guide
33540 Rev. C
Transition Networks EtherSAT User Guide
Trademarks
All trademarks and registered trademarks are the property of their respective owners.
Copyright Notice/Restrictions
Copyright © 2012, 2013 Transition Networks
All rights reserved.
No part of this work may be reproduced or used in any form or by any means (graphic, electronic or
mechanical) without written permission from Transition Networks.
The information contained herein is confidential property of Transition Networks, Inc. The use, copying,
transfer or disclosure of such information is prohibited except by express written agreement with Transition
Networks, Inc.
Printed in the U.S.A.
Contact Information
Transition Networks
10900 Red Circle Drive
Minnetonka, MN 55343 USA
Tel: 952- 941-7600 or 1-800-526-9267
Fax: 952-941-2322
Revision History
Rev Date Description
Revised for S3280-v1.4.3-rfc2544test.dat. Adds S4140 RFC2544 support and Test Report
B 06/12/13
Generation enhancements.
Contents
1. Introduction ............................................................................................................................................ 5
Supported Models ................................................................................................................................... 5
Dependencies and Prerequisites ............................................................................................................ 6
Configuration Model ................................................................................................................................ 6
RFC2544 Test Profile.......................................................................................................................... 7
RFC2544 Test Record ...................................................................................................................... 10
RFC2455 Test System-Level Configuration ..................................................................................... 11
RFC2544 Test Report ....................................................................................................................... 11
Test Execution ....................................................................................................................................... 13
Throughput Test ................................................................................................................................ 13
Latency Test...................................................................................................................................... 14
Frame Loss Test ............................................................................................................................... 14
Back-to-back Frames Test ................................................................................................................ 15
Relationship to the Y.1564 SAM Tests ............................................................................................. 17
RFC 2544 Test Mechanisms ................................................................................................................. 18
Deployment Scenarios ...................................................................................................................... 18
NID Roles: Initiator, Collector, and Reflector .................................................................................... 19
Delay Measurement Procedures ...................................................................................................... 20
Peer Protocol .................................................................................................................................... 20
Test MAC Address ............................................................................................................................ 20
Peer Protocol Encapsulation ............................................................................................................. 20
Related Manuals and Online Help......................................................................................................... 21
RFC2544 Configuration Process........................................................................................................... 21
2. CLI Commands .................................................................................................................................... 22
Introduction ............................................................................................................................................ 22
RFC2544 (EtherSAT) Commands (S3280) ........................................................................................... 23
RFC2544 (EtherSAT) Commands (S4140) ........................................................................................... 24
EtherSAT Loopback Configuration Commands ................................................................................ 25
EtherSAT Engine Commands ........................................................................................................... 29
EtherSAT Profile Commands ............................................................................................................ 31
EtherSAT Test Commands ............................................................................................................... 45
EtherSAT Test Result Commands .................................................................................................... 52
CLI Command Privilege Levels ............................................................................................................. 61
RFC 2544 Example (CLI) ...................................................................................................................... 63
1. Unit L (SAT Test Initiator) Configuration Commands ................................................................... 63
2. Unit R (SAT Collector) Configuration Commands ........................................................................ 66
3. Sample Procedure ........................................................................................................................ 67
3. Web Interface ....................................................................................................................................... 76
Configuration > Service Activation > System ........................................................................................ 76
Configuration > Service Activation > Profiles ........................................................................................ 78
Add a New Service Activation Profile ................................................................................................ 78
Edit an Existing Service Activation Profile ........................................................................................ 82
Delete an Existing Service Activation Profile .................................................................................... 82
Configuration > Service Activation > Tests ........................................................................................... 83
Diagnostics > Service Activation > Loopback ....................................................................................... 87
Loopback Test Parameter Descriptions ............................................................................................ 88
Diagnostics > Service Activation > Test ................................................................................................ 90
Run Test ............................................................................................................................................ 90
Saved Test Report Format ................................................................................................................ 91
Common Test Results....................................................................................................................... 92
Throughput Test Results ................................................................................................................... 93
Latency Test Results......................................................................................................................... 94
FLR Test Results .............................................................................................................................. 95
Back-to-Back Test Results ................................................................................................................ 96
Figures
Figure 1. RFC 2544 Test between Two S3280-TST NIDs ........................................................................ 18
Figure 2: RFC 2544 Test between an S3280-TST NID and a Third-party Device .................................... 18
Figure 3. RFC 2544 Example (CLI) ........................................................................................................... 63
Figure 4. RFC 2544 Example (Web GUI) .................................................................................................. 98
Figure 5. RFC 2544 between Customer Handoff Points ......................................................................... 101
Figure 6. RFC 2544 in an Ethernet Loopback Configuration .................................................................. 112
Tables
Table 1. Relationship between RFC 2544 Tests and Y.1564 SAM Tests ................................................. 17
Table 2. CLI Command Privilege Levels ................................................................................................... 61
Table 3. Public MIBs ................................................................................................................................ 136
1. Introduction
This manual documents the TN Service Activation Test (EtherSAT) which can be used for RFC2544
testing. IETF RFC 2544 defines a specific set of tests that can be used to measure and report the
performance characteristics of network devices. The results of these tests will provide comparable data
from different vendors with which to evaluate these devices. References to RFC 2544 in this manual imply
the TN Service Activation Test (EtherSAT) function.
RFC 2544 is the de facto methodology that outlines the tests required to measure and to prove
performance criteria for carrier Ethernet networks. It provides an out-of-service benchmarking methodology
to evaluate the performance of network devices using throughput, back-to-back, frame loss and latency
tests. Each standard test validates a specific part of a SLA. See the IETF website at
http://www.ietf.org/rfc/rfc2544 for specifics.
In terms of traffic flows, the S3280 can perform the following roles:
The Initiator (Generator) if it is the source of a traffic flow.
The Collector if it counts and terminates a traffic flow.
The Reflector if it loops back a received traffic flow.
Note: Depending on a given test step, the near-end device may be either the Initiator and/or Collector of
the traffic flow.
A “near-end device” refers to the NID on which a test operation is initiated by the user.
A “far-end device” is the peer NID device where traffic is counted and/or optionally looped back.
Supported Models
RFC 2544 tests are supported on Transition Networks model S3280-TST, S4212, S4224, and S4140
products. RFC 2544 operation is essentially identical between models, with minor differences (e.g., Service
Activation, EVC, PTP, wire speed, and frame sizes) noted where they exist.
ECE and EVC: RFC2544 Test Record must have a reference to an existing ECE and EVC record in the UI
that has the same User Port and VLAN tag value as specified for the RFC2544 Test and direction type
“UNI-to-NNI” or “Both”. During the test, the ECE’s ingress user port should block traffic for a given C-VLAN.
The S3280 allows selection of the RFC2544 Test’s bandwidth parameters as a reference to an existing
Policer record to use its bandwidth profile configuration (CIR, EIR, CBS, and EBS). By default, the Policer
that was assigned for a given ECE is used. The S3280 shows the CIR, EIR, CBS, and EBS values in the
list as well as the Policer IDs.
PTP Clock Configuration / Clock synchronization: IEEE 1588-based clock synchronization must be
running on the S3280. The 1588 packets are sent periodically (from once every few seconds to every 5
minutes) from an internal source when the tests are not running. Frame encapsulation is L2 with EthType
0x88F7 and Broadcast Destination MAC. The PTP message type is “SYNC”. Only the originTimestamp
field is actual.
STP (Spanning Tree Protocols) is enabled by default on the S3280-TST. When enabled, the S3280-TST
periodically sends Spanning Tree packets on all ports. The spanning tree packets take from the available
bandwidth that is needed to pass the test. It is recommended to disable STP in these instances:
1. Disable STP if running “collector” or “initiator” mode on the S3280-TST.
2. Disable STP on the S3280 for any RFC2544 tests that is running 100% port utilization.
Configuration Model
The RFC2544 tests provided by the S3280 (or S4140) are used to validate that a newly established end-to-
end service has been properly configured and that it meets the required SLA. The tests typically run before
the service is delivered to the customer.
From a configuration model perspective, the RFC2544 tests are modeled by two entities:
a) The RFC2544 test profile, and
b) The RFC2544 test record.
l) Test steps (the Throughput test, Latency test, Back-to-Back test, or Frame Loss test) to be
executed as part of the RFC2544 testing. This attribute indicates, for each of the test steps, whether
they are included in the testing. By default, all the test steps are included. Since the Latency test is not
a separate test, it is always assumed that the Throughput test will be executed instead with a DM/DMV
results calculation. For more details about each step, see “Test ” on page 13.
For a particular test, you may choose any combination of up to 10 sizes in the sequence.
L2 Frames
The RFC2544 module is configured with a Test MAC address, unique per NID. The Test MAC address is
different from the MAC addresses that are used by the physical ports or from the Management MAC
address.
L2 frames use this Test MAC address as the source address, and use the Test MAC address of the
destination NID as the destination MAC.
The L2 frames have a VLAN encapsulation specific to the service under test. Untagged, single-tagged, and
double-tagged frames are supported.
The remainder of the frame (after the inner C-VLAN tag) can support the following formats:
a) An ETH-TST frame.
b) An ETH-TST frame with a customized EthType. This option lets you specify a different EthType
(other than 0x8902) for the frame, but the remaining frame format is the same as for the ETH-
TST frame. This option should be used when intermediate devices on the network may capture
SOAM frames based on the EthType and do further determination only in the slow path. Such
devices will undermine the results of high-capacity tests.
c) An LLC/SNAP-based encapsulation, using user-provided OUIs and a protocol identifier.
Note that internally the frames have a sequence number field used for the out-of-order counters. However,
the location and identification of this field is not reported.
L3 Frames
The test frames may use L3/L4 (UDP/IP or TCP/IP) encapsulation. The frames use the Test MAC address
of the originating NID as the source address and the Test MAC address of the destination NID as the
destination MAC, and have a VLAN encapsulation specific to the service under test.
IP headers:
Destination IP address
Source IP address
DSCP (default 0)
ECN (default 0)
Flags (default 0)
TTL (default 64)
Next protocol – UDP or TCP (default UDP)
UDP headers:
Source port (default 0)
Destination port (default 0)
TCP headers:
Source port (default 0)
Destination port (default 0)
Sequence number (note that the sequence number is NOT incremented in transmission) (default
16)
ACK number (default 16)
Flags (default SYN/ACK)
Window size (default 16)
Urgent Pointer (default 0)
All the other fields, such as the header checksums, are filled in by the software.
Payload Filler
You can specify how the remainder of the packet (after the configured headers) will be filled, up to the
maximum frame size for the test.
Test Attributes
An RFC2544 test record contains the following attributes (only one test record can be in the system):
a) Test name of up to 32 characters.
b) An RFC2544 profile reference.
c) Ingress port. The test frames are generated by the FPGA and processed by the S3280 “as if”
real frames are received on a specified ingress port. The frames received on the actual ingress
port for the CVID under test will be dropped while the test is running.
d) Egress port. This parameter indicates the network port from which the test frames will be sent.
This value is ‘read-only’ and is taken as an NNI port from the corresponding EVC record. The
EVC record is taken from the ECE record for which the UNI port is the same as the Test
Ingress port and VLAN-ID value is the same as the Ingress C-VID.
e) Ingress encapsulation: Untagged/C-Tagged/CS-Tagged/CC-Tagged.
f) Egress encapsulation: Untagged/C-Tagged/CS-Tagged/CC-Tagged.
g) If frames are tagged, the Ingress CVID/PCP on which the test will be executed. The default
PCP value is 3.
h) If frames are double-tagged, the Ingress outer tag VID/PCP.
i) If frames are tagged, the Egress CVID/PCP on which the test frames will be sent from the peer
NID to the user. By default, these values are the same as ingress values.
j) If frames are double-tagged, the Egress outer VID/PCP.
k) Management IP of the peer NID.
l) Bandwidth profile parameters: CIR, EIR, CBS, and EBS.
m) Target Test MAC address for the Loopback test.
Test Status
The status of an RFC2544 test is a run-time attribute that can be:
(a) None (the test has never been run since the device or service was brought online).
(b) In progress.
(c) Failed.
(d) Unable To Run (the requested test cannot be executed, for example, a problem with the
connection to the peer NID).
(e) Aborted (due to a manual stop request).
(f) Completed (all the test steps in the RFC2544 test have passed).
(g) Unknown (This state indicates the test result state is currently unknown).
Individual tests display specific results (e.g., the Latency test can display Traffic Loss, No Traffic Loss,
Not tested, or Fail to execute).
The following status and read-only attributes are exposed to the user:
a) The list of remotely initiated tests. Each entry in the list includes:
The IP address of the originating NID.
The local VLANs ID of the service under test.
The local PCPs of the service under test.
An indication of whether the test is unidirectional or bi-directional.
The test report contains full details of the RFC2544 profile used at the time of the test, including:
a) An overall test result (completed, failed, aborted, or none).
b) For each individual test step, the test report includes a qualitative (and sometimes
quantitative) test result. (See section “3. Web Interface” on page 76 for a full description of
the test steps.)
c) Details about the ingress CE-VLAN, ingress PCP, egress CE-VLAN, and egress PCP.
Test Execution
This section describes the individual functional test steps that are included in an RFC2544 test. The focus
of this section is on what is tested, rather than on how it is tested. The actual test mechanisms, including
the interaction with the FPGA, are described in the following sections.
Throughput Test
The test is executed in the following sequence:
As the first step, the near end requests the far-end unit to send MAC learning frames. The MAC learning
frames are sent by the RFC2544 module on the S3280 as the IP frames, 64 bytes long with Test MAC
addresses and VLAN encapsulations specific to the test in their Ethernet header. The counters related to
those frames are ignored at both the near end and the far end.
The near end indicates to the far end that a test is ready to start and waits for an acknowledgement from
the far end.
Furthermore, the near end sends to the far end throughput test traffic with the specified frame size, for the
specified test step duration (according to the configuration in the RFC2544 profile). After the completion of
the test step, the far end reports:
a) The number of green frames received and the number of yellow frames received (based on
PCP statistics).
b) Any error that may occur during the test (for example, “can’t read statistics”).
The test “passes” if the total number of received frames (green+yellow, or the total receive counter) is the
same as the number of generated frames.
If a test step fails, it is repeated with a new rate, reduced by the specified RFC2544 rate step decrease
value:
The process continues until the step rate is larger than 10% of the R0, or until two consecutive test steps
pass.
The results of the Throughput test are recorded as PASS if the first two steps of the test are passed, and
FAILED otherwise (that is, the overall test fails even if a lower-rate step passes). The same PASS criteria
are used for the bidirectional test. The fail result for the test can be as following:
fail NE – if near end to far end direction has failed.
fail FE – if far end to near end direction has failed (for bidirectional mode only).
fail NE & FE – if both directions have failed (for bidirectional mode only).
If individual test steps are marked as failed, this is interpreted as the inability of the network to sustain the
requested CIR+EIR; the network can sustain up to the rate used for the test step marked as passed. This
result indicates a problem within the network, not in the ingress traffic.
Latency Test
As per the RFC2544 requirements, the Latency test is executed logically “after” the determination of the
throughput at each of the specified frame sizes. Since the latency can be calculated during each traffic
generation cycle, the Latency test is actually executed in parallel with the Throughput test, not as a
separate step. During the Throughput test, the 10 DM and 10 DVM bins are filled in by the FPGA for each
rate step. Thus, the number of steps (and Latency results) is the same as for the Throughput test.
First, the near end requests the far end to send MAC learning frames. The MAC learning frames are sent
by the RFC2544 module on the S3280 CPU as the IP frames (with the Management source/destination IP
of the NIDs) 64 bytes long with Test MAC addresses in its Ethernet header. The counters related to those
frames are ignored at both the near end and the far end.
The near end indicates to the far end that a test is ready to start and waits for an acknowledgement from
the far end.
In the first step, the near end sends to the far end throughput test traffic with the specified frame size, for
the specified test step duration (according to the configuration in the RFC2544 profile). After the completion
of the test step, the far end reports via peer communication channel:
a) The number of green frames received and the number of yellow frames received.
b) An error that can occur during the test (e.g., “can’t read statistics counter”).
c) Out-of-sequence counters.
The test “passes” if the calculate frame loss rate (FLR) is less than the acceptable frame loss ratio from the
RFC2544 Profile during the first two consecutive test steps, and the out-of-sequence events counter is 0.
The Frame Loss Rate is calculated as follows:
If a test step fails (the FLR is higher than the acceptable loss rate), it is repeated with a new rate, reduced
by the specified RFC2544 rate step decrease value in percentages:
The process continues until the step rate is larger than 10% of the R0, or until two consecutive test steps
pass.
The results of the Frame Loss Rate test are recorded as PASS if the first two steps of the test are passed,
and FAILED otherwise (i.e., the overall test fails even if a lower-rate step passes). The same PASS criteria
are used for the bidirectional test. The fail result for the test can be:
fail NE – if near end to far end direction has failed
fail FE – if far end to near end direction has failed (For bidirectional mode only).
fail NE & FE – if both directions have failed (For bidirectional mode only).
If both the Throughput and the Frame Loss tests are enabled, then both tests run in a single pass.
If individual test steps are marked as failed, this is interpreted as the inability of the network to sustain the
requested CIR+EIR with acceptable Green frame losses and no out-of-sequence frames; that is, the
network can sustain up to the rate used for the test step marked as passed. Such result indicates a
problem inside the network, not in the ingress traffic.
The near end requests a Partner to send MAC learning frames. The MAC learning frames are sent by the
RFC2544 module on the S3280 CPU as the IP frames 64 bytes along with Test MAC addresses and
proper VLAN encapsulations in their Ethernet header. The counters related to those frames are ignored at
both the near end and the far end.
The near end indicates to the far end that a test is ready to start and waits for an acknowledgement from
the far end.
The test is run for each frame size in the RFC2544 profile. The near end then sends, at a specified “CBS
line rate”, the largest number of frames of a given size, such that the leaky buckets become almost empty.
Note on CBS Line Rate: The field labeled “CBS Line Rate” is used to set the bit-rate (in Mbps) of traffic
generated during an RFC-2544 test. CBS stands for Committed Burst Size, which refers to an amount of
data, such as 100 KB (kilobytes). CBS does not refer to a data rate, such as Mbps (megabits-per-second).
CBS Line Rate displays at Configuration > Service Activation > Profiles > Edit and at Diagnostics >
Service Activation > Test > Show. The name “CBS Line Rate” can be confusing; it means the line rate to
fill in the CBS bucket. The Back-to-back test includes two steps: 1) Burst traffic at given CBS line rate (must
be much more CIR), and 2) usual traffic at a given CIR rate. The Back-to-back test is actually the CBS test
- it checks that network can carry service traffic at the desired CIR rate while a burst of CBS+EBS occurred,
with no Green frames lost.
And the number of frames required for this purpose is calculated as follows:
(That is, a burst large enough to “almost” empty the CBS+EBS leaky bucket, taking into account the
amount of data required to overcome the leak in the leaky bucket. While the bucket is emptied by frames
arriving at the line rate, the bucket is replenished at the CIR rate at the same time).
Immediately after the burst, the near end sends traffic frames at the CIR rate, for a period equal to the
length of a throughput test step, as specified in the RFC2544 profile.
The current cycle passes if the FLR is less than the acceptable frame loss ratio from the RFC2544 Profile.
The FLR is calculated as follows:
If the current cycle fails, the initial BurstSize (CBS+EBS) is decreased by the specified RFC2544 rate step
decrease value:
And the test cycle is repeated. These test cycles run until a cycle passes or the BurstSize decreases below
10% of (CBS+EBS).
The results of the Back-To-Back test is recorded as PASS if the first step passes and FAILED otherwise
(that is, the overall test fails even if a lower BurstSize step passes). The same PASS criteria are used for
the bidirectional test. The fail result for the test can be as following:
fail NE – if near end to far end direction has failed
fail FE – if far end to near end direction has failed (for bidirectional mode only).
fail NE & FE – if both directions have failed (for bidirectional mode only).
After the completion of the test cycle, the far end reports via peer communication channel:
a) The total number of green and yellow frames received.
b) An error that can occur during the test (e.g., “can’t read statistics counter”).
Table 1. Relationship between RFC 2544 Tests and Y.1564 SAM Tests
Deployment Scenarios
This section describes the implementation of the RFC2544 procedures discussed above.
Figure 2: RFC 2544 Test between an S3280-TST NID and a Third-party Device
A NID can be the Initiator and Collector for the same service at the same time during the Loopback test.
There is a system-level flag to enable or disable the Collector role for the NID. If the Collector role is
disabled, the NID will not accept RFC2544 test requests from a far-end NID. If the Collector role is enabled,
the NID displays the CE VLANs for which it acts as the Collector.
A Reflector NID that is in VLAN loopback mode cannot act as the Initiator, and the other way around.
Otherwise a one system-level flag to enable or disable a peer communication channel is implemented:
If enabled, the NID can support RFC2544 tests.
If disabled, the NID is unable to support an RFC2544 test either as the Generator or the Collector;
only Loopback mode is supported in this case since it does not use the communication channel.
Only one test can be executed on a NID, either as the Collector or Initiator.
Processing in loopback mode – no peer protocol: The loopback mode test requires that the far end be
in the MAC/VLAN loopback mode, so the far end device is provisioned in loopback mode out of band (i.e.,
manually by the operator). Since no communication messages are used in this mode, neither handshake
nor “Test Start” messages are sent to the far end. The destination Test MAC address must be specified in
the RFC2544 Test profile. Upon beginning of the test, all statistics counters to be used as a baseline will be
read for the service under test before traffic generation begins. The NID begins generating traffic and
collecting statistics in parallel; that is, it performs the Initiator and Collector roles at the same time. Upon
completion of the frame transmission, the near end compares the local statistics counters with the expected
results and declares the test step as pass or fail.
Bi-directional tests: The bi-directional tests require that the far end initiate the same procedure in the
reverse direction. In other words, test frames are sent from the far end towards the near end, and the
statistics collection is performed at the near end.
The tests are still “owned” by the near end; to avoid deadlocks, the far end simply executes the requests
initiated by the near end.
The near end sends a “Test start” message, upon receiving “Ack” from the far end the near end will read
the counters to be used as a baseline (since the counters are not clear on read [5]), and begin a statistics
collection cycle. The far end sends the requested traffic, using its own SAT engine in the FPGA. After the
traffic generation is completed, the far-end sends its results to the near end (transmitted frames counter, an
error indication if any). Upon receipt of the test results, the near end finishes statistics collection and
processes the test results. Based on those results, the near end declares the test passed or failed.
Clock synchronization: IEEE 1588-based clock synchronization must be running on the S3280. The 1588
packets are sent periodically (every 5 minutes) from the internally when the tests are not running. Frame
encapsulation is L2 with EthType 0x88F7 and Broadcast Destination MAC. The PTP message type is
“SYNC”. Only the originTimestamp field is actual.
Peer Protocol
The RFC2544 test record in the Initiator identifies the target S3280 for each test by using the target
S3280’s Management IP address. So in order to establish communication, both S3280s (the Initiator and
the Collector) must have the Management IP address enabled on the S3280 and similar VLAN tag
encapsulations for management traffic. Management traffic must have a VLAN-ID other than the VLAN-ID
under test.
Both devices must see each other by the Management IP; the Initiator must be able to ping its Collector by
the Management IP address (in-band or out-of-band). For each test, the peer S3280s exchange the
following information necessary to identify the service under test:
The Test MAC address of the unit (must NOT be used by the port), which will be used as the
Source and Destination MAC addresses for test frames.
The Ingress CE VLAN ID (at the Initiator) and Egress CE-VLAN ID (at the Collector), as well as the
ingress PCP and egress PCP.
Check the TN web site at http://www.transition.com/ for additional white papers, application notes, etc.
When the procedures in this manual are successfully completed, refer to the S3280 Web Interface User
Guide or the S3280 CLI Reference for configuration, monitoring, diagnostics, and maintenance information.
The process is similar for configuring RFC 2544 via the Web GUI and via CLI commands:
► See section “2. CLI Commands” on page 22 for CLI command details.
► See section “3. Web Interface” on page 76 for web GUI details.
2. CLI Commands
Introduction
The S3280 offers a rich set of commands through its CLI for performing configuration and status
monitoring. The CLI is accessible through the RS-232 serial console, telnet and SSH. The CLI incorporates
user authentication for security purposes.
The CLI interface can be accessed via Secure Shell (SSH) interface. This provides a more secure interface
as SSH uses public-key cryptography for authentication. When the SSH server is enabled, normal telnet
access can be enabled or disabled to avoid potential security holes.
This manual is for experienced network administrators who are responsible for configuring and maintaining
the S3280. The CLI offers a comprehensive set of management features for use during initial setup (set IPs
etc.) and troubleshooting, as well as for day-to-day management (device management, firmware upgrades,
managing security features, etc.).
Note: CLI commands are case sensitive. Enter the CLI commands in lower case unless otherwise
specified. In order to execute the commands described in this manual, you must press Enter after the
command has been entered.
The full set of available RFC2544 (EtherSAT) commands are categorized as:
>
Messages:
Error: FPGA link ANEG failed
failed to open system sharedport table
The port is used for the internal for FPGA.
The shared port mode must be internal!
The shared port must be internal mode!
The Ethernet Virtual Connection (EVC) Latching Loopbacks for Service Activation Testing (SAT)
commands are explained below.
State: Active
Active Time Remaining: 161
Frames: 0, Bytes: 0
>eth loop status
State: Inactive
Frames: 0, Bytes: 0
>
The EtherSAT Loopback parameters that can be reported are:
State: whether the EtherSAT loopback function is currently “Active” or “Inactive”.
Active Time Remaining: How much longer the test has to run (in seconds). When the “Active Time
Remaining” counts down to 0, the reported “State” changes from “Active” to “Inactive”.
Frames: the number of frames that were looped back.
Bytes: the number of bytes that were looped back.
Configuration Commands
These commands let you set the parameters configured for each profile. The configurable parameters
include Name, CBS Line rate, Frame Loss Ratio, Yellow Frames PCP Values, Frame Size Mix, Rate Decrease
Step, Step Length, Test Mode, Test Steps, and Thresholds for DM and DMV bins.
Each of these commands is described below.
Example 2:
>ethersat profile frameip set 1
Frame IP dest address: 10.10.152.12
Frame IP src address: 10.10.152.13
Frame IP DSCP : 0
Frame IP ECN : 3
Frame IP Flags : 5
Frame IP TTL : 100
>ethersat profile frameip set 1 10.10.152.12 10.10.152.13 0 3 5 100
>ethersat profile frameip set 1
Frame IP dest address: 10.10.152.12
Frame IP src address: 10.10.152.13
Frame IP DSCP : 0
Frame IP ECN : 3
Frame IP Flags : 5
Frame IP TTL : 100
>
Messages: Error: unable get profile with Id 11
S4212/S4224 Shared Port Note: The S4212 and S4224 switches have one port that is 'Shared'. On the
S4212, port 12 is ‘shared’ and on the S4224 port 24 is ‘shared’. The Shared Port can be toggled between
two modes of operation:
Internal: This mode disconnects the the Shared Port from the SFP interface and attaches it
internally to to an FPGA. No connectivity can be achieved through the Shared Port's SFP interface
while in this mode.
External: This is the default mode. In this mode, the Shared Port is attached to the SFP interface,
and works like the rest of the ports on this switch.
The Shared Port mode must be set to 'External' for normal port function and 'Internal' for the EtherSAT
Loopback to work.
>
Messages:
Error: FPGA link ANEG failed
failed to open system sharedport table
The port is used for the internal for FPGA.
The shared port mode must be internal!
The shared port must be internal mode!
Configuration Commands
This section contains all parameters configured for each test (Name; Profile; CIR; CBS; EIR; EBS; and
Target Test MAC address (to be used for Loopback test only).
Note: you must have a PTP clock instance configured for accurate RFC 2544 Latency test step timestamps.
PTP must be running on both devices to synchronize the Time of Day.
The commands below let you display the FLR test results of the specified test.
Throughput:
Latency:
Frame Loss Rate:
Back-To-Back Frames
>
Messages:
Can't allocate memory
Can't get test result for test id %d
Creating test report failed
create txt file failed\n
DM min/max/avg: %u/%u/%u us\n
No test ID specified
resolving hostname %s failed\n
tftp client put failed: n
E ether_sat 00:47:25 68/saPeerProtoFreeSession#401: Error: Can't find session with IP 0x0
E ether_sat 00:01:44 11/saDbGetTestReportTxt#2503: Error: Can't get test result for test id 1
create txt file failed
Status: None
System Contact :
System Name :
System Location :
Status: None
Status: Executed
System Contact :
System Name :
System Location :
--------------------------------------------------------------------------------
Throughput test results:
--------------------------------------------------------------------------------
Latency test results:
Elapsed Time: 0 ms
Step Dir Frame size (byte) Actual Tx Rate (bps)
------ ------ ------------------ --------------------
--------------------------------------------------------------------------------
Frame Loss Rate test results:
Step Dir Frame size (byte) Actual Tx Rate (bps) FLR (%%)
------ ------ ------------------ --------------------- --------
--------------------------------------------------------------------------------
Back-To-Back Frames test results:
--------------------------------------------------------------------------------
Frame format:
Level: L2
Encapsulation Type: Custom ETH-TST type
Filling Mode: PRBS
Frame Payload Pattern: 0x00000000
Custom EthType: 0x0000
LLC/SNAP OUI: 00-00-00
LLC/SNAP Protocol: 0x0000
SOAM MEG Level: 4
Example:
>Security Switch Privilege Level Config
Example:
>Security Switch Privilege Level Current
Privilege Current Level: 15
>
The setup consists of two TN 3280 NIDs (Unit L and Unit R), connected to traffic generators (SB1 and SB2)
as shown below. A third unit (or a third party device capable of performing VLAN level policing) is used as
en emulator for the network.
Initiator Collector
Unit L Unit R
ECE ECE
CVID 55 EVC 300 CVID 55
P4 EVC 200 P4
P5 P5 ECE
ECE
CVID 77 S3280 S3280 or 3rd party S3280 CVID 77
SB1 SB2
EVC 300 (blue) carrying CVID 77 is not subject to RFC 2544 tests. Traffic is sent continuously on that EVC,
and will not be affected by the RFC 2544 operations.
b) Set Port Type to C-Port (not unaware) and set Ingress filtering to enabled:
vlan porttype 5 c-port
vlan ingressfilter 5 enable
c) Setup PTP between the initiator and collector. For this test, the initiator is configured as master
while the collector is configured as slave. (PTP connection is on port 4.)
On the Initiator S3280 (Unit L):
PTP ClockCreate 0 mst
PTP PortState 0 4 enable
mac learn 4 disable
Three S3280 profiles that are created, one profile for tests with 3 frame sizes, one profile for tests
for Jumbo frames, and a third profile for yellow frames.
All tests use L2 frames, running all 4 tests (throughput, latency, flr, back-to-back). The test steps
are 15 second in length and the rate decrease step is 10%.
The DM buckets are configured as:
0 - 10ms
10ms – 20ms
20ms – 30ms
30ms – 40ms
40ms - 100ms
100ms – 5sec
>5sec
(The expected one way delay is approx 20-30 ms.)
DMV buckets are configured in 100usec steps:
ethersat profile new 1 test3FrameSizes
ethersat profile linerate set 1 1000
ethersat profile sizemix set 1 64 128 256
ethersat profile ratedecstep set 1 10
ethersat profile steplength set 1 15
ethersat profile testmode set 1 unidir
ethersat profile frameencaps set 1 l2 ethtst
ethersat profile teststep set 1 throughput latency flr back-to-back
ethersat profile dmthr insert 1 10000
ethersat profile dmthr insert 1 20000
ethersat profile dmthr insert 1 30000
ethersat profile dmthr insert 1 40000
ethersat profile dmthr insert 1 100000
ethersat profile dmvthr insert 1 100
ethersat profile dmvthr insert 1 200
ethersat profile dmvthr insert 1 500
ethersat profile dmvthr insert 1 1000
ethersat profile dmvthr insert 1 10000
The first two tests correspond to the two profiles described above. The tests are run for these traffic
parameters:
CIR = 100Mbps
CBS = 64Kbytes
EIR = 0
EBS = 0
The fourth test will demonstrate the back-to-back procedures. Hence, the CBS for the back-to-back
test is larger (CBS = 256Kbytes).
All tests will run on ingress port P5 and Ingress C-VID 55 and ingress PCP 2.
b) Set Port Type to C-Port (not unaware) and Ingress filtering to enabled:
vlan porttype 5 c-port
vlan ingressfilter 5 enable
3. Sample Procedure
From the test generator SB1 (connected to S3280 Unit L) start traffic on VLAN 55 and VLAN 77,
at 100 Mbps each, with frame size of 128 bytes. The traffic should be received at SB2 without loss.
Keep the traffic running for the duration of the test.
Periodically check test status. Test status displays ‘In progress’ for a while.
>EtherSAT test result show 1
Status: In Progress
CBS Line Rate: 1000000000 bps
Target Frame Loss Ratio: 0.00 %
Ingress Encapsulation: C-tagged
Ingress inner VID/PCP: 55/2
Ingress outer VID/PCP: 0/0
Egress Encapsulation: C-tagged
Egress inner VID/PCP: 55/2
Egress outer VID/PCP: 0/0
CIR: 100000000 bps
CBS: 64000 bytes
EIR: 0 bps
EBS: 0 bytes
Yellow Frames PCP Values:
Frame Size Mix: 64 128 256
Rate Decrease Step: 10 %
Step Length: 15 sec
Test Mode: unidir
Frame Level: L2
Test Steps: throughput latency flr back-to-back
Last Error: OK
When all four tests complete execution, the status changes to “Completed”.
On SB2, check that traffic from CVID 77 is not disturbed while the test is in progress.
Check that the traffic for CVID 55 is blocked while the test is in progress, and it resumes after the
test completes.
Latency test
Enable two VLAN level policers, one for VLAN 200 and another for VLAN 300 in the middle
device.
Set the policers to CIR = 80 Mbps, CBS = 64000 bytes.
Verify that the traffic rate on SB2 is approximately 75 Mbps for each stream (since the 80Mbps
policer applies to the outer-tagged frames of the EVC).
Restart test 1 on S3280 Unit L, and check periodically for its completion.
>ethersat test start 1
The test will complete this time with the result Failed:
>EtherSAT test result show 1
Status: Failed
CBS Line Rate: 1000000000 bps
..
Check test results for individual tests. As the throughput test failed, no test is executed for the
back-to-back test.
Check detailed Frame Loss results, which will show the number of out-of-sequence frames
received.
>ethersat test flr show 1 11
Direction: NE->FE
Frame Size: 256 byte
Actual Tx Rate: 100000000 bps
Test step duration: 19140 ms
Tx Frames: 721153
Rx Green Frames: 568424
Rx Yellow Frames: 0
Frame Loss ratio: 21.18
Out-of-sequence events: 152695
Test step result: fail
Check on SB2 that the traffic for CVID 55 is blocked while the test is in progress and restored after
the test completes.
Wait for the test to complete, and check the results. The test will complete with Failed status (due to
the policers being enabled):
For this step, configure the policers in the middle box with CIR = 120 Mbps, CBS = 16000 bytes (or
the lowest supported CBS). Check that the traffic for C-VID 55 and C-VID 77 is received by SB2
without any loss.
On Unit L, start test 3.
>ethersat test start 3
Wait for the test to complete, and check the results. The test will complete with the Failed status (due
to the CBS loss).
3. Web Interface
The EtherSAT menu paths include:
The Service Activation Systems Settings table selections are explained below.
Collector state: The Collector Flag determines will the SA module accept SA test requests from outside.
Select Disabled or Enabled. The default is Disabled.
Peer communication protocol state: select Disabled or Enabled. The default is Enabled. If disabled, a
NID is unable to support unidirectional and bidirectional RFC2544 tests (both as Initiator and Collector)
since it cannot communicate with the far end. Only loopback tests can be executed if this is set to
“disabled”.
PTP clock instance: from the S3280-TST dropdown select a configured PTP clock instance (0-3).
Test MAC address: displays the currently configured MAC address for this test (e.g., 00-C0-F2-21-DB-
8D). This Test MAC Address is used as the source MAC address of the generating frames.
Buttons
Auto-refresh: Check this box to automatically update (refresh) the page the page every three seconds.
Refresh: Refresh the page. Any changes made locally will be undone.
Save: Click to save changes.
Reset: Click to undo any changes made locally and revert to previously saved values.
At the updated Service Activation Profiles Configuration table, click the “Edit” button to modify the existing
profile.
The Service Activation Profiles Configuration table parameters are explained below.
ID: the SA profile identifier entry (e.g., 1).
Name: the SA profile name (e.g., SaProfile1)
Test Mode: the profile’s assigned testing mode (unidirectional, bidirectional, or loopback).
Frame Size Mix: a number of bytes in the range 64-9600 bytes for throughput tests. No two instances can
have the same Frame Size Mix. No two instances can have the range setting.
Test Steps: the test step(s) (Throughput, Latency, Back-to-Back, or Frame Loss) to be executed as part of
the RFC2544 testing. This attribute indicates, for each of the test steps, whether they are included in the
testing. By default, all the test steps are included. Since the Latency test is not a separate test, it is always
assumed that the Throughput test will be executed instead with a DM/DMV results calculation.
Edit button: click to change the selected SA profile’s configuration.
Delete button: click to delete the selected SA profile from the table.
Buttons
Auto-refresh: Check this box to automatically update (refresh) the page the page every three seconds.
Refresh: Click to refresh (update) the page. Any changes made locally will be undone.
Add New Profile: Click to create and configure a new Service Activation Profile to add to the page.
To specify the “Frame Mode” field in the Profiles table, you must first create an entry in the “L2 Protocol
Configuration” or “L3 Protocol Configuration” table. Then this user can specify what frame mode will be
used for profile and index of entry in the L2 or L3 Protocol configuration table (e.g. L2:1 L3:1).
To specify the “DM bin” field in the Profiles table, you must first create an entry in the “DM Threshold
Configuration” table. After this, you can specify the DM bin from the drop down list using the index from
“DM Threshold Configuration” table. The same is valid for a DMV bin field.
The Service Activation Profiles Configuration tables and parameters are explained below.
Profile parameters:
Profile ID: The profile entry ID. Enter a unique SA profile identifier (e.g., 1).
Name: Enter a name for this test profile (e.g., SaProfile1).
Payload Fill: At the dropdown, select PRBS (pseudo-random bit stream) pattern or Fixed (fixed pattern
of 4 octets). The pattern value is defined in a separate 32-bit FPGA register.
Payload Fill pattern (hex): Enter only if Payload Fill = Fixed selected above.
CBS Line Rate (Mbps): Line rate at which burst traffic should be sent for the Back-to-back frames test,
in Mbps. The CBS line rate in Mbps (e.g., 1000). The valid range is 1-1000.
FLR (%): Frame loss ratio (expressed as a percentage, with 2 decimals (i.e., 99.99 %). The Frame Loss
Ratio (e.g., 0.00 or 1.25 %).
Yellow Frames PCP Values: List of PCP values corresponding to yellow frame. Check a checkbox 0-7.
Frame Size Mix (bytes): Traffic frame size mix, for throughput tests. A number of bytes in the range 64-
9600.
Rate Decrease Step (%): Rate decrease step size, in percentage. Enter the percentage of rate decrease
at each test step (e.g., 25%).
Step Length (sec): Rate step length, in seconds. Enter the amount of time (duration) of each test step
(e.g., 10 seconds)
Test Mode: Directionality of the tests: uni-directional, bi-directional or loopback based. At the dropdown
select unidirectional, bidirectional, or loopback test mode.
Test steps: List of tests to execute. Check the checkbox for which test steps to perform (check or
uncheck Throughput, Latency, Frame Loss Rate, or Back to Back). Note: you must have a PTP clock
instance configured for accurate Latency test step timestamps. PTP must be running on both devices to
synchronize the Time of Day.
DM Threshold Configuration
The Delay Measurement threshold values in usec. The valid range is 0 to 5000000 usec (microseconds).
The default is 0. Note that with more than one DM thresholds configured, the last DM threshold value must
be set to 5000000 usec.
Buttons
New: Add new entry to the appropriate table.
Delete: Delete a table entry.
Save: Click to save changes.
Reset: Click to undo any changes made locally and revert to previously saved values.
Messeges
Message: Service Activation Error
Min frame size for TCP encapsulation is: 68 bytes
Message: Error. Invalid value : DMV Threshold must be sorted and last value must be 5000000.
The default Service Activation Tests Configuration page displays. This page lets you set the SA Test
settings, Ingress Tag configuration, Egress Tag configuration, and Bandwidth configuration
parameters.
This page lets you add and configure EtherSAT tests. Before test creation, you must first create
appropriate records in the Ingress Tag, Egress Tag, and Bandwidth tables.
Egress Tag settings can be copied from Ingress or can be configured in the Egress Tag table. Bandwidth
settings can be imported from a Policer or can be defined manually.
When you add a test, click the Edit button to display its parameters:
The Service Activation Tests Configuration page parameters are explained below.
Test settings
ID: enter an identifier for this Test.
Name: enter an identifying name for this Test.
Profile: select a configured test from the dropdown (e.g., SaProfile1).
Collector IP: enter the IP address for the Test Collector.
Target MAC address: enter the MAC address of the Test target (e.g., 00-C0-F2-21-DB-8D).
Ingress Port: select an ingress port for this test from the dropdown (e.g., 1-8).
Collector's Ingress Port: displays the Collector’s ingress port for this test (e.g., 1-8).
Egress Port: displays the configured egress port number (e.g., port 1).
EVC/ECE: displays the configured EVC and ECE numbers (e.g., 0/0).
Bandwidth configuration
CIR (bps): the default is 500,000,000 bps (500 Mbps).
CBS (bytes): the default is 100,000 bytes (500 Kbytes).
EIR (bps): the default is 0 bps.
EBS (bytes): the default is 0 bytes.
Policer to import from: select a number from 1-128 from the dropdown and click the Import button.
This updates the BW config with the selected BW config from the Configuration > Ethernet
Services > Bandwidth Profiles menu path. If the imported policer is not configured, the CIR,
CNS, EIR, and EBS parameters are set to 0. Use the Reset button to replace the 0 values with the
previously configured values.
Buttons
Import: click when the dropdown is selected in order to import the BW from the selected Policer.
This updates the BW config with the selected BW config from the Configuration > Ethernet Services >
Bandwidth Profiles menu path. If the imported policer is not configured, the CIR, CNS, EIR, and EBS
parameters are set to 0. Use the Reset button to replace the 0 values with the previously configured
values.
Save: Click to save changes.
Reset: Undo any changes made locally and revert to previously saved values.
Example
A sample configured Service Activation Tests Configuration page is shown below.
Messeges
Service Activation Error
Can't find ECE for VID 0, port 1
The Ethernet Service Activation Testing page displays the Loopback table.
The table lets you activate loopback on a port. All traffic matching the criteria below will be looped back to
the SMAC in the incoming frame.
Note: Policy ID 254 is used for marking traffic. Make sure this Policy ID is not used for other purposes
(ECEs) and the ACE Policy Filter is not being used as a bit field that would inadvertently match 254 (i.e.,
Policy Bitmask should be 0xFF for all ACEs). See the related User Guide’s “ACL Ports Configuration”
section for more information.
Buttons
Auto-refresh: Automatically update (refresh) the page the page every three seconds.
Refresh: Refresh the page. Any changes made locally will be undone.
Save: Click to save changes.
Restore: Click to undo any changes made locally and revert to previously saved values.
Example
An active Loopback test page is shown below.
S4212/S4224 Shared Port Note: The S4212 and S4224 switches have one port that is 'Shared'. On the
S4212, port 12 is ‘shared’ and on the S4224 port 24 is ‘shared’. The Shared Port can be toggled between
two modes of operation:
Internal: This mode disconnects the the Shared Port from the SFP interface and attaches it
internally to to an FPGA. No connectivity can be achieved through the Shared Port's SFP interface
while in this mode.
External: This is the default mode. In this mode, the Shared Port is attached to the SFP interface,
and works like the rest of the ports on this switch.
The Shared Port mode must be set to 'External' for normal port function and 'Internal' for the EtherSAT
Loopback and EtherSAT Test functions to work.
Messages:
Error: FPGA link ANEG failed
failed to open system sharedport table
The port is used for the internal for FPGA.
The shared port mode must be internal!
The shared port must be internal mode!
A test selection displays when a test has been created from the Configuration > Service Activation >
Test menu path.
Run Test
Test: At the Test dropdown, select an existing configured Test from the dropdown (e.g., Test1).
Start: Click to initiate the selected test. Start the selected SA test. Only one test can be executed at time.
Stop: Click to end a started test. Stops the test currently being executed. The test’s status displays as
“Aborted”.
Show: click to display the test results (described below).
Save report: click to display a “File Download” dialog that lets you select to open or save the test report
.TXT file.
Buttons
Auto-refresh: Automatically update (refresh) the page the page every three seconds.
Refresh: Refresh the page. Any changes made locally will be undone.
A sample Service Activation test display is shown below with Common, Throughput, and FLR Test
Results.
To see the result of a completed test, select the appropriate test in the dropdown list and press the Refresh
button. The results tables contain detailed information about the specific tests.
Each of the test results is described in the following sections.
Status: The Test status (e.g., Traffic Loss, No Traffic Loss, Not tested, or Fail to execute).
Elapsed Time: Total elapsed time for appropriate test in milliseconds (e.g., 21720 ms).
Step Length: Rate step length (e.g., 10000 ms).
Buttons:
Test Step dropdown: Select a configured test (e.g., Step1)
Show Details button: Click to display the selected test results for the selected Step in the dropdown.
Clear button: Click to clear the displayed test results.
The setup consists of two TN 3280 NIDs (Unit L and Unit R), connected to traffic generators (SB1 and SB2)
as shown below. A third unit (or a third party device capable of performing VLAN level policing) is used as
en emulator for the network.
EVC 300 (blue) carrying CVID 77 is not subject to RFC 2544 tests. Traffic is sent continuously on that EVC,
and will not be affected by the RFC 2544 operations.
Configuration Notes
The smallest accurate increment for Delay Measurement buckets is 1ms (1000us).
The smallest accurate increment for Delay Measurement Variation buckets is 0.1ms (100us).
1518B frames are not supported (only multiples of 4, so 1516 and 1520 are supported).
Typical one-way delay of a packet going through one S3280 switch ranges from 50uS to 80uS
(generally less time with smaller packet size and more time with larger packet size).
Network Configuration
The sample configuration below can be used to run RFC 2544 between customer handoff points.
Make one S3280 (Unit R) the PTP Master clock, and the other S3280 (Unit L) the PTP Slave.
RFC-2544 works with other PTP configurations as well; this particular config was just chosen for ease of
demonstration. The Master and Slave are assumed to be connected to each other via port 4.
5. Observe the “Peer Mean Path Delay by clicking Ports Monitor in the above screen, which brings you to
the below screen.
Configure EVC & ECE that RFC-2544 will run inside of EVC Config.
1. Navigate to the Configuration > Ethernet Services > EVCs menu path.
2. Clicking the + symbol to add an EVC.
3. Configure the as shown below:
ECE Configuration
1. Navigate to the Configuration > Ethernet Services > ECEs menu path.
2. Add ECE by clicking the + symbol.
3. Configure as shown, then Save:
When these EVC/ECE configurations are combined with the upcoming RFC2544 configurations, RFC2544
traffic will be double tagged as200 outer, 55 inner.
RFC2544 Configuration
When the dependencies (PTP, EVC/ECE, and VLAN) are configured, begin RFC2544 configuration by
configuring the Collector (Unit R) and then the Initiator (Unit L).
Collector Configuration
1. Navigate to the Configuration > Service Activation > System menu path.
2. Configure as shown below:
Initiator Configuration
1. Navigate to the Configuration > Service Activation > System menu path.
2. Configure as shown below:
3. Navigate to the Configuration > Service Activation > Profiles menu path.
4. Click the “Add New Profile” button.
6. Navigate to the Configuration > Service Activation > Tests menu path.
7. Click the “Add New Test” button.
1. Navigate to the Diagnostics > Service Activation > Test menu path.
2. Select a test and click the Start button.
3. Click the Show button; to view results as they become available, tick the Auto-refresh button.
4. Results display as shown below:
Spanning Tree is enabled by default, and will send packets out the test port, which may be
undesirable while the test is running, and depending on the loopback used, Spanning Tree may be
inadvertently triggered to block traffic on the test port. It is a best practice to disable Spanning Tree
now to avoid confusion later.
2. Configure an EVC:
a. Navigate to the Configuration > Ethernet Services > EVCs menu path.
b. Create an EVC with the following parameters:
All test traffic will be encapsulated in this EVC, and tagged with the VID configured here (100).
You may need to enter this VLAN number (100) in the Ethernet Loopback device at the remote end
of the network under test.
3. Configure an ECE:
a. Navigate the GUI to the Configuration > Ethernet Services > ECEs menu path.
b. Create an ECE with the following parameters:
When the RFC2544 test runs, the S3280’s internal traffic generator will be logically connected to
this port (and customer traffic that normally passes through this ECE will be blocked).
4. Configure PTP:
a. Navigate to the Configuration > PTP menu path.
b. Add a new PTP clock with the following parameters:
The RFC2544 implementation in the S3280-TST references PTP time when calculating the latency
during the delay measurement portions of the test. If the tests are to include delay measurements,
PTP must be configured, if not, it’s okay to omit this step.
This is the most basic PTP configuration possible, and only valid for this test.
5. Configure RFC2544:
a. Navigate to Configuration > Service Activation > System menu path.
b. Confirm configuration is as shown:
c. Copy this Test MAC address (each device has a unique Test MAC, which is different than the
management MAC). You will need to enter it in the Ethernet Loopback configuration on the
remote S3280-TST. All test traffic generated by the S3280-TST will contain this as the source
MAC address.
d. Navigate to the Configuration > Service Activation > Profiles menu path.
When testing in loopback mode, the values for Collector IP and Target MAC still need to be
populated, but they can be nearly anything, because the packets will be looped instead of sent to
an actual collector.
Click Start, click Show, and then click the Auto-refresh button. The results display:
Click the ‘Save Report’ button to export the results to a text file.
The reports will only pass after the Ethernet Loopback at the remote end has been activated.
For many messages, recovery involves reviewing the command/function description and verifying the entry
selection/syntax. For example, for many CLI messages, the first recovery step would be to refer to the
applicable Command section (e.g., “System” or “IP” or “Ports”) or the related CLI Command Group or
specific CLI command for syntax /instructions.
For any error condition, you can check the TN Tech Support web site for possible solutions. For any
problem that persists, contact TN Tech Support in the US or Canada at 1-800-260-1312, International at
00-1-952-941-7600; via fax at +1 952-941-2322; or via Email at [email protected].
Message: Object Ingress Tag Config Inner VID has not been found
Meaning: SAT message indicating an invalid ingress Tag parameter was selected.
Recovery:
1. Click the OK button to clear the webpage message.
2. Verify the operating parameters. See the “Test settings” section of the “Configuration > Service
Activation > Tests” on page 83.
Message:
Error. Invalid value : First Frame Size Mix shouldn’t be equal 0
Error. Invalid value : Frame Size Mix[1] should be in the range [64-9600]
Error. Invalid value : Frame Size Mix[0] should be multiple of 4
Meaning: At the Service Activation Profiles Configuration table, you entered an invalid “Frame Size Mix”
value.
Recovery:
1. Click the OK button to clear the webpage message.
2. Enter a valid “Frame Size Mix” value at the Service Activation Profiles Configuration table.
Message: Error. Invalid value : Frame Size Mix[2], there shouldn’t be equal values
Meaning: At the Service Activation Profiles Configuration table, you entered two equal Frame Size Mix
values, which is invalid.
Recovery:
1. Click the OK button to clear the webpage message.
2. Enter a two different Frame Size Mix values at the Service Activation Profiles Configuration table.
Meaning: At the Configuration > Service Activation > Profiles menu path in the Test Frame
Configuration table, you entered a Time To Live (TTL) value outside of the valid range.
Recovery:
1. Click the OK button to clear the webpage message.
2. Enter a valid TTL value in the Test Frame Configuration table.
Meaning: At the Configuration > Service Activation > Profiles menu path in the Test Frame
Configuration table, your combination of Encapsulation Type and Encapsulation Level is not a valid
selection.
For example you can only select “LLC/SNAP Protocol” as the Encapsulation Level if “LLC SNAP” was
selected as “Encapsulation Type”.
Recovery:
1. Click the OK button to clear the webpage message.
2. Enter a valid combination of Encapsulation Type and Encapsulation Level.
Meaning: At the Configuration > Service Activation > Profiles menu path in the Profile setting table,
you entered an invalid “Frame Size Mix (bytes)” parameter.
Recovery:
1. Click the browser back button to return to the Service Activation Profiles Configuration table.
2. Enter a “Frame Size Mix (bytes)” value of 64-9600 bytes.
3. Click the Save button.
Messages:
af_fpga_extra_init failed
af_fpga_read_sa_version failed
FPGA_ID is unreadable
FPGA_ID is bad
SA version is incompatible
Meaning: The version for Service Activation (SA) is now 0xAMMMNNNN, where 0xA is a check,
0xMMM is the major version number, and 0xNNNN is the minor version number (e.g., current version is
v0.40).
Recovery:
1. Check the S3280 version numbers and upgrade if required.
2. Verify theoperation in light of the “Meaning” information above.
3. Contact TN Technical Support for more information.
Meaning: You must have a PTP clock instance configured for accurate RFC 2544 Latency test step
timestamps. This occurs for the “Latency” test step only.
Recovery:
1. Configure PTP on both devices to synchronize the Time of Day. See the related Web User Guide for
IEE 1588 PTP configuration information.
2. Retry the operation.
Recovery:
1. Set the EVC ID Filter to “None” (at Configuration > Ethernet Services > ECEs).
2. Re-try the failed EtherSAT test. See the Diagnostics > Service Activation > Test section of the related
User Guide manual.
CLI Messages
Message: There is 1 error entry in the syslog - Assertion failed
Example: Telnet > Login > There is 1 error entry in the syslog
Meaning: You logged in successfully, an error occurred and this message displayed.
Recovery:
1. Follow the on-screen prompts to display the error, or press Enter to display the commands Help screen.
2. If the problem persists, contact TN Tech Support.
Message:
Unable set the port xx to blocked state
Unable set the port xx to forwarding state
Can't get SM for Port:xx, Link status
Meaning: A link state error or inconsistency exists.
Recovery:
1. Check the MVR configuration.
2. See the S3280 CLI Reference for MVR command information.
3. See “EtherSAT Test Commands” on page 45 or “EtherSAT Test Result Commands” on page 52.
Message:
E sa 04:08:24 11/saTestObjDelete#178: Error: SA: The test is running.
E sa 04:08:24 11/SA_conf_apply#194: Error: Cannot apply new configuration!
Meaning: The test was configured with a test actively running.
Recovery:
1. Hit the Enter key to clear the message.
2. Verify the operating parameters. See “EtherSAT Test Commands” on page 45 or “EtherSAT Test Result
Commands” on page 52.
Message:
altera_present(TN_SPI_GPIO_CS_ET_FPGA)
Could not open device
EtherSAT Loopback Active Time Remaining: %d\n
EtherSAT Loopback Port: %u\n
EtherSAT Loopback SMAC: %02X-%02X-%02X-%02X-%02X-%02X\n
EtherSAT Loopback State: %s\n
EtherSAT Loopback Timeout: %d\n
EtherSAT Loopback VID: %d\n
'EVC Port Tag' must be set to outer for Port\n
'EVC Port Addr' must be set to source for Port\n
Feature not present
FIFO contains %d bytes, but expected 4
FPGA is not present
FPGA is not present: exiting
FPGA version v%d.x is required
loopback is now active
Loopback must be inactive to change parameters\n
Not present (FPGA is not present)
Meaning: 1. You tried to enter an EthernetSAT command, but the device does not support the EtherSAT
feature. 2. Information or status message (not an error – no recovery needed).
The tn_ether_sat_fpga_present checked for the FPGA using the Board ID but none was found.
Recovery: 1. Try another command. 2. Try the command on another device.
Message:
altera_spi_app_loopback_setup failed: %d
exit
enter
port_mgmt_counters_get failed
tn_ether_sat_lb_fpga_ace_del failed: %d
tn_ether_sat_lb_tsp_ace_del failed: %d
tn_ether_sat_lb_tsp_ace_add failed: %d
tn_ether_sat_lb_fpga_ace_add failed: %d
tn_ether_sat_lb_tsp_ace_add failed: %d
tn_ether_sat_lb_fpga_ace_add failed: %d
tn_ether_sat_lb_conf_get failed
tn_ether_sat_lb_conf_set failed
vtss_switch_port_mode_ena_set failed
Meaning: The EtherSAT loopback is in progress or has failed.
1. Determine the point of failure based on the error message returned.
2. Retry the failed procedure with the corrected parameter.
3. See “EtherSAT Loopback Configuration Commands” on page 25 for more information.
Message:
HPIC control data not present
HPIC usb data not present
SMAC address' is not valid. The format is 'xx-xx-xx-xx-xx-xx' or 'xx.xx.xx.xx.xx.xx' or 'xxxxxxxxxxxx' (x is
a hexadecimal digit).
Warning: 'Configuration > Ethernet Services > Port Configuration > Tag Mode' should be set to Outer
for Port
Warning: 'Configuration > Ethernet Services > Port Configuration > Address Mode' should be set to
Source for Port
Warning: 'EVC Port Tag' should be set to outer for Port
Warning: 'EVC Port Addr' should be set to source for Port
Warning: Policy ID (%d) is in use by ECE
Warning: Policy ID (%d) is in use by ACL Port
Warning: VLAN %d not found
Meaning: The EtherSAT loopback is in progress or has failed.
1. Determine the point of failure based on the error message returned.
2. Retry the failed procedure with the corrected parameter.
3. See “EtherSAT Loopback Configuration Commands” on page 25 for more information. See the S3280
User Guide “ACL Ports Configuration” section for more information.
Messages:
EtherSAT Loopback Active Time Remaining: n
EtherSAT Loopback Port: n
EtherSAT Loopback SMAC: %02X-%02X-%02X-%02X-%02X-%02X\n
lb_conf.smac.addr[0], lb_conf.smac.addr[1], lb_conf.smac.addr[2],
lb_conf.smac.addr[3], lb_conf.smac.addr[4], lb_conf.smac.addr[5]);
EtherSAT Loopback State: "Inactive" or "Active"
EtherSAT Loopback TestSidePort: n
Meaning: The EtherSAT loopback is in progress or has failed.
Recovery:
1. Wait for the procedure to successfully complete.
2. Determine the point of failure based on the error message returned.
3. Retry the failed procedure with the corrected parameter.
4. See “EtherSAT Loopback Configuration Commands” on page 25 for more information.
Message:
Can't init Peer proto session
No PTP clock for the given instance created
Clock Compensation is not actuated
Clock compensation is not actuated on Initiator
Clock compensation is not actuated on Collector
FPGA clock initialization in progress, please try again
Collector's FPGA clock initialization in progress, please try again
Meaning: A clock, sync, or peer proto error occurred.
1. afErrSaPeerProto = 9
2. afErrSaPtpSync = 10
3. afErrSaClockCompensation = 11
Recovery:
1. Verify the Peer Protocol setup. See “Peer Protocol” on page 20.
2. Verify the PTP Clock setup. See “PTP Configuration for RFC 2544“ on page 102.
3. See “Dependencies and Prerequisites” on page 6.
4. See the “EtherSAT Engine Commands” section on page 29.
Message:
Last Error: Peer protocol timeout
Meaning: A problem exists with the management connection between Initiator and Collector (e.g. there is a
loop between the devices).
Recovery: If you use PTP, the frames should be in a separate VLAN, since PTP uses the Management
MAC and can relearn the MAC table entries.
Message:
Status: Failed
Last Error: OK
Meaning: An unknown error occurred during the test.
Recovery: 1. Check the test parameters. 2. Check the peer device. 3. Re-run the test.
Message:
Last Error: No response from the peer NID
Meaning: The peer device was not able to respond to this test.
Recovery: 1. Check the peer device. 2 Check the test parameters. 3. Re-run the test.
Messages:
Username: E ether_sat 00:00:07 29/saTestCreate#864: Error: SA: Inner VID/PCP must be specified only
for double tagged frames
E ether_sat 00:00:07 29/saDbApplyConfig#2324: Error: SA: Can't create a new test 1
E ether_sat 00:00:07 29/SA_conf_apply#155: Error: Cannot apply new configuration!
Meaning: An EtherSAT configuration error occurred.
Recovery:
1. Navigate to the Configuration > Service Activation menu path.
2. Select the desired option (System, Profiles, or Tests).
3. Re-try the failed SAT operation. See "EtherSAT Test Commands" on page 45.
Problem: Bidirectional FE--> NE tests sometimes fail, RX Green frames limited to 100
Meaning: When the RFC-2544 test is Bidirectional, sometimes the FE --> NE tests fail, because all
except 100 packets are dropped by the NNI port of the Initiator. Dropped packets are
identical to NE --> FE packets that passed, but with the source and destination MACs
swapped. The only difference between these passing and failing configs is that on Unit L,
Tests are set to C tag when failing, and CC tag when passing.
Recovery: None - the configuration is not valid. The test traffic has encapsulation SOAM EthTst. But
since MEP is configured on level 4 that intercepts all SOAM frames with level 4 or lower,
the test traffic should have MEG level 5 or more. Or use different encapsulation
(LLC/SNAP, L3).
Example: Initiator has MEP on level 4:
mep conf
MEP Configuration is:
Inst Mode Direction Port Dom Level Format Name Meg id Mep id Vid Flow Eps MAC
1 Mep Down 4 Port 4 ITU ICC TRNSTN meg000 1 200 4 0 00-C0-F2-21-DE-17
Problem: DM & DMV bins do not appear to be catching all traffic. The "99" and "98" in the bins
indicate that all counters for each measurement do not add up to 100%. (At Latency Test
Results > DM Bin Counters and DMV Bin Counters.)
Meaning: The rate of DM frames is fixed to approximately one every 100ms. So the DM packet rate
is about 10 packets per second. The “99” means that test step length was 10 seconds, so the
number of DM results must be ~100 frames. The number of DMV results must be one less
then DM since it calculates differences between two delays (per the RFC 2544 design).
Recovery: None required.
Problem: After initial configuration, even though the units are configured correctly, the RFC2544
tests will fail as shown:
Meaning: If this happens, the tests will keep failing until the Collector is rebooted. During failure,
the Collector appears to be filtering all test packets:
Recovery: 1. Try reconfiguring and power cycling and the tests will pass.
2. Reboot the S3280.
3. Upgrade your S3280 software.
Problem: Several packet sizes fail when running S3280-TST RFC2544 tests at 100% throughput
using third-party equipment to generate tests.
Problem: The results of RFC 2544 throughout and back to back tests with a third-party tester “failed“
because they only did 99.999% (not 100%).
Meaning: A configuration prerequisite exists for running RFC2544 using S3280-TST. Spanning Tree
is enabled by default on the S3280-TST. When enabled, the S3280-TST periodically sends
Spanning Tree packets on all ports. The spanning tree packets take from the available
bandwidth that is needed to pass the test.
Recovery:
1. Disable STP if running “collector” or “initiator” mode on the S3280-TST.
2. Disable Spanning Tree on the S3280 for any RFC2544 tests that is running 100% port
utilization.
3. Via web GUI: at the Configuration > Spanning Tree > CIST Ports menu path,
uncheck the "STP Enabled" checkbox for the related ports.
4. Via CLI: use the "stp port mode" command to disable STP for the related ports (e.g.,
"stp port mode 1,4 disable"). Use the "stp port mode" command to display the current
settings (enabled or disabled).
Note: you may want to disable STP globally, depending on your test configuration and
maintenance concerns.
Problem: EtherSAT test packets are sent at the wrong frame rate.
Meaning: Frames are sent at a rate that is ideal for frames 16 bits smaller than configured.
Work-around: For example, if you want to fill a 100Mb link with 80-byte packets, then configure a frame
size of 80 bytes and a CIR of 80,000,000 bps. The resulting frame rate should be 125,000 pps, but it’s
actually 148,810 pps. A 148,810 bps frame-rate would fill a 100 Mbps link with 64-bit frames.
7. SNMP MIBs
Supported MIBs
The RFC2544 module supports a private Management Information Bases (MIBs) for RFC 2544.
Table 3. Public MIBs
tnEtherSATMIB
tnSaMIB
tnSAProfileNextID
tnSATestNextID
tnSASysConfPeerCommunicationProto
tnSASysConfCollectorState
tnSASysTestMacAddress
tnSAPtpClockNum
tnSAProfileTable
tnSAProfileEntry
tnSAProfileID
tnSAProfileName
tnSAProfileFrameLossRatio
tnSAProfileCbsLineRate
tnSAProfileFrameSizeMix
tnSAProfileRateDecStep
tnSAProfileRateStepLength
tnSAProfileDirectionality
tnSAProfileYellowPcpList
tnSAProfileStepsToExecute
tnSAProfileRefCounter
tnSAProfileRowStatus
tnSAFrameFormatProfileTable
tnSAFrameFormatProfileEntry
tnSAFrameFormatProfileFrameLevel
tnSAFrameFormatProfilePaylodFiller
tnSAFrameFormatProfileEncapsulationL2
tnSAFrameFormatProfileEncapsulationL3
tnSAFrameFormatProfileEthType
tnSAFrameFormatProfileIpDscp
tnSAFrameFormatProfileIpEcn
tnSAFrameFormatProfileIpFlags
tnSAFrameFormatProfileIpTtl
tnSAFrameFormatProfileUdpSrcPort
tnSAFrameFormatProfileUdpDstPort
tnSAFrameFormatProfileTcpSrcPort
tnSAFrameFormatProfileTcpDstPort
tnSAFrameFormatProfileTcpSeqNum
tnSAFrameFormatProfileTcpAckNum
tnSAFrameFormatProfileTcpControlBits
tnSAFrameFormatProfileTcpWindowSize
tnSAFrameFormatProfileLlcSnapOui
tnSAFrameFormatProfileLlcSnapProto
tnSAFrameFormatProfileIpDestIpAddress
tnSAFrameFormatProfileIpSrcIpAddress
tnDmBinThresholdTable
tnDmBinThresholdEntry
tnDmBinThresholdIndex
tnDmBinThresholdValue
tnDmvBinThresholdTable
tnDmvBinThresholdEntry
tnDmvBinThresholdIndex
tnDmvBinThresholdValue
tnSATestTable
tnSATestEntry
tnSATestID
tnSATestSAProfileId
tnSATestIngressEncapsulationType
tnSATestIngressInnerVid
tnSATestIngressInnerPcp
tnSATestIngressOuterVid
tnSATestIngressOuterPcp
tnSATestEgressEncapsulationType
tnSATestEgressInnerVid
tnSATestEgressInnerPcp
tnSATestEgressOuterVid
tnSATestEgressOuterPcp
tnSATestIngressPort
tnSATestCollectorIngressPort
tnSATestCollectorIpAddr
tnSATestName
tnSATestCir
tnSATestCbs
tnSATestEir
tnSATestEbs
tnSATestTargettestMacAddr
tnSATestAction
tnSATestRowStatus
tnSACommonTestResultsEntry
tnSACommonTestResultsTestId
tnSACommonTestResultsTestStatus
tnSACommonTestResultsEgressPort
tnSACommonTestResultsCbsLineRate
tnSACommonTestResultsDirectionality
tnSACommonTestResultsFrameLossRatio
tnSACommonTestResultsYellowPcpList
tnSACommonTestResultsFrameSizeMix
tnSACommonTestResultsRateDecStep
tnSACommonTestResultsRateStepLength
tnSACommonTestResultsFrameFormatFrameLevel
tnSACommonTestResultsStepsToExecute
tnSACommonTestResultsFrameFormatPaylodFiller
tnSACommonTestResultsFrameFormatEncapsulationL2
tnSACommonTestResultsFrameFormatEncapsulationL3
tnSACommonTestResultsFrameFormatEthType
tnSACommonTestResultsFrameFormatIpDscp
tnSACommonTestResultsFrameFormatIpEcn
tnSACommonTestResultsFrameFormatIpFlags
tnSACommonTestResultsFrameFormatIpTtl
tnSACommonTestResultsFrameFormatUdpSrcPort
tnSACommonTestResultsFrameFormatUdpDstPort
tnSACommonTestResultsFrameFormatTcpSrcPort
tnSACommonTestResultsFrameFormatTcpDstPort
tnSACommonTestResultsFrameFormatTcpSeqNum
tnSACommonTestResultsFrameFormatTcpAckNum
tnSACommonTestResultsFrameFormatTcpControlBits
tnSACommonTestResultsFrameFormatTcpWindowSize
tnSACommonTestResultsFrameFormatLlcSnapOui
tnSACommonTestResultsFrameFormatLlcSnapProto
tnSACommonTestResultsFrameFormatIpDestIpAddress
tnSACommonTestResultsThroughputTestElapsedTime
tnSACommonTestResultsLatencyTestElapsedTime
tnSACommonTestResultsFlrTestElapsedTime
tnSACommonTestResultsBacktoBackTestElapsedTime
tnSACommonTestResultsThroughputTestResult
tnSACommonTestResultsLatencyTestResult
tnSACommonTestResultsFlrTestResult
tnSACommonTestResultsBacktoBackTestResult
tnSACommonTestResultsLastError
tnSACommonTestResultsTestIngressEncapsulationType
tnSACommonTestResultsTestIngressInnerVid
tnSACommonTestResultsTestIngressInnerPcp
tnSACommonTestResultsTestIngressOuterVid
tnSACommonTestResultsTestIngressOuterPcp
tnSACommonTestResultsTestEgressEncapsulationType
tnSACommonTestResultsTestEgressInnerVid
tnSACommonTestResultsTestEgressInnerPcp
tnSACommonTestResultsTestEgressOuterVid
tnSACommonTestResultsTestEgressOuterPcp
tnSACommonTestResultsTestIngressPort
tnSACommonTestResultsTestCollectorIngressPort
tnSACommonTestResultsTestCir
tnSACommonTestResultsTestCbs
tnSACommonTestResultsTestEir
tnSACommonTestResultsTestEbs
tnSACommonTestResultsDmBinThresholdTable
tnSACommonTestResultsDmBinThresholdEntry
tnSACommonTestResultsDmBinThresholdIndex
tnSACommonTestResultsDmBinThresholdValue
tnSACommonTestResultsDmvBinThresholdTable
tnSACommonTestResultsDmvBinThresholdEntry
tnSACommonTestResultsDmvBinThresholdIndex
tnSACommonTestResultsDmvBinThresholdValue
tnSAThroughputTestResultsTable
tnSAThroughputTestResultsEntry
tnSAThroughputTestResultsTestId
tnSAThroughputTestResultsStepNumber
tnSAThroughputTestResultsDirection
tnSAThroughputTestResultsActualRate
tnSAThroughputTestResultsStepDuration
tnSAThroughputTestResultsTxFrames
tnSAThroughputTestResultsRxGreenFrames
tnSAThroughputTestResultsRxYellowFrames
tnSAThroughputTestResultsStepResult
tnSAThroughputTestResultsFrameSize
tnSALatencyTestResultsTable
tnSALatencyTestResultsEntry
tnSALatencyTestResultsTestId
tnSALatencyTestResultsStepNumber
tnSALatencyTestResultsDirection
tnSALatencyTestResultsStepDuration
tnSALatencyTestResultsFrameSize
tnSALatencyTestResultsStepResult
tnSALatencyTestResultsDmBinThresholdTable
tnSALatencyTestResultsDmBinThresholdEntry
tnSALatencyTestResultsDmBinThresholdIndex
tnSALatencyTestResultsDmBinThresholdRange
tnSALatencyTestResultsDmBinThresholdValue
tnSALatencyTestResultsDmvBinThresholdTable
tnSALatencyTestResultsDmvBinThresholdEntry
tnSALatencyTestResultsDmvBinThresholdIndex
tnSALatencyTestResultsDmvBinThresholdRange
tnSALatencyTestResultsDmvBinThresholdValue
tnSAFlrTestResultsTable
tnSAFlrTestResultsEntry
tnSAFlrTestResultsEntry
tnSAFlrTestResultsTestId
tnSAFlrTestResultsStepNumber
tnSAFlrTestResultsDirection
tnSAFlrTestResultsActualRate
tnSAFlrTestResultsStepDuration
tnSAFlrTestResultsTxFrames
tnSAFlrTestResultsRxGreenFrames
tnSAFlrTestResultsRxYellowFrames
tnSAFlrTestResultsFlr
tnSAFlrTestResultsStepResult
tnSAFlrTestResultsFrameSize
tnSAFlrTestResultsOutOfSeqEvents
tnSABackToBackTestResultsTable
tnSABackToBackTestResultsEntry
tnSABackToBackTestResultsTestId
tnSABackToBackTestResultsStepNumber
tnSABackToBackTestResultsDirection
tnSABackToBackTestResultsActualRate
tnSABackToBackTestResultsStepDuration
tnSABackToBackTestResultsTxFrames
tnSABackToBackTestResultsRxGreenFrames
tnSABackToBackTestResultsRxYellowFrames
tnSABackToBackTestResultsFlr
tnSABackToBackTestResultsStepResult
tnSABackToBackTestResultsBurstSize
Status: Completed
CBS Line Rate: 1000 Mbps
Target Frame Loss Ratio: 0.00 %
Ingress port: 1
Egress port: 2
Collector's Ingress port: 1
Ingress Encapsulation: C-tagged
Ingress inner VID/PCP: 0/0
Ingress outer VID/PCP: 100/0
Egress Encapsulation: C-tagged
Egress inner VID/PCP: 0/0
Egress outer VID/PCP: 100/0
CIR: 500000000 bps
CBS: 100000 bytes
EIR: 0 bps
EBS: 0 bytes
Yellow Frames PCP Values:
Frame Size Mix: 128
Rate Decrease Step: 90 %
Step Length: 10 sec
Test Mode: bidir
Frame Level: L2
Test Steps: throughput latency flr back-to-back
Last Error: OK
--------------------------------------------------------------------------------
Throughput test results:
Status: Pass
Elapsed Time: 51580 ms
Step Dir Frame size (byte) Actual Tx Rate (bps) Result
------ ------ ------------------ --------------------- ------
1 NE->FE 128 498113207 pass
2 NE->FE 128 498113207 pass
3 FE->NE 128 498113207 pass
4 FE->NE 128 498113207 pass
Step 1
Direction: NE->FE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 14030 ms
Tx Frames: 4734848
Rx Green Frames: 4734848
Rx Yellow Frames: 0
Test step result: pass
Step 2
Direction: NE->FE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 14030 ms
Tx Frames: 4734848
Step 3
Direction: FE->NE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 11760 ms
Tx Frames: 4734848
Rx Green Frames: 4734848
Rx Yellow Frames: 0
Test step result: pass
Step 4
Direction: FE->NE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 11760 ms
Tx Frames: 4734848
Rx Green Frames: 4734848
Rx Yellow Frames: 0
Test step result: pass
--------------------------------------------------------------------------------
Latency test results:
Step 1
Direction: NE->FE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 14030 ms
DM bins:
[ 0 - 10000 ] : 99
[ 10001 - 20000 ] : 0
[ 20001 - 50000 ] : 0
[ 50001 - 100000 ] : 0
[ 100001 - 5000000] : 0
[ > 5000000] : 0
DM min/max/avg: 0/0/0 us
DMV bins:
[ 0 - 10 ] : 98
[ 11 - 100 ] : 0
[ 101 - 5000000] : 0
[ > 5000000] : 0
DMV min/max/avg: 0/0/0 us
Test step result: pass
Step 2
Direction: NE->FE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 14030 ms
DM bins:
[ 0 - 10000 ] : 99
[ 10001 - 20000 ] : 0
[ 20001 - 50000 ] : 0
[ 50001 - 100000 ] : 0
[ 100001 - 5000000] : 0
[ > 5000000] : 0
DM min/max/avg: 0/0/0 us
DMV bins:
[ 0 - 10 ] : 98
[ 11 - 100 ] : 0
[ 101 - 5000000] : 0
[ > 5000000] : 0
DMV min/max/avg: 0/0/0 us
Test step result: pass
Step 3
Direction: FE->NE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 11760 ms
DM bins:
[ 0 - 10000 ] : 99
[ 10001 - 20000 ] : 0
[ 20001 - 50000 ] : 0
[ 50001 - 100000 ] : 0
[ 100001 - 5000000] : 0
[ > 5000000] : 0
DM min/max/avg: 0/0/0 us
DMV bins:
[ 0 - 10 ] : 98
[ 11 - 100 ] : 0
[ 101 - 5000000] : 0
[ > 5000000] : 0
DMV min/max/avg: 0/0/0 us
Test step result: pass
Step 4
Direction: FE->NE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 11760 ms
DM bins:
[ 0 - 10000 ] : 99
[ 10001 - 20000 ] : 0
[ 20001 - 50000 ] : 0
[ 50001 - 100000 ] : 0
[ 100001 - 5000000] : 0
[ > 5000000] : 0
DM min/max/avg: 0/0/0 us
DMV bins:
[ 0 - 10 ] : 98
[ 11 - 100 ] : 0
[ 101 - 5000000] : 0
[ > 5000000] : 0
DMV min/max/avg: 0/0/0 us
Test step result: pass
--------------------------------------------------------------------------------
Frame Loss Rate test results:
Status: Pass
Elapsed Time: 51580 ms
Step Dir Frame size (byte) Actual Tx Rate (bps) FLR (%%)
------ ------ ------------------ --------------------- --------
1 NE->FE 128 498113207 0.00
2 NE->FE 128 498113207 0.00
3 FE->NE 128 498113207 0.00
4 FE->NE 128 498113207 0.00
Step 1
Direction: NE->FE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 14030 ms
Tx Frames: 4734848
Rx Green Frames: 4734848
Rx Yellow Frames: 0
Frame Loss ratio: 0.00
Out-of-sequence events: 0
Test step result: pass
Step 2
Direction: NE->FE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 14030 ms
Tx Frames: 4734848
Rx Green Frames: 4734848
Rx Yellow Frames: 0
Frame Loss ratio: 0.00
Out-of-sequence events: 0
Test step result: pass
Step 3
Direction: FE->NE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 11760 ms
Tx Frames: 4734848
Rx Green Frames: 4734848
Rx Yellow Frames: 0
Frame Loss ratio: 0.00
Out-of-sequence events: 0
Test step result: pass
Step 4
Direction: FE->NE
Frame Size: 128 byte
Actual Tx Rate: 498113207 bps
Test step duration: 11760 ms
Tx Frames: 4734848
Rx Green Frames: 4734848
Rx Yellow Frames: 0
Frame Loss ratio: 0.00
Out-of-sequence events: 0
Test step result: pass
--------------------------------------------------------------------------------
Back-To-Back Frames test results:
Status: Pass
Elapsed Time: 55690 ms
Step Dir Frame size (byte) Burst Size (bytes) Result
------ ------ ------------------ ------------------- ------
1 NE->FE 128 100000 pass
2 NE->FE 128 100000 pass
3 FE->NE 128 100000 pass
4 FE->NE 128 100000 pass
Step 1
Direction: NE->FE
Step 2
Direction: NE->FE
Frame Size: 128 byte
Burst size: 100000 bytes
Test step duration: 11280 ms
Tx Frames: 4736616
Rx Green Frames: 4736616
Rx Yellow Frames: 0
Frame Loss ratio: 0.00 %
Test step result: pass
Step 3
Direction: FE->NE
Frame Size: 128 byte
Burst size: 100000 bytes
Test step duration: 11250 ms
Tx Frames: 4736616
Rx Green Frames: 4736616
Rx Yellow Frames: 0
Frame Loss ratio: 0.00 %
Test step result: pass
Step 4
Direction: FE->NE
Frame Size: 128 byte
Burst size: 100000 bytes
Test step duration: 11250 ms
Tx Frames: 4736616
Rx Green Frames: 4736616
Rx Yellow Frames: 0
Frame Loss ratio: 0.00 %
Test step result: pass
--------------------------------------------------------------------------------
Frame format:
Level: L2
Encapsulation Type: ETH-TST
Filling Mode: PRBS
Frame Payload Pattern: 0x00000000
Custom EthType: 0x0000
LLC/SNAP OUI: 00-00-00
LLC/SNAP Protocol: 0x0000
SOAM MEG Level: 5
Warranty
See the "Warranty" section in the online device User Guide manual for regulatory agency compliance
information.
Compliance Information
See the "Compliance Information" section in the online device User Guide manual for regulatory agency
compliance information.
Definitions
Cautions indicate that there is the possibility of poor equipment performance or potential damage to the
equipment. Warnings indicate that there is the possibility of injury to a person.
Cautions and Warnings appear here and may appear throughout this manual where appropriate. Failure to
read and understand the information identified by this symbol could result in poor equipment performance,
damage to the equipment, or injury to persons.
See "Electrical Safety Warnings" in the online device User Guide manual for Electrical Safety Warnings
translated into multiple languages.
CIR
(Committed Information Rate) the Bandwidth Profile parameter that defines the average rate in bits/s of
Frames at an EI up to which the network delivers Frames, and is committed to meeting the performance
objectives defined by the CoS Service Attribute.
DM
Delay measurement.
DMV
Delay measurement variation.
DUT
Device under test.
EBS
(Excess Burst Size) a Bandwidth Profile parameter that limits the maximum number of bytes available for a
burst of Frames sent at the EI speed to remain EIR-conformant.
EIR
(Excess Information Rate) a Bandwidth Profile parameter that defines the average rate in bits/s of Frames up
to which the network may deliver Frames but without any performance objectives.
Far-end device
The peer NID device where traffic is counted and/or optionally looped back. AKA “FE device”. Contrast
“Near End device (NE)”.
FLR
(Frame Loss Ratio) a measure of the number of lost frames between the ingress UNI and the egress UNI.
Frame Loss Ratio is expressed as a percentage. See MEF 10.2 19, 10, 14, and 15. FLR is replaced by
“Frame Loss Ratio Performance” in MEF 10.2.
FPGA
A field-programmable gate array (FPGA) is an integrated circuit designed to be configured by a customer or
designer after it is manufactured.
Frame Delay
The time required to transmit a Service Frame from ingress UNI to egress UNI. Note: Replaced by “Frame
Delay Performance” in MEF 10.2. See MEF 6.1, 10.1, 19, 10, 14, and 15.
Near-end device
The NID on which a test operation is initiated by the user. AKA “NE device”. Contrast “Far End device (FE)”.
RFC 2544
IETF de facto methodology that outlines the tests required to measure and to prove performance criteria for
carrier Ethernet networks. It provides an out-of-service benchmarking methodology to evaluate the
performance of network devices using throughput, back-to-back, frame loss and latency tests. Each standard
test validates a specific part of a SLA. See http://www.ietf.org/rfc/rfc2544 for specifics.
RFC 3544
IETF standard that defines a specific set of tests that vendors can use to measure and report the
performance characteristics of network devices. The results of these tests provide comparable data from
different vendors with which to evaluate these devices.
SLA
Service Level Agreement; initially defined in MEF 2. See also MEF 3, 6.1, 7, 10.2, 14, 15, 17, and 19.
Index
ACE Policy .......................................................... 25 Safety ................................................................144
Commands, System .....................................23, 24 specifications ........................................................5
error messages ................................................. 121 test output ...........................................................52
External mode ...............................................25, 45 test procedures ...................................................13
frame content ........................................................ 8 Test process .......................................................21
frame size ............................................................. 8 test record ...........................................................10
Internal mode ................................................25, 45 test report ......................................................11, 52
Mgmt IP address ................................................. 10 test status ............................................................10
MIBs .................................................................. 138 test steps ...............................................................7
output .................................................................. 52 test, commands...................................................22
Policy ID .............................................................. 25 test, error messages .........................................121
prerequisites ......................................................... 6 test, peer NID ......................................................10
problem solving .........................................121, 133 test, starting ........................................................10
Profile attributes .................................................... 7 test, stoping .........................................................10
reports ................................................................. 52 test, troubleshooting .........................................120
roles ................................................................ 5, 25
Transition Networks
10900 Red Circle Drive
Minnetonka, MN 55343 USA
Tel: 952- 941-7600 or 1-800-526-9267
Fax: 952-941-2322
Copyright© 2012, 2013 Transition Networks
All rights reserved.