Debugging RTL problems using the BreakingPoint Elite

I am an RTL designer that found my home at BreakingPoint doing Hardware design.  After the initial checkout of our 8 port, 1Gig blades for the BreakingPoint Elite chassis, I moved over to our software team to work on some of the lower layer code, such as our phy drivers, and really get the 1Gig board up and running enough for our network processor designers to start running some real traffic on these boards.

Having valuable experiance in FPGA design, board design, and now even software design, I thought I would share an RTL debug experience that may hopefully give your RTL designers some food for thought.

When debugging an RTL problem, there are 2 big steps in getting to a solution; recreate the problem in the lab, and ultimately recreating the problem in simulation.  Once we can recreate the problem in a simulation, it almost always becomes a mere matter of implementation from that point. We can make the changes in the Verilog, rerun simulations to verify the fix, rerun regression simulations, and finally head back to synthesis. 

Recently, one of our FPGA designers was tracking down an issue which we were able to catch in the PCAP files, but we were having trouble triggering on the error with a Logic Analyzer. So, the thought occurred to me: what if we were able to take the traffic we captured and play it back directly into the FPGA simulation?

In the following example I will show how we were able to do just that.

Lets say you are in the lab running a "Session Sender" test with "Stack Scrambler" enabled, and you find that you are dropping sessions.  You can export a PCAP from BreakingPoint Elite to see the traffic generated:

Click on Image for Full View

This test generated more then 700MBytes of Egress traffic.  I am going to skip over the first 1000 frames, and export the next 200 frames.  I want to grab the Transmit data only, because at this point, I am only interested in seeing the traffic that was sent into the DUT (read more on traffic filtering):

Click on Image for Full View

Here is a quick look at the traffic in Wireshark:

Click on Image for Full View

Now we can see the traffic that was generated by the Session Sender and Stack Scrambler.  This is great, but what I really wanted to do was inject this traffic directly into an FPGA simulation.  There are many different ways to accomplish this:

1. I could write Verilog models that were capable of reading a PCAP file directly.
2. I could write some C application that could read the PCAP file and translate it into a vector file more easily read by Verilog.
3. I could use the Verilog Programming Language Interface (PLI) to execute some C code for reading the PCAP.

The task of reading a PCAP file seemed like something that would be much more easily done in a software language like C, especially considering I would have access to libpcap which already has everything I need to read PCAP files. Although I had never used PLI before, I did a little web research and found a few examples to get me started in the right direction.  If you are a SystemVerilog user, I would recommend you also look into the Direct Programming Interface (DPI).

If you have never seen or used PLI before, it essentially provides a method of calling C functions from a Verilog simulation, and allows passing signals into and out of the C code. The signal will get translated to an integer or real value in the C code.  You will typically have a C function that you call from the Verilog, which will initialize all of your data in the C environment.  In that initialization function, you can configure other functions to be called on signal events. In my case, I used a Verilog module to generate my XGMII clocks, and resets.  I call my PLI initialization function and pass it my XGMII clock, reset signal, XGMII data bus, and XGMII command bus. The C code sets up pointers to each of these signals and configures a function to call on each transition of my XGMII clock.  

You may note that I also pass in a boolean value that tells me whether play back is fast mode, or real time mode. This allows me to skip all of the timestamps in the PCAP file and play the packets back to back as quickly as possible, or to use the timestamps to help recreate the actual timing of the packets.

