Portfast on Trunk port Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm 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?
How long can equipment go unused before powering up runs the risk of damage?
One-one communication
Are sorcerers unable to use the Careful Spell metamagic option on themselves?
Is it possible for SQL statements to execute concurrently within a single session in SQL Server?
Did any compiler fully use 80-bit floating point?
How many morphisms from 1 to 1+1 can there be?
Amount of permutations on an NxNxN Rubik's Cube
What's the difference between the capability remove_users and delete_users?
What does it mean that physics no longer uses mechanical models to describe phenomena?
preposition before coffee
What would you call this weird metallic apparatus that allows you to lift people?
Deconstruction is ambiguous
Can the Flaming Sphere spell be rammed into multiple Tiny creatures that are in the same 5-foot square?
How do I find out the mythology and history of my Fortress?
Prove that BD bisects angle ABC
Is there any word for a place full of confusion?
How did Fremen produce and carry enough thumpers to use Sandworms as de facto Ubers?
Significance of Cersei's obsession with elephants?
How often does castling occur in grandmaster games?
Output Devanagari (Hindi) from raw unicode using luatex
What is an "asse" in Elizabethan English?
Co-worker has annoying ringtone
Would it be easier to apply for a UK visa if there is a host family to sponsor for you in going there?
If the probability of a dog barking one or more times in a given hour is 84%, then what is the probability of a dog barking in 30 minutes?
Portfast on Trunk port
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm 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.4k1938
12.4k1938
asked Apr 11 at 14:56
Alexandre Amaral BednellAlexandre Amaral Bednell
1135
1135
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 Apr 14 at 18:59
answered Apr 11 at 21:55
Marc 'netztier' LuethiMarc 'netztier' Luethi
4,5111420
4,5111420
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
3717
3717
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