Most likely cause of network input errors?
I have an HA pair of LTMs running 10.2.3. On one vlan I am incrementing input errors at the same exact rate on both the active and passive units. Discussing with our network engineer, he says he has seen this before at another job, but can't quite remember the cause. He believes it is a case of the LTMs not understanding some type of traffic coming across the port and dropping it as a result. Have any of you ever encountered anything like this? Thanks, Chris
Connection loss Client -> F5 BIGIP LTM
Hi all, I am currently experiencing an issue with an application that is being used on 3 application servers (windows server 2003), loadbalanced behind the F5 BIGIP. Users are sometimes losing connection to the server, which makes the application crash. I have launched a capture for one of these clients and I'm seeing the following when this issue occurs (capture.png): Client: 10.229.237.235, IP of virtual server on BIGIP: 172.20.5.41 From what I can see there is no SYN-ACK being returned from BIGIP. There are also a lot of messages in the log containing TCP Window Full & TCP out of order. When we let the user connect directly to an application server instead of passing through BIGIP, they have no issues. The capture is also very clean in that case, no retransmissions, no duplicate acks or TCP resets.. The TCP protocol being used is Protocol Profile (Client) - TCP LAN Optimized and for Protocol Profile (Server) - TCP WAN Optimized. Does anyone have an idea why BIGIP doesn't send a SYN-ACK in this case? I was thinking maybe an issue with receiving window & send buffers.. Or would I need a capture on the virtual server to further analyze this behaviour? Any help would be greatly appreciated! Thank you Kind regards Ron
Intermittent Net::ERR_CONNECTION_RESET Error and Incomplete Loading over HTTPS
I have an F5 load balancing setup configured with two servers. My MVC web application, which incorporates Kendo UI, Jquery, and bootstrapping, is hosted on an IIS server with an SSL certificate. However, when accessing the application via HTTPS from outside the server, it often or sometimes results in a 'net::ERR_CONNECTION_RESET' error, with intermittent failures to load javascript and CSS files to the client browser. Strangely, upon reloading the page, the assets load properly, and the page functions as expected. This issue did not occur when the application was accessed via HTTP, where it worked properly without any issues. What could be the reason behind this problem?
New i2800 to Cisco 93180YC-FX3 Twinax
I've seen older post and I've used these before but cannot get them working now. Does anyone know if you can still use the Cisco Twinax cables (SFP-H10GB-CU3M)? My F5 is showing the following: Net::Interface Name Status Bits Bits Pkts Pkts Drops Errs Media In Out In Out --------------------------------------------------------------- 1.0 up 0 0 0 0 0 0 1000CX-FD 2.0 miss 0 0 0 0 0 0 none 3.0 miss 0 0 0 0 0 0 none 4.0 miss 0 0 0 0 0 0 none 5.0 down 0 0 0 0 0 0 none 6.0 down 0 0 0 0 0 0 none mgmt up 20.2G 6.2G 1.7M 670.7K 0 0 1000T-FD net interface 5.0 { if-index 352 mac-address 14:a9:d0:06:80:88 media-max 10000T-FD module-description "Unsupported Optic detected" mtu 9198 serial JPC23220CWT vendor CISCO-JPC vendor-oui 001897 vendor-partnum P3410UB03000-1 vendor-revision A0Strange SNAT IP address behaviour
Hello everyone, Recently we've discovered a weird behaviour on our BIG-IP system. We are currently running version 11.5.1 on an 8950 Active/Passive HA pair. We have detected that a couple of servers, due to misconfiguration, are generating UDP traffic to port 1002 of an SNAT IP address which belongs to a SNAT Pool. Our BIG-IP is bouncing that traffic back to the network simply changing source an destination MAC address on the ethernet header. You can see it on the following screenshots: Is this an expected behaviour? Shouldn't F5 just drop this traffic? As additional info: the VS to which this SNAT Pool belongs is configured for port 80 HTTP. Thank you very much in advance for your answers. Best regards, Carlos
