PacketCheck™ Software Ver 3.0 is Now Available! Download it
here
Overview |
Main Features |
Ethernet BER Testing |
Configuration Options |
Statistics and Results
Other VoIP Products |
Application Notes |
Buyer's Guide
Overview
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.
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.
Throughput up to 800 Mbps can be easily tested.
|
|
|
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 Byte Error Rate, Total Packets, Packet loss, Out of Sequence Packets, and
Erred Packets. Additional features include transmit HDL file traffic, a new traffic generation mode i.e. the IFG (Inter
Frame Gap). Also included is BER testing capability with provision to generate PRBS patterns or user–defined test
patterns.
PacketCheck™ supports features like transmission of prerecorded file traffic, which can duplicate packet traffic as it occurred at
a particular Ethernet interface. 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 CSV and PDF formats.
PacketCheck™ can operate on any of the layers - Layer 1 (Physical), Layer 2 (Data Link), Layer 3 (Network), and Layer 4
(Transport) of the OSI reference model.
PacketCheck™ at Layer 1 (Physical), Layer 2 (Data Link), Layer 3 (Network),
and Layer 4
(Transport) of OSI model
Applications
- 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
- 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
Main Features:
- PC based Ethernet Tester which can generate/receive Ethernet or IP traffic of up to 800 Mbps bandwidth.
- User Defined test patterns – up to 24 bytes length
- Simulate real-world traffic (such as IPTV, RTP,…) by transmitting pre-captured GL proprietary HDL files
- Capability to generate various per stream Impairments – Insert/Delete Bytes, and Byte Level Impairments (AND, OR, XOR).
- Run time impairments generation of various impairments types like Insert/Delete Bytes, Change Bytes etc
- 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
- Customizable protocol headers like MAC Source/Destination address, Length/Type field, IP Source/destination address, and UDP
Source/Destination Port.
- Full flexibility to control per stream traffic duration
- Monitor performance statistics – throughput, round trip delay (RTD), total packets, packet loss, out of sequence frames, error frames,
correct pattern frames, pattern sync status, byte 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.
- Powerful Report Generation feature to generate reports in CSV / PDF formats which include various test details like Statistics,
Configuration Information, NIC card details information and others.
Ethernet BER Testing
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.
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
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 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).
Configuration Options
Interface Selection and Details
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.
Interface Selection and Details Settings
Parameter 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, Layer 3 IP
settings, Layer 4 UDP settings, Stream Payload, Tx & Rx Parameter Settings, RTD (µsecs), and various impairments settings.
PacketCheck™ is automatically set to Layer 1 BER testing by disabling other layers.
Interface Configuration Settings
Layer – MAC, IP, UDP Parameters
- [Layer 2] - Ethernet
Configure with 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
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 3] - IP
Configure with 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.
- [Layer 4] - UDP
Requires source and destination UDP ports to be defined for Layer 4 testing, which can also be changed as per the
user’s requirements
Layer 2 (MAC) and Layer 3 (IP) Configuration Settings
Payload
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.
Various Source Types for Payload Transmission
Tx & Rx Parameters
Tx Parameter settings are applicable to Tx or Tx and Rx modes. Used to configure Frame size, Bandwidth, Inter Frame
Gap (IFG) and transmission stop condition parameters. Users can specify frame size of fixed / random length, and define
the transmission rate in Bps units. Rx Parameter settings are relevant to Rx and Tx_Rx streams only and allow creation of
log files for each stream. The received frame details can be logged into a binary (*.bin), HDL, and also BERT files, which
are used for diagnosis purposes.
Result Log for Tx and Rx Mode
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 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.
Impairments
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.
Various Impairment Types and Duration Settings
Statistics and Results
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, Byte Error Rate, Error Status,
Sync Loss Count, Error Count, & RTD.
- 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.
- 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.
- Byte Error Rate – this is relevant for PRBS patterns only. Displays the calculated Byte 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
Normal & Loopback Mode Statistics
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.
Sample Script:
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, Layer 3, Layer 4 BERT and Loopback testing
Detail Report Generation (pdf, csv 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 and other test information. Report can be generated in Portable Document Format (PDF), and
Comma Separated Value (CSV) format with customizable headers and footers, and . an option to include test comments with custom
logo in the report.
Report Generation Configuration
Screen Shot of pdf test report
Screen Shot of csv test report
Application Notes
Buyer's Guide:
* Specifications are subject to change without notice.
Back to VoIP Analysis and
Simulation Index Page
![](javascript:myOpen("images/packetcheck-web-pdf-report-file.gif"))
![](javascript:myOpen("images/packetcheck-web-csv-report-file.gif"))
