Network Redundancy with LACP Trunking
I would like to set up a redundant link between two switches. I have four ports available to accomplish this.
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are plugged into Switch 2 ports 1+2.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They are plugged into Switch 2 Ports 1+2.
In Scenario B I can unplug one of the patch cables and the switches will still be linked, establishing redundancy. In Scenario A, what will happen when I unplug one of the patch cables? Will LACP allow the link over just one interface? Or will the link stop because an interface is missing.
switch switching spanning-tree redundancy ieee-802.1ax
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
asked Jan 22 at 20:22
jbakerjjbakerj
283
add a comment |
I would like to set up a redundant link between two switches. I have four ports available to accomplish this.
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are plugged into Switch 2 ports 1+2.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They are plugged into Switch 2 Ports 1+2.
In Scenario B I can unplug one of the patch cables and the switches will still be linked, establishing redundancy. In Scenario A, what will happen when I unplug one of the patch cables? Will LACP allow the link over just one interface? Or will the link stop because an interface is missing.
switch switching spanning-tree redundancy ieee-802.1ax
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
asked Jan 22 at 20:22
jbakerjjbakerj
283
1
If switch2 has got LACP disabled but switch1 has LACP enabled, then you don't have a negotiated LACP link at all.
– Criggie
Jan 23 at 3:00
1
Cisco LACP failover time was enhanced on Cisco IOS Release 12.2(33)SB, which states:Link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds; port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.
– Cown
Jan 23 at 7:58
add a comment |
I would like to set up a redundant link between two switches. I have four ports available to accomplish this.
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are plugged into Switch 2 ports 1+2.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They are plugged into Switch 2 Ports 1+2.
In Scenario B I can unplug one of the patch cables and the switches will still be linked, establishing redundancy. In Scenario A, what will happen when I unplug one of the patch cables? Will LACP allow the link over just one interface? Or will the link stop because an interface is missing.
switch switching spanning-tree redundancy ieee-802.1ax
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
asked Jan 22 at 20:22
jbakerjjbakerj
283
I would like to set up a redundant link between two switches. I have four ports available to accomplish this.
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are plugged into Switch 2 ports 1+2.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They are plugged into Switch 2 Ports 1+2.
In Scenario B I can unplug one of the patch cables and the switches will still be linked, establishing redundancy. In Scenario A, what will happen when I unplug one of the patch cables? Will LACP allow the link over just one interface? Or will the link stop because an interface is missing.
switch switching spanning-tree redundancy ieee-802.1ax
switch switching spanning-tree redundancy ieee-802.1ax
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
asked Jan 22 at 20:22
jbakerjjbakerj
283
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
asked Jan 22 at 20:22
jbakerjjbakerj
283
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
edited Jan 22 at 20:33
Ron Maupin♦
65.9k1369124
65.9k1369124
asked Jan 22 at 20:22
jbakerjjbakerj
283
asked Jan 22 at 20:22
jbakerjjbakerj
283
asked Jan 22 at 20:22
jbakerjjbakerj
283
283
1
If switch2 has got LACP disabled but switch1 has LACP enabled, then you don't have a negotiated LACP link at all.
– Criggie
Jan 23 at 3:00
1
Cisco LACP failover time was enhanced on Cisco IOS Release 12.2(33)SB, which states:Link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds; port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.
– Cown
Jan 23 at 7:58
add a comment |
1
If switch2 has got LACP disabled but switch1 has LACP enabled, then you don't have a negotiated LACP link at all.
– Criggie
Jan 23 at 3:00
1
Cisco LACP failover time was enhanced on Cisco IOS Release 12.2(33)SB, which states:Link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds; port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.
– Cown
Jan 23 at 7:58
1
1
If switch2 has got LACP disabled but switch1 has LACP enabled, then you don't have a negotiated LACP link at all.
– Criggie
Jan 23 at 3:00
If switch2 has got LACP disabled but switch1 has LACP enabled, then you don't have a negotiated LACP link at all.
– Criggie
Jan 23 at 3:00
1
1
Cisco LACP failover time was enhanced on Cisco IOS Release 12.2(33)SB, which states:
Link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds; port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.– Cown
Jan 23 at 7:58
Cisco LACP failover time was enhanced on Cisco IOS Release 12.2(33)SB, which states:
Link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds; port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.– Cown
Jan 23 at 7:58
add a comment |
2 Answers
2
active
oldest
votes
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are
plugged into Switch 2 ports 1+2.
Both links will be used, but a single flow will only use one link. There is a hashing algorithm that determines which flow uses which link. If one of the links goes down, then all the traffic will be switched to the other link. This happens very rapidly.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They
are plugged into Switch 2 Ports 1+2.
They will not actually be trunked together. STP will block one link because it creates a single, loop-free path to the root bridge. When the active link goes down, STP will switch over to the redundant link, but this happens fairly slowly; a few seconds for RSTP, and up to 50 seconds for standard STP.
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
RSTP can fail over in milliseconds if either end of the link actively detects the failure.
– chrylis
Jan 23 at 9:10
I thought RSTP was supposed to be faster than a few seconds... Based on a quick test, it might depend on the topology and where the orphaned switch is located. For switches with two links towards the root (as in the question with those parallel links), dropping the active link caused just a ~200 ms interruption. However, a switch that had the only alternate route going "away" from the root took those few seconds to recover. I didn't check if this is a standard behaviour, or an optimization, though.
– ilkkachu
Jan 23 at 11:54
@chrylis, it depends on the whole topology. @ ilkkachu is correct. I was giving worst-case number. It would be rare for STP to take 50 seconds, but it is possible. Normally an STP failure will take about 30 seconds to recover, but a full convergence can take 50 seconds.
– Ron Maupin♦
Jan 23 at 15:21
@RonMaupin, hmm, if I trust Wikipedia on this, RSTP was introduced in 2001 and standardized in 2004. One would hope nobody would use the original STP now, ~15 years later, but I suppose some things die hard.
– ilkkachu
Jan 23 at 15:35
@ilkkachu, RSTP needs a managed switch, and not all switches are managed. Putting in a single STP switch will cause the entire domain to fall back to STP. It is something that dies hard.
– Ron Maupin♦
Jan 23 at 15:38
add a comment |
From a functional point of view, there's no difference between LACP trunks and static trunks. All links are aggregated (with the limitations Ron has already pointed out) and the aggregation group is redundant. An LACP trunk set up with eight ports works with anything between one to eight physical links - so does a static trunk.
The difference is that an LACP trunk only works when both sides negotiate the aggregation. Without successful negotiation the physical links fall apart into separate logical links. Usually, it's combined with a spanning tree protocol to avoid bridge loops - without STP the bridge loop would bring down the network.
In contrast, in a static trunk the links are aggregated when they're up. The switch doesn't check whether the trunk makes sense. You could use links terminated differently and you'd get weird and possibly unexpected effects.
Generally, LACP trunks are safer to use. You should only use static trunks when LACP isn't available.
Of course, the combination of LACP and STP calls for a better integrated solution that even works with multiple switches and meshed setups. This is what Shortest Path Bridging aka IEEE 802.1aq is for. Sadly it hasn't caught on in the mid-range class yet.
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
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%2f56308%2fnetwork-redundancy-with-lacp-trunking%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
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are
plugged into Switch 2 ports 1+2.
Both links will be used, but a single flow will only use one link. There is a hashing algorithm that determines which flow uses which link. If one of the links goes down, then all the traffic will be switched to the other link. This happens very rapidly.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They
are plugged into Switch 2 Ports 1+2.
They will not actually be trunked together. STP will block one link because it creates a single, loop-free path to the root bridge. When the active link goes down, STP will switch over to the redundant link, but this happens fairly slowly; a few seconds for RSTP, and up to 50 seconds for standard STP.
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
RSTP can fail over in milliseconds if either end of the link actively detects the failure.
– chrylis
Jan 23 at 9:10
I thought RSTP was supposed to be faster than a few seconds... Based on a quick test, it might depend on the topology and where the orphaned switch is located. For switches with two links towards the root (as in the question with those parallel links), dropping the active link caused just a ~200 ms interruption. However, a switch that had the only alternate route going "away" from the root took those few seconds to recover. I didn't check if this is a standard behaviour, or an optimization, though.
– ilkkachu
Jan 23 at 11:54
@chrylis, it depends on the whole topology. @ ilkkachu is correct. I was giving worst-case number. It would be rare for STP to take 50 seconds, but it is possible. Normally an STP failure will take about 30 seconds to recover, but a full convergence can take 50 seconds.
– Ron Maupin♦
Jan 23 at 15:21
@RonMaupin, hmm, if I trust Wikipedia on this, RSTP was introduced in 2001 and standardized in 2004. One would hope nobody would use the original STP now, ~15 years later, but I suppose some things die hard.
– ilkkachu
Jan 23 at 15:35
@ilkkachu, RSTP needs a managed switch, and not all switches are managed. Putting in a single STP switch will cause the entire domain to fall back to STP. It is something that dies hard.
– Ron Maupin♦
Jan 23 at 15:38
add a comment |
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are
plugged into Switch 2 ports 1+2.
Both links will be used, but a single flow will only use one link. There is a hashing algorithm that determines which flow uses which link. If one of the links goes down, then all the traffic will be switched to the other link. This happens very rapidly.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They
are plugged into Switch 2 Ports 1+2.
They will not actually be trunked together. STP will block one link because it creates a single, loop-free path to the root bridge. When the active link goes down, STP will switch over to the redundant link, but this happens fairly slowly; a few seconds for RSTP, and up to 50 seconds for standard STP.
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
RSTP can fail over in milliseconds if either end of the link actively detects the failure.
– chrylis
Jan 23 at 9:10
I thought RSTP was supposed to be faster than a few seconds... Based on a quick test, it might depend on the topology and where the orphaned switch is located. For switches with two links towards the root (as in the question with those parallel links), dropping the active link caused just a ~200 ms interruption. However, a switch that had the only alternate route going "away" from the root took those few seconds to recover. I didn't check if this is a standard behaviour, or an optimization, though.
– ilkkachu
Jan 23 at 11:54
@chrylis, it depends on the whole topology. @ ilkkachu is correct. I was giving worst-case number. It would be rare for STP to take 50 seconds, but it is possible. Normally an STP failure will take about 30 seconds to recover, but a full convergence can take 50 seconds.
– Ron Maupin♦
Jan 23 at 15:21
@RonMaupin, hmm, if I trust Wikipedia on this, RSTP was introduced in 2001 and standardized in 2004. One would hope nobody would use the original STP now, ~15 years later, but I suppose some things die hard.
– ilkkachu
Jan 23 at 15:35
@ilkkachu, RSTP needs a managed switch, and not all switches are managed. Putting in a single STP switch will cause the entire domain to fall back to STP. It is something that dies hard.
– Ron Maupin♦
Jan 23 at 15:38
add a comment |
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are
plugged into Switch 2 ports 1+2.
Both links will be used, but a single flow will only use one link. There is a hashing algorithm that determines which flow uses which link. If one of the links goes down, then all the traffic will be switched to the other link. This happens very rapidly.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They
are plugged into Switch 2 Ports 1+2.
They will not actually be trunked together. STP will block one link because it creates a single, loop-free path to the root bridge. When the active link goes down, STP will switch over to the redundant link, but this happens fairly slowly; a few seconds for RSTP, and up to 50 seconds for standard STP.
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
Scenario A: Switch 1 has ports 1+2 trunked together via LACP. They are
plugged into Switch 2 ports 1+2.
Both links will be used, but a single flow will only use one link. There is a hashing algorithm that determines which flow uses which link. If one of the links goes down, then all the traffic will be switched to the other link. This happens very rapidly.
Scenario B: Switch 1 has ports 1+2 trunked together without LACP. They
are plugged into Switch 2 Ports 1+2.
They will not actually be trunked together. STP will block one link because it creates a single, loop-free path to the root bridge. When the active link goes down, STP will switch over to the redundant link, but this happens fairly slowly; a few seconds for RSTP, and up to 50 seconds for standard STP.
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
answered Jan 22 at 20:32
Ron Maupin♦Ron Maupin
65.9k1369124
65.9k1369124
RSTP can fail over in milliseconds if either end of the link actively detects the failure.
– chrylis
Jan 23 at 9:10
I thought RSTP was supposed to be faster than a few seconds... Based on a quick test, it might depend on the topology and where the orphaned switch is located. For switches with two links towards the root (as in the question with those parallel links), dropping the active link caused just a ~200 ms interruption. However, a switch that had the only alternate route going "away" from the root took those few seconds to recover. I didn't check if this is a standard behaviour, or an optimization, though.
– ilkkachu
Jan 23 at 11:54
@chrylis, it depends on the whole topology. @ ilkkachu is correct. I was giving worst-case number. It would be rare for STP to take 50 seconds, but it is possible. Normally an STP failure will take about 30 seconds to recover, but a full convergence can take 50 seconds.
– Ron Maupin♦
Jan 23 at 15:21
@RonMaupin, hmm, if I trust Wikipedia on this, RSTP was introduced in 2001 and standardized in 2004. One would hope nobody would use the original STP now, ~15 years later, but I suppose some things die hard.
– ilkkachu
Jan 23 at 15:35
@ilkkachu, RSTP needs a managed switch, and not all switches are managed. Putting in a single STP switch will cause the entire domain to fall back to STP. It is something that dies hard.
– Ron Maupin♦
Jan 23 at 15:38
add a comment |
RSTP can fail over in milliseconds if either end of the link actively detects the failure.
– chrylis
Jan 23 at 9:10
I thought RSTP was supposed to be faster than a few seconds... Based on a quick test, it might depend on the topology and where the orphaned switch is located. For switches with two links towards the root (as in the question with those parallel links), dropping the active link caused just a ~200 ms interruption. However, a switch that had the only alternate route going "away" from the root took those few seconds to recover. I didn't check if this is a standard behaviour, or an optimization, though.
– ilkkachu
Jan 23 at 11:54
@chrylis, it depends on the whole topology. @ ilkkachu is correct. I was giving worst-case number. It would be rare for STP to take 50 seconds, but it is possible. Normally an STP failure will take about 30 seconds to recover, but a full convergence can take 50 seconds.
– Ron Maupin♦
Jan 23 at 15:21
@RonMaupin, hmm, if I trust Wikipedia on this, RSTP was introduced in 2001 and standardized in 2004. One would hope nobody would use the original STP now, ~15 years later, but I suppose some things die hard.
– ilkkachu
Jan 23 at 15:35
@ilkkachu, RSTP needs a managed switch, and not all switches are managed. Putting in a single STP switch will cause the entire domain to fall back to STP. It is something that dies hard.
– Ron Maupin♦
Jan 23 at 15:38
RSTP can fail over in milliseconds if either end of the link actively detects the failure.
– chrylis
Jan 23 at 9:10
RSTP can fail over in milliseconds if either end of the link actively detects the failure.
– chrylis
Jan 23 at 9:10
I thought RSTP was supposed to be faster than a few seconds... Based on a quick test, it might depend on the topology and where the orphaned switch is located. For switches with two links towards the root (as in the question with those parallel links), dropping the active link caused just a ~200 ms interruption. However, a switch that had the only alternate route going "away" from the root took those few seconds to recover. I didn't check if this is a standard behaviour, or an optimization, though.
– ilkkachu
Jan 23 at 11:54
I thought RSTP was supposed to be faster than a few seconds... Based on a quick test, it might depend on the topology and where the orphaned switch is located. For switches with two links towards the root (as in the question with those parallel links), dropping the active link caused just a ~200 ms interruption. However, a switch that had the only alternate route going "away" from the root took those few seconds to recover. I didn't check if this is a standard behaviour, or an optimization, though.
– ilkkachu
Jan 23 at 11:54
@chrylis, it depends on the whole topology. @ ilkkachu is correct. I was giving worst-case number. It would be rare for STP to take 50 seconds, but it is possible. Normally an STP failure will take about 30 seconds to recover, but a full convergence can take 50 seconds.
– Ron Maupin♦
Jan 23 at 15:21
@chrylis, it depends on the whole topology. @ ilkkachu is correct. I was giving worst-case number. It would be rare for STP to take 50 seconds, but it is possible. Normally an STP failure will take about 30 seconds to recover, but a full convergence can take 50 seconds.
– Ron Maupin♦
Jan 23 at 15:21
@RonMaupin, hmm, if I trust Wikipedia on this, RSTP was introduced in 2001 and standardized in 2004. One would hope nobody would use the original STP now, ~15 years later, but I suppose some things die hard.
– ilkkachu
Jan 23 at 15:35
@RonMaupin, hmm, if I trust Wikipedia on this, RSTP was introduced in 2001 and standardized in 2004. One would hope nobody would use the original STP now, ~15 years later, but I suppose some things die hard.
– ilkkachu
Jan 23 at 15:35
@ilkkachu, RSTP needs a managed switch, and not all switches are managed. Putting in a single STP switch will cause the entire domain to fall back to STP. It is something that dies hard.
– Ron Maupin♦
Jan 23 at 15:38
@ilkkachu, RSTP needs a managed switch, and not all switches are managed. Putting in a single STP switch will cause the entire domain to fall back to STP. It is something that dies hard.
– Ron Maupin♦
Jan 23 at 15:38
add a comment |
From a functional point of view, there's no difference between LACP trunks and static trunks. All links are aggregated (with the limitations Ron has already pointed out) and the aggregation group is redundant. An LACP trunk set up with eight ports works with anything between one to eight physical links - so does a static trunk.
The difference is that an LACP trunk only works when both sides negotiate the aggregation. Without successful negotiation the physical links fall apart into separate logical links. Usually, it's combined with a spanning tree protocol to avoid bridge loops - without STP the bridge loop would bring down the network.
In contrast, in a static trunk the links are aggregated when they're up. The switch doesn't check whether the trunk makes sense. You could use links terminated differently and you'd get weird and possibly unexpected effects.
Generally, LACP trunks are safer to use. You should only use static trunks when LACP isn't available.
Of course, the combination of LACP and STP calls for a better integrated solution that even works with multiple switches and meshed setups. This is what Shortest Path Bridging aka IEEE 802.1aq is for. Sadly it hasn't caught on in the mid-range class yet.
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
add a comment |
From a functional point of view, there's no difference between LACP trunks and static trunks. All links are aggregated (with the limitations Ron has already pointed out) and the aggregation group is redundant. An LACP trunk set up with eight ports works with anything between one to eight physical links - so does a static trunk.
The difference is that an LACP trunk only works when both sides negotiate the aggregation. Without successful negotiation the physical links fall apart into separate logical links. Usually, it's combined with a spanning tree protocol to avoid bridge loops - without STP the bridge loop would bring down the network.
In contrast, in a static trunk the links are aggregated when they're up. The switch doesn't check whether the trunk makes sense. You could use links terminated differently and you'd get weird and possibly unexpected effects.
Generally, LACP trunks are safer to use. You should only use static trunks when LACP isn't available.
Of course, the combination of LACP and STP calls for a better integrated solution that even works with multiple switches and meshed setups. This is what Shortest Path Bridging aka IEEE 802.1aq is for. Sadly it hasn't caught on in the mid-range class yet.
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
add a comment |
From a functional point of view, there's no difference between LACP trunks and static trunks. All links are aggregated (with the limitations Ron has already pointed out) and the aggregation group is redundant. An LACP trunk set up with eight ports works with anything between one to eight physical links - so does a static trunk.
The difference is that an LACP trunk only works when both sides negotiate the aggregation. Without successful negotiation the physical links fall apart into separate logical links. Usually, it's combined with a spanning tree protocol to avoid bridge loops - without STP the bridge loop would bring down the network.
In contrast, in a static trunk the links are aggregated when they're up. The switch doesn't check whether the trunk makes sense. You could use links terminated differently and you'd get weird and possibly unexpected effects.
Generally, LACP trunks are safer to use. You should only use static trunks when LACP isn't available.
Of course, the combination of LACP and STP calls for a better integrated solution that even works with multiple switches and meshed setups. This is what Shortest Path Bridging aka IEEE 802.1aq is for. Sadly it hasn't caught on in the mid-range class yet.
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
From a functional point of view, there's no difference between LACP trunks and static trunks. All links are aggregated (with the limitations Ron has already pointed out) and the aggregation group is redundant. An LACP trunk set up with eight ports works with anything between one to eight physical links - so does a static trunk.
The difference is that an LACP trunk only works when both sides negotiate the aggregation. Without successful negotiation the physical links fall apart into separate logical links. Usually, it's combined with a spanning tree protocol to avoid bridge loops - without STP the bridge loop would bring down the network.
In contrast, in a static trunk the links are aggregated when they're up. The switch doesn't check whether the trunk makes sense. You could use links terminated differently and you'd get weird and possibly unexpected effects.
Generally, LACP trunks are safer to use. You should only use static trunks when LACP isn't available.
Of course, the combination of LACP and STP calls for a better integrated solution that even works with multiple switches and meshed setups. This is what Shortest Path Bridging aka IEEE 802.1aq is for. Sadly it hasn't caught on in the mid-range class yet.
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
answered Jan 22 at 21:19
Zac67Zac67
29.7k21859
29.7k21859
add a comment |
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%2f56308%2fnetwork-redundancy-with-lacp-trunking%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
If switch2 has got LACP disabled but switch1 has LACP enabled, then you don't have a negotiated LACP link at all.
– Criggie
Jan 23 at 3:00
1
Cisco LACP failover time was enhanced on Cisco IOS Release 12.2(33)SB, which states:
Link failover time of 250 milliseconds or less and a maximum link failover time of 2 seconds; port channels remain in the LINK_UP state to eliminate reconvergence by the Spanning-Tree Protocol.– Cown
Jan 23 at 7:58