Portfast on Trunk port Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Mixing Cisco STP Features: BPDU Guard, BPDU Filter, PortFast and PortFast TrunkCisco 2960 Portfast ports generate Spanning Tree TCNWhen does the Cisco IOS SNMP “ifCounterDiscontinuityTime” counter change?VLAN, Trunk and OSPFWhen should the portfast command be used on Cisco switchesACL on trunk PortConfigure pfSense VLAN TrunkTrunk Ports only Allowing Native VLAN?spanning tree loop with bpdufilter on acces port but not on trunk?when to make a port dynamic desirable instead of trunk?
If Jon Snow became King of the Seven Kingdoms what would his regnal number be?
Is the Standard Deduction better than Itemized when both are the same amount?
Is there a Spanish version of "dot your i's and cross your t's" that includes the letter 'ñ'?
Why is "Consequences inflicted." not a sentence?
Is there a concise way to say "all of the X, one of each"?
Can inflation occur in a positive-sum game currency system such as the Stack Exchange reputation system?
Is a manifold-with-boundary with given interior and non-empty boundary essentially unique?
How discoverable are IPv6 addresses and AAAA names by potential attackers?
ListPlot join points by nearest neighbor rather than order
What causes the vertical darker bands in my photo?
How do I stop a creek from eroding my steep embankment?
Do I really need recursive chmod to restrict access to a folder?
Is 1 ppb equal to 1 μg/kg?
"Seemed to had" is it correct?
When -s is used with third person singular. What's its use in this context?
Why are there no cargo aircraft with "flying wing" design?
Output the ŋarâþ crîþ alphabet song without using (m)any letters
Is there a service that would inform me whenever a new direct route is scheduled from a given airport?
G-Code for resetting to 100% speed
What's the purpose of writing one's academic bio in 3rd person?
If a contract sometimes uses the wrong name, is it still valid?
What happens to sewage if there is no river near by?
What are 'alternative tunings' of a guitar and why would you use them? Doesn't it make it more difficult to play?
The logistics of corpse disposal
Portfast on Trunk port
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Mixing Cisco STP Features: BPDU Guard, BPDU Filter, PortFast and PortFast TrunkCisco 2960 Portfast ports generate Spanning Tree TCNWhen does the Cisco IOS SNMP “ifCounterDiscontinuityTime” counter change?VLAN, Trunk and OSPFWhen should the portfast command be used on Cisco switchesACL on trunk PortConfigure pfSense VLAN TrunkTrunk Ports only Allowing Native VLAN?spanning tree loop with bpdufilter on acces port but not on trunk?when to make a port dynamic desirable instead of trunk?
Why shouldn't I activate portfast on a trunking port for a Cisco switch?
I do understand that it could cause a loop on the the network, but I still cant wrap my head around the concept.
cisco trunk
add a comment |
Why shouldn't I activate portfast on a trunking port for a Cisco switch?
I do understand that it could cause a loop on the the network, but I still cant wrap my head around the concept.
cisco trunk
1
The warning message was compiled to warn people about portfast on trunks between network devices. You can still set portfast for hosts connected via trunk.
– Cown
Apr 11 at 15:00
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
Switches forward frames, routers forward packets. The packets have a TTL that will expire if you hit a routing loop. Frames have nothing like a TTL. When switches receive broadcasts, they flood them to every interface, and if there is a loop, they continue to do that forever amplifying the broadcasts on each loop, eventually crashing the network with too much traffic for the switches to handle.
– Ron Maupin♦
Apr 12 at 1:30
add a comment |
Why shouldn't I activate portfast on a trunking port for a Cisco switch?
I do understand that it could cause a loop on the the network, but I still cant wrap my head around the concept.
cisco trunk
Why shouldn't I activate portfast on a trunking port for a Cisco switch?
I do understand that it could cause a loop on the the network, but I still cant wrap my head around the concept.
cisco trunk
cisco trunk
edited Apr 11 at 14:59
jonathanjo
12.3k1937
12.3k1937
asked Apr 11 at 14:56
Alexandre Amaral BednellAlexandre Amaral Bednell
965
965
1
The warning message was compiled to warn people about portfast on trunks between network devices. You can still set portfast for hosts connected via trunk.
– Cown
Apr 11 at 15:00
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
Switches forward frames, routers forward packets. The packets have a TTL that will expire if you hit a routing loop. Frames have nothing like a TTL. When switches receive broadcasts, they flood them to every interface, and if there is a loop, they continue to do that forever amplifying the broadcasts on each loop, eventually crashing the network with too much traffic for the switches to handle.
– Ron Maupin♦
Apr 12 at 1:30
add a comment |
1
The warning message was compiled to warn people about portfast on trunks between network devices. You can still set portfast for hosts connected via trunk.
– Cown
Apr 11 at 15:00
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
Switches forward frames, routers forward packets. The packets have a TTL that will expire if you hit a routing loop. Frames have nothing like a TTL. When switches receive broadcasts, they flood them to every interface, and if there is a loop, they continue to do that forever amplifying the broadcasts on each loop, eventually crashing the network with too much traffic for the switches to handle.
– Ron Maupin♦
Apr 12 at 1:30
1
1
The warning message was compiled to warn people about portfast on trunks between network devices. You can still set portfast for hosts connected via trunk.
– Cown
Apr 11 at 15:00
The warning message was compiled to warn people about portfast on trunks between network devices. You can still set portfast for hosts connected via trunk.
– Cown
Apr 11 at 15:00
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
Switches forward frames, routers forward packets. The packets have a TTL that will expire if you hit a routing loop. Frames have nothing like a TTL. When switches receive broadcasts, they flood them to every interface, and if there is a loop, they continue to do that forever amplifying the broadcasts on each loop, eventually crashing the network with too much traffic for the switches to handle.
– Ron Maupin♦
Apr 12 at 1:30
Switches forward frames, routers forward packets. The packets have a TTL that will expire if you hit a routing loop. Frames have nothing like a TTL. When switches receive broadcasts, they flood them to every interface, and if there is a loop, they continue to do that forever amplifying the broadcasts on each loop, eventually crashing the network with too much traffic for the switches to handle.
– Ron Maupin♦
Apr 12 at 1:30
add a comment |
2 Answers
2
active
oldest
votes
Having portfast on a inter-switch link is not the best of ideas, indeed.
Switches and Bridges should take the time needed (going through listening/learning phases) to converge to a loop free L2 topology. Rapid-Spanning-Tree, Rapid-PVST (Cisco), and MST are there to speed that process up from the classic 30sec of Spanning-Tree down to like 2-5 seconds.
On the other hand, not having portfast on a (non-bridging) end device's port is practically never a good idea - no matter if that port is "access" or "trunk".
Routers (not necessarily restricted the "on a stick" scenario) often run 802.1q tagged (sub)interfaces, and hypervisors such as VMware have trunk ports too.
And these devices are (more often than not) very unhappy with the 30seconds of black-hole situation after they see the line protocol go "up", just as a DCHP client on an access port is not happy with having to retry after more than 30 seconds.
VMware ESXi for example, when a link comes up, wants to send out a burst of RARP messages (at least one for each VM, with the VM's MAC address as source) through the link that has just come "up" (a feature called "notify switches" somewhere deep in the vSwitch's configuration). This helps the switches involved to immediately update their MAC address tables for the given VLANs. ESXi does this within a fraction of a second after it detects the "line protocol up" event.
A non-portfast trunk port going through LIS/LRN phases of STP (or the LRN of Rapid-PVST) will just break the "notify switches" feature. Users and admins will be quite unhappy, because their VMs might remain unreachable for even longer than these 30seconds, until the VM sees fit to send its first frame and the switches re-learn the VM's MAC address.
Even Cisco's DTP (Dynamic Trunking Protocol) interferes with "notify switches", as it keeps the port blocking for something less than 1 second before aborting negotiation. switchport nonegotiate
becomes your friend in these situations.
Pretty much the same thing can be said for routers and their dynamic routing protocols. As soon as they detect "line protocol up", they want to launch their hello and discovery mechanisms. Blackholeing them with non-portfast ports for 30seconds is just extending network reconvergence time, ruining the router admin's own efforts to optimize to sub-10-seconds reconvergence. They'll be standing at your desk, tapping their feet.
Be sure to know the difference between spanning-tree portfast
and spanning-tree portfast trunk
for classic IOS switches, respectively spanning-tree port type edge
and spanning-tree port type edge trunk
for more recent IOS and NX-OS (syntax may vary in details, check your documentation), and apply them correctly.
Without the trunk
keyword, the portfast setting is only active if the port is in 'access' mode. If you configure switchport mode trunk
for an edge device, you have to include the trunk
keyword in the portfast command, too.
Yes, a portfast enabled port skips the LIS/LRN phases of spanning-tree.
That's why you should always add bpduguard to portfast ports. Some Cisco switching platforms support the spanning-tree portfast bpduguard default
global command, so you get bpduguard implicitely on every portfast enabled port, and you cannot forget it.
Yes, I've been running switched networks in quite a range of sizes with portfast trunk
and bpduguard
for the end devices for years.
And now for the question about the warning:
The warning about (temporary) loops - to some degree - might be a leftover from the days when trunks were primarily a thing for inter switch links, bpduguard was not widely deployed and DTP was still a thing.
If one connected a switch to another switch without setting the port modes explicitely, DTP might've negotiated an inter-switch trunk, and these should never be "portfast". Hence Cisco probably decided to let spanning-tree portfast
be without effect for trunk ports. But that's more speculation than actual knowlegde.
Suggested reading: Any of the many Cisco documents titled "Configuring Optional Spanning-Tree Features", usually part of the collection of Configuration Guides.
Pick one that fits the given platform and software generation. One example:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-2_4_e/configurationguide/b_1524e_consolidated_3750x_3560x_cg/b_1524e_consolidated_3750x_3560x_cg_chapter_01000001.html
thank you very much!!
– Alexandre Amaral Bednell
Apr 12 at 8:29
add a comment |
You can use PortFast to connect a single end station or a switch port to a switch port. If you enable PortFast on a port that is connected to another Layer 2 device, such as a switch, you might create network loops. But you can enable portfast with router on stick case.where you have switch with trunk configured with router interface.
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
@ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
– serverAdmin123
Apr 11 at 15:42
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "496"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f58371%2fportfast-on-trunk-port%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Having portfast on a inter-switch link is not the best of ideas, indeed.
Switches and Bridges should take the time needed (going through listening/learning phases) to converge to a loop free L2 topology. Rapid-Spanning-Tree, Rapid-PVST (Cisco), and MST are there to speed that process up from the classic 30sec of Spanning-Tree down to like 2-5 seconds.
On the other hand, not having portfast on a (non-bridging) end device's port is practically never a good idea - no matter if that port is "access" or "trunk".
Routers (not necessarily restricted the "on a stick" scenario) often run 802.1q tagged (sub)interfaces, and hypervisors such as VMware have trunk ports too.
And these devices are (more often than not) very unhappy with the 30seconds of black-hole situation after they see the line protocol go "up", just as a DCHP client on an access port is not happy with having to retry after more than 30 seconds.
VMware ESXi for example, when a link comes up, wants to send out a burst of RARP messages (at least one for each VM, with the VM's MAC address as source) through the link that has just come "up" (a feature called "notify switches" somewhere deep in the vSwitch's configuration). This helps the switches involved to immediately update their MAC address tables for the given VLANs. ESXi does this within a fraction of a second after it detects the "line protocol up" event.
A non-portfast trunk port going through LIS/LRN phases of STP (or the LRN of Rapid-PVST) will just break the "notify switches" feature. Users and admins will be quite unhappy, because their VMs might remain unreachable for even longer than these 30seconds, until the VM sees fit to send its first frame and the switches re-learn the VM's MAC address.
Even Cisco's DTP (Dynamic Trunking Protocol) interferes with "notify switches", as it keeps the port blocking for something less than 1 second before aborting negotiation. switchport nonegotiate
becomes your friend in these situations.
Pretty much the same thing can be said for routers and their dynamic routing protocols. As soon as they detect "line protocol up", they want to launch their hello and discovery mechanisms. Blackholeing them with non-portfast ports for 30seconds is just extending network reconvergence time, ruining the router admin's own efforts to optimize to sub-10-seconds reconvergence. They'll be standing at your desk, tapping their feet.
Be sure to know the difference between spanning-tree portfast
and spanning-tree portfast trunk
for classic IOS switches, respectively spanning-tree port type edge
and spanning-tree port type edge trunk
for more recent IOS and NX-OS (syntax may vary in details, check your documentation), and apply them correctly.
Without the trunk
keyword, the portfast setting is only active if the port is in 'access' mode. If you configure switchport mode trunk
for an edge device, you have to include the trunk
keyword in the portfast command, too.
Yes, a portfast enabled port skips the LIS/LRN phases of spanning-tree.
That's why you should always add bpduguard to portfast ports. Some Cisco switching platforms support the spanning-tree portfast bpduguard default
global command, so you get bpduguard implicitely on every portfast enabled port, and you cannot forget it.
Yes, I've been running switched networks in quite a range of sizes with portfast trunk
and bpduguard
for the end devices for years.
And now for the question about the warning:
The warning about (temporary) loops - to some degree - might be a leftover from the days when trunks were primarily a thing for inter switch links, bpduguard was not widely deployed and DTP was still a thing.
If one connected a switch to another switch without setting the port modes explicitely, DTP might've negotiated an inter-switch trunk, and these should never be "portfast". Hence Cisco probably decided to let spanning-tree portfast
be without effect for trunk ports. But that's more speculation than actual knowlegde.
Suggested reading: Any of the many Cisco documents titled "Configuring Optional Spanning-Tree Features", usually part of the collection of Configuration Guides.
Pick one that fits the given platform and software generation. One example:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-2_4_e/configurationguide/b_1524e_consolidated_3750x_3560x_cg/b_1524e_consolidated_3750x_3560x_cg_chapter_01000001.html
thank you very much!!
– Alexandre Amaral Bednell
Apr 12 at 8:29
add a comment |
Having portfast on a inter-switch link is not the best of ideas, indeed.
Switches and Bridges should take the time needed (going through listening/learning phases) to converge to a loop free L2 topology. Rapid-Spanning-Tree, Rapid-PVST (Cisco), and MST are there to speed that process up from the classic 30sec of Spanning-Tree down to like 2-5 seconds.
On the other hand, not having portfast on a (non-bridging) end device's port is practically never a good idea - no matter if that port is "access" or "trunk".
Routers (not necessarily restricted the "on a stick" scenario) often run 802.1q tagged (sub)interfaces, and hypervisors such as VMware have trunk ports too.
And these devices are (more often than not) very unhappy with the 30seconds of black-hole situation after they see the line protocol go "up", just as a DCHP client on an access port is not happy with having to retry after more than 30 seconds.
VMware ESXi for example, when a link comes up, wants to send out a burst of RARP messages (at least one for each VM, with the VM's MAC address as source) through the link that has just come "up" (a feature called "notify switches" somewhere deep in the vSwitch's configuration). This helps the switches involved to immediately update their MAC address tables for the given VLANs. ESXi does this within a fraction of a second after it detects the "line protocol up" event.
A non-portfast trunk port going through LIS/LRN phases of STP (or the LRN of Rapid-PVST) will just break the "notify switches" feature. Users and admins will be quite unhappy, because their VMs might remain unreachable for even longer than these 30seconds, until the VM sees fit to send its first frame and the switches re-learn the VM's MAC address.
Even Cisco's DTP (Dynamic Trunking Protocol) interferes with "notify switches", as it keeps the port blocking for something less than 1 second before aborting negotiation. switchport nonegotiate
becomes your friend in these situations.
Pretty much the same thing can be said for routers and their dynamic routing protocols. As soon as they detect "line protocol up", they want to launch their hello and discovery mechanisms. Blackholeing them with non-portfast ports for 30seconds is just extending network reconvergence time, ruining the router admin's own efforts to optimize to sub-10-seconds reconvergence. They'll be standing at your desk, tapping their feet.
Be sure to know the difference between spanning-tree portfast
and spanning-tree portfast trunk
for classic IOS switches, respectively spanning-tree port type edge
and spanning-tree port type edge trunk
for more recent IOS and NX-OS (syntax may vary in details, check your documentation), and apply them correctly.
Without the trunk
keyword, the portfast setting is only active if the port is in 'access' mode. If you configure switchport mode trunk
for an edge device, you have to include the trunk
keyword in the portfast command, too.
Yes, a portfast enabled port skips the LIS/LRN phases of spanning-tree.
That's why you should always add bpduguard to portfast ports. Some Cisco switching platforms support the spanning-tree portfast bpduguard default
global command, so you get bpduguard implicitely on every portfast enabled port, and you cannot forget it.
Yes, I've been running switched networks in quite a range of sizes with portfast trunk
and bpduguard
for the end devices for years.
And now for the question about the warning:
The warning about (temporary) loops - to some degree - might be a leftover from the days when trunks were primarily a thing for inter switch links, bpduguard was not widely deployed and DTP was still a thing.
If one connected a switch to another switch without setting the port modes explicitely, DTP might've negotiated an inter-switch trunk, and these should never be "portfast". Hence Cisco probably decided to let spanning-tree portfast
be without effect for trunk ports. But that's more speculation than actual knowlegde.
Suggested reading: Any of the many Cisco documents titled "Configuring Optional Spanning-Tree Features", usually part of the collection of Configuration Guides.
Pick one that fits the given platform and software generation. One example:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-2_4_e/configurationguide/b_1524e_consolidated_3750x_3560x_cg/b_1524e_consolidated_3750x_3560x_cg_chapter_01000001.html
thank you very much!!
– Alexandre Amaral Bednell
Apr 12 at 8:29
add a comment |
Having portfast on a inter-switch link is not the best of ideas, indeed.
Switches and Bridges should take the time needed (going through listening/learning phases) to converge to a loop free L2 topology. Rapid-Spanning-Tree, Rapid-PVST (Cisco), and MST are there to speed that process up from the classic 30sec of Spanning-Tree down to like 2-5 seconds.
On the other hand, not having portfast on a (non-bridging) end device's port is practically never a good idea - no matter if that port is "access" or "trunk".
Routers (not necessarily restricted the "on a stick" scenario) often run 802.1q tagged (sub)interfaces, and hypervisors such as VMware have trunk ports too.
And these devices are (more often than not) very unhappy with the 30seconds of black-hole situation after they see the line protocol go "up", just as a DCHP client on an access port is not happy with having to retry after more than 30 seconds.
VMware ESXi for example, when a link comes up, wants to send out a burst of RARP messages (at least one for each VM, with the VM's MAC address as source) through the link that has just come "up" (a feature called "notify switches" somewhere deep in the vSwitch's configuration). This helps the switches involved to immediately update their MAC address tables for the given VLANs. ESXi does this within a fraction of a second after it detects the "line protocol up" event.
A non-portfast trunk port going through LIS/LRN phases of STP (or the LRN of Rapid-PVST) will just break the "notify switches" feature. Users and admins will be quite unhappy, because their VMs might remain unreachable for even longer than these 30seconds, until the VM sees fit to send its first frame and the switches re-learn the VM's MAC address.
Even Cisco's DTP (Dynamic Trunking Protocol) interferes with "notify switches", as it keeps the port blocking for something less than 1 second before aborting negotiation. switchport nonegotiate
becomes your friend in these situations.
Pretty much the same thing can be said for routers and their dynamic routing protocols. As soon as they detect "line protocol up", they want to launch their hello and discovery mechanisms. Blackholeing them with non-portfast ports for 30seconds is just extending network reconvergence time, ruining the router admin's own efforts to optimize to sub-10-seconds reconvergence. They'll be standing at your desk, tapping their feet.
Be sure to know the difference between spanning-tree portfast
and spanning-tree portfast trunk
for classic IOS switches, respectively spanning-tree port type edge
and spanning-tree port type edge trunk
for more recent IOS and NX-OS (syntax may vary in details, check your documentation), and apply them correctly.
Without the trunk
keyword, the portfast setting is only active if the port is in 'access' mode. If you configure switchport mode trunk
for an edge device, you have to include the trunk
keyword in the portfast command, too.
Yes, a portfast enabled port skips the LIS/LRN phases of spanning-tree.
That's why you should always add bpduguard to portfast ports. Some Cisco switching platforms support the spanning-tree portfast bpduguard default
global command, so you get bpduguard implicitely on every portfast enabled port, and you cannot forget it.
Yes, I've been running switched networks in quite a range of sizes with portfast trunk
and bpduguard
for the end devices for years.
And now for the question about the warning:
The warning about (temporary) loops - to some degree - might be a leftover from the days when trunks were primarily a thing for inter switch links, bpduguard was not widely deployed and DTP was still a thing.
If one connected a switch to another switch without setting the port modes explicitely, DTP might've negotiated an inter-switch trunk, and these should never be "portfast". Hence Cisco probably decided to let spanning-tree portfast
be without effect for trunk ports. But that's more speculation than actual knowlegde.
Suggested reading: Any of the many Cisco documents titled "Configuring Optional Spanning-Tree Features", usually part of the collection of Configuration Guides.
Pick one that fits the given platform and software generation. One example:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-2_4_e/configurationguide/b_1524e_consolidated_3750x_3560x_cg/b_1524e_consolidated_3750x_3560x_cg_chapter_01000001.html
Having portfast on a inter-switch link is not the best of ideas, indeed.
Switches and Bridges should take the time needed (going through listening/learning phases) to converge to a loop free L2 topology. Rapid-Spanning-Tree, Rapid-PVST (Cisco), and MST are there to speed that process up from the classic 30sec of Spanning-Tree down to like 2-5 seconds.
On the other hand, not having portfast on a (non-bridging) end device's port is practically never a good idea - no matter if that port is "access" or "trunk".
Routers (not necessarily restricted the "on a stick" scenario) often run 802.1q tagged (sub)interfaces, and hypervisors such as VMware have trunk ports too.
And these devices are (more often than not) very unhappy with the 30seconds of black-hole situation after they see the line protocol go "up", just as a DCHP client on an access port is not happy with having to retry after more than 30 seconds.
VMware ESXi for example, when a link comes up, wants to send out a burst of RARP messages (at least one for each VM, with the VM's MAC address as source) through the link that has just come "up" (a feature called "notify switches" somewhere deep in the vSwitch's configuration). This helps the switches involved to immediately update their MAC address tables for the given VLANs. ESXi does this within a fraction of a second after it detects the "line protocol up" event.
A non-portfast trunk port going through LIS/LRN phases of STP (or the LRN of Rapid-PVST) will just break the "notify switches" feature. Users and admins will be quite unhappy, because their VMs might remain unreachable for even longer than these 30seconds, until the VM sees fit to send its first frame and the switches re-learn the VM's MAC address.
Even Cisco's DTP (Dynamic Trunking Protocol) interferes with "notify switches", as it keeps the port blocking for something less than 1 second before aborting negotiation. switchport nonegotiate
becomes your friend in these situations.
Pretty much the same thing can be said for routers and their dynamic routing protocols. As soon as they detect "line protocol up", they want to launch their hello and discovery mechanisms. Blackholeing them with non-portfast ports for 30seconds is just extending network reconvergence time, ruining the router admin's own efforts to optimize to sub-10-seconds reconvergence. They'll be standing at your desk, tapping their feet.
Be sure to know the difference between spanning-tree portfast
and spanning-tree portfast trunk
for classic IOS switches, respectively spanning-tree port type edge
and spanning-tree port type edge trunk
for more recent IOS and NX-OS (syntax may vary in details, check your documentation), and apply them correctly.
Without the trunk
keyword, the portfast setting is only active if the port is in 'access' mode. If you configure switchport mode trunk
for an edge device, you have to include the trunk
keyword in the portfast command, too.
Yes, a portfast enabled port skips the LIS/LRN phases of spanning-tree.
That's why you should always add bpduguard to portfast ports. Some Cisco switching platforms support the spanning-tree portfast bpduguard default
global command, so you get bpduguard implicitely on every portfast enabled port, and you cannot forget it.
Yes, I've been running switched networks in quite a range of sizes with portfast trunk
and bpduguard
for the end devices for years.
And now for the question about the warning:
The warning about (temporary) loops - to some degree - might be a leftover from the days when trunks were primarily a thing for inter switch links, bpduguard was not widely deployed and DTP was still a thing.
If one connected a switch to another switch without setting the port modes explicitely, DTP might've negotiated an inter-switch trunk, and these should never be "portfast". Hence Cisco probably decided to let spanning-tree portfast
be without effect for trunk ports. But that's more speculation than actual knowlegde.
Suggested reading: Any of the many Cisco documents titled "Configuring Optional Spanning-Tree Features", usually part of the collection of Configuration Guides.
Pick one that fits the given platform and software generation. One example:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-2_4_e/configurationguide/b_1524e_consolidated_3750x_3560x_cg/b_1524e_consolidated_3750x_3560x_cg_chapter_01000001.html
edited yesterday
answered Apr 11 at 21:55
Marc 'netztier' LuethiMarc 'netztier' Luethi
4,4111420
4,4111420
thank you very much!!
– Alexandre Amaral Bednell
Apr 12 at 8:29
add a comment |
thank you very much!!
– Alexandre Amaral Bednell
Apr 12 at 8:29
thank you very much!!
– Alexandre Amaral Bednell
Apr 12 at 8:29
thank you very much!!
– Alexandre Amaral Bednell
Apr 12 at 8:29
add a comment |
You can use PortFast to connect a single end station or a switch port to a switch port. If you enable PortFast on a port that is connected to another Layer 2 device, such as a switch, you might create network loops. But you can enable portfast with router on stick case.where you have switch with trunk configured with router interface.
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
@ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
– serverAdmin123
Apr 11 at 15:42
add a comment |
You can use PortFast to connect a single end station or a switch port to a switch port. If you enable PortFast on a port that is connected to another Layer 2 device, such as a switch, you might create network loops. But you can enable portfast with router on stick case.where you have switch with trunk configured with router interface.
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
@ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
– serverAdmin123
Apr 11 at 15:42
add a comment |
You can use PortFast to connect a single end station or a switch port to a switch port. If you enable PortFast on a port that is connected to another Layer 2 device, such as a switch, you might create network loops. But you can enable portfast with router on stick case.where you have switch with trunk configured with router interface.
You can use PortFast to connect a single end station or a switch port to a switch port. If you enable PortFast on a port that is connected to another Layer 2 device, such as a switch, you might create network loops. But you can enable portfast with router on stick case.where you have switch with trunk configured with router interface.
answered Apr 11 at 15:19
serverAdmin123serverAdmin123
3617
3617
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
@ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
– serverAdmin123
Apr 11 at 15:42
add a comment |
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
@ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
– serverAdmin123
Apr 11 at 15:42
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
@ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
– serverAdmin123
Apr 11 at 15:42
@ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
– serverAdmin123
Apr 11 at 15:42
add a comment |
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f58371%2fportfast-on-trunk-port%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
The warning message was compiled to warn people about portfast on trunks between network devices. You can still set portfast for hosts connected via trunk.
– Cown
Apr 11 at 15:00
So if switches only foward packets, what packets may cause a loop ? BPDU packets?
– Alexandre Amaral Bednell
Apr 11 at 15:32
Switches forward frames, routers forward packets. The packets have a TTL that will expire if you hit a routing loop. Frames have nothing like a TTL. When switches receive broadcasts, they flood them to every interface, and if there is a loop, they continue to do that forever amplifying the broadcasts on each loop, eventually crashing the network with too much traffic for the switches to handle.
– Ron Maupin♦
Apr 12 at 1:30