Constructing a Linux-Based Network Testing System?

10Brett-T asks: "Is it possible to build a Linux box with two interfaces to test a network's ability to carry traffic between two ports? I work for a company developing ethernet switching hardware. We need to test its ability to carry traffic correctly under a variety of conditions. Various vendors have expensive test platforms available that may or may not do the tests we want, but we have a tight budget. We decided to try building a Linux system with two ethernet interfaces, and modify the routes to force the traffic to go across the network. Testing would be as simple as running an FTP connection between a client on one interface and a server on the other. This would be a great victory for Linux in our company, if I could get it working. The problem is that I cannot figure out how to bypass the Linux kernel's TCP/IP stack routing optimization. All the combinations of routing table modifications and iptables that I've tried still don't make the packets flow out the interfaces and on the wire instead of within the stack. Has anyone else tried something like this before? How did/would you approach this?"

Comments

Mobile network testing

[sachachua]

A pair of Linux iPAQs with expansion sleeves may work fantastically in this environment. Get two CF or PCMCIA network cards, install them on the iPAQs (the old 3630s or maybe even the monochrome iPAQs will do just fine), and check away. You can even install netcat.

It's really portable and flexible, and you can test all sorts of things easily.

Incidentally, for wireless neworks - there are tools for helping you check wireless signal strength. Grab a supported WLAN card, plug it in, and wander around the building checking if your wireless network's okay.

second box?

[smoon]

How about a second box? Hardware capable of saturating a 10MB ethernet connection should be really cheap, and even saturating a 100MB connection isn't hard.

Get two interfaces on each, one interface to an internal 'management' network, the other interface to the equipment you're testing. That way you can operate both boxes out of a single computer, possibly using SSH (or X or Telnet or whatever).

You might also try some other tools besides ftp -- some of the cracker tools can be tuned to blast out an amazing amount of traffic, and even ping can saturate a link if you make the packets big enough and have enough processes sending them.

I dunno. Just a thought.

forget Linux, try OpenBSD

[Permission Denied]

OpenBSD has a number of features to do the "transparent" routing which you desire - basically, you can plug in two interfaces and route from one to the other without changing the packets at all. The OpenBSD box basically looks just like a hub or a dumb switch to its peers, eg, it doesn't even have an IP address assigned to either interface, it doesn't decrement ttl, it doesn't do TCP optimizations, etc. As far as I know, this is not possible with Linux and it sounds like this is exactly what you want. See this page for more information.

Re:forget Linux, try OpenBSD

[Permission Denied]

Which means that the OpenBSD acts as a repeater (a hub) without any IP addresses on the 2 NICs, and without touching the packets it lets go through. Have I correctly understood what you said OpenBSD can do?

Yes, this is exactly correct.

His goal is to send packets on NIC 1, through his switching equipment, then through NIC 2, and check for errors.

You explained it more clearly than he did :)

This makes sense - it's much easier to write single a simple program that sends out data and then reads it back in, checking for errors, than it is to write two programs which run on separate machines to check the integrity.

My suggestion would then be to modify the kernel. I imagine it shouldn't be too hard to find the place in the kernel where it does this optimization and simply comment it out. Whenever I've needed to make a simple modification to the Linux kernel (like allowing people in group 80 to listen on port 80 to ensure my web server never starts as root, and simple stuff like that), I've found that the Linux kernel is pretty easy to grok and modify. In addition, this will show his management the power of having source code (one of his goals), as this sort of modification would probably be really hard to do with Windows :)

Be your own man in the middle

[Halvard]

You could do something along the lines of the Frame Diverter project but instead of just tcp port 80 for transparent caching proxy, you could divert everything so that you can test.

To summarize, you take a system with 2 nics and replace the destination mac address of all frames passing through with the Linux box's input interface. Bridge the 2 interfaces and run the tests of your choice.

When you want to take this out of if, God forbid, something breaks in hardware or software, if it, say, between to switches, you replace it with an Ethernet Crossover cable and your network is restored to operation.

Ditto

[Clue4All]

The problem is that I cannot figure out how to bypass the Linux kernel's TCP/IP stack routing optimization. All the combinations of routing table modifications and iptables that I've tried still don't make the packets flow out the interfaces and on the wire instead of within the stack.

Nor could I. I spent the past year working on a thesis-like project for undergraduates building a new queueing mechanism using the Linux kernel. Using only one 300 Mhz processor and saturating two 100 BaseT interfaces would suck down about 1/3 of the CPU, and I found no way to bypass the stack. FreeBSD and OpenBSD can do it transparently if you want to give them a try.