- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-19-2007 01:13 PM - edited 03-05-2019 02:59 PM
Switch to switch?
Switch to server?
Switch to desktop?
Switch to router?
Switch to firewall?
By the way, I've decided to disable auto-negotiation and set speeds for 100/full or 1000/full for ports and connecting hosts.
Solved! Go to Solution.
- Labels:
-
Other Switching
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-19-2007 01:24 PM
Chris
Portfast is appropriate when you are sure that you are connecting to a single device that will not potentially bridge you to other ports. So portfast is fine switch to server, desktop, router, and firewall.
What you do about auto-negotiation does not have any impact on portfast or not. I will just observe that when you configure speed and duplex on one device it will not negotiate with the other device. That means if the device connected to the switch is auto for speed or duplex it will fail negotiation and the assumption then is to do half-duplex. So you need to be careful to configure every device that connects to the switch.
HTH
Rick
Rick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-19-2007 01:19 PM
Portfast is designed for access ports where you never expect to see BPDU packets. Portfast shortens/bypasses normal STP timers to get ports up and forwarding as quickly as practical. This typically is a host PC/Workstation.
It's used to minimimize the impact of STP TCN BPDU traffic when a simple host is being rebooted or connected to a switch.
It's a Layer 2 function so routers/firewalls are out.
Switch-to-switch connections are STP environments and need to talk BPDU with each-other, so Portfast shouldn't be enabled on these connections.
Servers and workstations should be portfast enabled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-20-2007 11:17 AM
Not for sure what you mean when you say "route/firewalls are out"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2020 10:28 PM - edited 08-29-2020 10:31 PM
Bcs they are L3 devices. Best way is to config Portfast only on point-to-point edge port types.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-19-2007 01:21 PM
Chris,
You don't want to enable porfast in situations that could cause spanning tree loops. With that said, in your scenario, you can enable portfast in all except between the 'switch to switch' connection under normal circumstances.
One other situation you don't want to enable portfast is if your router has multiple interfaces and they are part of the same bridge group then you don't want to enable portfast on the switchport(s). Although, you mayn't be having this setup it's a good to know that.
HTH
Sundar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-19-2007 01:24 PM
Chris
Portfast is appropriate when you are sure that you are connecting to a single device that will not potentially bridge you to other ports. So portfast is fine switch to server, desktop, router, and firewall.
What you do about auto-negotiation does not have any impact on portfast or not. I will just observe that when you configure speed and duplex on one device it will not negotiate with the other device. That means if the device connected to the switch is auto for speed or duplex it will fail negotiation and the assumption then is to do half-duplex. So you need to be careful to configure every device that connects to the switch.
HTH
Rick
Rick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-22-2007 12:24 PM
Another good way to do it is to enable the following commands globally:
spanning-tree portfast default
spanning-tree portfast bpduguard default
spanning-tree portfast bpdufilter default
Any switchport that is configured as an access port will then inherit the default commands--trunk ports do not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-25-2017 09:29 AM
It is not wise to use both bpduguard AND bpdufilter because bpdufilter kicks first and kills ANY BPDU which makes bpduguard useless. Using bpduguard only will allow you to shut down the port which is IMHO better.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2020 08:43 AM
Commonly, PortFast is only enabled for edge/access ports which host devices like workstations/PCs, but it can be enabled for other devices like servers and network devices like routers, FWs and even switches. (BTW, DHCP hosts sometimes have issues with STP startup delays.)
The reason some devices don't have PortFast enabled, even when they could, is because generally they keep their links constantly active, so they don't generate extra TCNs as their up/down port status doesn't change, and since you control such devices, hopefully you won't create any L2 loops using them. (User host/edge ports, "out there", are more of a risk of someone doing something wrong/unexpected.) Also, a delay of a few extra seconds, for the link to become active, is often not an issue with such devices, either. BTW, I recall (?) the "normal" port PortFast command doesn't apply to switch trunk ports (also recall, there is a PortFast command to enable on trunks, if desired). Remember, STP is only needed if there are intentional L2 loops (i.e. L2 backup paths) or for the unexpected/accidental creation of L2 loops.
"By the way, I've decided to disable auto-negotiation and set speeds for 100/full or 1000/full for ports and connecting hosts."
BTW, why?
Reason I ask, vendors for almost two decades now, have recommended auto be used for FE (multiple reasons for the recommendation), and I recall (?) auto is more, or less, expected (the standard?) for gig.
