NetworkNightmare.net

gigEnn.net


gigEnn Products

Packet-Craft.net Products

OnlineOrder

Terms

Discounts

Warranty

Manuals

FirmwareVersions

Upgrade Howto

Support

USB-RS232

Customers


Network Performance

WanSim.net

Packet-Craft.net

Packet Crafting

Monitoring Traffic

Bandwidth Hogs

Wansim Testing

IMAP/Pop3 Sniffing

Sniffer

Firewalls

IPtables

HoneyPots

Tarpits

DDoS

IPv6

MRTG

vLAN


Network Security

Linux-Sec.net

Encrypted-Email.net

Encrypted WebMail

VNC

VPN

OpenSSL

SSH Tunnels


NN2gigEnn upgrade

NN-Plus End-of-Life

NN-Minus End-of-Life



Contact

Sales @ NetworkNightMare.net



Linux is a registered trademark of
Linus Torvalds

More Linux Legalese


gigEnn.net/Testing
Wansim Howto


  • Setup a simplified network ... ( eliminate possible unexpected network complications )..
  • Send packets from oneSide to the otherSide
  • Apply wansim parameters: bandwidth limits, rtt tests, packet loss, queue size

  • Your Network ( bandwith limit ) can only be as fast as your slowest device on the wire

Simplified WAN/LAN Testing Methodology

  • Setup a Simplified WAN/LAN Testing Environment

    • For Initial Control Setup Testing, Start with minimal setup:

        Net1Server <----> cross-over-cable <----> Net2Client

    • For Initial Setup Testing, Start simple:

        Net1Server <---->net1+gigEnn-T3+net2<----> Net2Client

        • Use one PC on each side of the wansim to avoid "confusion"
        • Avoid hubs and switches since they add it's "smartness" to the network
        • Use cross over cable to avoid "confusion"

        • Net1Server# ping Net2Client .. watch the rtt delays
          • Apply RTT delays
          • wansim# gigEnn -bw 0 -rtt 0 .. no bandwidth limit .. no rtt delay .. full speed
          • wansim# gigEnn -rtt 5
          • wansim# gigEnn -rtt 55
          • wansim# gigEnn -rtt 555

    • Bandwidth Testing
      • Flood the network for network parametric testing
        • Your steady state bandwidth over 5min or an hour or 10hrs is your "bandwidth limit"
            -- most likely ... it will NOT be any where near what you're expecting/desire --

        • to go faster ... you will need to tune your TCP buffers

        • be sure you have enough tcp flows generating enough packets to flood the wire

      • Your CPU/memory is overloaded if the wansim does NOT immediately respond to your keystrokes
      • Your CPU/memory is overloaded if the wansim does NOT immediately respond html_gui changes
      • Your CPU/memory/network is congested if the wansim does NOT immediately respond
        • be sure that your server and clients have at least 20% - 30% idle cpu power
        • standard ping xxx should still be able to reply in the typical 5ms range

      • You will NEED to adjust your send/receive tcp buffers for Bandwidth Limit Testing
        • your TCP buffers are named differently between FreeBSD, Linux, MS .. duh ..
          • some tcp buffers are only loaded at boot time

        • You will need to properly calculate your Bandwidth Delay Product
            BDP = BW * rtt
        • You probably will need to adjust your send/receive tcp buffers on your hardware
            the wansim, server, clients and hubs/switches
        • You probably will need to adjust your send/receive tcp buffers in your software apps
            packet generators and client apps

      • Reboot your TestServer and TestClient
        • Your bandwidth limit ( as calculated by netstat.nn ) should be running at 1000Mbit/s
        • Adjust your tcp window and tcp buffers on your TestServer and TestClient

      • Bandwidth Limit Testing
        • 45Mbit/s, 155Mbit/s, 622Mbit/s, 1000Mbit/s, 2488Mbit/s, 10000Mbit/s
        • buffer sizes used could signicantly affect your network performance

        • Net2Server# iperf -w 128K -s
        • Net1Client# iperf -w 128K -c 192.168.242.25 -P 20 -t 600
          • buffer size is "-w 128"

          -- or --

        • Net1Server# socat -u /dev/zero TCP4:192.168.242.25:3333,rcvbuf=64000,sndbuf=64000
        • Net2Client# socat -u TCP4-LISTEN:3333,reuseaddr,rcvbuf=64000,sndbuf=64000,fork /dev/null
          • buffer size is "64000" bytes

        • wansim# netstat.nn em0 .. watch the bandwidth limits

        • Apply BW limits
        • wansim# gigEnn -bw 0 -rtt 0 .. no bandwidth limit .. no rtt delay .. full speed
        • wansim# gigEnn -bw 45 -bwunit Mbit/s
        • wansim# gigEnn -bw 155 -bwunit Mbit/s
        • wansim# gigEnn -bw 255 -bwunit Mbit/s
        • wansim# gigEnn -bw 355 .. you will need to adjust your tcp buffer sizes
        • wansim# gigEnn -bw 455 .. you will need to adjust your tcp buffer sizes
        • wansim# gigEnn -bw 555 .. you will need to adjust your tcp buffer sizes
        • wansim# gigEnn -bw 622 .. you will need to adjust your tcp buffer sizes
        • wansim# gigEnn -bw 1244 .. you will need to adjust your tcp buffer sizes
        • wansim# gigEnn -bw 2048 .. you will need to adjust your tcp buffer sizes
        • wansim# gigEnn -bw 4096 .. you will need to adjust your tcp buffer sizes
        • wansim# gigEnn -bw 8192 .. you will need to adjust your tcp buffer sizes

        • auto-Adjust your bandwith limits via cron

    • Apply your Network Parametric Test Variables
      • There are 6 ways to change the gigEnn WanSim parameters
        ( each way has different feature capabilities )
        • local rs232 console gui
        • local SVGA + keyboard + mouse
        • remote wansim gui via ssh ( telnet ) into the wansim
        • wansim command line ( drop to shell )
        • automated shell scripts or crontabs
        • html gui ( required for MRTG and IPv6 support )

      • Apply the various Network Parameters
        • gigEnn -bw 622 == 622 Mbit/s Bandwidth limit
        • gigEnn -rtt 100 == 100ms RTT delays
        • gigEnn -loss 0.001 == packet loss
        • gigEnn -qs 5183 == 5183 slot queue size

        • the various parameters can be on one line
          • gigEnn -bw 622 -rtt 100 -loss 0.0001 -qs 5183

    • Monitor the Network
      • Is it behaving as expected
      • Change your network test metrics
      • Change the network and system parameters on your client/server and other hardware
      • Change the network parameters on your client/server/monitor apps

