BGP Neighbor Monitoring in Multi-VRF environment
The core DataSource “BGP-” uses the BGP4-MIB to discover and monitor BGP neighbors on a device. This MIB doesn’t account for VRFs or address families.
Does anybody use some advanced DataSources to monitor BGP neighbor state information which considers different VRFs?
My use case is: We have some routers with multiple VRFs with overlapping IP subnets (which is obviously the major point of having VRFs...). Hence we do have multiple neighbors with the same neighbor IP within different VRFs. The BGP- DataSource just discovers one neighbor per IP, although there are multiple. I’d like to have a separate instance for each neighbor.
therealsle
Posted 2 years ago·Last reply 1 year ago
7 comments
joeyfc
·1 year agoHello, I'm working on this now. First question, can anyone share their code or the module they created?
LM Support will not help us on this. It's a standard ask as there is a free product out there that does this out of the box.
From what I'm reading I will need to utilize a groovy script to find the context, then use the context in the SNMP grab. Is this correct?
I can get the VRF names using .1.3.6.1.4.1.9.9.468.1.1.1.2 but I do not know how to get the context name which is what is actually used to poll. Does anyone know how to get the context name?
If I can't get the context name then I need to make it the same as the VRF.
snmp-server context VRF-TEST vrf VRF-TEST
Then I can do:
snmpwalk -v2c -c public\@VRF-TEST router-r1 .1.3.6.1.2.1.15.3.1
Any thoughts or help on this will be greatly appreciated. Thank you.
Michael Baker
·2 years ago@therealsle
That OID is fine the important part is the context switching when doing the walk. Here is a snippet of the most important part in the AD
Then play around with the WildAlias
As for Fortigate we had a similar issue with multiple vDOM’s on SNMPv3 the work around around for that is changing snmp.security on the fly to its original value + “-vdomname”
therealsle
OP2 years ago@Michael Baker Thanks for sharing your insights. I would need this working for Fortigate and Cisco IOS XE devices. If you follow the above approach, you will at least have issues with the OID 1.3.6.1.2.1.15.3.1.7 when having multiple neighbors with the same IP, since the OID will only return one value.
@Patrick Rouse Thanks, I will consider creating a feature request.
Michael Baker
·2 years agoDepending on the vendor?
Cisco Nexus use a propertysource on the devices and walk 1.3.6.1.4.1.9.9.468.1.1.1 to get a list of VRF’s
Then a datasource to walk 1.3.6.1.2.1.15.3.1.7
The special part os the community what we done is used the VRF name as part of the context so our community would then be
$VRFNAME-CM
Also a contextname as a property
This would then grab the BGP peers from within the VRF
igeorgiev
·1 year agoHi Michael,
For the setup that you are describing, did you have multiple VRFs or just one? I have a Nexus switch with two VRFs and have been banging my head against the wall for a while, trying to monitor both VRFs at the same time. I can monitor one of them with no problem but not both.
If you have multiple VRFs, do you mind sharing more details?
Patrick Rouse
·2 years agoThanks so much for raising this opportunity. If you don’t mind, please create a feature request in your LM Portal with this information as well as the URL to a device with this configuration, so (if you authorize) we might assess the feasibility of what you’re asking. I’m happy to have our team look at this as an enhancement.
However, because this will require research and regression testing, if it is urgent please consider options like LM Professional Services, creating your own DataSource, or engaging a consultant. Even if you choose this route, I hope you will create the feature request so we might have a customer-related improvement opportunity.
Thanks so much.
igeorgiev
·1 year agoHi Patrick, was this feature implemented?