Re: Network Traffic Generation
I concur. You could try playing with routing by assigning certain routes to phys ifaces. But you are way better off with multiple boxes. ---MAV Marc. Volovic +972-54-467-6764 m...@swiftouch.com Sent from my iPhone On Mar 13, 2009, at 6:46 PM, Aviv Greenberg avivg...@gmail.com wrote: Seems like you have a routing problem. Say you have 1 box with 2 interfaces, having IP x and y. When you try to ping or connect to either x or y, the routing table is being consulted. The answer of what is the route to x is Local - and it is treated as loopback. I don't think actual packets will go on the wire. you can try crafting mind bogling routing rules to fix it, or better use 2 boxes. 2009/3/13 Daniel Feiglin dilog...@inter.net.il: Hello folks! I'm trying to use a Linux box as a packet traffic generator. It has two NICs configured with fixed IP addresses, 192.168.2.100/101. For testing purposes, I connected the two NICs to each other with a crossed network cable (hardware loopback). For what it's worth, they can both be pinged from the host and the ifconfig output looks fine. Later, the crossed cable will be replaced by a radio link (which relates to the purpose of all this). To carry out the packet generation, I downloaded and built the iperf program (http://sourceforge.net/forum/forum.php?forum_id=808751). I'd like to sent stuff from .100 to .101 using the client and server instances of iperf in two console sessions and (later) monitor what's happening with tcpdump from a third session. For various reasons, it's not working. (I have successfully done it using two machines on either side of the radio link, which is the standard method.) Has anyone on the list done this (using iperf or something similar) using a single box with two NICs? Regards, Daniel P.S. I'll supply further background material if there is interest in this subject. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- Joan Collins - The problem with beauty is that it's like being born rich and getting poorer. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
2009/3/16 Shachar Shemesh shac...@shemesh.biz: Sorry, almost got it :-) Didn't i say mind boggling routing rules? Told ya! :) Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- Jean Anouilh - What you get free costs too much. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Aviv Greenberg wrote: 2009/3/16 Shachar Shemesh shac...@shemesh.biz: Sorry, almost got it :-) Didn't i say mind boggling routing rules? Told ya! :) Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il Meanwhile, I've had a lengthy chat with the Linux/Networking guru where I work. (I didn't know that he was one, until someone else there told me!) Luckily for me, he picked up my itch and we almost got it too. We were able to get ping packets from eth0 to side 1 of the link, and thence to side 2, but no further. any attempt to get back to eth1 via the link was thwarted - ping (logically) took the shortest route, eth0-eth1. I won't go into the morbid routing details of a failure. Our guru's view was: 1. What I wanted to do (as stated) was probably not possible. 2. I could also forget about the crossed cable simulation. 3. Our radio links work in bridged or hub mode. If I chose bridged mode, an set up the two NIC cards using separate subnets, maybe ... the use of dual routing tables (suggest earlier in this thread) might help. At that point grim reality returned - and we had to drop it in favor of real work. If at some point, we reach a successful round trip via the link, I'll publish the details. Daniel begin:vcard fn:Daniel Feiglin n:Feiglin;Daniel adr:;;POB 36;Shavei Shomron;Doar Na;44858;ISRAEL email;internet:dilog...@inter.net.il tel;work:972 9 8616204 tel;fax:972 9 8621052 tel;pager:Skype user ID: baba_danny tel;home:972 9 8320939 tel;cell:927 52 3869986 version:2.1 end:vcard ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Daniel Feiglin wrote: Hello folks! I'm trying to use a Linux box as a packet traffic generator. It has two NICs configured with fixed IP addresses, 192.168.2.100/101. For testing purposes, I connected the two NICs to each other with a crossed network cable (hardware loopback). For what it's worth, they can both be pinged from the host and the ifconfig output looks fine. Okay, I thought I had a simple answer for you. One that does not involve multiple machines. Assuming we want eth0 to be .100 and eth1 to be .101, perform the following operations: ifconfig eth0 192.168.2.98 ifconfig eth1 192.168.2.99 route add -host 192.168.2.100 dev eth1 route add -host 192.168.2.101 dev eth0 iptables -A POSTROUTING -t nat -o eth1 -d 192.168.2.100 -j DNAT --to-destination 192.168.2.98 iptables -A POSTROUTING -t nat -o eth0 -d 192.168.2.101 -j DNAT --to-destination 192.168.2.99 The idea is to assign one IP address to the interface card, and then try and connect to another one. Then use iptables to rewrite the packet. The problem, as anyone trying to implement this will notice, is that the DNAT rule is illegal in the POSTROUTING table. It is only legal in the PREROUTING or OUTPUT table, at which point it is too early to make this change (we will revert back to the original problem). You can probably rig something up using raw packet modifications, but I cannot find anything about that. Another solution, one that requires more work on your part, is to use a virtual interface (such as tun) for your work, and write the code for the rewriting inside of it. Sorry, almost got it :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Daniel Feiglin wrote: For what it's worth, they can both be pinged from the host and the ifconfig output looks fine. I am sorry. For what it's worth is exactly nothing. The setup you are trying to achieve is not possible as is. The problem is convincing the TCP/IP stack to route packets to an IP it knows to be local through a physical network card. Truth be told, I'm faced with a similar problem for a project I'm working on, and don't have a great solution either. Do the following experiment. Connect the 100 card to a network, and from another computer ping the 101 address while a sniffer is running. You will see an ARP reply going out from the 100 card, carrying the 100 MAC address, and the ping will succeed despite the 101 card being disconnected. Why? Because the computer says I know how to reach 101 - it's my IP, so if the ARP reached the 100 card, it's probably a good MAC address to respond with. Later, the crossed cable will be replaced by a radio link (which relates to the purpose of all this). To carry out the packet generation, I downloaded and built the iperf program (http://sourceforge.net/forum/forum.php?forum_id=808751). From the quick look I gave it, it seems that iperf does not force the sending of the packets from a network interface (it can bind to address, but that still goes through the machine's TCP/IP stack and routing tables, so no solutions there). What you need is to partition the TCP/IP stack for the machine. You need to have the 100 and 101 addresses belong to separate routing tables. The most immediate solution is to run a virtual machine, and give it exclusive access to one of the NICs. This way you can configure, for example, the 100 address in the real machine and the 101 address in the virtual one. There is also a solution I've heard of once, but never had chance to either try it or even look at it. Basically, it does this partitioning inside one running kernel. It came as a patch to the Linux kernel. I don't recall how its called or what are the details, so it may even not be a solution at all. Has anyone on the list done this (using iperf or something similar) using a single box with two NICs? Never done it, but maybe a packet based traffic generator, instead of a traffic based one, will be able to be told issue the packets through this NIC. The problem is, of course, that I don't think a packet generator checks what you are trying to check - TCP throughput. Either way, give tcpreplay a go and see whether it is capable of testing what you want tested (I doubt it). Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Shachar Shemesh shac...@shemesh.biz writes: Do the following experiment. Connect the 100 card to a network, and from another computer ping the 101 address while a sniffer is running. You will see an ARP reply going out from the 100 card, carrying the 100 MAC address, and the ping will succeed despite the 101 card being disconnected. Why? Because the computer says I know how to reach 101 - it's my IP, so if the ARP reached the 100 card, it's probably a good MAC address to respond with. Let me first make a disclaimer that I have not tried it myself in this configuration, but here is what *might* point you towards a solution. It may also turn out a dead end, mind you. Try to use iproute2 to created multiple routing tables by policy. In principle, iproute2 should enable you to create multiple routing tables per process (you need policy routing enabled in the kernel, too). Configure routing rules per destination host in such a way that traffic intended to 101 goes out of device eth0, and traffic intended to 100 goes out of device eth1. Google for more descriptions and explanations for multiple default gateways linux or some such. Some links that (say similar things and) may be of help are http://www.clintoneast.com/articles/multihomed.php http://lartc.org/howto/lartc.rpdb.multiple-links.html http://linux-ip.net/html/adv-multi-internet.html http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/ Once again, I am not saying it is a solution for you problem, just something that might help you work it out, if it is at all possible. The most immediate solution is to run a virtual machine, and give it exclusive access to one of the NICs. This way you can configure, for example, the 100 address in the real machine and the 101 address in the virtual one. But this does not necessarily mean packets will go out of the machine - hypervisors include local (in-box) switching nowadays. -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Oleg Goldshmidt wrote: Let me first make a disclaimer that I have not tried it myself in this configuration, but here is what *might* point you towards a solution. It may also turn out a dead end, mind you. I'm sorry, my money is on the later. http://www.clintoneast.com/articles/multihomed.php http://lartc.org/howto/lartc.rpdb.multiple-links.html http://linux-ip.net/html/adv-multi-internet.html http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/ None of those links say anything about causing a packets destined for a LOCAL ip to actually go out. I'd love to be proven wrong as, as I've said, I need a similar thing myself. Once again, I am not saying it is a solution for you problem, just something that might help you work it out, if it is at all possible. It is, indeed, worth a try. The most immediate solution is to run a virtual machine, and give it exclusive access to one of the NICs. This way you can configure, for example, the 100 address in the real machine and the 101 address in the virtual one. But this does not necessarily mean packets will go out of the machine - hypervisors include local (in-box) switching nowadays. Switching is fine, as long as they are only layer 2 aware. So long as you actually have two actual physical network cards, there is no reason for the packet not to go out. A layer 3 switch might notice the short path, but a layer 2 switch should work fine. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Shachar Shemesh shac...@shemesh.biz writes: None of those links say anything about causing a packets destined for a LOCAL ip to actually go out. This is what I meant when I wrote I hadn't tried this configuration. It is, indeed, worth a try. If you do, I am curious whether it works or not, so a summary will be appreciated. Switching is fine, as long as they are only layer 2 aware. So long as you actually have two actual physical network cards, there is no reason for the packet not to go out. A layer 3 switch might notice the short path, but a layer 2 switch should work fine. Unless VM0 sends an ARP inquiring about the destination IP, VM1 dutifully replies with its MAC (all through the hypervisor's virtual switch), then VM0 stack forms a frame with VM1's MAC as destination. The frame, from VM0's point of view, goes out of its *virtual* NIC, and then gets L2-switched locally by the virtual switch without going out of any physical interface. -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Oleg Goldshmidt wrote: It is, indeed, worth a try. If you do, I am curious whether it works or not, so a summary will be appreciated. Me it'll take some time until I get to try it. If Daniel tries it, please do report. Switching is fine, as long as they are only layer 2 aware. So long as you actually have two actual physical network cards, there is no reason for the packet not to go out. A layer 3 switch might notice the short path, but a layer 2 switch should work fine. Unless VM0 sends an ARP inquiring about the destination IP, This ARP is sent to a physical NIC. VM1 dutifully replies with its MAC (all through the hypervisor's virtual switch), No, as far as the machine is concerned, the sending out of an ARP through VM1 and receiving it through VM0 are two separate events. Unless it is layer 3 aware, there is no reason for it to know that the ARP received through a physical Ethernet device originated in our machine. then VM0 stack forms a frame with VM1's MAC as destination. Of course it does. I find it hard to believe that a VM would form a switch between two separate physical interfaces. In fact, VMs work extra hard to make sure that you can INCREASE the number of physical layers you have, no decrease it. The frame, from VM0's point of view, goes out of its *virtual* NIC, and then gets L2-switched locally by the virtual switch without going out of any physical interface. Who gave the VM the right to assume that VM1 and VM0 are layer 2 connected? If it does that, switch VM software - it's a bug. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Shachar Shemesh shac...@shemesh.biz writes: Unless VM0 sends an ARP inquiring about the destination IP, This ARP is sent to a physical NIC. Actually, no. It is sent by the VM's virtual NIC (the VM does not know anything else), and the switch in the hypervisor forwards it, among other things, to the virtual NIC of the other VM, that has its own MAC address, etc. I suppose it may depend on the configuration - I am not performing any experiments. Unless it is layer 3 aware, there is no reason for it to know that the ARP received through a physical Ethernet device originated in our machine. But it isn't received on the physical interface - see above. Who gave the VM the right to assume that VM1 and VM0 are layer 2 connected? If it does that, switch VM software - it's a bug. The VM does not assume anything, nor does it know about the other VM, for that matter. It needs to send a packet to an IP address that - in your setup - is somewhere else. It sends an Ethernet frame out of its virtual NIC (the only one it knows of), and as soon as this is done the VM considers the frame to be out in the network, even though it may still be inside the physical box. The hypervisor, in turn, contains a virtual switch, that has virtual ports virtually connected to the VM's virtual NICs, and has the appropriate forwarding table that says, for DA 'X' forward to port N. At least this is what happens in today's VMware. Again, possibly modulo configurations that I am not checking. The motivation behind it is exactly the above: not to send frames out to the physical network if it can be avoided. There are heated discussions going on in the IEEE standartization bodies in order to determine whether forcing the frames out to real switches would be better overall, but that's another topic. Xen/KVM/others may be different (I have not checked lately if they include virtual switches by default). -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Shachar Shemesh shac...@shemesh.biz writes: The behavior you are suggesting is akin to a hardware switch forwarding packets between two VLANS to save on routing. A layer 2 switch is simply not allowed to do that. I thought that the two entities in question live in the same broadcast domain (subnet/vlan) by requirement (just a cable between the NICs in the original formulation). In any case, this took us too far from the OP. I would be really curious to know if iproute2 trickery can solve the problem for Daniel or for you. -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Oleg Goldshmidt wrote: I thought that the two entities in question live in the same broadcast domain (subnet/vlan) by requirement (just a cable between the NICs in the original formulation). They do, but you have to be layer 3 aware to notice that. Exactly like I said - if you're layer 2, you are not allowed to do this optimization. In any case, this took us too far from the OP. I would be really curious to know if iproute2 trickery can solve the problem for Daniel or for you. Agreed. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Oleg Goldshmidt wrote: Shachar Shemesh shac...@shemesh.biz writes: Do the following experiment. Connect the 100 card to a network, and from another computer ping the 101 address while a sniffer is running. You will see an ARP reply going out from the 100 card, carrying the 100 MAC address, and the ping will succeed despite the 101 card being disconnected. Why? Because the computer says I know how to reach 101 - it's my IP, so if the ARP reached the 100 card, it's probably a good MAC address to respond with. Let me first make a disclaimer that I have not tried it myself in this configuration, but here is what *might* point you towards a solution. It may also turn out a dead end, mind you. Try to use iproute2 to created multiple routing tables by policy. In principle, iproute2 should enable you to create multiple routing tables per process (you need policy routing enabled in the kernel, too). Configure routing rules per destination host in such a way that traffic intended to 101 goes out of device eth0, and traffic intended to 100 goes out of device eth1. Google for more descriptions and explanations for multiple default gateways linux or some such. Some links that (say similar things and) may be of help are http://www.clintoneast.com/articles/multihomed.php http://lartc.org/howto/lartc.rpdb.multiple-links.html http://linux-ip.net/html/adv-multi-internet.html http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/ Once again, I am not saying it is a solution for you problem, just something that might help you work it out, if it is at all possible. The most immediate solution is to run a virtual machine, and give it exclusive access to one of the NICs. This way you can configure, for example, the 100 address in the real machine and the 101 address in the virtual one. But this does not necessarily mean packets will go out of the machine - hypervisors include local (in-box) switching nowadays. It seems that I've unintentionally opened a Pandora's Box with this one. For the moment I've grabbed the iproute2 howto , which is available from one of Oleg's links, above. (It's installed on all 3 of my Linux boxes by default.) Heavy homework for what I'd hoped was a rather simple problem! About using virtual machines: (1) It's heavy fisted - even if it works (2) It's self defeating - My 2 Linux test boxes are each P IIs with limited memory running a minimal SuSE 9.2 installation. Enough for now. D begin:vcard fn:Daniel Feiglin n:Feiglin;Daniel adr:;;POB 36;Shavei Shomron;Doar Na;44858;ISRAEL email;internet:dilog...@inter.net.il tel;work:972 9 8616204 tel;fax:972 9 8621052 tel;pager:Skype user ID: baba_danny tel;home:972 9 8320939 tel;cell:927 52 3869986 version:2.1 end:vcard ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Network Traffic Generation
Seems like you have a routing problem. Say you have 1 box with 2 interfaces, having IP x and y. When you try to ping or connect to either x or y, the routing table is being consulted. The answer of what is the route to x is Local - and it is treated as loopback. I don't think actual packets will go on the wire. you can try crafting mind bogling routing rules to fix it, or better use 2 boxes. 2009/3/13 Daniel Feiglin dilog...@inter.net.il: Hello folks! I'm trying to use a Linux box as a packet traffic generator. It has two NICs configured with fixed IP addresses, 192.168.2.100/101. For testing purposes, I connected the two NICs to each other with a crossed network cable (hardware loopback). For what it's worth, they can both be pinged from the host and the ifconfig output looks fine. Later, the crossed cable will be replaced by a radio link (which relates to the purpose of all this). To carry out the packet generation, I downloaded and built the iperf program (http://sourceforge.net/forum/forum.php?forum_id=808751). I'd like to sent stuff from .100 to .101 using the client and server instances of iperf in two console sessions and (later) monitor what's happening with tcpdump from a third session. For various reasons, it's not working. (I have successfully done it using two machines on either side of the radio link, which is the standard method.) Has anyone on the list done this (using iperf or something similar) using a single box with two NICs? Regards, Daniel P.S. I'll supply further background material if there is interest in this subject. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il -- Joan Collins - The problem with beauty is that it's like being born rich and getting poorer. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