Flooding the Network for ( Bandwidth Limit ) Testing

  • More Packet Crafting Apps available to flood the network

  • gigEnn-T3 can support up to about 45Mbit/s
    • be careful NOT to overload the 800Mhz Geode CPU + 256MB system memory

  • gigEnn-OC12 can support up to about 622Mbit/s
  • Flooding the Wire with PING ( ping, nping, hping, ... )
    • Frequency of Packets to Send
    • ping -i 0.01 # send 100 packets per second
    • ping -i 0.001 # send 1000 packets per second
    • ping -i 0.0001 # send 10000 packets per second
    • ping -i 0.00001 # send 100000 packets per second

    • Size of Packets to Send
    • ping -s 100 # send 100 byte packets, 1 packet/sec default
    • ping -s 1000 # send 1000 byte packets, 1 packet/sec default
    • ping -s 10000 # send 10000 byte packets, 1 packet/sec default

    • Flood the wire with Size * Frequency of Packets to Send
    • ping -i 0.1 -s 100 # send 10 packets per second at 100 byte each packet == 1,000 Byte/sec
    • ping -i 0.01 -s 1000 # send 100 packets per second at 1000 byte each packet == 100,000 Byte/sec
    • ping -i 0.001 -s 10000 # send 1000 packets per second at 10000 byte each packet 10,000,000 Byte/sec
    • ping -i 0.0001 -s 10000 # send 10000 packets per second at 10000 byte each packet 100,000,000 Byte/sec

  • Check your Cables and Media Connectivity
    • Use 3' to 6' Cat-6e cables for gigE speeds
    • Check your media detection ... 100 Mbit vs 1000baseTX

  • Turn off icmp limits Limiting icmp ping response from xxxx to 200 packets/sec
    • sysctl net.inet.icmp.icmplim=0 # default to 200, turn off ping limits

  • ping: sendto: No buffer space available
    • increase your NMBcluster, and tcp send and receive buffers
      on your server, client, wansim and software apps

  • Net1serverside# ping -f Net2Client
    • Each dot on the screen represents a dropped packet

  • netperf
  • uperf
  • iperf Change your tcp window size
      Net1Server# iperf -w 1024K -s
      Net2Client# iperf -w 1024K -c Net1Server -P 2 -t 600 == with gigEnn-t3 wansim
      Net2Client# iperf -w 1024K -c Net1Server -P 10 -t 600 == with gigEnn-OC12 wansim

  • netcat ( nc )
  • socat Change your tcp window size
      Net1Server# socat -u /dev/zero TCP4:Net1Client:3333,rcvbuf=64000,sndbuf=64000
      Net2Client# socat -u TCP4-LISTEN:3333,reuseaddr,rcvbuf=64000,sndbuf=64000,fork /dev/null

  • ip6sic
  • ISIC

  • LMBench Change your tcp window size
      Net1Server# bw_tcp -s
      Net2Client# bw_tcp Net1Server
        Other lmbench capabilities: lat_tcp, lat_udp, tcp connection speeds, ...

  • nepim Change your tcp window size
      Net1Server# nepim -s -w SndBuff -z RcvBuff
      Net2Client# nepim -c Net1Server -w SndBuff -z RcvBuff -d
        UDP: -u -W UDPSndBuff -Z UDPRcvBuff
        various buffer options, ttl options, bw limits

  • netperf Change your tcp window size
      Net1Server# netserver
      Net2Client# netperf

  • NetPerfMeter

  • NetPipe

  • NetIO not too interesting results
      Net1Server# netio -b 32k -s -t -u
      Net2Client# netio -b 32k -t Net1Server

  • nuttcp Change your tcp window size
      Net1Server# nuttcp -S -w1m
        -S -6 == IPv6 server
      Net2Client# nuttcp -v -w1m [options] Net1Server
        -w1m == 1MB ( 1024*1024 ) window size
        -u -i == UDP mode for checking packet loss
        -Ri155 == 155Mbit/s limit
        -Ri622 == 622Mbit/s limit