Here is an example of my PLI initialization code:

  struct pli_play_data {
      wtap *pcap;
      char *tfinst_p;
      char filename[512];
      frame_info_t fi;
      int64_t time_ref;
      uint32_t pktptr;
      uint32_t pktcount;
      uint8_t  fast_play;
      uint8_t  ipg_bits;
      eth_play_states state;
      handle eth_clk;
      handle eth_data;
      handle eth_cmd;
      handle reset_n;
      uint32_t last_reset_n;
      handle pcap_done;
  };
  
  static PLI_INT32 pli_pcap_playback() {
      struct pli_play_data *pcap_data;
      acc_initialize();
  
      //allocate memory for this instance of playback
      //we may be playing multiple PCAPs back in the same
      //simulation, so we need to be sure the data is kept
      //seperated.
      pcap_data = malloc(sizeof(struct pli_play_data));
  
      //Get handles to the Verilog signals
      pcap_data->eth_clk = acc_handle_tfarg(PLI_CLK);       // XGMII clock
      pcap_data->eth_cmd = acc_handle_tfarg(PLI_COMMAND);   // XGMII Command
      pcap_data->eth_data = acc_handle_tfarg(PLI_DATA);     // XGMII data
      pcap_data->reset_n  = acc_handle_tfarg(PLI_RST_N);    // Reset
      //store the previous value of reset so we can detect rising or falling edges
      pcap_data->last_reset_n = pli_get_uint32(pcap_data->reset_n);
                          
      // this is a status signal driven from the C code to tell Verilog that
      // playback is finished.
      pcap_data->pcap_done = acc_handle_tfarg(PLI_PCAP_DONE);
      pli_set_signal(pcap_data->pcap_done, 0);  // set signal low

      // Boolean value to tell us whether to play the PCAP back at full speed or
      // to obey the timestamps in the PCAP file.
      pcap_data->fast_play = pli_get_uint32(acc_handle_tfarg(PLI_FAST_PLAY));
      if (pcap_data->fast_play)
          printf("Using fast play\n");
      else
          printf("Play at normal speed\n");
      
      // Set the initial state of the Playback State machine.  This is a
      // state machine in the PCAP playback C code.
      pcap_data->state = PLAY_IDLE;

      // Get the PCAP filename and open it.
      strncpy(pcap_data->filename, tf_strgetp(PLI_FILENAME, 'b'), 512);
      pcap_data->pcap = pc_pcap_open(pcap_data->filename);

      // call the function "pli_play_data" on every edge of the XGMII clock signal
      acc_vcl_add(pcap_data->eth_clk, pli_play_data, (PLI_BYTE8 *)pcap_data, vcl_verilog_logic);

      acc_close();
      return 0;
  }

Many of the examples I found on the web used global variables for data storage.  This does not work if you plan to playback multiple PCAP files in the same simulation. So, instead I reallocate memory for all of my pcap_data structure each time I call the initializer. Then I pass that data to my worker function in the line:

        acc_vcl_add(pcap_data->eth_clk, pli_play_data, (PLI_BYTE8 *)pcap_data, vcl_verilog_logic);

Here is an example of the Verilog code to call this function:

       reg pcap_cap_done;
       parameter FAST_PLAY = 1;  // play back capture file as fast as possible
       parameter REAL_PLAY = 0;  // play back capture file using timestamps in pcap file
      
       $pli_pcap_playback ("export.pcap",         // input playback pcap filename
                          pcap_sim_TB.XGMII_1_RX_CLK, // input  Ethernet Transmit clock
                          pcap_sim_TB.XGMII_1_RXC,    // output Ethernet Command [3:0]
                          pcap_sim_TB.XGMII_1_RXD,    // output Ethernet Data [31:0]
                          pcap_sim_TB.pcap_play_done, // output indicates pcap playback completed
                          pcap_sim_TB.RST_N,          // input active low reset
                          REAL_PLAY                   // input fast play boolean
                          );

