PacketCheck™ - Software Ethernet/IP Tester

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

Normal Mode

PacketCheck™ offers the flexibility to configure Normal Tx and Rx modes for conducting BER testing across different layers. These layers include Layer 1 (Framed Layer 1), Layer 2 (Framed Ethernet), Layer 2.5 (Stacked MPLS), Stacked VLAN, IP, and UDP.

Normal Mode Configuration Window

Add/Delete/Insert Streams

The configuration window provides Add, Delete, Insert options to operate on the stream instances.

Copy and Paste Streams

Provides options to copy from one stream to another (both one-to-one copy and one-to-many copy) to quickly configure multiple streams.

Start/Stop Streams

Allows users to independently start or stop 'All Tx streams,' 'All Rx streams,' 'All Tx_Rx streams,' and 'All streams,' providing the flexibility to start All Rx streams first, followed by All Tx streams.

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.

Default Stream

Apart from user-configured Ethernet frames, other frames may be sent/received on the NIC card on which PacketCheck™ is running.

PacketCheck – These are Tx or Rx Ethernet frames that match with the PacketCheck streams but do not belong to the actual test traffic.

NIC card – Non-PacketCheck traffic sent/received on the NIC card. This can be other application Tx/Rx traffic and also Broadcast/Multicast frames received from the LAN.

Other Statistics – The traffic sent or received that doesn't belong to either PacketCheck™ or the NIC card can include other application traffic with different MAC/IP addresses. This can occur when two PacketCheck™ applications are running on separate PCs and one mistakenly sends traffic with addresses that don't match any PacketCheck™ streams or NIC card addresses. Thus, it can also be misconfigured incoming test traffic.

Default stream is always a present stream (user need not configure it) in PacketCheck. All the default stream frames (as explained above) are identified, categorized and statistics displayed for user convenience. Users can start/stop the default stream at any time. Additionally, user can record the default stream frames into a PCAP or HDL file. By capturing the traffic from this default stream and saving it in either PCAP or HDL file formats, users can conveniently analyze the non-test traffic by opening the file in Wireshark® or PacketScan™ tools.

Default Stream Configuration

Default Stream Statistics pane displays the categorized statistics for both Tx and Rx.

Default Stream Statistics

Capture Traffic

Provides options to record the user defined stream’s traffic to a PCAP (Wireshark®) or HDL (GL Proprietary) file format and playback the pre-recorded traffic from a PCAP (Wireshark®) or HDL (GL Proprietary) file format.

Capture Traffic

Playback from File

This option allows users to specify a source file for the stream, this source file can be PCAP or HDL file format. The packets are read from the specified file and the packets are transmitted sequentially. User has option to transmit the file continuously or stop at the end of file or after N number of frames or after specified duration in seconds.

In File based option the default mode is set to Tx and all the other configurations will be disabled as it is not required in File Based option. Select the HDL or PCAP file format as recorded and choose the file name to transmit the traffic.

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 EtherType field value. Users can enable VLAN up to 3 stacks and configure with the headers.

The following table gives the Field values for the configured Layers (2/3/4)

Traffic (Payload) Configuration

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.

Delay Measurements

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.

OWD Measurement on Single PC

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.

RTD Measurement

OWD and RTD provides user configurable frame length (for the special frames that are sent/received to measure OWD and RTD), minimum frame length, maximum frame length or define any value within the allowed range.

Impairments

The following Impairment types are supported in PacketCheck™:

• Delete bytes: Deletes ‘X’ number of bytes at specified offset for every ‘Y’ packets sent out for the stream. Repeat this for limited number of times or repeat continuously.
  
  E.g : 20 bytes being deleted from every 11th frame sent at an offset of 18 bytes which will be repeated 500 times

• Insert bytes: Insert ‘X’ number of bytes at specified offset for every ‘Y’ packets sent out for the stream. Repeat this for limited number of times or repeat continuously.
  
  E.g.: “ABCD” being inserted within the frame at an offset of 14 bytes in every alternate frame, which will be repeated 500 times

• Logical AND: Modify a byte at specified offset for every ‘Y’ packets sent out for the stream. Modification is done by doing logical AND with the user specified Hex byte. Repeat this for limited number of times or repeat continuously
  
  E.g.: 56TH byte of every 17th frame being ANDed with 00 which will be repeated 20 times

• Logical OR: Modify a byte at specified offset for every ‘Y’ packets sent out for the stream. Modification is done by doing logical OR with the user specified Hex byte. Repeat this for limited number of times or repeat continuously
  
  E.g.: 21st byte of every 6th frame being ORed with FF which will be repeated continuously

• Logical XOR: Modify a byte at specified offset for every ‘Y’ packets sent out for the stream. Modification is done by doing logical XOR with the user specified Hex byte. Repeat this for limited number of times or repeat continuously.
  
  E.g.: 36th byte of every 22nd frame being XORed with 55 which will be repeated 30 times