Udp Packets drop by kernel

Hi all

I have a customer there had some UDP packets loose. I found this 4 following triggers:

• SLES 11 with SP2.
• Alias IP configured on an interface.
• IP traffic send as UDP without any checksum in the header to the alias IP address.
• No route to the source IP address.

If all 4 triggers where true, the IP packet will be drop by the kernel.
I could reproduced it with netcat.

The fix where to make a route to the source IP address.

Does anyone have any explantion on this behavior ?

SLES 10 SP2 don´t behavior like SLES 11 SP2. SLES 10 SP just forward the packets as expected.

Thanks :slight_smile:

Hi deo112,

[QUOTE=deo112;13589]Hi all

I have a customer there had some UDP packets loose. I found this 4 following triggers:

• SLES 11 with SP2.
• Alias IP configured on an interface.
• IP traffic send as UDP without any checksum in the header to the alias IP address.
• No route to the source IP address.

If all 4 triggers where true, the IP packet will be drop by the kernel.
I could reproduced it with netcat.

The fix where to make a route to the source IP address.

Does anyone have any explantion on this behavior ?

SLES 10 SP2 don´t behavior like SLES 11 SP2. SLES 10 SP just forward the packets as expected.

Thanks :)[/QUOTE]

I assume this is a custom application sending these packets and you’re seeing some counter increase - or do you monitor the network?

Did I grasp that right that the application is sending out packets to a destination IP address that is configured as a secondary IP address on the (only) network interface of the sending host?

As you’re explicitly mentioning “without any checksum in the header” - is that checksum “0”? AFAICT a checksum field has to be present :wink:

Is offloading configured for the physical adapter?

Any messages in “dmesg” or syslog?

“no route to the source address” sounds strange - if the above is correct, the source address ought to be one of the local interface IP addresses - and you ought to have a routing table entry for that network.

Could you please give some more details, probably enriched by the output of “ifconfig”, “netstat -rn” etc?

With regards,
Jens

[QUOTE=jmozdzen;13626]Hi deo112,

I assume this is a custom application sending these packets and you’re seeing some counter increase - or do you monitor the network?

Did I grasp that right that the application is sending out packets to a destination IP address that is configured as a secondary IP address on the (only) network interface of the sending host?

As you’re explicitly mentioning “without any checksum in the header” - is that checksum “0”? AFAICT a checksum field has to be present :wink:

Is offloading configured for the physical adapter?

Any messages in “dmesg” or syslog?

“no route to the source address” sounds strange - if the above is correct, the source address ought to be one of the local interface IP addresses - and you ought to have a routing table entry for that network.

Could you please give some more details, probably enriched by the output of “ifconfig”, “netstat -rn” etc?

With regards,
Jens[/QUOTE]

Hi Jens

It is a custom application there are used and I also monitor the network :slight_smile:

I have attached to pictures there show the problem.

The first picture show netcat open the ip port, verify the port is open. The traffic can be seen on Wireshark but not by netcat.

http://www.flickr.com/photos/95798673@N07/8746444931/

Then I add the route to the source:

http://www.flickr.com/photos/95798673@N07/8747565410/

Now everything works.

Does anyone know want there have been change in SLES 11 SP2. This setup works with SLES 10 SP2 without any problems.

With Regards

Dennis

Hi Dennis,

Does anyone know want there have been change in SLES 11 SP2. This setup works with SLES 10 SP2 without any problems.

first of all, a kernel change from 2.6 to 3.0 happend… and with it, an updated network stack. Especially rp_filter functionality was fixed.

You might try out (as a quick test) to disable rp_filter on your interface.

Regards,
Jens

PS: For further help, please provide the output of “netstat -rn” before you add the explicit route, and the output of “ifconfig”. And again the question if there’s anything related in dmesg or /var/log/messages.

Hi Jens

First thakns for you help :slight_smile:

I have upload one new screenshot:
http://www.flickr.com/photos/95798673@N07/8787824163/

Where output from netstat -rn and ifconfig.

There are not anything in dmesg or messages about drop packets.

The rp_filter on eth3 is disabled by default

/Dennis

Hi Dennis,

I have upload one new screenshot:

no need for an image for such short information - you could have simply c&p the parts here :slight_smile:

“netstat -rn” is for printing the current routing table, thus grep’ing for the port number is counter-productive :smiley:

You have not yet really described your test setup, so I’m still guessing. I cannot tell if the UDP sender is on the same host or elsewhere. Might be irrelevant (see next line), but you need to provide a more detailed description in order to have others analyze complex networking problems: It’s about tracing the packet flow in one’s mind. Sender (complete IP configuration including routing table, firewalling, IP stack config…), intermediate network, receiver (again complete information). You may leave out information if it seems obvious or definitely unrelated, but in the current case, too much is left open :frowning:

Back to suggestions: What happens when you bind netcat explicitly to the proper IP? Even netcat’s documentation mentions possible quirks when listening to UDP on multi-homed machines…

Regards,
Jens