-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Losing tons of data, wondering what i'm doing wrong #26
Comments
I see that you're starting pen with -x 15000. The "too many open files" error suggests that the server isn't configured to allow that. What is the traffic rate? Did you run top or something during the test to see that the server wasn't overloaded? You can use the transparent reverse proxy mode to preserve the original source address. https://github.com/UlricE/pen/wiki/Transparent-Reverse-Proxy That describes TCP, but UDP is the same but with -U as usual. |
Didn't run top, but the only things running were 2 ipfixcol's and Pen. the 2 ipfixcol's were only getting about 10% of the packets I was expecting they would get. I added the -x15000 after my initial runs thinking I had to increase the configuration. I would think that UDP wouldn't open "connections", it should be stateless so copying the packet and sending it should be the end of the process, didn't think I would run out of "open files" with UDP. The traffic rate was 1000 packets per second. My goal is 15000 pps. I can receive 15000 pps directly to the ipfixcol software on this server before I begin to lose any data. I know the server can handle the load, so figure PEN would be a nice addition to spread the load a bit. Thanks for the link to the reverse proxy. I couldn't find information on it yesterday. |
I've been trying to reproduce the problem but not really had any success. Here 192.168.1.1 send "garbage" using iperf to 192.168.1.2, which is Pen load balancing round robin across 192.168.2.2 and 192.168.2.3. There are no iperf servers running on those last two, only tcpdump to see that they get the traffic.
As seen from "debtest":
And "test1":
That "connect" error is interesting, it looks like a bug. It doesn't seem to affect anything though. On "test3":
And finally "test4":
|
Thanks for looking into this Ulric, the only difference between your test above and min, I was attempting to send to two other ports on the same host. |
Trying that:
Pen, latest code from git:
Tcpdump:
|
@UlricE HI Ulric, I'm testing PEN to see if it works for me and I'm wondering what I'm doing incorrect.
I would like to start multiple instances of https://github.com/CESNET/ipfixcol on a server and I would like to put PEN as the gatekeeper to redirect incoming packets to the instances.
I'm starting one instance of ipfixcol on port 50000, and another instance on 50001
I start PEN with this command
pen -ddfUs -x 15000 4739 10.73.198.150:51000 10.73.198.150:51001
As you can see, I'm running PEN and the two instances of ipfixcol on the same VM.
When I send packets directly to ipfixcol, I collect about 500,000 unique records. When I send packets through PEN (port 4739), I'm only storing about 5,000 unique records. Somewhere data is getting lost. One issue is that too many "ports" are getting opened
All I really want to do is forward UDP incoming on port 4739 to other ports on the same box. I've tried forwarding to localhost 127.0.0.1 and then the eth0 IP (as above), I get the same massively lost amount of data.
Based on everything I read, PEN should be able to handle this no problem, but I can't seem to find the right keys.
Also, I lose the original address of who sent the packet, the new sender is now the address of PEN. Anyway to preserve the actual original packet received so that the original sender is saved?
Thanks!
ps, I also turned off debugging and get same results, I'm missing something for sure.
The text was updated successfully, but these errors were encountered: