Packet drops while connecting fiber patch code between two switch.

[riadreza]

Hello !

We have a core switch nexus 9000 and a distribution switch catalyst 4500X . If we connect or disconnect the fiber patch code between them then the core switch got packet loss for 5 sec. then every thing get normal again. 

For your information, they are connected 10G SFP+.

Please help me in this regards. 

[LanDownUnda]

Hi Riadreza,

Just confirming the scenario for my understanding here (correct me at any point if I'm wrong):

1. Your patching a Nexus 9K and a Catalyst 4500x together using a 10G SFP+
2. You are experiencing packet loss between the devices when disconnecting the Fibre. The Rest of the Nexus 9K Switch is performing well without any hiccups?
3. When you reconnect the Fibre you notice the packet loss issue is resolved.

I would expect some amount of packet loss when disconnecting the Fibre between the devices as traffic that is in transit would be reported back as packet loss.

A couple of questions from me:

-What sort of issues is it causing you?

-Have you compared the interface statistics between devices to see errors?

-Have you tried using a different SFP?

-Have you tried using a different Fibre Lead?

-What sort of configuration is on the interface that is causing the packet loss?

-Are you seeing any other errors/issues on the Nexus 9K?

[riadreza]

hi,

2. i am experiencing this in whole network. as all other distribution switches are connected to core switch.

3. when I reconnect, this occur and this packet loss observers for 5 seconds. 

- As all other distributions are connected to the core switch, so every connectivity got interrupted. 

- Yes. I have checked with other devices, no change in configuration.

- Yes.

- yes

- all the port for core and distribution switch are trunk. 

-no error found.

regards. 

[mdamirulislam]

You can check VTP and VLAN Looping if configured.

[Mark Malone]

Check if your seeing STP constant re-convergence at layer 2 command below , that can cause network spin out when links are pulled or added

Sounds as if the root stp may be wrong somewhere or your adding a link which is better than the current link as its 10gb and being preferred so stp is reconverging to suit that path and use it

is there another link to between them in play , you could try prevent the re-convergence by weighting that link first at layer 2 with spanning tree cost but you should try and confirm the STP layer 2 design first as that sounds like the issue

show spanning-tree detail | inc ieee|occurr|from|is exec

[riadreza]

Hello,

Thank you for your reply.

I have executed the command. result is:

CEPHDIST-252#show spanning-tree detail | inc ieee|occurr|from|is exec
VLAN0001 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 118 last change occurred 03:09:14 ago
from TenGigabitEthernet1/7
VLAN0010 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 173 last change occurred 00:41:18 ago
from TenGigabitEthernet1/15
VLAN0011 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 281 last change occurred 00:39:40 ago
from TenGigabitEthernet1/15
VLAN0012 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1443 last change occurred 00:00:30 ago
from TenGigabitEthernet1/7
VLAN0013 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 128 last change occurred 00:21:21 ago
from TenGigabitEthernet1/7
VLAN0014 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 471 last change occurred 00:09:16 ago
from TenGigabitEthernet1/7
VLAN0015 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 54 last change occurred 03:19:18 ago
from TenGigabitEthernet1/7
VLAN0025 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 142 last change occurred 00:40:42 ago
from TenGigabitEthernet1/7
VLAN0026 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 108 last change occurred 00:36:54 ago
from TenGigabitEthernet1/7
VLAN0027 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 67 last change occurred 00:27:59 ago
from TenGigabitEthernet1/7
VLAN0030 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 165 last change occurred 00:10:16 ago
from TenGigabitEthernet1/7
VLAN0031 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:17 ago
from TenGigabitEthernet1/7
VLAN0032 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 61 last change occurred 03:19:19 ago
from TenGigabitEthernet1/7
VLAN0035 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 63 last change occurred 03:19:19 ago
from TenGigabitEthernet1/7
VLAN0036 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 326 last change occurred 00:10:17 ago
from TenGigabitEthernet1/7
VLAN0070 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 106 last change occurred 03:19:54 ago
from TenGigabitEthernet1/15
VLAN0099 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 70 last change occurred 03:19:20 ago
from TenGigabitEthernet1/7
VLAN0147 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:20 ago
from TenGigabitEthernet1/7
VLAN0201 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1480 last change occurred 00:00:31 ago
from TenGigabitEthernet1/7
VLAN0203 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:19 ago
from TenGigabitEthernet1/7
VLAN0204 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 161 last change occurred 03:19:20 ago
from TenGigabitEthernet1/7
VLAN0205 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 166 last change occurred 00:39:07 ago
from TenGigabitEthernet1/15
VLAN0206 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 79 last change occurred 00:48:15 ago
from TenGigabitEthernet1/7
VLAN0220 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 56 last change occurred 03:19:19 ago
from TenGigabitEthernet1/7
VLAN0222 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:21 ago
from TenGigabitEthernet1/7
VLAN0225 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:21 ago
from TenGigabitEthernet1/7
VLAN0230 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:21 ago
from TenGigabitEthernet1/7
VLAN0250 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:20 ago
from TenGigabitEthernet1/7
VLAN0301 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:21 ago
from TenGigabitEthernet1/7
VLAN0420 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 55 last change occurred 03:19:21 ago
from TenGigabitEthernet1/7
VLAN0999 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 16 last change occurred 1d05h ago
from TenGigabitEthernet1/15

It seems that, most of the  VLAN STP topology coming from port TenGigabitEthernet1/7.

But my distribution Switch (4500 X) uplink is from TenGigabitEthernet1/15 to core switch (nexus 9K).

Whereas TenGigabitEthernet1/7 is a uplink of a access switch (Connected with 10G link).

For your information, there is no root bridge configuration in the network.

[Mark Malone · Accepted solution]

Ok so at least we know now whats happening its a layer 2 convergence issue
there has to be a root bridge even if you did not select it and you should always control STP even though its automatic feature in terms of convergence but you should know exactly whats going to happen when you pull or connect a link and control this by setting it up in a layer 2 design

your 9k should be set with root for all vlans that its owns , so if the SVIs are on that switch then it should be root , your 45 then would be backup root set at say 8192 for the all the vlans too, then all other access switches could be left standard , there should be some control over STP

All your seeing is a convergence issue and thats expected when you introduce new links into the layer 2 domain , after the convergence it should stabilize though yes ?

Any changes you make to a layer 2 domain whether pulling cable or resetting the values on switches or the stp you will see something like this


sh spanning-tree root

Root Hello Max Fwd
Vlan Root ID Cost Time Age Dly Root Port
---------------- -------------------- ------ ----- --- --- ----------------
VLAN0001 4097 0008.e3ff.fd90 0 2 20 15
VLAN0033 4129 0008.e3ff.fd90 0 2 20 15
VLAN0035 4131 0008.e3ff.fd90 0 2 20 15
VLAN0054 4150 0008.e3ff.fd90 0 2 20 15
VLAN0059 4155 0008.e3ff.fd90 0 2 20 15
VLAN0060 4156 0008.e3ff.fd90 0 2 20 15
VLAN0159 4255 0008.e3ff.fd90 0 2 20 15
VLAN0169 4265 0008.e3ff.fd90 0 2 20 15
VLAN0201 4297 0008.e3ff.fd90 0 2 20 15
VLAN0202 4298 0008.e3ff.fd90 0 2 20 15
VLAN0226 4322 0008.e3ff.fd90 0 2 20 15
VLAN0324 4420 0008.e3ff.fd90 0 2 20 15
VLAN0850 33618 0008.e3ff.fd90 0 2 20 15
VLAN1222 5318 0008.e3ff.fd90 0 2 20 15

[riadreza]

Thank you. 

It was a great help for me. :)