This gets us all set up to do the playback.  The real heavy lifting is done inside of the function "pli_play_data".   Here is an abbreviated version of that file (some details removed for space):

  static PLI_INT32 pli_play_data(p_vc_record vc_record) {
      int32_t sim_time_low;
      int32_t sim_time_high;
      int64_t sim_time;
      uint32_t txc, txd;

      struct pli_play_data *pcap_data;
      acc_initialize();
      pcap_data = (struct pli_play_data*)vc_record->user_data;

      sim_time_low = tf_getlongtime(&sim_time_high);
      sim_time = ((int64_t)sim_time_high << 32) + (int64_t)sim_time_low;

      switch (pcap_data->state) {
          case PLAY_IDLE:
              int64_t check_time = sim_time - pcap_data->time_ref;
              if ((check_time >= pcap_data->fi.tstamp) || pcap_data->fast_play) {
                  #ifdef DEBUG
                  printf("%lu: sending packet %d with tstamp %lu\n", sim_time,
                      pcap_data->pktcount, pcap_data->fi.tstamp);
                  #endif
                  pcap_data->state = PLAY_PREAMBLE1;
              }
              pcap_data->pktptr = 0;
              pli_set_signal(pcap_data->eth_data, 0x07070707);
              pli_set_signal(pcap_data->eth_cmd, 0xf);
              break;

          case PLAY_PREAMBLE1:
              pli_set_signal(pcap_data->eth_data, 0x555555fb);
              pli_set_signal(pcap_data->eth_cmd, 0x1);
              pcap_data->state = PLAY_PREAMBLE2;
              break;

          case PLAY_PREAMBLE2:
              pli_set_signal(pcap_data->eth_data, 0xd5555555);
              pli_set_signal(pcap_data->eth_cmd, 0x0);
              pcap_data->state = PLAY_SEND_PKT;
              break;

          case PLAY_SEND_PKT:
              txd = pcap_data->fi.framedata[pcap_data->pktptr];
              if (pcap_data->fi.bytecnt >= 4) {
                  txc = 0x0;
                  pcap_data->fi.bytecnt -= 4;
              } else {
                  switch (pcap_data->fi.bytecnt) {
                      case 3:
                          txc = 0x8;
                          txd &= 0x00FFFFFF;
                          txd |= 0xfd000000;
                          break;
                      case 2:
                          txc = 0xC;
                          txd &= 0x0000FFFF;
                          txd |= 0x07fd0000;
                          break;
                      case 1:
                          txc = 0xE;
                          txd &= 0x000000FF;
                          txd |= 0x0707fd00;
                          break;
                      case 0:
                          txc = 0xF;
                          txd = 0x070707fd;
                          break;
                  }
                  pc_read_next_packet(pcap_data->pcap, &pcap_data->fi);
                  pcap_data->pktcount++;
                  pcap_data->state = PLAY_IDLE;
              }
              pli_set_signal(pcap_data->eth_data, txd);
              pli_set_signal(pcap_data->eth_cmd, txc);
              pcap_data->pktptr++;
              break;
          case PLAY_DONE:
     &nbsp;        pli_set_signal(pcap_data->eth_data, 0x07070707);
              pli_set_signal(pcap_data->eth_cmd, 0xf);
              break;
      }
      pcap_data->last_reset_n = reset_n;
      acc_close();
      return 0;
  }

Here are the results of playing our PCAP file back into the Verilog simulation.

This screenshot shows the beginning of the first packet. Compare to the Wireshark screen shot above:

Click on Image for Full View

This screen shot shows the end of the first packet, some interpacket gap, and the 2nd packet beginning with the preamble.  In this simulation, I have chosen to run in FAST PLAY mode, so the packets are sent back to back without using the timestamps in the PCAP file:

Click on Image for Full View

After getting the PCAP data into the simulation, it only seemed logical that we capture the simulation output to a PCAP file as well.  Using very similar code this was quite trivial to implement.  Here is a screenshot of Wireshark showing the simulation output:

Click on Image for Full View

This is a good example of how to integrate real world data, using a C application, into a Verilog simulation. If you are looking to implement something similar in your test environment, I would also recommend that you consider using wiretap instead of libpcap for your backend.  Wiretap is distributed as part of the Wireshark package, and is a libpcap replacement. Wiretap has the advantage of being able to read many more PCAP file formats than libpcap, including PCAP files with nano second timestamps.

Unfortunately, most of the really good information on PLI is only available in hardcopy books.  However, you can find some decent information if you search hard enough.  The following links are a good starting point for designing with PLI:

• Asic-World PLI Information There are some PLI examples here, but this site is most useful for its instructions on compiling PLI code into different simulators.
• Aldec VHPI Tutorial This is a tutorial for using the VHDL PLI interface called VHPI.

Get Creative with Capture and Recreate when Testing Network Equipment

In my last blog post, I discussed several new Recreate features, some we just announced today. I am going to back things up a bit and explain some of Recreate's internals. Hopefully, armed with some insight into the inner workings of Recreate, it will help you to creatively evaluate and/or test your networking equipment.

Recreate's primary purpose is to allow the end user to import libpcap formatted network traffic files obtained from tools such as tcpdump and wireshark

When I was an IPS developer, I relied heavily on packet captures for various day-to-day tasks such as:

• Testing the accuracy of protocol decoding engines using different operations within the protocol from different vendors and/or implementations of the protocol.
• Testing the detection capability of security signatures.
• Testing the performance of the protocol decoding engines.
• Looping complicated traffic continuously to test for memory leaks.
• Fixing and validating bugs; a reproduceable bug in a packet capture was always a godsend.

All BreakingPoint users are obviously not IPS developers, but Recreate can perform valuable tasks that are similar to the testing needs from my past life. The test criteria for DUTs such as routers, switches, firewalls, IDS/IPS, load balancers, etc. should be similar. 

These pcap files can be obtained from customers, developers, QA, field engineers, security signatures writers, etc. They may contain varying amounts of actual client/server traffic or packets created and/or modified by various tools such as scapy, netdude, tcprewrite, hping, and nemesis.

