Is there a way to monitor conditions (as with ipsla etc) in a switch (or specific to a given port channel) and trigger the removal/shutdown of a member from within a port-channel? Example - after x% errors, remove the interface from service/throw an alert. Thank you in advance for your feedback!

  • While this is an interesting question, automatically removing port-channel members certainly poses risks. Links in my experience do not deteriorate that quickly, having logging in place to catch these errors could allow you to be alerted on these conditions (errors, optic levels, etc.) before they become an issue. – Brian Winning Jr. Aug 23 '16 at 2:22
  • Right, in this case we're in the process of deploying such monitoring and that is our standard. This is a special case where it's not been available thus the reason for the question as we were in fact blind to a heavily errored link in a bundle until impact was reported and we wanted to avoid this again in the interim while monitoring is rolled out – A L Aug 24 '16 at 15:18
  • I'm feeling like this question was not very clear and thus the ambiguity in me assigning an answer. Any advice? I suppose what I was really looking for here was: Is there a way to create triggered logic to the effect of "If X happens, then shutdown Y port". It seems like there isn't an ability to do this and if so there's no answer. Thank you in advance for any suggestions on how to either clean up or close out this topic! – A L Sep 1 '16 at 13:17
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 9 '17 at 18:50

+1 @BrianWinningJr. also, use LACP (Port Channel Active) to ensure that the link is up end-to-end. This will automatically remove failed links and return them to service.

Be careful if you opt to automate this that you don't end up removing all ports from a port channel!

| improve this answer | |
  • absolutely, these are LACP bundles, in this scenario though the member links don't actually go down, they're just heavily errored so traffic is still spread across those links causing major interruptions/outages. While we were looking for built-in features if we ever did try to programmatically automate such a task we'd keep that in mind (about automating all the links out of a channel :)) – A L Aug 24 '16 at 15:23
  • @AL, if you have a lot of errors on the links, you really need to fix the layer-1 problems causing the errors. It sounds like you should probably get a competent cable company in there to resolve the situation, then you will not need to worry about it. You should not see any, or an extremely small number of, errors for years. If you do, then you need to resolve the root cause. – Ron Maupin Aug 24 '16 at 23:50
  • @RonMaupin, thanks for the advice Ron! We already have replaced the fiber which was the root cause and I completely agree with you. – A L Sep 1 '16 at 13:08

One problem with removing interfaces from a channel is that it is a link, and you suddenly have multiple links between the two devices: the channel and the interface removed from the channel. Then you have have STP deciding which link is blocking, and which link is forwarding, and you may not want what STP decides (the failing link is the one forwarding).

You can certainly get alerts on interface/link problems via SNMP or some other alert mechanism that you have set up.

| improve this answer | |
  • 1
    I think he means "shut the link down," not "unbundle the link from the port channel." – Ron Trunk Aug 23 '16 at 13:05
  • As I read the question, it seemed to ask about both things. I was giving information not included in the other answer and comment. – Ron Maupin Aug 23 '16 at 13:17
  • @RonTrunk - Indeed that is what I was going for! RonMaupin - you are right on a second read using the word 'removal' could imply many things, apologies for the confusion - your caution was one we were definitely aware of, however, assuming the config was applied (VLANs etc) to the PO int and not the underlying int's directly, even if you remove the channel-group portion of the config it shouldn't cause an STP loop if we've got PVST and a non-default native vlan?? – A L Aug 24 '16 at 15:13
  • 1
    If you shut the link down, how will you bring it back into service? Eg: you will no longer be able to pull stats from a shutdown port in order to work out if the errors have cleared – Benjamin Dale Aug 24 '16 at 23:38

I just thought of a possible solution that I think we are going to try(for alerting only, not shutting down interfaces).

Use multiple IP SLA sessions (possibly with IP SLA responder) on each side and set source/dest IPs(and possibly udp port if doing src/dst port load-balancing) to ensure traffic in each session is hashed over a specific link in the port-channel. Set thresholds as needed and then use EEM to shutdown interface if SLA session fails.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.