I have a lot of resets on the network, can someone tell me what are the resets an what do the represent. asked 18 Jul '13, 14:32  ejohnson7 |
3 Answers:
OK, since the 10.97.54.9 is a load-balancer (and presumably the 10.97.54.8 is it's counterpart in the LB-cluster) it all makes sense. If you filter on 10.97.54.9, you can see that there is a session each 5 seconds. Load balancers have a health monitoring system to determine which servers are still alive. It looks like your load balancer is configured to use a TCP health monitor (probe in Cisco ACE terms). It will do a 3-way-handshake and then terminate the connection as it is done checking whether the TCP port is open and responding. answered 19 Jul '13, 12:06  SYN-bit ♦♦ Thanks Guys that is the answer for part of the puzzle. Thanks for the help because I am knew to all this Thanks Kurt SYN-bit and Jasper Appreciate it much my friends (19 Jul '13, 12:27) ejohnson7 you guys rock i have another one i will post later today that has me puzzled (19 Jul '13, 12:30) ejohnson7 |
In your case it looks like the client is closing connections right after they have been established, which is a little odd. Maybe it is some kind of test of the port is open, like a monitoring system checking if the port is still being serviced. You should find out what kind of device the client is and why it connects to that port. answered 18 Jul '13, 15:08  Jasper ♦♦ edited 18 Jul '13, 15:18 yes we are running test and they are using monitoring system to observe the operation. i is a Microsoft tool I believe (19 Jul '13, 11:42) ejohnson7 Thanks Jasper (19 Jul '13, 12:16) ejohnson7 |
The MAC address for the client (10.97.54.9) is different in Frame #1 (c0:62:6b:ad:d6:c1) and Frame #2 (00:00:0c:9f:f1:47). Either there is a cluster software/algorithm in place or the different MAC addresses are part of the problem (e.g. duplicate IP address). Please check if those two MAC addresses are what you expect for the client (10.97.54.9) in your environment. BTW: According to the time deltas of the frames, I believe you captured at (or near) the server. So, the TCP RESET could be caused by a firewall or a loadbalancer between client and server instead of the client (as it looks in the capture file). That would also explain the different MAC addresses, which could then be part of the cluster solution for your firewall (Cisco) or loadbalancer (also Cisco). Regards answered 19 Jul '13, 01:45  Kurt Knochner ♦ edited 19 Jul '13, 01:56 As the SYN/ACK and the RST come from the same mac-address I don't think there is a duplicate IP issue. The mac-addresses both are Cisco, so you might want to check whether there is asymmetric routing that causes the issue? Maybe some statefull filtering on the Cisco's (are they routers or firewalls or ... ?) (19 Jul '13, 02:11) SYN-bit ♦♦ 1 @Sake: check again: SYN, ACK and RST are same MAC - SYN/ACK is not (19 Jul '13, 02:39) Landi Sorry, I meant, the SYN, the ACK and the RST. That the SYN/ACK comes from a different mac-address could be a first hop redundancy protocol or asymmetric routing. (19 Jul '13, 02:58) SYN-bit ♦♦ I believe the source MAC (c0:62:6b:ad:d6:c1) is the node address of a firewall or loadbalancer cluster and the destination MAC (00:00:0c:9f:f1:47) is the cluster/virtual/floating (you name it) address of the cluster. (19 Jul '13, 04:06) Kurt Knochner ♦ Kurt the ip address 10.97.54.9 is a load lancer the servers are all VM servers. The captures are being collected closer to the server so you say that would explain the resets. They are still testing so I will keep you update dated (19 Jul '13, 11:56) ejohnson7 Thanks much Kurt (19 Jul '13, 12:16) ejohnson7 thanks for the help with this case (20 Jul '13, 19:10) ejohnson7 showing 5 of 7 show 2 more comments |
thanks in advance