I am looking for a route monitoring product that does the following:
-checks if a specific bgp route from a specific neighbor is present the BGP table (in some vrf, not necessarily internet routed vrf) of an ASR9K running IOS XR
-sends a syslog message or an alarm if the route goes missing
The use case is the following: we are receiving same routes over 2 or more bgp peerings, due to best route we cannot really see at the moment if one of the routes ceased to be received over a certain peering.
Alternative approach: a product that measures the number of bgp received prefixes from a certain peer.
Do you know of such product that is readily available and does not require ssh sessions to the routers and parsing the outputs?
I am trying to find a solution that does not require much scripting or customization.
Most monitoring products allow you to monitor custom SNMP OIDs, and your entire BGP RIB is – usually – exposed via SNMP.
Most monitoring products also treat “missing” OIDs specially, and can alert on that fact.
At least, that’s how I would start doing it.
We use Observium here, and it can do what you want, albeit with a little bit of futzing around in the Custom OID and Alerts sections.
Cisco does weird things with getting SNMP data from VRFs, though, so… YMMV. I know there used to be a Cisco-proprietary way to select which VRF you were polling common OIDs from, but don’t remember the details.
This sounds like something BMP might be useful for. I haven’t used it, but I would look at OpenBMP (https://github.com/SNAS/openbmp) as a starting point. I’m not familiar with what commercial offerings are out there, but I’m sure there are some.
Re: Adam’s advice about IOS/XR SNMP access to VRF, while this experience may be a bit dated [IOS XR 5.x], in production we have used “snmp-server community-map $x context $y”. I will say we weren’t pleased, we noticed that context switches didn’t work well. For example if our poller tried to simultaneously poll the global community and the vrf community at the same time, the results were non deterministic. Maybe this has been improved in later versions, or if you always have a single poller that will always be sequential, you may never see this.
Although more work BMP is probably the better/safer approach.
Suggestion to run BMP is a fine suggestion. Another option is plain
old BGP, setup iBGP+best-external (w/ add-path if you may receive >1
copy from local eBGP neighbours) from these boxes to a collector bgp,
maybe with a prefix-list filter to send only this prefix. Then have
the collector box raise an alert when it doesn't receive the route
from one of them.
Writing this from scratch in any language that has a free BGP library
(shockingly most open source BGP implementations are written 'wrong',
with tight coupling of consumer code and protocol, instead of
separated protocol library and consumer code, robbing us from BGP
libraries in many languages) is maybe 1h of work. Or you could use any
open source or commercial BGP implementation and query those (if you
did prefix-filtering on source nodes, the entire RIB is 0 to 2
prefixes), but this would require some work still, as you'd need to
query them either via some API or SSH.
What does 'much scripting or customisation' mean. I fear it means that
none of these, nor BMP work, as you still need to query for the data
somehow and act on it somehow and you just want to copy paste 'conf
term; ip do-the-thing', which I'm afraid isn't available.
Have you looked into object tracking?
This will work if the route state changes and is removed from the routing table.
So if the route is no longer present it will trigger for sure.
I admit I have not tried to see if it would trigger on a change from peer 1 to peer 2, as the route is still “up”.
This functionality is built into XR and can generate syslog events directly from the router without any additional software.
Disclosure - I work for Blue Planet.
Blue Planet, a division of Ciena, has Route Optimization and Analysis, a product that provides visibility into IP/MPLS networks and IGP/BGP routing. Its routing alerts include peering state change, prefix state change, path change, alerts for when number of non-baseline BGP peers are above or below a threshold, etc. It may have something to cover your use case.
Used and loved the product when it was called Packet Design, before Ciena picked it up. The IGP insights are amazing!