Spanning tree and dhcp: Knowledge doesn't always imply action

I went through three semesters of the Cisco CCNA training around 6 years ago. I keep most of that knowledge in the part of my brain that I use frequently, so I don't lose it often. I do sometimes get my Cisco CLI mixed up with my Juniper ScreenOS CLI, but I do the same with Linux and Windows from time to time, and anyway, I'm digressing.

Since I use it relatively frequently, you would think that I would apply this knowledge to my troubleshooting endeavors, but no.

I was reading this thread on Tech Republic about switches, and by chance, someone mentioned using portfast to stop problems with DHCP clients.

The lightbulb above my head went on, and it finally connected. For the past few months, I'd had reports of intermittent connection problems in one of our offices. Users would have to manually release and renew their leases in order to get on the network. I had checked the DHCP settings and leases, and everything looked normal. It was just like Windows wouldn't ask for a lease. I *know* that spanning tree will stop DHCP leases. For some reason, I just didn't put the two things together.

Funny how our brain works (or doesn't) sometimes, isn't it?

By the way, if you're interested in learning more about how and why spanning tree blocks dhcp sometimes, check this page. The short of it is that when a port on a switch is first made active (you plug a cable in, or turn the computer on), the switch checks to see if that port is a loop, and it refuses to forward traffic while it's checking. Conveniently this is the same time that the computer is asking for a DHCP lease. No traffic + no dhcp response = no lease. This can be solved by telling the switch that the port shouldn't enable spanning tree on that port.