BGP peer monitoring for multiple VRFs

[thl-cmk]

@jpht2

Would you happen to be able to spin up a virtual Arista switch, set up custom VRFs…

I will send you a PM on this.

@jpht2

I’m leaning towards having multiple plugins for each VRF will be our best route

This is an option, i don’t think a good one, but still…

First modify the original register.snmp_section and register.check_plugin part like this

_bgp_oids = SNMPTree(
        base='.1.3.6.1.2.1.15.3.1',  # BGP4-MIB::BgpPeerEntry
        oids=[
            '7',  # bgpPeerRemoteAddr
            '2',  # bgpPeerState
            '3',  # bgpPeerAdminStatus
            '9',  # bgpPeerRemoteAs
            '10',  # bgpPeerInUpdates
            '11',  # bgpPeerOutUpdates
            '12',  # bgpPeerInTotalMessages
            '13',  # bgpPeerOutTotalMessages
            '15',  # bgpPeerFsmEstablishedTransitions
            '16',  # bgpPeerFsmEstablishedTime
            '24',  # bgpPeerInUpdateElapsedTime
        ])
   

register.snmp_section(
    name='bgp_peer',
    parse_function=parse_bgp_peer,
    fetch=_bgp_oids,
    detect=exists('.1.3.6.1.2.1.15.3.1.1.*')
)


_bgp_discovery_default_parameters = {
        'build_item': [
            # 'remote_address',
            'remote_as',
            # 'address_family',
            # 'routing_instance',
        ]
    }


_bgp_check_default_parameters={
        'minuptime': (7200, 3600),
        'peer_list': [],
        'peernotfound': 2,
        'admindown': 1,
        'noprefixlimit': 1,
        'accepted_prefixes_upper_levels': (None, None),
        'accepted_prefixes_lower_levels': (None, None),
        'neighborstate': {
            '1': 2,  # idle
            '2': 1,  # connect
            '3': 1,  # active
            '4': 1,  # opensent
            '5': 1,  # openconfirm
            '6': 0,  # established
        }
        'internal_item': None,
    }


register.check_plugin(
    name='bgp_peer',
    service_name='BGP peer %s',
    discovery_function=discovery_bgp_peer,
    discovery_default_parameters=_bgp_discovery_default_parameters,
    discovery_ruleset_name='discovery_bgp_peer',
    check_function=check_bgp_peer,
    check_default_parameters=_bgp_check_default_parameters,
    check_ruleset_name='bgp_peer',
)

Create a copy of register.snmp_section and register.check_plugin for each VRF with a new name, if you have duplicate peers in the VRFs you need to change the service name

register.snmp_section(
    name='bgp_peer_vrf_1',
    parsed_section_name='bgp_peer',
    parse_function=parse_bgp_peer,
    fetch=_bgp_oids,
    detect=exists('.1.3.6.1.2.1.15.3.1.1.*')
)


register.check_plugin(
    name='bgp_peer_vrf_1',
    service_name='BGP peer VRF1 %s',
    discovery_function=discovery_bgp_peer,
    discovery_default_parameters=_bgp_discovery_default_parameters,
    discovery_ruleset_name='discovery_bgp_peer',
    check_function=check_bgp_peer,
    check_default_parameters=_bgp_check_default_parameters,
    check_ruleset_name='bgp_peer',
)

Than add a context rule for each new section → rediscover your device…

BGP peer 30.30.30.30 Peer state: idle
BGP peer 99.99.99.99 Peer state: idle
BGP peer VRF1 30.30.30.30 Peer state: idle
BGP peer VRF1 99.99.99.99 Peer state: idle

@jpht2

If you specify default in the context rule, do you also get BGP peers in the default VRF as well?

This depends on your system, if your default VRF has a label/context assigned than you can do this.

@Checkmk_tribe I my opinon this a design flaw in CMK that you don’t have a option to also fetch the default context for a snmp_section as soon as you are starting to use contexts. Also that the plugins have no knowledge that the data came from a context is suboptimal…

If you configure a context rule for each bgp snmp section (except for the original one) i think you sould get all the peers from the VRFs and from the global table.

[jpht2]

@thl-cmk

Create a copy of register.snmp_section and register.check_plugin for each VRF with a new name, if you have duplicate peers in the VRFs you need to change the service name

register.snmp_section(
    name='bgp_peer_vrf_1',
    parsed_section_name='bgp_peer',
    parse_function=parse_bgp_peer,
    fetch=_bgp_oids,
    detect=exists('.1.3.6.1.2.1.15.3.1.1.*')
)


register.check_plugin(
    name='bgp_peer_vrf_1',
    service_name='BGP peer VRF1 %s',
    discovery_function=discovery_bgp_peer,
    discovery_default_parameters=_bgp_discovery_default_parameters,
    discovery_ruleset_name='discovery_bgp_peer',
    check_function=check_bgp_peer,
    check_default_parameters=_bgp_check_default_parameters,
    check_ruleset_name='bgp_peer',
)

Just to make sure, would this part go in the same file as the previous part you mention to update? Or would we create a new py file for each VRF to have this section?

[thl-cmk]

@jpht2

Just to make sure, would this part go in the same file as the previous part you mention to update? O

Yes,put it all in the same file

[thl-cmk]

In the mean time I could lay my hands on a Arista device, so I was able to extend my BGP plugin for Arista. This addon will replace (supersede) the built in arista_bgp check.