|
|
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
- Monitor your network traffic and see if you get what you expected
|
| Simplified WAN/LAN Testing Methodology
|
- Setup a Simplified WAN/LAN Testing Environment
- 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"
- Setup of your wansim testing environment
- 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 the wansim, server, clients and hubs/switches
- You probably will need to adjust your send/receive tcp buffers
on your packet generators and client apps
- Send Data from oneSide to the otherSide
- Flood the network for network parametric testing
- 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
- Apply your Network Parametric Test Variables
- There are 5 ways to change the gigEnn WanSim parameters
( each way has different feature capabilities )
- local rs232 console gui
- 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
|
- 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
|
- gigEnn-T3 ( 100 Mbit/s ) == ping 100x per second
Net1serverside# ping -s 30000 -i 0.01 Net2Client > /dev/null
- gigEnn-OC12 ( 1000 Mbit/s ) == ping 1000x per second
Net1serverside# ping -s 30000 -i 0.001 Net2Client > /dev/null
|
- 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
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
- observe the RTT with ping ( ping6 ) ..
- Net1Server# ping Net2Client
- Bandwidth Testing
- gigEnn -bw 1540 -bwunit Kbit/s ( 1.54 Mbit/s )
- gigEnn -bw 45
- gigEnn -bw 155
- gigEnn -bw 622
- 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 )
- netstat -s | grep dropped
- ipfw pipe list look at the "dropped packet counter"
- 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:
#
# 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
#
|
|
|
|