Forum Discussion

IanK_37848's avatar
IanK_37848
Icon for Nimbostratus rankNimbostratus
Feb 25, 2010

Limiting open port RST response

 

 

Hi Guys we have a D68 , and we keep getting these messages in the ltm log , and I am just trying to establish why we are getting them so frequently , and whether this could be a sign of something else that wrong much worse.

 

 

Feb 25 12:42:34 tmm tmm[1786]: 011e0001:4: Limiting open port RST response from 676 to 500 packets/sec

 

Feb 25 13:07:04 tmm tmm[1786]: 011e0001:4: Limiting open port RST response from 551 to 500 packets/sec

 

Feb 25 13:07:05 tmm tmm[1786]: 011e0001:4: Limiting open port RST response from 524 to 500 packets/sec

 

Feb 25 13:07:24 tmm tmm[1786]: 011e0001:4: Limiting open port RST response from 510 to 500 packets/sec

 

 

Thnx

 

Ian

1 Reply

  • Hi Ian,

     

     

    There are two related solutions on AskF5 for this message:

     

     

    SOL9259: Limiting the rate at which the BIG-IP system issues TCP RSTs or ICMP unreachable packets

     

    https://support.f5.com/kb/en-us/solutions/public/9000/200/sol9259.html

     

     

     

    When the BIG-IP system receives a packet matching a virtual server address and port or self IP address and port, but the packet is not a SYN packet and does not match an established connection, the following error message is logged to the /var/log/ltm directory:

     

     

    011e0001:4: Limiting open port RST response from to packets/sec

     

     

     

    SOL9812: Overview of BIG-IP TCP RST behavior

     

    https://support.f5.com/kb/en-us/solutions/public/9000/800/sol9812.html

     

     

     

    TM.RejectUnmatched

     

     

    By default, the TM.RejectUnmatched bigdb variable is set to true and the BIG-IP system sends a TCP RST packet in response to a non-SYN packet that matches a virtual server address and port or self IP address and port, but does not match an established connection. The BIG-IP system also sends a TCP RST packet in response to a packet matching a virtual server address or self IP address, but specifying an invalid port. The TCP RST packet is sent on the client-side of the connection, and the source IP address of the reset is the relevant BIG-IP LTM object address or self IP address for which the packet was destined. If TM.RejectUnmatched is set to false, the system silently drops unmatched packets.

     

     

     

    If you're seeing this consistently, it would seem that there might be asynchronous communication where a host is sending packets to a defined VIP which don't have a corresponding connection table entry.

     

     

    You can check this post for some suggestions on troubleshooting this:

     

     

    Methodolgy to ID source of DOS attack

     

    http://devcentral.f5.com/Default.aspx?tabid=53&forumid=32&tpage=1&view=topic&postid=31931

     

     

    Aaron