Slashdot Mirror


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?"

3 of 30 comments (clear)

  1. Do a broadcast ping. by inkfox · · Score: 2, Insightful
    Any direct traffic is going to be optimized out of the picture. You should be able to put the 2nd NIC on the same subnet, do a broadcast ping, and still see responses from the other interface however.

    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.

    --
    Says the RIAA: When you EQ, you're stealing bass!
  2. Re:Mobile network testing by ClickNMix · · Score: 2, Insightful

    Its a great idea, and one that in the past Iv considered my self (More for gewizz then pratical value all be it)

    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. 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!

    --
    I saw the light at the end of the tunnel... But it was just someone with a flashlight bringing more work.
  3. Re:forget Linux, try OpenBSD by Papineau · · Score: 2, Insightful

    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.

    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...