Constructing a Linux-Based Network Testing System? 30
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?"
Different subnets? (Score:2, Interesting)
Mobile network testing (Score:3, Interesting)
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.
Re:Mobile network testing (Score:2, Insightful)
But, in an office enviroment, having to check wire by wire is hell. Iv done a network test like this using a Fluke Network tester [fluke.com]. At the very least, you need a pair of radios to go with them for talking to the guy at the other end!
Having something that scans the network from a single point is a much more appealing idea. And of course, having something thats not ease to do means you can sell if for more!
What kind of switching hardware? (Score:2)
This could help answer my next question. If your switching hardware has van routing, or routing moduale say like a Cisco 6509 you could set up a NAT or PAT on the switch. This would allow you to have an outgoing address that was not on your ipstack that could be rerouted back to the box. Just a thought, I am very tired and could just be out of my mind here at 4am and 6 coffee's to the wind.
Blue Warrior, needs sleep badly....
Do a broadcast ping. (Score:2, Insightful)
FWIW -- all UNIXes I've worked with have reported results from all responding systems on a broadcast ping, unlike Windows which only shows the first to respond. So you'll want to filter through grep if there are other systems on the network, as you'll get responses from many systems you don't likely care about.
User Mode Linux? (Score:1)
Could you do this with two firewalls on the machine running inside user-mode linux?
Other than that, I would say get into the network code. You might be better with an older kernel (2.2.x) since the 2.4.x have the fancy zero-copy network stuff which is probably what is your problem.
second box? (Score:3, Interesting)
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 (Score:4, Informative)
Re:forget Linux, try OpenBSD (Score:2, Insightful)
That's not exactly what the guy wants. In your option, you have:
<machine>
12
<outer network>-- --<inner network>
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?
The submitter wants this:
<machine>
1 2
<switching equipment>
His goal is to send packets on NIC 1, through his switching equipment, then trough NIC 2, and check for errors.
And what prevents him from doing this is that the Linux kernel sees that the destination IP address is in the same computer, and bypasses the 2 NICs and the switching equipment to be tested.
So the question is thus: how to bypass that? I don't think that any virtual machine (UML, VMWare) will work here, as the network traffic they generate will probably pass by the TCP/IP stack of the host, and won't work. Your best bet may be to take an older kernel version (2.2.21 has been released yesterday), which doesn't implement that enhancement.
Would it be possible to test at another layer? Raw IP, IPX, or even raw 802.3 frames? It will take a bit more of coding, but the switch should be able to speak those languages. Of course, it doesn't test the TCP/IP capability of the switch, but I don't think it really matters as the switch sees MAC addresses, not IP addresses. OTOH, if you don't test it, it may break silently...
Re:forget Linux, try OpenBSD (Score:3, Informative)
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 :)
Re:forget Linux, try OpenBSD (Score:2)
Agreed for small stuff (as I never tried some big changes). I once implemented a small driver for reading the sensors on my motherboard (before I found lm-sensors). It took me about a day to figure out the doc for the chip, then how to make the kernel ask the chip and report the values in
Maybe the optimization that is causing problem is simply absent there... (don't know, don't have a Windows box)
Re:forget Linux, try OpenBSD (Score:1)
We're trying to avoid using 2 boxes per station, because of the space available, and the sheer number of stations we're going to build. A cow-orker suggested pairing stations... so each station would have access to two Linux boxes, but only have one at each station. Each would have two NICs.
You need to modify ip_output (Score:1)
I am currently working on a patch to enable this to happen, but I dont see this getting ready soon enough for your needs. If you are constrained for time, you might want to look at the kernel, espcially the ip_output(), ip_route_output() and corresponding routines.
Does some other OS really implement this? Would be interesting to see what then do at the IP layer.
inexpensive test platform (Score:1)
Be your own man in the middle (Score:3, Interesting)
You could do something along the lines of the Frame Diverter project [sourceforge.net] 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 (Score:4, Informative)
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 [wpi.edu]. 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.
IBM Mainframe Linux (Score:1)
Re:IBM Mainframe Linux (Score:2)
Linux *can* run directly on the hardware, sure, but then your only choice for running mutiple copies under it are the same choices you have when you want to run mutiple copies of that port on PCs, and all of those use the stack and run into the zero copy optimizations.
Broadcast (Score:1)
This doesn't test backplane bandwidth, though. Just connectivity.
Raw Frames (Score:1)
any internal routing thats going on. Its not that tricky and it will give you
a lot more control if you want to experiment with stuff like TTL and ToS.