cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
481
Views
0
Helpful
1
Replies

Etherchannel in Catalyst 3850

flielguera
Level 1
Level 1

Good morning; there has been a problem with some etherchannel defined in a Catalyst 3850 Switch STACK.
At one point, defined interfaces belonging to EtherChannels and who have been working a long time without problems, change their status from "P" to "W" causing intermittent with HP servers which are connected to these interfaces.
I attached the log with error messages, and configuration of the switch.

Please any ideas about what happend.??

Regards Fernando.

1 Reply 1

Peter Paluch
Cisco Employee
Cisco Employee

Fernando,

It would appear that your 3850 stopped receiving LACPDUs from HP servers, and as a result, it removed the physical ports from the bundle.

At this point, it is difficult to say why the 3850 stopped receiving the LACPDUs - it might be that the HP servers, for some reasons, stopped sending them, or that they have been sent but they didn't make it to the 3850. This could either be a result of some intensive congestion, or there was some temporary connectivity issue between the HP servers and the 3850.

These are my suggestions:

  • You are running Rapid PVST+. In networks with RPVST+, configuring edge ports is of utmost importance, otherwise, during a Proposal/Agreement exchange, ports toward end hosts will become blocking for 30 seconds, impairing the connectivity. You are using spanning-tree portfast default which is very good but this command only applies to access ports, not to trunks. Because you have your trunks going to servers as well, you should explicitly configure the respective Port-channel interfaces toward servers with spanning-tree portfast trunk command to also protect them from being impacted by the Proposal/Agreement exchange. Of course, do not apply this command to trunks toward other switches - RPVST+ will  handle those links and their rapid convergence. I consider this to be an important step to accomplish.
  • Check the output of show interfaces for the physical ports that got suspended from the EtherChanel for any indications of input congestion, drops, or errors. Also check the same output for the related Port-channel interfaces. Ideally, there should be none errors/drops, or only an extremely small fraction compared to the total amount of traffic (by a rule of thumb, deep below 1 errored/dropped packet per million packets).
  • Check the show lacp counters command to see how many LACPDUs have been sent and received. These numbers should be roughly equal. No LACPDUs should be reported as errored.

Let's see if these checks produce any clues.

Best regards,
Peter