cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5840
Views
40
Helpful
21
Replies

LACP link failure

akhoonwaseem
Level 1
Level 1

 

Hi Need your help to understand for LACP I start continuous ping between PC0 and PC1 over etherchannel. When I shut one interface fa0/2 there is no ping drop but when I bring the interface back up I observer ping drop 

Can you please explain me what is the reason for it and is it normal behavior of LACP as it is a Link aggregation and not a real HA solution. As once link comes back up it starts running algorithms again so etherchannel recalculates which ethernet to select for traffic flow

 

21 Replies 21

Switch mode access suggests where the end device is connected. (use case of Port-channel always pass more vlan tagging one switch to another switch).

 

If you like to use only one  VLAN, then you need to use with control switch to allow VLAN command in the port channel.

 

 

add load-balance :

port-channel load-balance src-dst-mac

 

Can you post the output :

show run (from both the switches - latest running config)

show EtherChannel summary

 

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Hello,

 

Hopefully this helps some.

 

A couple things I noticed. 

1.) Your port channel was in access mode. I would change that to trunk mode as they are connected to another switch and not an end device. I don't think its required but if you want more than 1 VLAN across it at some point, it will fix that.

2.) I created an Interface VLAN 1 and put an IP address on  each switch 192.168.10.3\192.168.10.4 255.255.255.0 respectively. This allowed me to do a continuous ping of 1000 packets to test

3.) When I shut down an interface and brought it back up it took a long time to come up and dropped pings as you said. My BEST guess for this happening is its still going through its initial spanning-tree states before actually sending traffic. So while it could show as UP in the port channel it may not be sending traffic until this process completes. I lost several packets while this was going on.

4.) I added this command to both port-channels 'spanning-tree portfast trunk' (this basically brings up the interface right away bypassing spanning-tree timers). This allowed me to achieve 100% continuous ping.

 

Hope that helps out a bit.

 

-David

Thankyou David, 

I would like to keep it in access mode to replicate my production network. Your findings regarding STP is insightful. 

To set etherchannel as trunk and enabling portfast we get this warring which indicates it is not best practice to use when connecting switches 

Switch(config-if)#spanning-tree portfast trunk

%Warning: portfast should only be enabled on ports connected to a single

host. Connecting hubs, concentrators, switches, bridges, etc... to this

interface when portfast is enabled, can cause temporary bridging loops.

Use with CAUTION

 

Thank you

Yes. That is just the general warning but it should still have taken. If you want to keep it in access mode on a trunk link then don't use portfast. You might be able to play with modifying spanning-tree timers to see if this improves the ping loss as well. Make sure you're using RSTP or at least not the original Spanning-tree modes with slower timers.

 

Thank you David. It is working fine now after enabling portfast trunk on port channel interface.

 

interface Port-channel1

switchport mode trunk

spanning-tree portfast trunk

 

Thank you 

PortFast in trunk connect two SW, I don't recommend this, 
there is time that data not pass due to STP but run portfast lead in some case to Loop. 
gggg.png

Use other protocol that have low time restore is better, from My side.

After looking into it more it seems it's only best practice to apply spanning-tree portfast trunk trunk to maybe a router with a Router on a Stick configuration or a server with multiple VLANs acting as a trunk. Thank you @MHM Cisco World for digging into it a bit more.

 

It does not look like good practice to issue that command when its another Bridging (L2) device. If that did fix your issue I would point the culprit to spanning tree still and try and modify the forward delay (listening/Learning) timers. Also I make sure all devices are running RSTP. 

 

 

-David

Review Cisco Networking for a $25 gift card