Importing Packet Capture Files

When a pcap is imported into Recreate, the original pcap file is saved for raw playback mode.

• Recreate's Ramp Parameters control the number and rate of sessions and how they are started, maintained, and closed.
• Sessions Parameters control minimum and maximum simultaneous sessions and test criteria target values.
• The IPv4 and TCP Parameters can be altered to adjust the characteristics of the flows within the test.
• The Data Rate parameters control minimum and maximum data rates.

Multiple Recreate Test components can be run simultaneously or mixed in with other test components and run simultaneously through the device under test (DUT) on different interfaces.

Since pcap formatted files are more familiar to everyone and we store this information internally a little different, I will discuss pcap files first.

TCPDUMP Captures and Replay Capture File without Modification Mode

Below is an example of a tcpdump capture. This information would be replayed exactly "as-is" in raw playback mode. It should be noted that the const struct pcap_pkthdr contains timing information that Recreate honors if the General Behavior Parameter Value is set to Use Capture File settings. Recreate will also not import packet captures if the number of bytes on the wire was more than the number of bytes captured. If using tcpdump, set the snaplen to capture the whole packet by passing the parameter -s 0 

The Modification Options affect how the raw playback mode retransmits the pcap in its entirety. The BPF filter string allows you to only send traffic that matches your BPF filter without modifying the pcap on disk. The pcap can be replayed over and over again by setting loop count to a number greater than 1. The Session Ramp, Session Configuration, IPv4, TCP, and Data Rate parameters are ignored in raw playback mode. While this mode cannot send packets nearly as fast as normal mode, it is valuable for testing L2, L3, and L4 header issues that cannot be easily tested in normal mode.

Examining a TCPDUMP packet capture file in detail

Let's examine the beginning of a single HTTP session in tcpdump.

Below we see the TCP three-way handshake and an HTTP GET request to www.google.com.

$ tcpdump -Xvvv -r bpt2.pcap "tcp port 80" | more 
10:14:37.567201 IP (tos 0x0, ttl 64, id 39249, offset 0, 
flags [DF], proto TCP (6),
length 60) 10.10.10.42.46340 > yx-in-f104.google.com.http: 
S, cksum 0xd303 (correct), 974896626:974896626(0) win 5840 
<mss 1460,sackOK,timestamp 99
2419 0,nop,wscale 6>
   0x0000:  4500 003c 9951 4000 4006 1552 0a0a 0a2a  E..<.Q@.@..R...*
   0x0010:  4a7d 2d68 b504 0050 3a1b bdf2 0000 0000  J}-h...P:.......
   0x0020:  a002 16d0 d303 0000 0204 05b4 0402 080a  ................
   0x0030:  000f 24a3 0000 0000 0103 0306            ..$.........
10:14:37.600386 IP (tos 0x0, ttl 55, id 22877, offset 0, flags [none], proto
TCP (6), length 60) yx-in-f104.google.com.http > 10.10.10.42.46340: S, cksum
0x3946 (correct), 1132689922:1132689922(0) ack 974896627 win 5672 <mss 1430,s
ackOK,timestamp 3090949296 992419,nop,wscale 6>
   0x0000:  4500 003c 595d 0000 3706 9e46 4a7d 2d68  E..<Y]..7..FJ}-h
   0x0010:  0a0a 0a2a 0050 b504 4383 7a02 3a1b bdf3  ...*.P..C.z.:...
   0x0020:  a012 1628 3946 0000 0204 0596 0402 080a  ...(9F..........
   0x0030:  b83c 24b0 000f 24a3 0103 0306            .<$...$.....
10:14:37.600432 IP (tos 0x0, ttl 64, id 39250, offset 0, flags [DF], proto TC
P (6), length 52) 10.10.10.42.46340 > yx-in-f104.google.com.http: ., cksum 0x
7d9e (correct), 1:1(0) ack 1 win 92 <nop,nop,timestamp 992452 3090949296>
   0x0000:  4500 0034 9952 4000 4006 1559 0a0a 0a2a  E..4.R@.@..Y...*
   0x0010:  4a7d 2d68 b504 0050 3a1b bdf3 4383 7a03  J}-h...P:...C.z.
   0x0020:  8010 005c 7d9e 0000 0101 080a 000f 24c4  ...\}.........$.
   0x0030:  b83c 24b0                                .<$.
