2

There is a wireless Ubiquity bridge set up between our main building and this switch in a building across the street. The Ubiquity connection never appears to have any issues, it's just the cisco. Every few days, the Cisco will go offline (and therefore the whole building) and the only way to get it back up is to unplug/replug the trunk port. We've replaced all the cables and tried a different switch port. We're having a recurring issue every few minutes that outputs in the cisco log like this:

Feb 19 14:12:31.200 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 2 Feb 19 14:12:32.191 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1088, changed state to up Feb 19 14:14:55.700 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1088, changed state to down Feb 19 14:14:56.644 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/48, changed state to down Feb 19 14:14:57.666 Pacific: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/48, changed state to down Feb 19 14:15:00.162 Pacific: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/48, changed state to up Feb 19 14:15:01.164 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/48, changed state to up Feb 19 14:15:16.217 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 10: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180 Feb 19 14:15:16.223 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 10 Feb 19 14:15:17.250 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 2: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180 Feb 19 14:15:17.256 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 2 Feb 19 14:15:17.303 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1088, changed state to up Feb 19 14:26:48.075 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 20: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180 Feb 19 14:26:53.569 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 20: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180 Feb 19 14:36:43.014 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1088, changed state to down Feb 19 14:36:43.958 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/48, changed state to down Feb 19 14:36:44.980 Pacific: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/48, changed state to down Feb 19 14:36:47.476 Pacific: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/48, changed state to up Feb 19 14:36:48.477 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/48, changed state to up Feb 19 14:37:15.505 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 2 Feb 19 14:37:15.532 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1088, changed state to up Feb 19 14:37:18.122 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 10 Feb 19 14:37:18.122 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 10: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180 Feb 19 14:37:19.165 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 7 Feb 19 14:37:19.165 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 7: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180

The port is configured like this:

interface GigabitEthernet1/0/48 switchport trunk native vlan 10 switchport trunk allowed vlan 2-1088 switchport mode trunk switchport nonegotiate mls qos trust dscp

UPDATE Diagram: enter image description here

Spanning tree is still a new concept to me, so I am hoping someone may be able to help. Please let me know if you need any more information.

UPDATE: I just found these messages today in the log from the switch in our main building (Cisco 3750), during the time when the switch across the street was down:

Feb 20 02:29:42.386 Pacific: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/45 (not half duplex), with 222-core-2960 GigabitEthernet1/0/48 (half duplex). Feb 20 02:30:42.420 Pacific: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/45 (not half duplex), with 222-core-2960 GigabitEthernet1/0/48 (half duplex). Feb 20 02:31:42.412 Pacific: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/45 (not half duplex), with 222-core-2960 GigabitEthernet1/0/48 (half duplex). Feb 20 02:32:42.421 Pacific: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/45 (not half duplex), with 222-core-2960 GigabitEthernet1/0/48 (half duplex). Feb 20 02:33:42.430 Pacific: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/45 (not half duplex), with 222-core-2960 GigabitEthernet1/0/48 (half duplex). Feb 20 02:34:42.431 Pacific: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/45 (not half duplex), with 222-core-2960 GigabitEthernet1/0/48 (half duplex). Feb 20 02:35:42.440 Pacific: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet1/0/45 (not half duplex), with 222-core-2960 GigabitEthernet1/0/48 (half duplex).

UPDATE 2/24 We've made some changes to the config and tested/replaced all the physical hardware and cables (Except for the port on the wireless bridge...) and are still getting issues. It seems that a LOOPGUARD_BLOCK often preceeds the short outages we're having. Here's another example from the logs

Feb 24 10:13:22.819 Pacific: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/48 on VLAN0002. Feb 24 10:13:22.867 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1088, changed state to down Feb 24 10:13:23.852 Pacific: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/48 on VLAN0010. Feb 24 10:13:37.291 Pacific: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/48 on VLAN0002. Feb 24 10:13:37.291 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 2: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180 Feb 24 10:13:37.296 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 2 Feb 24 10:13:37.348 Pacific: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1088, changed state to up Feb 24 10:13:38.334 Pacific: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/48 on VLAN0010. Feb 24 10:13:38.339 Pacific: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 10: New Root Port is GigabitEthernet1/0/48. New Root Mac Address is 442b.0387.5180 Feb 24 10:13:38.339 Pacific: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 10

Improve this question
6
  • 4
    STP doesn't look like it's involved. The physical interface is dropping.
    – Ricky
    Feb 19, 2020 at 23:49
  • What is Gi 1/0/48 connected to? A simple diagram would help.
    – Ron Trunk
    Feb 20, 2020 at 1:05
  • @RonTrunk It is connected to a Ubiquity dish that is a bridge to another Ubiquity across the street. That one goes inside our main building to another Cisco trunk port (that switch has a few trunks on it). I can get a diagram tomorrow
    – phandolin
    Feb 20, 2020 at 1:55
  • 2
    You have either a cabling problem or a hardware problem. For whatever reason, the connection to gi 1/0/48 is dropping. Bad cable, bad port, bad power injector or bad wireless bridge. You can ignore the spanning tree messages. That's just a result of the port going down.
    – Ron Trunk
    Feb 21, 2020 at 15:21
  • Disable CDP (and LLDP) on those links. Those frames shouldn't be bridged, but apparently are.
    – Ricky
    Feb 21, 2020 at 22:00

3 Answers 3

Reset to default
3

As it seems, the physical link is simply failing. Check cabling and connectors.

STP requires that you select the root bridge - it should be (one of) your most central switch(es). If you don't configure a root bridge it will be the switch with the lowest MAC address - essentially random.

A random root bridge that gets disconnected from the rest triggers a root re-election, completely rebuilding the spanning tree and temporarily disrupting all network traffic - you don't want that.

And while you're at it, also configure a designated bridge (close to the root) that takes over when the root fails.

The root bridge is the switch with the lowest STP priority value. The designated bridge is the one with the second lowest value.

Improve this answer
9
  • I just added some logs from the other switch stating CDP-4-DUPLEX_MISMATCH, could this be part of the problem?
    – phandolin
    Feb 20, 2020 at 23:22
  • Could be. You need to fix it in any case.
    – Ron Trunk
    Feb 21, 2020 at 0:07
  • 1
    Make sure you've set all interfaces to autonegotiation. If you do configure one side specifically you need to configure the other side as well. Forcing full duplex on one side and using autoneg on the other very reliably produces a duplex mismatch. Also, forcing a mode often prevents a link from using gigabit speed (where autoneg is mandatory).
    – Zac67 ♦
    Feb 21, 2020 at 7:23
  • 1
    @phandolin Simple cable testers are just good for continuity testing, shorts and pairing checks only. To really certify a cable you'd need a professional device ($1500+). For budget, I usually run a full speed, 1 Gbit/s loopback test for 10-20 minutes and when I get more than 1 or 2 errors the cable's done with.
    – Zac67 ♦
    Feb 21, 2020 at 15:26
  • 1
    That makes sense. Consensus seems to be on hardware/cabling so I will replace POE injector and figure out the roof cabling and report back. As for autonegotiate, is that just speed auto on the port config? Appreciate all the tips, thank you!
    – phandolin
    Feb 21, 2020 at 15:38
1

Look inside the port. Sometimes people bend the pins in the switch port when they push in the rj45 upside down, I have to tilt the cable upwards on my lab equipment because of this. Watch out for this in the PoE injector and ubiquity too.

Improve this answer
1

As was suggested by many folks, it turns out this was a physical issue. After tweaking the switch configs, changing out all the cables, switch ports, and POE injector, we finally replaced the Ubiquiti and it looks like the problem was on its outgoing ethernet port. It's been 2 days of solid connection, I appreciate all the tips.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.