Ports are down

  • 2
  • Question
  • Updated 3 years ago
  • Answered
I have several ports that are down on my switch showing access down or access down stpd. No matter what devices I plug into those ports they don't allow access how do I fix it or are they just bad ports.
Photo of Ryan Benner

Ryan Benner

  • 3 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 2
Photo of Brian Powers

Brian Powers, Champ

  • 391 Posts
  • 91 Reply Likes
Just a quick shot in the dark here, but without trying to replicate it, I'd say stpd has to do with Spanning Tree Protocol (stp) and d for Down?  Which would mean they were most likely disabled to prevent a loop on the LAN of some sort.  You should be able to get into the CLI of the switch and do something along the lines of "no int eth1/x shutdown" (where x is the port number).  That may bring them up.  A reboot may bring them all back up too, but may not be the best option if other devices are being server with this switch.

Hope that helps and if I can get some more time, I will try to find more about that down stpd message you are getting.
Photo of Ryan Benner

Ryan Benner

  • 3 Posts
  • 0 Reply Likes
I figured it was STP but why it did that with only a select few ports was interesting to me. I rebooted the device and all is well. Kind of an odd situation as I was just moving from my dell to these aerohives and about 15 of my ports were down STPD.
Photo of J. Goodnough

J. Goodnough, Champ

  • 265 Posts
  • 32 Reply Likes
if stp detected a loop you may have had to manually kick them out of disabled, as Brian mentioned. If they were down without ever having anything plugged into them, that would look like some sort of bug to me.
Photo of Matt Kopp

Matt Kopp

  • 47 Posts
  • 12 Reply Likes
I ran into this today on a couple of loaner switches we'd deployed to a customer site.

The best way I found to alleviate the issue, without rebooting, was to, on the CLI, run:

no interface eth1/1 spanning-tree edge-port
no interface eth1/3 spanning-tree edge-port

interface eth1/1 shut
interface eth1/3 shut

no interface eth1/1 shut
no interface eth1/3 shut

interface eth1/1 spanning-tree edge-port
interface eth1/3 spanning-tree edge-port
Of significance, we've found that if you connect an AP or like item into an Access Port with STP enabled (STP or RSTP) it will place the port into Down (ah_stpd) status.  Obviously we had issues on Eth1/1 and Eth1/3, but you get the idea.

The other issue we encountered was that converting a port from Access to Trunk did not actually remove the STPD status.  Downing/Upping the port did not have an effect until we ran the first command above.  To be safe, we also ran:
no interface eth1/1 spanning-tree bpdu-protection bpdu-guard
Which removed the remnants of STP on that port.  Bear in mind, the running configuration (sh run) did not have any STP commands listed for the trunk port.  Just something to be aware of.

What ultimately cause the issues we encountered today was a Cisco WAP321 (we inherited the client, we're working on AP230s ;) ), a Sonos Bridge, and the Firewall uplink.  None of the devices have VLANs configured, but all of them wanted in on BPDUs.  Once the ports were reset and had the aforementioned clear-out, life's groovy.
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
spanning-tree bpdu-protection bpdu-guard

if the switch sees this a bpdu on a access port - this security feature will shut the port down.

in the C world - you can have error recovery enabled to automagically bring port back up to see if the offending device has been removed. Not sure it's an option in AH switches yet.

I believe for trunks you would expect bpdus, but usually you would run spanning tree per vlan instance.

Photo of Matt Kopp

Matt Kopp

  • 47 Posts
  • 12 Reply Likes
You got it.  The caveat we, specifically, ran into was when converting the port from Access (while in ah_stpd state) to Trunk, the port did not remove the down state and reset the BPDU Guard.  More specifically, it didn't show the BPDU functions in the CLI when running a sh run command - just by whim did I run the 'no' commands, down and re-up the port to make it work.

Seems like what could be a bug to me - again, it wasn't a complete config written, but if it doesn't show up in CLI, one should be able to trust that it is no longer effecting things, no?