10:14:37.600515 IP (tos 0x0, ttl 64, id 39251, offset 0, flags [DF], proto TCP (6),
length 671) 10.10.10.42.46340 > yx-in-f104.google.com.http: P, cksum 0x5bc3 (correct),
1:620(619) ack 1 win 92 <nop,nop,timestamp 992452 3090949296>
0x0000:  4500 029f 9953 4000 4006 12ed 0a0a 0a2a  E....S@.@......*   
   0x0010:  4a7d 2d68 b504 0050 3a1b bdf3 4383 7a03  J}-h...P:...C.z.   
   0x0020:  8018 005c 5bc3 0000 0101 080a 000f 24c4  ...\[.........$.   
   0x0030:  b83c 24b0 4745 5420 2f20 4854 5450 2f31  .<$.GET./.HTTP/1   
   0x0040:  2e31 0d0a 486f 7374 3a20 7777 772e 676f  .1..Host:.www.go   
   0x0050:  6f67 6c65 2e63 6f6d 0d0a 5573 6572 2d41  ogle.com..User-A   
   0x0060:  6765 6e74 3a20 4d6f 7a69 6c6c 612f 352e  gent:.Mozilla/5.   
   0x0070:  3020 2858 3131 3b20 553b 204c 696e 7578  0.(X11;.U;.Linux   
   0x0080:  2069 3638 363b 2065 6e2d 5553 3b20 7276  .i686;.en-US;.rv   
   0x0090:  3a31 2e39 2e31 2920 4765 636b 6f2f 3230  :1.9.1).Gecko/20   
   0x00a0:  3039 3036 3330 2046 6564 6f72 612f 332e  090630.Fedora/3.   
   0x00b0:  352d 312e 6663 3131 2046 6972 6566 6f78  5-1.fc11.Firefox   
   0x00c0:  2f33 2e35 0d0a 4163 6365 7074 3a20 7465  /3.5..Accept:.te   
   0x00d0:  7874 2f68 746d 6c2c 6170 706c 6963 6174  xt/html,applicat   
   0x00e0:  696f 6e2f 7868 746d 6c2b 786d 6c2c 6170  ion/xhtml+xml,ap   
   0x00f0:  706c 6963 6174 696f 6e2f 786d 6c3b 713d  plication/xml;q=   
   0x0100:  302e 392c 2a2f 2a3b 713d 302e 380d 0a41  0.9,*/*;q=0.8..A   
   0x0110:  6363 6570 742d 4c61 6e67 7561 6765 3a20  ccept-Language:.   
   0x0120:  656e 2d75 732c 656e 3b71 3d30 2e35 0d0a  en-us,en;q=0.5..   
   0x0130:  4163 6365 7074 2d45 6e63 6f64 696e 673a  Accept-Encoding:   
   0x0140:  2067 7a69 702c 6465 666c 6174 650d 0a41  .gzip,deflate..A   
   0x0150:  6363 6570 742d 4368 6172 7365 743a 2049  ccept-Charset:.I   
   0x0160:  534f 2d38 3835 392d 312c 7574 662d 383b  SO-8859-1,utf-8;   
   0x0170:  713d 302e 372c 2a3b 713d 302e 370d 0a4b  q=0.7,*;q=0.7..K   
   0x0180:  6565 702d 416c 6976 653a 2033 3030 0d0a  eep-Alive:.300..   
   0x0190:  436f 6e6e 6563 7469 6f6e 3a20 6b65 6570  Connection:.keep   
   0x01a0:  2d61 6c69 7665 0d0a 436f 6f6b 6965 3a20  -alive..Cookie:.   
   0x01b0:  5052 4546 3d49 443d 6461 6230 3736 3834  PREF=ID=dab07684   
   0x01c0:  3433 3630 3861 6530 3a55 3d32 3233 3565  43608ae0:U=2235e   
   0x01d0:  6434 3334 3338 3835 6464 653a 544d 3d31  d4343885dde:TM=1
   0x01e0:  3234 3736 3730 3236 383a 4c4d 3d31 3234  247670268:LM=124
   0x01f0:  3736 3730 3330 373a 533d 7032 7879 3235  7670307:S=p2xy25
   0x0200:  486c 6474 7871 4f76 7558 3b20 4e49 443d  HldtxqOvuX;.NID=
   0x0210:  3234 3d64 4170 5869 6574 7438 6837 3173  24=dApXiett8h71s
   0x0220:  4759 6448 3832 7861 4b50 5565 7534 5a44  GYdH82xaKPUeu4ZD
   0x0230:  6d2d 6b69 4e70 4b32 4467 4868 5275 356a  m-kiNpK2DgHhRu5j
   0x0240:  3169 484a 7945 4d67 5341 5635 3537 4173  1iHJyEMgSAV557As
   0x0250:  504d 735f 5979 4a65 4c57 4f7a 7032 4f53  PMs_YyJeLWOzp2OS
   0x0260:  6458 3562 4255 7353 494e 776b 626c 7663  dX5bBUsSINwkblvc
   0x0270:  5149 4566 614d 5949 5454 6d37 5347 3339  QIEfaMYITTm7SG39
   0x0280:  7a73 6c4e 7032 6445 7871 5a37 5751 2d46  zslNp2dExqZ7WQ-F
   0x0290:  724d 5a3b 2054 5a3d 3330 300d 0a0d 0a    rMZ;.TZ=300....

Import the above pcap file into Recreate

Examining a Recreate packet capture file in detail

Behind the scenes, two things happen. First, the original pcap file is copied to the BreakingPoint Elite. Second, a directory structure is created that sorts the capture file into protocols. The protocols are identified first, via regular expressions; if there are no matches, IANA well known port assignments are used. Within each protocol directory, we store files that contain information about a flow.A flow is defined as having matching source and destination IPv4 or IPv6 addresses and matching source and destination TCP or UDP ports. Our network processor then uses the information contained within these files, along with the Recreate Parameters and the Network Neighborhood settings, to recreate the network traffic for your tests.

Here is the identical flow as seen in the above example, although in our internal format. As you can see, we only store the minimum amount of Layer 3 information.  The IP addresses and Port numbers are used to identify the individual flows and are rewritten according to the Network Neighborhood settings. The file also stores the Ethernet Type (Layer 2 information), the IP Protocol, the direction Client or Server, and the TCP flags if applicable.

flow 0: reqs: ***DP  flags: 0x08 eth_type: 0x0800, ip_p: 0x06 10.10.10.42 46340 > 74.125.45.104 80
flow 0: buffer: C->S 619 bytes, flags: 0x04 NoT
[0000]   47 45 54 20 2F 20 48 54   54 50 2F 31 2E 31 0D 0A   GET...HT TP.1.1..
[0010]   48 6F 73 74 3A 20 77 77   77 2E 67 6F 6F 67 6C 65   Host..ww w.google
[0020]   2E 63 6F 6D 0D 0A 55 73   65 72 2D 41 67 65 6E 74   .com..Us er.Agent
[0030]   3A 20 4D 6F 7A 69 6C 6C   61 2F 35 2E 30 20 28 58   ..Mozill a.5.0..X
[0040]   31 31 3B 20 55 3B 20 4C   69 6E 75 78 20 69 36 38   11..U..L inux.i68
[0050]   36 3B 20 65 6E 2D 55 53   3B 20 72 76 3A 31 2E 39   6..en.US ..rv.1.9
[0060]   2E 31 29 20 47 65 63 6B   6F 2F 32 30 30 39 30 36   .1..Geck o.200906
[0070]   33 30 20 46 65 64 6F 72   61 2F 33 2E 35 2D 31 2E   30.Fedor a.3.5.1.
[0080]   66 63 31 31 20 46 69 72   65 66 6F 78 2F 33 2E 35   fc11.Fir efox.3.5
[0090]   0D 0A 41 63 63 65 70 74   3A 20 74 65 78 74 2F 68   ..Accept ..text.h
[00a0]   74 6D 6C 2C 61 70 70 6C   69 63 61 74 69 6F 6E 2F   tml.appl ication.
[00b0]   78 68 74 6D 6C 2B 78 6D   6C 2C 61 70 70 6C 69 63   xhtml.xm l.applic
[00c0]   61 74 69 6F 6E 2F 78 6D   6C 3B 71 3D 30 2E 39 2C   ation.xm l.q.0.9.
[00d0]   2A 2F 2A 3B 71 3D 30 2E   38 0D 0A 41 63 63 65 70   ....q.0. 8..Accep
[00e0]   74 2D 4C 61 6E 67 75 61   67 65 3A 20 65 6E 2D 75   t.Langua ge..en.u
[00f0]   73 2C 65 6E 3B 71 3D 30   2E 35 0D 0A 41 63 63 65   s.en.q.0 .5..Acce
[0100]   70 74 2D 45 6E 63 6F 64   69 6E 67 3A 20 67 7A 69   pt.Encod ing..gzi
[0110]   70 2C 64 65 66 6C 61 74   65 0D 0A 41 63 63 65 70   p.deflat e..Accep
[0120]   74 2D 43 68 61 72 73 65   74 3A 20 49 53 4F 2D 38   t.Charse t..ISO.8
[0130]   38 35 39 2D 31 2C 75 74   66 2D 38 3B 71 3D 30 2E   859.1.ut f.8.q.0.
[0140]   37 2C 2A 3B 71 3D 30 2E   37 0D 0A 4B 65 65 70 2D   7...q.0. 7..Keep.
[0150]   41 6C 69 76 65 3A 20 33   30 30 0D 0A 43 6F 6E 6E   Alive..3 00..Conn
[0160]   65 63 74 69 6F 6E 3A 20   6B 65 65 70 2D 61 6C 69   ection.. keep.ali
[0170]   76 65 0D 0A 43 6F 6F 6B   69 65 3A 20 50 52 45 46   ve..Cook ie..PREF
[0180]   3D 49 44 3D 64 61 62 30   37 36 38 34 34 33 36 30   .ID.dab0 76844360
[0190]   38 61 65 30 3A 55 3D 32   32 33 35 65 64 34 33 34   8ae0.U.2 235ed434
[01a0]   33 38 38 35 64 64 65 3A   54 4D 3D 31 32 34 37 36   3885dde. TM.12476
[01b0]   37 30 32 36 38 3A 4C 4D   3D 31 32 34 37 36 37 30   70268.LM .1247670
[01c0]   33 30 37 3A 53 3D 70 32   78 79 32 35 48 6C 64 74   307.S.p2 xy25Hldt
[01d0]   78 71 4F 76 75 58 3B 20   4E 49 44 3D 32 34 3D 64   xqOvuX.. NID.24.d
[01e0]   41 70 58 69 65 74 74 38   68 37 31 73 47 59 64 48   ApXiett8 h71sGYdH
[01f0]   38 32 78 61 4B 50 55 65   75 34 5A 44 6D 2D 6B 69   82xaKPUe u4ZDm.ki
[0200]   4E 70 4B 32 44 67 48 68   52 75 35 6A 31 69 48 4A   NpK2DgHh Ru5j1iHJ
[0210]   79 45 4D 67 53 41 56 35   35 37 41 73 50 4D 73 5F   yEMgSAV5 57AsPMs.
[0220]   59 79 4A 65 4C 57 4F 7A   70 32 4F 53 64 58 35 62   YyJeLWOz p2OSdX5b
[0230]   42 55 73 53 49 4E 77 6B   62 6C 76 63 51 49 45 66   BUsSINwk blvcQIEf
[0240]   61 4D 59 49 54 54 6D 37   53 47 33 39 7A 73 6C 4E   aMYITTm7 SG39zslN
[0250]   70 32 64 45 78 71 5A 37   57 51 2D 46 72 4D 5A 3B   p2dExqZ7 WQ.FrMZ.
[0260]   20 54 5A 3D 33 30 30 0D   0A 0D 0A                  .TZ.300. ...
flow 0: delay 33 milliseconds  

Defining the Test Criteria for the imported pcap (bpt2.pcap)

 

Summary of Session Ramp Distribution Settings

The specified parameters tell Recreate to Ramp Up for 10 seconds during which time it should perform a Full Open (perform TCP three-way handshake, but don't send any data). The test to maintains each session for 10 seconds. During the 10 second Ramp Down stage, Recreate closes all sessions.

After the test was completed, I exported the packet buffer off of my test interfaces. Opening this file up in wireshark, you can see the 10 TCP sessions being initiated to and from the IP address ranges defined within Network Neighborhood.

Examining Test Results

The following wireshark filter was used :  (tcp.flags == 2  or tcp.flags == 18 or tcp.flags == 16) and tcp.port == 80

Following any one of the above streams in wireshark will show the exact some contents as detailed in the above flow description.

This demonstrates some of the power, flexibility, and extensibility of the Recreate test component and explains how the individual parameters within Recreate and Network Neighborhood interact. Hopefully this will inspire you to use the Recreate component in other creative ways during your tests.

Taking A Look at P2P: Gnutella and BitTorrent

Whether you want to admit it or not, there is a high probability that P2P protocols are present on your network. No matter how hard you try (or don’t try) to lock down access. Understanding these protocols and how they work is extremely important for network managers, device manufacturers, and service providers. Today, in part three of our series examining the stateful application protocols BreakingPoint simulates during testing, I wanted to look at Gnutella and BitTorrent. These are two of the most popular peer to peer (P2P) file sharing protocols available today.

BitTorrent™ is probably the most recognized name in P2P file sharing currently. According to the Digital Music News Research Group, BitTorrent accounts for 15% of all P2P traffic. BitTorrent works in a way that is slightly different from other P2P applications. The software breaks up large files for transfer into many small pieces that may be downloaded from multiple peers simultaneously. This facilitates rapid file transfers as well as improving the ability of a downloading host to also act as a “seed” for downloads by other peers.

The increasing amount of bandwidth consumed by BitTorrent has resulted in many service providers utilizing deep packet inspection (DPI) technology to throttle BitTorrent bandwidth. However, BitTorrent also supports an encrypted mode of transfer which makes DPI classification much more difficult. Finally, BitTorrent has increased its use of the UDP transport which can sometimes make more efficient usage of available bandwidth than TCP.

Gnutella, while probably a less recognized name than BitTorrent, is estimated to have a P2P market share of roughly 35%, according to the Digital Music News Research Group. The reason it owns such a large percentage is that Gnutella is the actual file sharing protocol used by applications compatible with the Gnutella network. iMesh, Limewire, Morpheus, and Shareaza are well known applications that have all had, at some point, support for the Gnutella network.

Gnutella starts by finding a set of peers, either in cached addresses or discovered from those cached addresses that do work. Once connected, the peers can share searching information, as well as actually perform the file transfers. Most of the data transfer itself is then transmitted over HTTP.

Knowing what traffic is on your network, and being handled by network equipment, is important. But you also must have an understanding of how those protocols actually work in order to realistically test devices. Above are quick descriptions of the intricacies of both BitTorrent and Gnutella, and it is important that network equipment can recognize and handle these unique attributes. That is why BreakingPoint simulates the protocols statefully so that you can test under real-world conditions. I've written up more details on testing with both BitTorrent and Gnutella protocols.

IPv6 Testing: Check Your Expiration Dates

In a recent CIO Magazine article Yanick Pouffary, technology director for the North American IPv6 Task Force and an HP Distinguished Technologist summed up why it is critical to perform IPv6 testing today:

"At least half of U.S. CIOs have IPv6 on their networks that they don't know about, but the hackers do. You can't ignore IPv6. You need to take the minimum steps to secure your perimeter. You need firewalls that understand IPv4 and IPv6. You need network management tools that understand IPv4 and IPv6."

Mr. Pouffary's quote hit home as BreakingPoint announced yesterday the industry's most comprehensive and current support for IPv6 dual-stack testing. The key word here being "current". Not only is IPv6 already on your network, but even if you did test using IPv6 traffic, the standard has changed rapidly over the years, deprecating different RFCs and most likely leaving you with spoiled test results.

Reminds me of checking the expiration date on that gallon of milk that has been sitting in your fridge for perhaps a bit too long. Sure, it's still milk, but the result you'll get when you drink the milk is going to be...well...a bit off. Same goes for testing with IPv6 traffic that adheres to a now expired standard.

This topic of testing with the most current traffic was brought up during a conversation I was having with BreakingPoint CTO Dennis Cox and we ended up including this in the news release (emphasis mine):

“No matter what your opinion is on the adoption of IPv6, it is out there. Not only is it on every network, but you also need to understand what version of the IPv6 standard your network devices comply with. IPv6 has changed a lot since the original standards. For example, if your testing tool cites RFC 2462 your tests are worse than worthless because they are giving you a false sense of IPv6 compliance. The only way to perform IPv6 validation is to have the most current implementation of the standard and the most comprehensive dual-stack testing.”

Being current (one could say fresh, if you wanted to keep riding the milk analogy) in your testing is critical, whether you are talking about realistic application protocols, the latest security attacks or the ability to generate up-to-date IPv6 traffic. Go and check the "expiration date" on your testing tools to make sure you are still testing with the most current standards.

Show Us Your Board

During my interview last week with BreakingPoint CTO Dennis Cox (When NP Doesn't Equal Network Processors) it became apparent how important it is to use real network processors within network testing tools. Also important was asking to see the board to determine if your testing tool is using a true network processor. I asked Dennis to show us the BreakingPoint Elite board and that footage is below.

Now it's your chance to get in the fun. We have created a YouTube room so you can show off your board. Whether you are in the testing tools space, manufacture network equipment, build custom PCs or anything else, head on over to the room and show us your boards!