Cisco spanning tree add options to select interface and status

[lpinsivy]

For Cisco spanning tree, add the possibility to select interface with spanning tree and an option/filter to overwrite status.

For example, we can disable a network interface on a switch to prevent loop. So it is normal that this network interface is down on a switch.

[nailyk-fr]

I agree!
Gonna try to work on a patch.
Will you be able to test @lpinsivy ?

[Sims24]

Hi there,

We skip disable port by design, and also we consider as OK if spt state is disabled.

What would you want to change about the following rules :

    1 => ['disabled', 'OK'], 
    2 => ['blocking', 'CRITICAL'], 
    3 => ['listening', 'OK'], 
    4 => ['learning', 'OK'],
    5 => ['forwarding', 'OK'],
    6 => ['broken', 'CRITICAL'],
    
    10 => ['not defined', 'UNKNOWN'], # mine status

@nailyk-fr you would wish to override some of the mapping spt state -> status described above ?

Regards

[nailyk-fr]

@nailyk-fr you would wish to override some of the mapping spt state -> status described above ?

thanks for fastiness.
Most likely something to overwrite this:
if (${$states{$stp_state}}[1] ne 'OK') {
with custom values (like with --stp-overwrite-status 21:disabled --stp-overwrite-status 22:blocked) to be "in-line" with network STP topology.
Example, if states change from blocked to forwarding STP have changed somewhere and should be displayed.

P.S. am trying to change the plug-in, and guess the hardest part will be to retrieve the custom values.

[Sims24]

Then you want to catch state transitions ? Or gain flexibility about status and ports (I assume 21: and 22: corresponds to a port number right ?) ?

This plugin should be refactor with the new counter template class anyway.

You may want to get some example with the bgppeerstate.pm which is probably close from what you try to achieve.

[nailyk-fr]

Exactly. Catch status transition.
Thanks will look at the BGP plugin for code samples.

Am not able to help you on the plugin rewrite. Is it ok if I add this functionality on the old plugin anyway ?

[Sims24]

We would prefer that you propose a PR according refactoring, but as we miss some time if your change keep backward compatibility with existing check (adding instead of breaking/changing, especially options) we may merge it of course.

[nailyk-fr]

As it is the first time am doing perl I prefer not do a PR (PR on github cannot be modified by other people than author). Also my time at work dedicated on this is over.

Here is the not-well-written-patch: toto.txt
(written from the 'prod' /usr/lib/centreon/plugins/centreon_cisco_standard_snmp.pl so will probably require changes in two plugins. )

Do not handle 'disabled' port yet (will still be skipped).

Usage:
--stp-overrite-status 21@blocking:22@forwarding
Option is --stp-overrite-status each port are defined with <port>@<needed status> and separated with colon. In this example port 21 should be blocking and port 22 should be forwarding (22@forwarding is useless as it is default one)

[administrateur@serv-sup ~]$ ~/centreon_cisco_standard_snmp.pl --plugin=network::cisco::standard::snmp::plugin --mode=spanning-tree --hostname=172.29.2.3 --snmp-version='2c' --snmp-community='public'  --stp-overrite-status 21@blocking:22@forwarding --verbose
**OK**: Spanning Tree is ok on all interfaces |
Skipping interface '5': Stp port disabled
Skipping interface '23': Stp port disabled
Skipping interface '9': Stp port disabled
Skipping interface '17': Stp port disabled
Skipping interface '1': Stp port disabled
Skipping interface '14': Stp port disabled
Skipping interface '24': Stp port disabled
Skipping interface '3': Stp port disabled
Skipping interface '15': Stp port disabled
Found 2 custom STP topology
Spanning Tree interface '13' state is forwarding
Spanning Tree interface '18' state is forwarding
Spanning Tree interface '21' state is **blocking**
Spanning Tree interface '12' state is forwarding
Spanning Tree interface '8' state is forwarding
Spanning Tree interface '6' state is forwarding
Spanning Tree interface '10' state is forwarding
Spanning Tree interface '7' state is forwarding
Spanning Tree interface '19' state is forwarding
Spanning Tree interface '4' state is forwarding
Spanning Tree interface '11' state is forwarding
Spanning Tree interface '22' state is forwarding
Spanning Tree interface '2' state is forwarding
Spanning Tree interface '20' state is forwarding
Spanning Tree interface '16' state is forwarding

Hope it is fine.

[Sims24]

Hey @nailyk-fr

Thanks for the patch, do not hesitate to do PR, even if they are rejected it is more readable and we can discuss about the way of implementing such feature.

I refactored the code. You should be able to filter on port and have no limit in overriding status.

I have also added ability to filter on port description and enhance globally the output.

I'll merge my PR and it will then close this issue.

Thanks for you contribution !

[nailyk-fr]

Thanks for the work @Sims24 !
However looks like your #908 does not handle the same way.
Looks like now the option is filter-port and will remove the specified interface from the result.

Original patch add custom topology like 21@blocking . This way, while port 21 is blocking, reported status is OK. If port change to forwarding , status will be reported as critical as topology have changed.

Hope it is clear, am not good at all at English writing....

Should I open a PR with adding this option again ?
Thanks in advance.

[Sims24]

@nailyk-fr

No problem. Filter port is just an "extra" I could easyly add during the refactoring. But to achieve what you want you can use the code of my PR. You command would looks like below :

perl centreon_plugins.pl --plugin=network::cisco::standard::snmp::plugin --mode=spanning-tree --hostname=X.X.X.X --snmp-version='2c' --snmp-community='snmpcommunity' --verbose --warning-status='%{state} =~ /blocking|broken/ && (%{state} =~ /blocking/ && %{index} ne "21"')

This way, any port in a blocking / broken state will trigger a critical except the port with 21 index. That way of defining options let us handle any custom topology regarding spanning tree

What dou you think about it ?

[nailyk-fr]

Sadly I already did the PR ( #912 ) with the --stp-overwrite-status way.... Should I close it ?

Am not sure to understand your way. =~ are perl regex, right ?
So you suggest to have customizable rules through regex writing ?
Is it not harder to write for end user ?

[Sims24]

I'll close it but it's always interesting to see how other would handle such feature.

We know this is harder at first sight but this is also more reliable and flexible. Practice a little and it will become simpler and simpler.

[nailyk-fr]

@Sims24 thanks for taking care of my requests and guiding me.
Will try to rewrite it your way while back of my vacation.