Results 1 to 6 of 6

Thread: Udp Packets drop by kernel

Hybrid View

  1. #1

    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 dont behavior like SLES 11 SP2. SLES 10 SP just forward the packets as expected.

    Thanks

  2. Re: Udp Packets drop by kernel

    Hi deo112,

    Quote Originally Posted by deo112 View Post
    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 dont behavior like SLES 11 SP2. SLES 10 SP just forward the packets as expected.

    Thanks
    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

    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

  3. #3

    Re: Udp Packets drop by kernel

    Quote Originally Posted by jmozdzen View Post
    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

    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

    Hi Jens

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

    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

  4. Re: Udp Packets drop by kernel

    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.

  5. #5

    Re: Udp Packets drop by kernel

    Hi Jens

    First thakns for you help :-)

    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

  6. Re: Udp Packets drop by kernel

    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

    "netstat -rn" is for printing the current routing table, thus grep'ing for the port number is counter-productive

    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

    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

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •