Hi Erwin, Thanks for the interest, here's a little bit more information about our setup.
The linux box (i.e. the router) has 3 gigE NICs (into a gigE switch) and routes between 3 subnets: eth0 - 192.168.100.x (test network) eth1 - 192.168.101.x (test network) eth2 - 192.168.0.x (corporate network) The box is set up with the route utility to route between the 3 networks although the test devices are only on the 100.x and 101.x subnets. I.e. a video producer device on a 100.x address sends traffic to a consumer device on a 101.x address. (Although the devices each have a gigE MAC, I think most of the time they're actually running at 100Mb.) We have a number of pairs of devices which are being tested (often simultaneously) so one of my colleagues here wrote a tcl wrapper that implements a nistServer state machine which runs on the box, issues the actual cnistnet commands and keeps track of the settings for each nistnet connection. Any tester can run a nistClient script (from anywhere on the network) which will set up whatever nist test settings he/she wants. In doing my tests, I ran tethereal directly on the linux box capturing on eth0 (fully expecting to lose packets in the capture, that's ok) and wrote to a file for offline examination. The producer device pumps out up to about 40 Mbit but it is bursty so it will occasionally get higher than that. With nist off, I get no duplicated packets. With nist b/w set to 500 Mb (i.e. 62,500,000 since I take it that the units are in bytes/second) I also get no duplicated packets. With nist b/w set to 100 Mb (i.e. 12,500,000) and no drd setting, about a quarter of the packets are duplicated with occasional stretches of up to about 6 packets or so which aren't. With nist b/w set to 100 Mb and drd settings 150 250, again about a quarter of the packets are duplicated as before. The device logs are also reporting duplicated packets so it wouldn't appear to be a capture artifact. Any thoughts? Thanks again .... N --- Nou Dadoun [EMAIL PROTECTED] 604-628-1215 ________________________________ From: Erwin Himawan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 01, 2007 5:25 PM To: Nou Dadoun Subject: Re: [nistnet] Nist Net duplicate packet problem Can you roughly sketch up your setup; i.e. where is the Ethereal node is attached? Are you using hub or switch to monitor the traffic? Are you also use Gb NIC? Other member might know whether Gb NIC or kernel 2.6 might have something to do with it or not. It seems that you have been narrowing down the issue as the nistnet issue. However, if you have not done so, I could suggest the following to rule out whether this is a NistNet issue or setup issue: 1. While the application is exchanging data, you can turn on NistNet -> cnistnet -u and observe whether there is pakcet duplication, which according to your email, there will be. 2. While the application is still running, turn off nistnet -> cnisnet -d, and observe whether packet duplication is still happening. 3. From here we can conclude whether this is a nistnet issue or setup configuration issue. Beyond than this, I do not have any more to suggest. Erwin On 3/1/07, Nou Dadoun <[EMAIL PROTECTED]> wrote: Hi, We're using Nist Net to do some network impairment testing, one of the guys here has written a tcl wrapper for the nist net functions to allow for more automated testing setups; we're principally interested interested in doing b/w limiting right now (I haven't put in any drd parameters yet but I wouldn't think that should matter). We have a hardware/firmware remote imaging application that sends our own (proprietary imaging) protocol wrapped in an ESP header and we don't do packet retransmissions; our b/w utilization is averages about 25Mb although it can be pretty bursty. When I set a b/w limit of 500 Mb (which isn't limiting at all) everything is fine and operates as expected. However, when I set the b/w to 100Mb (which should still only run into the occasional burst limit) , I end up getting duplicate packets fairly consistently. (We do want to handle duplicate packets but that's not what this test should be exercising.) Any ideas as to why this might be occurring, has this problem been reported before? A few more details about our setup that was tweaked by one of the other discussion messages that I noticed. The traffic endpoints (call them client and host) are on different subnets and the machine running nistnet is also the router between those two subnets - running linux kernel 2.6.11-prep . The traffic is mainly ESP traffic so there are no port numbers visible, our working implementation uses an SPI of 0 for now. I'm not sure how nistnet interacts with the routing changes controlled by the linux route utility but it occurred to me that it might be possible that the 'regular' routing is still happening, with nistnet grabbing the packets to be delayed and then (when they've been sufficiently delayed) blindly sending them off without realizing that they've now been duplicated. The duplicate packets I'm capturing in t/ethereal are identical (down to the timestamps) but differ in frame/capture numbers (and they're not always back to back). Anybody have experience with this? Is this a possible explanation or am I way off base? Is there anything else in this setup that raises a flag? Thanks in advance for any suggestions ... N --- Nou Dadoun [EMAIL PROTECTED] 604-628-1215 _______________________________________________ nistnet mailing list nistnet@antd.nist.gov http://www-x.antd.nist.gov/mailman/listinfo/nistnet _______________________________________________ nistnet mailing list nistnet@antd.nist.gov http://www-x.antd.nist.gov/mailman/listinfo/nistnet
