PacketCheck™ - Software Ethernet Tester
GL's enhanced PacketCheck™ is a comprehensive PC based Ethernet / IP test tool with BERT and Throughput testing abilities. It is very easy to use as a general purpose network performance analysis tool for 10Mbps, 100Mbps and 1Gbps LANs and WANs.Brochure
GL's enhanced PacketCheck™ is a comprehensive PC based Ethernet / IP test tool with BERT and Throughput testing abilities. It is a general purpose network performance analysis tool for 10Mbps, 100Mbps and 1Gbps LANs and WANs. Throughput up to 800 Mbps can be easily tested.
PacketCheck™ makes use of PC's network interface card (NIC) to transmit and receive Ethernet or IP packets over the network.
The application generates multi stream Ethernet/IP/UDP traffic with on-demand bandwidth (up to 800 Mbps) and measures end to end performance such as Bit Error Rate, Total Packets, Packet loss, Out of Sequence Packets, and Erred Packets. Additional features include transmission of pre-recorded file traffic, GTP traffic simulation, Bursty and Fixed IFG (Inter Frame Gap) traffic generation mode, Delay measurements, impairment generation, and BER testing capability with provision to generate PRBS patterns or user–defined test patterns.
It also includes a Command Line Interface (CLI) to support all the GUI functionalities of PacketCheck™ through simple commands, allowing easy scripting and automation of the testing. Also included is a powerful Report Generation feature to view report in XML and PDF formats.
PacketCheck™ can operate on - Layer 1 (Physical), Layer 2 (Data Link), Stacked VLAN (Q-in-Q), Layer 2.5 (Stacked MPLS), Layer 3 (Network), and Layer 4 (Transport) of the OSI reference model.
PacketCheck™ at Layer 1 (Physical), Layer 2 (Data Link) with Stacked VLAN tag,
Layer2.5 (MPLS), Layer 3 (Network), and Layer 4 (Transport) of OSI model
- Determine the maximum throughput and error rates in a LAN / WAN
- Determine Round Trip Delay (RTD) with microsecond accuracy
- Determine One Way Delay (OWD) between two NIC cards with microseconds accuracy
- Test network infrastructure for dropped packets, errors, latency, and so on
- Detect traffic overload
- Test network behavior with real world traffic like IPTV, VoIP and more
- Test CAT 6 / CAT 5 cables for efficiency
- Test Ethernet or IP/UDP traffic of up to 800 Mbps bandwidth
- Generate full duplex traffic at any of the four layers (Layer1, Data Link with stacked VLAN/ MPLS, Network, Transport) with on-demand bandwidth
- Generate multi-stream traffic with varying frame size, bandwidth, MAC, MPLS, IP and UDP parameters, payloads, and modes of operation
- Customizable VLAN stacks up to 3 levels with headers such as VLAN Type, ID, and Priority
- Customizable stacked MPLS layers up to 3 levels with headers such as Label, CoS, TTL
- Customizable protocol headers like MAC Source/Destination address, Length/Type field, IP Source/destination address, and UDP Source/Destination Port
- Bit-error-rate testing (BERT) on layer 1, layer 2, layer 2.5, layer 3, and layer 4 with various measurements - Bit Error Rate, Sync Loss Count, Bit Error Count, and more
- PRBS Pattern Generation/Verification of various patterns like QRSS 26-1, 29-1, 211-1, 215-1, 220-1, 223-1
- User Defined test patterns – up to 24 bytes length
- Simulate real-world traffic (such as IPTV, RTP,...) by transmitting packets using pre-captured GL proprietary HDL files
- Simulate real-world Mobile GTP traffic by using PacketCheck™ along with MAPS™ (requires additional licensing)
- Generate various run-time impairments – insert/delete bytes, and byte level impairments
- Jumbo frames are supported, in addition to all normal frame sizes from 64 bytes to 1518 bytes
- Generate aggregated and per-stream statistics
- Monitor performance per stream – throughput, Round Trip Delay (RTD), One Way Delay (OWD), total packets, packet loss, out of sequence frames, error frames, correct pattern frames, pattern sync status, bit error rate, sync loss count, error count etc.
- Execute remote commands through a Command Line Interface (CLI).
- Generate reports in XML or PDF formats.
Ethernet BER Testing
GL's PacketCheck™ supports BERT testing at various levels -
- Layer 1 (Physical layer) – Payload is made up of BERT patterns.
- Layer 2 (Framed Ethernet layer) - Bit pattern is inserted as the Ethernet Payload.
- Layer 2 with Stacked VLAN - Bit pattern is inserted as Ethernet Payload with VLAN tags.
- Layer 2.5 (MPLS) - Bit pattern is inserted as MPLS Headers
- Layer 3 (IP level) – Bit pattern is inserted as the IP packet payload.
- Layer 4 (UDP level) – Bit pattern is inserted as the UDP packet payload.
At Layer 1
The physical layer of the OSI model is where data is physically moved across the network interface. At Layer 1 cables, hubs and repeaters are used to transmit data across the medium.
For Layer 1 BER testing, PacketCheck™ can test the basic data flow over the physical connection. Connect the two test PCs using an Ethernet cable as shown below:
BERT Test Setup at Layer 1 connected using Ethernet cable
At Layer 2
Testing at layer 2 involves the switches, bridges, or NICs as the DUT. The bridges, switches, and NICs handle physical addressing, packing data into frames, and sequencing data frames. Only the MAC addresses need to be configured for layer 2 testing.
GL's PacketCheck™ can test the basic data flow over the network. This test is performed in order to
- Test the capability of the switch to handle frames at various bandwidths
- Test the forwarding capacity of the switch
- Measure the ability of the switch to deliver the frames in sequence
- Verify incoming data by analyzing bit patterns of the received frames
Scenario 1 - Source & Destination PC in the same LAN, connected through a single switch
Ethernet BER Test Setup at Layer 2 connected through a single switch
Scenario 2 - Source & Destination PC located at different LANs connected through multiple switches.
Ethernet BER Test Setup at Layer 2 connected through multiple switches
At Stacked VLAN Layer
Stacked VLAN ID feature is used to simulate Carrier Ethernet as shown below, where the SP VLAN ID is stacked on top of CE VLAN ID.
Stacked VLAN simulating Carrier Ethernet
At Stacked MPLS Layer
Stacked MPLS (up to 3 levels) is supported. Various test combinations such as single MPLS, multiple MPLS, VLAN + MPLS can be tested for single and multiple streams.
Ethernet BERT Test Setup at stacked MPLS
At Layer 3/Layer 4
The Network Layer (Layer 3) uses routing technologies to connect various systems within a network or to connect multiple networks together through Gateways. In Layer 3 testing, packets are routed between the Source and Destination PCs based on both the IP address and MAC address. So, both the MAC address and the IP address have to be configured for Layer 3 testing.
The Transport Layer (Layer 4) provides end-to-end, error-free reliable data transfer. TCP and UDP are the most common Layer 4 protocols. For Layer 4 testing, source and destination UDP ports need to be configured in addition to MAC and IP addresses.
PacketCheck™ supports BER testing at Layer 3 as well as Layer 4.
Testing at Layer 3 using GL's PacketCheck™ can be accomplished as shown in the figure below. Here, two PacketCheck™ applications operate in separate IP networks and are connected through routers, which route the frames based on the IP addresses in the test frames. Since IP networks encompass various types of physical networks consisting of LAN and WAN links, there is lot of scope for packet modification, packet loss and out of order packets. GL's PacketCheck™ helps measure these metrics of the IP network.
Two test scenarios at Layer 3 / 4 are as depicted in the diagram where the information in layer 3 / layer 4 is transmitted through the network in packets.
Scenario 1 - Source & Destination PC are located within the same IP network, and hence are directly reachable.
Ethernet BERT Indirect Routing Test Setup at Layer 3/ Layer 4 within the same IP network
Scenario 2 - Source & Destination PC are located at different IP networks, and are connected through routers.
Ethernet BERT Indirect Routing Test Setup at Layer 3/ Layer 4 at different IP networks
At Layer 4 testing, UDP packets are sent. This testing is useful in cases where there are firewalls which can intervene at network boundaries to reject, pass or modify packets.
Modes of Operation
The MAC and IP addresses of the available NICs in a PC are displayed in the GUI. PacketCheck™ can be configured in Normal or Loopback mode.
- In "Normal" mode, the application can perform either transmit (Tx), receive (Rx), or transmit and receive (Tx and Rx) functions on single or multiple streams.
- In "Loopback" mode the packets received from the device under test (DUT) are transmitted back to the same device without modifying the pattern. This mode is used for RTD measurement.
Interface Selection and Details Settings
MAC, MPLS, IP, UDP Layer-wise Parameters Configuration
All test parameters are configured through the GUI. Key parameters include the Layer/Direction selection, MAC, VLAN, MPLS, IP, UDP, payload, transmit and receive, delay measurements and various impairments settings PacketCheck™ is automatically set to Layer 1 BER testing by disabling other layers.
Interface Configuration Settings
[Layer 2] - Ethernet
Here you can configure the source and destination MAC Addresses. In addition, user can specify the Length/Type field value. Users can enable VLAN up to 3 stacks and configure with the headers.
The following table gives the Length/Field values for the configured Layers (2/3/4)
|Layer Configured||Frame Size Configured||Length/Type Field Value|
|Layer 2||60 (actual frame size = 64 bytes)||00-2E|
|Layer 2||(between 64 and 1514)||(Hex Value of Configured Frame Size -14)|
|Layer 2||1514 (actual frame size = 1518 bytes)||05-DC|
|Layer 3 (IP)||ANY||08-00|
|Layer 4 (UDP)||ANY||08-00|
[Layer 2.5] - Stacked MPLS
Selecting MPLS enables MPLS layer for the test. If MPLS is selected MPLS header is inserted after Ethernet header, and higher layer is by default set to IP. PacketCheck™ supports MPLS/IP (i.e., selecting Layer 2.5 as MPLS and Layer3 as IP) only. In this case, IP header will be inserted after MPLS. If None is selected for Layer 2.5, it will be a normal Ethernet packet, without the MPLS header inserted.
[Layer 3] - IP
Here you can configure the source and destination IP addresses. Users can configure various IP header fields like TOS field, TTL field and protocol field.
Build MAC Header Automatically option provided for the user's convenience automatically builds MAC header for Layer 3/ Layer 4 testing.
Increment Identification option may be used to set the initial IP header identification value, which will be automatically incremented for the subsequent packets.
Traffic (Payload) Configuration
Users can choose to insert various types of packets into the stream by enabling the sequence number format, magic pattern, PRBS patterns through predefined files, and user-defined fixed pattern of up to 24 bytes. Payload Transmission types also includes HDL File Transmission, a GL's proprietary Ethernet traffic capture format. In addition, to the captured packet, HDL file format stores additional information about the packet such as timestamp. Using HDL file for transmission allows user to generate various kinds of traffic like IPTV, VoIP etc., using captured traffic.
Layer 1 BER Testing supports only PRBS patterns through predefined files, and user-defined fixed pattern of up to 24 bytes.
Users are allowed to configure Frame size, Bandwidth, Inter Frame Gap (IFG) and transmission stop condition parameters during packet transmission. Users can specify frame size of fixed / random length, and define the transmission rate in Bit per second. The received frame details can be logged into a binary (*.bin), HDL, and also BERT files for each stream, which are used for diagnosis purposes.
Traffic Generation Mode
The HDL file transmission has necessitated PacketCheck™ to operate in 2 different modes. The traffic generation mode is common to all the streams.
- Burst Mode - In this normal mode of operation, traffic is generated in bursts and the configured bandwidth is maintained, ignoring the IFG value. Here, the emphasis is to try and achieve the configured bandwidth for each stream. The resultant Inter Frame Gap varies because of the bursty nature of the traffic.
- IFG Mode - In this Inter Frame Gap mode, traffic is generated frame-by-frame, and the configured IFG is maintained. The configured bandwidth is ignored. Here, the emphasis is on maintaining the IFG value between successive packets for each stream. The actual Bandwidth generated depends on the Frame Size and the configured IFG.
Traffic Generation Mode
Inter Frame Gap (IFG) option emphasizes on maintaining the Inter Frame Gap rather than the bandwidth during traffic generation for HDL files. There are 2 ways to configure Inter Frame Gap for HDL file transmission:
- For "Take from HDL File" option, the timestamps stored within the HDL file is read. The Inter Frame Gap between the packets is computed from these timestamps. This allows the generated traffic to mimic the captured traffic as much as possible.
- User can also configure the "IFG value", during which the timestamps read from the HDL file is ignored and frames are transmitted with this Inter frame Gap.
Mobile GTP Traffic Simulation
Using the “HDL File Playback” feature within PacketCheck™, the packet data can be carried as pre-recorded traffic files (GL's proprietary Ethernet traffic capture format *.HDL files) to destination points and the same can be verified at the receiving end, which can also be a PacketCheck™. This feature can be used GL’s Mobile IP Core traffic module (requires Additional Licenses) to simulate GTP traffic over UMTS or LTE network.
Generally, in an EPC network, are two types of data pipes can be found - Default Bearer (with non-guaranteed QOS) and Dedicated Bearer (with assured guaranteed QOS). The PacketCheck™ can be used with GL’s MAPS™ UMTS / LTE Simulators to encapsulate the generated packet data within GTP headers when transmitting through the gateways such as SGSN & GGSN, or SGW & PGW to verify the bearer allocation bandwidth at the end points. The packet data traffic generated at one end is received at the other end can be verified with various statistics such as packet loss, lost frames, bit error count, Tx Rx frames count and other traffic parameters.
Users can introduce impairments into the outgoing traffic using various impairment types and duration. Supports various types of impairments - DELETE BYTES, INSERT BYTES, AND, OR, & XOR. Impairments can be introduced at specific intervals or can be set to continuous insertion on each stream.
PacketCheck™ can measure One-Way Delay (OWD), calculating the delay at the receiving end in µsec. OWD can only be correctly calculated on a single PC with 2 NICs running PacketCheck™ on each of them. Only a single license needs to be purchased in this scenario. OWD-Tx option embeds Tx Timestamp within a special OWD packet along with the normal stream data. OWD-Rx option receives and detects the special OWD packet.
Also, PacketCheck™ can be configured to measure the average Round Trip Delay [RTD] value of each packet in µsec. RTD is applicable to Tx_RX streams with DUT/ remote end configured in Loopback mode for RTD to work.
While the test is running, users can view statistics for each stream. These include bit error rates, throughput, lost or out of order frames, RTD and OWD.
Stream Specific Statistics:
- Stream ID - ID of the streams as added in the configuration window
- Stream Name - displays the name of the streams specified while adding in the configuration window
- Mode - indicates mode of traffic as specified for each stream during configuration
- Duration - per stream statistics displays the Duration for which the stream is running in "HH:MM:SS" format
- Tx Frames - is the number of frames being transmitted for the stream configured in Tx and Tx_Rx mode
- Tx Rate - gives total data rate at which the frames are being transmitted
- Rx Frames - is the number of frames received for the streams configured in Rx or Tx_Rx mode
- Rx Rate - gives rate at which the data are being received
- Lost Frames - gives the count of total lost frames for that particular stream
- Out Of Order Frames - gives the count of total out of order frames which are received for the particular stream
- Pattern Error Frames - gives the count of total pattern error frames received on that particular stream. This is relevant for Fixed Pattern only
- Good Frames - count of total frames with matching pattern received
- Non-test Frames Received - count of all non test frames received on that stream. A received frame is said to be a non test frame if it does not match the Layer addresses properly
- Bit Error Rate - this is relevant for PRBS patterns only. Displays the calculated Bit Error Rate for the PRBS pattern being received
- Error Status - Status condition displays 3 states - IN_SYNC, NO_SYNC, NO_RX_DATA (when no data is received)
- Sync Loss Count - display the number of time Sync loss has occurred. This is relevant for PRBS patterns only
- Error Count - displays the number of times Error has occurred. This is relevant for PRBS pattern only
- Round Trip Delay (RTD) - provides round trip delay measurement for the stream
- One Way Delay (OWD) - provides one way delay measurement for the stream
- UDP Checksum Statistics - On the receiving side of the statistics window, UDP Checksum Error Frames indicate how many packets are received with wrong UDP Checksum per stream
- Zero Checksum UDP Packet: Total number of UDP packets received with the checksum value ‘Zero’.
- Rx Broadcast Frames – displays the total number Broadcast frames received.
- Rx Unicast Frames – displays the total number Unicast frames received.
- Rx IP Frames – displays the count of received IP frames encapsulated in another IP packet.
- Rx UDP Frames – displays the count of received UDP frames encapsulated in IP packets.
- Rx ICMP Frames – displays the count of received ICMP frames encapsulated in IP packets used in exchanging control messages.
- Rx ARP Frames – displays the count of received ARP (Address Resolution Protocol) frames
- Rx 64 Length Frames – displays the count of frames with 64 bytes length received.
- Rx 65-127 Length Frames - displays the count of frames varying between 65 to 127 bytes length received.
- Rx 128-511 Length Frames - displays the count of frames varying between 128 to 511 bytes length received.
- Rx 512-1023 Length Frames - displays the count of frames varying between 512 to 1023 bytes length received
- Rx 1024-1518 Length Frames - displays the count of frames varying between 1024 to 1518 bytes being received.
PacketCheck™ can generate reports at the end of every test. The reports include statistics, configuration information, NIC details, stream and aggregated statistics, and other test information. Reports can be generated in Portable Document Format (PDF), and Extensible Markup Language (XML) format with customizable headers, footers, comments and logos. User can also generate periodic reports during the test execution.
Command Line Interface (CLI)
PacketCheck™ Command Line Interface (CLI) supports all the functionalities of PacketCheck™ that can be accessed via commands, instead of the GUI. The CLI can be accessed through GL's proprietary WCS (Windows Client Server) architecture, thereby allowing remote execution of commands.
Commands can be customized to implement interactive menu options to run a script file, wait for a reply, generate reports, statistics display, and so on. Clients connect remotely to GL's PacketCheck™ via TCP/IP and perform various functions like Layer 2/3/4 Testing, Impair the traffic on the stream, Transmit PRBS patterns, Monitor performance statistics, Generate test report, and others.
Screen shot of WCS Command Line Interface (CLI)
Start Server Initial Commands are necessarily executed before sending traffic.
WCS Client application use "run task" command to start the server, which informs about the number of NIC cards detected in the system to the client. The client can use "inform task" command to initialize the server with NIC card number.
Once the NIC card is initialized, the client can use "inform task #" command to start the traffic. PacketCheck™ returns all link status and traffic statistics to WCS client as task status information. Client can also stop the traffic after completion of the test and inform to generate reports.
run task "PacketCheckServer:StartServer";
inform task "Init 2;";
inform task "Runscript 0 'Scripts\Layer2_Test.txt' 0.0.0.0;";
inform task "Statistics 0;";
inform task "StopTraffic;";
inform task "GenerateReport pdf 'TestRpt' 'Good Test' 'www.gl.com' 'Copyright' "GL_Logo.JPG' 's1'; ";
Click here to download the sample scripts for Layer 2, Stacked VLAN and MPLS, Layer 3, Layer 4 BERT and Loopback testing
|Item No.||Item Description|
|ETH200||Two PacketCheck™ applications|
* Specifications are subject to change without notice.
Back to VoIP Analysis and Simulation Index Page