RSTP and PXE

I'm trying to understand something my boss is working on. The way we have our network setup is with a L3 switch performing the "routing" functions and then multiple switch are chained off of that. At the end there are all computer clients connected. All switches has RSTP running and when we try to PXE boot clients (server is in seperate vlan) they all fail after they start to pull down the image file. Enabling portfast on the switches seems to fix this issue, however I'm trying to understand why....

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

xwesleyxwillisx

Sounds like the download is timing out due to the port running through spanning tree.

Without portfast the port will not forward any frames for 30-40 seconds...

When portfast is enabled the port will immediately transition to the forwarding state and pass frames. To clarify, RSTP has nothing to do with portfast, they are seperate terms and functions.

Neeko

xwesleyxwillisx wrote: »

Sounds like the download is timing out due to the port running through spanning tree.

Without portfast the port will not forward any frames for 30-40 seconds...

When portfast is enabled the port will immediately transition to the forwarding state and pass frames. To clarify, RSTP has nothing to do with portfast, they are seperate terms and functions.

But portfast does have a direct effect on RSTP as you've explained, or did you mean portfast is not an exclusive feature to RSTP?

xwesleyxwillisx

Neeko wrote: »

But portfast does have a direct effect on RSTP as you've explained, or did you mean portfast is not an exclusive feature to RSTP?

My original explanation was worded poorly. I only meant RSTP != portfast. Running RSTP does not automatically mean your edge ports will have portfast capability, it would still need to be enabled. In RSTP, portfast designates the ports as "edge" ports. This is analogous to STP portfast ports.

From Cisco:

Understanding Rapid Spanning Tree Protocol (802.1w) [Spanning Tree Protocol] - Cisco Systems

Neeko

xwesleyxwillisx wrote: »

My original explanation was worded poorly. I only meant RSTP != portfast. Running RSTP does not automatically mean your edge ports will have portfast capability, it would still need to be enabled. In RSTP, portfast designates the ports as "edge" ports. This is analogous to STP portfast ports.

From Cisco:

Understanding Rapid Spanning Tree Protocol (802.1w) [Spanning Tree Protocol] - Cisco Systems

Yeah, I'm with you. You still have to enable portfast basically, STP doesn't do that for you.

miller811

you can also run the switchport host command on the end user ports which will change the ports to access and enable spanning-tree portfast

DLS1(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled

interface FastEthernet0/7
switchport mode access
spanning-tree portfast

NightShade03

Thanks for the clarification. I want to go one step further however. Looking into bpduguard vs bpduguard filter. The difference between the two isn't entirely clear in Cisco's documentation.

Neeko

miller811 wrote: »

you can also run the switchport host command on the end user ports which will change the ports to access and enable spanning-tree portfast

DLS1(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled

interface FastEthernet0/7
switchport mode access
spanning-tree portfast

Nice tip, thanks.

miller811

NightShade03 wrote: »

Thanks for the clarification. I want to go one step further however. Looking into bpduguard vs bpduguard filter. The difference between the two isn't entirely clear in Cisco's documentation.

bpduguard—Detects when a spanning-tree bridge protocol data unit (BPDU) is received on a port configured for STP portfast. If an error condition is detected, the switch port is put into the errdisable state and is disabled.

You should use BPDU guard on all switch ports where STP PortFast is enabled. This prevents any possibility that a switch will be added to the port, either intentionally or by mistake. An obvious application for BPDU guard is on access-layer switch ports where users and end devices connect.
BPDUs normally would not be expected there and would be detected if a switch or hub inadvertently was connected.

BPDU Filtering—filters BPDUs on a switch port to prevent the port
from participating in STP altogether. Bridging loops are neither detected nor prevented.

STP operates on all switch ports in an effort to eliminate bridging loops before they can form. BPDUs are sent on all switch ports—even ports where PortFast has been enabled. BPDUs also can be received and processed if any are sent by neighboring switches. You always should allow STP to run on a switch to prevent loops. However, in special cases when you need to prevent BPDUs from being sent or processed on one or more switch ports, you can use BPDU filtering to effectively disable STP on those ports.

mella060

Basically Portfast should be enabled on ports connected to devices that don't participate in the STP topology. Devices such as PC's, servers, routers.

By default when you connect a PC to a switch port you will notice that the light stays amber for around 30 seconds. Most PCs boot quicker then that these days so you will get issues with getting an IP from a DHCP server.

NightShade03

So essentially you'd be using either PortFast + BPDUGuard (to prevent accidental loops) or BPDU Filter (to prevent STP from working all together)?