Simplified Network Parametric Testing

  • RTT changes Testing
    • gigEnn -rtt 5
    • gigEnn -rtt 55
    • gigEnn -rtt 555
    • gigEnn -rtt 5555

    • observe the RTT with ping ( ping6 ) ..
      • Net1Server# ping Net2Client

  • Bandwidth Testing
    • gigEnn -bw 1540 -bwunit Kbit/s ( 1.54 Mbit/s )
    • gigEnn -bw 45 -bwunit Mbit/s
    • gigEnn -bw 155 -bwunit Mbit/s
    • gigEnn -bw 622
    • gigEnn -bw 1244
    • gigEnn -bw 2048
    • gigEnn -bw 4096
    • gigEnn -bw 8192

    • Be sure to have enough data flowing between Server and Clients
    • Similarly, be sure NOT to overload the CPU/memory/network

    • observe the BW limits with netstat.nn .. ( or your favorite BW monitoring app )
      • wansim# netstat.nn vr1

      • Watch out for "ran out of network buffer space"
      • Watch out for "fragmented packets"
      • Watch out for incorrect tcp buffer settings on the wansim, server, client and apps

  • Queue size Testing
    • gigEnn -qs 0 == ( infinite queue buffers )
    • gigEnn -qs 50 ( dummynet default in slots )
    • gigEnn -qs 75000 -qsunit KByte ( dummynet default in Kbytes )
    • gigEnn -qs 5183 -qsunit slots for 622Mbit/s * 100ms delay )


  • Packet Loss Testing
    • gigEnn -loss 0 ( no packets lost )
    • gigEnn -loss 0.001 ( 1 out of 1,000 packets )
    • gigEnn -loss 0.000001 ( 1 out of 1,000,000 packets )

    • UDP packets are easier to drop/lose
    • TCP apps tries to recover its dropped/lost packets

    • To force a particular amt of packet lost
      • you can probably use "these packet lost apps"

      • Use ping to send simple packets you can count, ( one packet per second )
      • Use packet lost rate of 0.1 ( 1 packet lost out of 10 ), ez enough to count n verify

    • observe the packet lost with your favorite monitoring app )
      • ipfw pipe list look at the "dropped packet counter"
      • netstat -s | grep dropped
      • netstat -ib # dropped - collisions

  • Jitter Testing
    • by default, you have RTT jitter shown from ping results
    • by default, you have BW jitter shown from BW monitoring tools

    • To force a particular amt of jitter

  • Collision Testing
    • no idea how to intentionally generate collisions
      • simple collision test is to use the same IP# on different devices

    • Watch the collision lights on your hubs/switches ?
    • Watch for arp messages ?

  • Congestion Testing
    • it should be trivial to overload your network and/or CPU, memory

    • observe the Congestion with netstat.nn .. ( or your favorite monitoring app )
      • Kill the source of the packets overloading your network

      • if "netstat.nn" now has time to catch up to post its bandwidth data...
        you have a congestion problem
        ( the intentional flooding of the network using up the bandwidth )

  • IPv6 Testing

Testing with crontabs

  • Edit crontabs with:
      root# crontab -e
      
    #  
    # minute hour  mday  month wday  who   command  
    #  
    # un-comment these to run MRTG every 5 minutes  
    # --------------------------------------------  
    # */5 * * * * /usr/local/bin/mrtg /home/apache/html.mrtg/wansim.cfg >/dev/null 2>&1  
    # */5 * * * * /usr/local/bin/mrtg /home/apache/html.mrtg/cpu-mem.cfg >/dev/null 2>&1  
    #  
    #  
    # simulate Bandwidth limit for T1, T3, OC-3, OC-12 at midnight, 1am, 2am, 3am ...  
    #  
    0 0     *     *     *     /usr/bin/gigEnn -bw 1540 -bwinit Kbit/s  
    0 1     *     *     *     /usr/bin/gigEnn -bw 45 -bwunit Mbit/s 
    0 2     *     *     *     /usr/bin/gigEnn -bw 155  
    0 3     *     *     *     /usr/bin/gigEnn -bw 622  
    0 *     *     *     *     /usr/bin/gigEnn -bw 0  
    # 



Copyright © 2000
Linux-Consulting
All Rights Reserved.
Updated: Sun Mar 30 12:24:02 2014 PDT