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 very easy to use as a general purpose network performance analysis tool for 10Mbps, 100Mbps and 1Gbps LANs and WANs. Throughput up to 800 Mbps can be easily tested.
The application truly takes confusion out of Ethernet testing at all protocol layers - from raw Ethernet frames to IP/UDP packets. 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 any of the layers - 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 IP bandwidth consumption, throughput, errors rates in a LAN / WAN
- Determine Round Trip Delay (RTD) between two IP address or two Ethernet MAC addresses with microsecond accuracy
- Determine One Way Delay (OWD) between two NIC cards with microseconds accuracy
- Testing LAN Data Switch for dropped packets, errors, overload, and so on
- Detection of traffic overload
- Testing network behavior with real world traffic like IPTV, VoIP and more
- Test CAT 6 / CAT 5 cables for efficiency
- Capability to test Ethernet or IP traffic of up to 800 Mbps bandwidth.
- Generates full duplex IP, UDP, or Ethernet frame traffic to transmit and/or receive traffic on any of the four layers (Layer1, Data Link with stacked VLAN/ MPLS, Network, Transport) with on-demand bandwidth
- Multi-stream traffic generation for each stream including different frame size, bandwidth, MAC, MPLS, IP and UDP parameters, payload, and mode of operation (Tx only /Rx only /TxRx only) etc.
- 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)
- Capability to generate various run-time impairments – Insert/Delete Bytes, and Byte Level Impairments (AND, OR, XOR).
- Capability to generate/respond to ARP requests, making it easy to work with Routers
- Jumbo frames are supported, in addition to all normal frame sizes from 64 bytes to 1518 bytes
- Full flexibility to control and monitor per stream traffic duration
- Capability to generate common and stream specific statistics providing traffic monitor on the NIC.
- Monitor performance per stream statistics – throughput, time duration for the traffic sent/received, 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.
- Command Line Interface (CLI) allowing remote execution of commands for all functionalities through GL's proprietary WCS (Windows Client Server) architecture.
- Report Generation in both XML/ PDF formats for the completed test or periodic report for the test.
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 abbreviated as "PHY" is the only layer over OSI model where data is physically moved across the network interface. At Layer1 cables, hubs and repeaters are used as physical devices to transmit data across the media.
PacketCheck™ configuration for Layer1 BER Testing is as depicted below, can test the basic packet flow over physical connection. Connect the two test PCs present at the same location using 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 network interface cards as DUT. The bridges, switches, and network interface cards (NIC) work at Layer 2 (Data Link) and handle physical addressing, packing data into frames, and sequencing data frames. The Layer 2 consists of Logical Link Control (LLC) and Media Access Control (MAC) sub-layers, which route the packets based on the MAC address. So, only the MAC addresses need to be configured for layer 2 testing.
GL's PacketCheck™, in the configuration depicted below, can test the basic packet flow over the network. This test is performed in order to
- Test the capability of the switch to handle the MAC frames at various bandwidths
- Test the forwarding capacity of the switch (based on the MAC addresses)
- 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 can be used to simulate the Carrier Ethernet condition shown in the figure, where SP VLAN ID is stacked on top of CE VLAN ID.
Stacked VLAN simulating Carrier Ethernet
At Stacked MPLS LayerStacked MPLS (up to 3 levels) is supported. Various combinations tests such as single MPLS, multiple MPLS, VLAN + MPLS can be tested for both 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
The test setup for Layer 4 is similar to test setup for Layer 3, as UDP is carried on IP. At Layer 4, proper UDP packets are sent (instead of raw IP packets as in the case of Layer 3 testing). The testing at Layer 4 (UDP) is useful in cases where there are firewalls in the network, which typically intervene at network boundaries and handle/modify packets at Layer 4 (TCP/UDP).
Modes of Operation
The MAC address and IP address of the available network cards in a PC is automatically displayed using I/F (Interface) selection option in the GUI. PacketCheck™ can be configured in Normal or Loopback mode.
- In "Normal" mode, application can be configured to perform "Tx" | "Rx" | "Tx and Rx" on multiple streams or a single stream.
- In "Loopback" mode the packets (layer2/3/4) received from a device (DUT) are transmitted back to the same device without any modifications of the pattern. This mode is preferably used for RTD measurement over supported layers.
Interface Selection and Details Settings
MAC, MPLS, IP, UDP Layer-wise Parameters Configuration
Various test parameters can be configured for all the PCs connected to DUTs before starting the test using the Configuration GUI window. Some key parameters include – Layer/Direction selection, Layer 2 MAC settings, Stacked VLAN, Layer 2.5 Stacked MPLS settings, Layer 3 IP settings, Layer 4 UDP settings, Stream Payload, Tx & Rx Parameter Settings, Delay Measurements (RTD and OWD) in µsecs, and various impairments settings. PacketCheck™ is automatically set to Layer 1 BER testing by disabling other layers.
Interface Configuration Settings
[Layer 2] - Ethernet
In this layer, you can configure PacketCheck™ with the source and destination MAC Addresses (6 byte hex format). The source address can be automatically fetched from the PacketCheck™ application, while the destination MAC address can be obtained using 'Resolve IP to MAC' feature. In addition, user can specify the Length/Type field value. Users can enable VLAN upto 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
In this layer, you can configure PacketCheck™ with the source and destination IP Addresses. The source address can be automatically fetched from the PacketCheck™ application. Users can define destination IP address and 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 SimulationUsing 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 be configured to measure One-Way Delay (OWD), calculating the delay at the receiving end in µsec. One Way Delay [OWD] can be correctly calculated only on a single PC with 2 NIC cards running PacketCheck™ on each of them. 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.
Once the test is started, users can view various statistics and measurements performed for the configured streams. Some parameters displayed include Stream ID, Stream Name, Mode, Tx/Rx Frames, Tx/Rx Rate, Lost Frames, Out Of Order Frames, Frames Dropped, Pattern Error Frames, Good Frames, Non-test Frames Received, Bit Error Rate, Error Status, Sync Loss Count, Error Count, RTD & 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.
Detail Report Generation (pdf, xml file formats)
PacketCheck™ has the capability to generate report at the end of every test. Generates test reports including Statistics, Configuration Information, NIC card details Stream Statistics, Common Statistics, VLAN, MPLS, and other test information. Report can be generated in Portable Document Format (PDF), and Extensible Markup Language (XML) format with customizable headers and footers, and an option to include test comments with custom logo in the report. The Periodic Reports option enables the users to generate the test reports for a consecutive time period for the selected stream during the test.
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|
|GTP Mobile Traffic Options|
|ETH101||Mobile Traffic Core – GTP|
|ETH102||Mobile Traffic Core - Gateway|
|ETH103||Mobile Traffic Core - Gb|
|PXG101||PacketExpert™ 10G with Tablet|
|PKS100||PacketGen™ (includes PacketScan™)|
|PKV100||PacketScan™ (Online and Offline)|
|IPN506||IPNetSim™ Option for PXG100 (1G and 10G)|
|IPN507||IPNetSim™ Option for PXN100 (1G and 10G)|
|IPN505||IPNetSim™ 1G Tablet (* Coming Soon)|
||IPNetSim™ Handheld (* Coming Soon)
|IPN702||Remote Option (* Coming Soon)|
MAPS™ SIP Emulator
MAPS™ SIP Conformance Test Suite (Test Scripts)
MAPS™ MEGACO Emulator
MAPS™ MEGACO Conformance Test Suite (Test Scripts)
MAPS™ MGCP Emulator
MAPS™ SIGTRAN Emulator
* Specifications are subject to change without notice.