TCP Connection issues when STP topology change occurs

[j_molineux]

I have an issue with a LAN that I recently took over.  The problem I have occurs when a STP topology change occurs.

In the network I have 3560 switches at remote sites that connect back to distribution switches in another building. Each

of the remote switch have a six host connected.  Four of the host connect to a remote server application using UDP.  Two

of them connect using TCP.  I have configured all of the ports as edge nodes using portfast.  The issue I have is that 

occasionally one of the remote sites will drop power.  When power comes back up the switch rejoins the network which

causes a STP topology change to occur. This cause a problem across the entire LAN.  The UDP host at each remote site

are able to reestablish connectivity with the remote application monitoring them after STP convergence.  The problem is

with the TCP host.  When the topology change occurs the clearing of the CAM table during the topology change leaves

the TCP hosts orphaned.  The host at the remote sites have a half-open socket.  To resolve this problem requires an

operator to notice the problem and then manually cycle power on the device to clear the half-open socket.

I have two questions:  Can anyone explain to me why this occurs?  Is there anything I can configure on the switch

to tell the host to close the socket during an STP topology change?

Thanks ahead of time for any help

[Joseph W. Doherty]

As a guess, I would say TCP sessions might be using TCP keepalives, perhaps on one end and not the other, that timeout during the STP re-convergence.

Don't believe there's anything the switch can do do tell the host to close sockets.

However, what might help would be avoid or "speed up" STP convergence.

Do you have a root bridge manually assigned?  (Ideally you don't want a new STP root needlessly assigned.)

Are you using a "rapid" STP variant?  (By default, Cisco doesn't.)

You mention using portfast on edge ports, and especially if not using a rapid-STP variant, have you considered UplinkFast and/or BackboneFast?

Lastly, as you're using 3560 switches, as they are L3 switches, have you considered moving from a L2 topology to a L3 topology?

[j_molineux]

I am using rapid STP and have manually assigned a root bridge.  The switches that are causing the issue are not the root.  They are three layers below the root.  I wish I could go to an L3 topology.  The guy in charge, who ordered the switches, only paid for the basic license.  I believe I have to upgrade the license to get the L3 capability.  Hopefully in the future I can convice someone to give me some funding.  I had not considered uplinkfast or backbonefast.  I thought that  portfast would give me an advantage.  I will look into both of those.

[Joseph W. Doherty]

"I am using rapid STP and have manually assigned a root bridge."

Double check you're using rapid-STP on all your switches.  I mention this again because "standard" STP and rapid-STP can interoperate, although for such you don't get the full advantage of rapid if there are still some non-rapid device in topology.

"I believe I have to upgrade the license to get the L3 capability."

For advanced routing protocols, like OSPF and EIGRP, correct.  However, basic 3560 license supports static routing, and, I recall (?), RIP.

"I had not considered uplinkfast or backbonefast."

I think (?) they are already included in rapid-STP.

"I thought that portfast would give me an advantage."

It should for edge hosts, but you note the link between switches is what's dropping.

[MHM Cisco World]

friend there are three delay in Link come up,
DTP disable it 
duplex and speed "manual config it in both Server and SW port"
STP "you can use portfast"

for the Server TCP are sure there are no asymmetric flow here? if there asymmetric flow then the Host and Server still open session.

check FW L2 in both Core/Agg layer.

[j_molineux]

I hadn't thought of manually configuring the duplex and speed.  I will give that a shot.

[Joseph W. Doherty]

"I hadn't thought of manually configuring the duplex and speed"

BTW, that's very, very old school.  At least this century, network equipment vendors generally recommend using auto/auto.