I am currently wrapping up my ICND2 studies and started reviewing some official Cisco Press documentation. This statement has been bothering me for some time now.
I quote, "Portfast is used on access ports that are connected to a single workstation or server to allow these devices to connect to the network immediately rather than waiting for STP to converge. Portfast is useful if a workstation is configured to acquire an IP address through DHCP. The workstaion can fail to get an IP address because the switch port the workstation is connected to might not have transitioned to the forwarding state by the time DHCP times out".
I completely understand that portfast will allow the port to transition to forwarding immediately, but that statement makes no sense. On most networks, the DHCP server can be swithces and trunks away, especially if we are following the standard Cisco 3 layer model.
The point it's trying to make is that the PC attached to the switchport will query for an address, but it will not get one because portfast is not enabled and the PC DHCP request will timeout.
Hope that helps.
I understand what it said, I am trying to state that it does not make any sense.
Portfast appears to be useless in most networks, especially campus networks based on the cisco 3 layer model. In most companies, the DHCP server is on a completely different segment than the host.
The host will never get a DHCP address during convergence because the switch the host is connected to is in a blocking state with the distribution switch.
How often do you think the network will be in convergence? It's not often, or at least it shouldn't be. Portfast is a very important feature for access only ports. You are correct that DHCP servers are on different subnets, but you use ip helpers to forward the DHCP requests to the DHCP server.
In addition to Collin's post if a port is not enabled with portfast every time the end device is switched off and on the port will generate an STP TCN (Topology Change Notification) which you really don't want.
So portfast is anything but useless in a switched network.
Now that makes sense! I just found the statement about DHCP to be a very bad example of an edgeport. It never crossed my mind that a host on a port not configured with portfast would trigger a TCN. Very useful fact!
I believe that the DHCP example is a very good one in that when the machine on that port comes up, if the port doesn't go forwarding right away then the DHCP request from the end station will not get to the router and forwarded on (because it doesn't get there) before the time out occurs on the end station. so when port fast is not enabled a lot of machines will not get IP addresses due to timeout issues on the dhcp request.
I think everyone is missing my point.
In a common topolgy with a core, distribution, and access layer switch, the portfast command will be useless for the sole purpose of acquiring a DHCP address.
This is due to the fact that the trunking ports will be listening for BPDU's and dropping frames for the alloted amount of time and any DHCP request will not make it to the DHCP server anyway.
Maybe I am wrong or missing something? Everything else i've learned points to this being a fact for standard PVSTP/STP.
I think you are missing everyone else's point :-)
Trunking ports do not drop frames for an allocated amount of time - i'm not sure where you got this concept from. If there is an STP convergence then yes maybe so but in normal operation trunk ports will forward all traffic, unless of course they are blocked by STP. But they would only be blocked by STP if there was another active path.
So what everyone is saying is that without portfast the client will still send DHCP requests but they will not go anywhere because the port that the client is connected to is not forwarding.
With portfast the port that the client is connected to can forward immediately. So the client sends out a DHCP request and this gets forwarded on to the DHCP server, whether that server is on the same vlan or another vlan, assuming you have an ip helper-address configured.
Nothing else will drop that packet ie. there will be a path to the DHCP server whether the DHCP server is in the distribution or core layer.
=) Ok, it just dawned on me.
What you are saying is my situation is only during convergence, which does not happen very often.
During normal operations when everything is up and running just fine (99.89% of the time) the edgeport will bypass listening/learning and go directly to forwarding allowing it to access the DHCP server before the PC's request times out.
That was so obvious, I just got caught up on convergence that I overlooked that fact.
Sorry for wasting everyones time and thanks for helping me understand this a little more clearly!
Thats why Cisco is saying in the documentation "Portfast is used on access ports that connected to a single workstation or Server". If you are following the 3 layer model, then make sure portfast is not configured on trunk ports , this could result in Spanning-tree loop. I mean of course, if you have a single path to the upstream switch then there is no possibility for aloop and you can configure "portfast". But if you have redundant links, then never set portfast on the uplinks.
Anyone who can clarify what exactly the "spanning-tree portfast trunk" command is for?
According to documentation:
"You should use this feature only with interfaces that connect to end stations; otherwise, an accidental topology loop could cause a data packet loop and disrupt the Catalyst 4500 series switch and network operation."
But then it states:
"spanning-tree portfast trunk - This command allows you to configure PortFast on trunk ports.
Note If you enter the spanning-tree portfast trunk command, the port is configured for PortFast even when in the access mode."
My understanding is that it is used primarily when you have a server that is running 802.1q on it's NIC card and so you know it is an end host connecting to the port.
Consider situations where you have a virtual environment (hyper-v or vmware for example) where multiple logical servers sit on the same physical interface. You may wish logicalserv1 to be on vlan25 and logicalserv2 to be on vlan 2. Therefore you run a trunk connection to the virtual server interface.
The spanning-tree command you mention is great for that type of scenario.