Test LAN for Research Project - Help & Suggestions

Unanswered Question
Dec 17th, 2007
User Badges:

Hello all,


I am asking for help for a research project I am doing on how network topology affects data traffic and routing. Most of my background is in the sciences and while I consider myself reasonably knowledge about IT and networks, there are a few fine engineering points I know I might miss.


In particular for this experiment, I am setting up an experimental network of between 25-35 Layer 3 switches (routers more or less) in different network configurations. What I plan on doing is simulating network traffic between all switch pairs by connecting all of the switches into one network.


I want to generate traffic on the network by connecting ALL of these switches to a large hub which is also connected to a PC which will direct TCP/IP and UDP/IP traffic to all of the switch IP addresses and by routing it through the hub I want to make sure I generate traffic on all paths by having all of these packets pass through each switch to the other pairs.


1) Is there an easier way to generate traffic across the network than this? I obviously don't want (or can afford) hooking up 25-35 different PCs to each switch to generate traffic.

2) I have a feeling I may run into some major packet collision problems. Is there a way to minimize this?


Next, most of the traffic going through the network will be UDP since I don't want to deal with all the feedback traffic connection-based protocols like TCP create in addition to congestion control activity, etc. I need to measure the data rate of the network though so I am planning to have small TCP flows (compared to the size of UDP flows) generated in the network to all IP addresses whose return packets (they can return through the hub right?) will provide RTT and TTL data on the different network paths to help me evaluate the performance on the network under stressful loads.


1) Is there any better way to measure traffic across the network (once again I'm on a very tight research budget)

2) Will TCP be routed with priority over UDP or interfere with UDP traffic in any way?


Finally, two more questions:

1) Does anyone have any good ideas on how to measure packet loss in this network to make sure this isn't affecting the data rate too much?

2) How can I estimate how much of the transit time is due to queuing in the switches/routers? Granted, will this be the majority of the transit time since the actual links will be very short (a few meters at most).


Thanks for any help or criticism.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
wdrootz Tue, 12/25/2007 - 07:43
User Badges:
  • Bronze, 100 points or more

1) As you are using UDP flows, you can generate traffic from your PC itself.

2) Better than a hub, go for any layer 2 switch.

3) There are many freeware utilities available, which can measure the throughtput of the network.

4) Different queuing mechanisms can be configured the device to improve the responsiveness.

scottmac Tue, 12/25/2007 - 13:36
User Badges:
  • Green, 3000 points or more

Check out Qcheck (google for it). Qcheck can do per-endpoint-pair throughput, packet loss, and latency. It is (or at least was) the "little brother" to Chariot, a very popular (and expensive) seven-layer test suite.


iPerf is also fairly popular (and also free), I believe it's *nix only.


All the network sees at layer two is Ethernet (or Frame Relay, or ...), all it sees at layer three is IP ... TCP and UDP aren't see until a little farther up the stack.


Regarding transit time, it might be best to just go with the manufacturer's stated performance. GENERALLY SPEAKING, they are following RFC-based testing procedures, with well-known and reproducible test equipment and software suites (like, SmartBits and Chariot, to name a couple or many).


I'm not sure how many topologies you're going to be able to come up with. Aside from hub & spoke and possibly a ring, there aren't any other "best practice" layouts (maybe full-mesh, but scaling makes it impractical for larger networks).


Anything else produces bottlenecks and single-points-of-failure ... Very Bad Things for a network of any critical nature.


You shouldn't see any collisions in a full-duplex environment; if you do, it's generally a media problem (crap cables, damaged cables, flakey termination).


Also, on the TCP / UDP thing ... you can have phenomenal transmit rates with UDP ... with zero reception rates. Unless you can totally quantify exactly how much UDP is sent AND received, it's a worthless experiment.


In the case of TCP, the ACK becomes your limiting factor to throughput. Any (throughput) experiment you do at ten meters is probably invalid at ten, one hundred, or one thousand miles. Until the first data is ACK'd (or NAK'd) the next data cannot be sent (ddata size depends on transmission unit and segment size).


You can directly observe what's going on by running something like Wireshark (or Ethereal) on either or both ends.


Good Luck


Scott


Actions

This Discussion