Unless someone else has a better idea...here's how I do it.
I discover as many known IPs behind the VRF that I can, usually around 6 or more and place these as Members into a GROUP name.
I then monitor this Group for having all Members being 'down' to generate an alert which considers the MPLS VRF to be down or else there's some issue within the MPLS cloud.
It works best when you have as many members in the group which have different subnet numbers.
Another way I've tried this is monitoring the VRF sub-interface when it has zero packets per second for so many minutes. This is characteristic of MPLS traffic not flowing.
I'm open to better ways to do this with MPLS - its been a thorn in my side for years now with trying to monitor.
Use syslog messages from the router for now.
They should be sending out messages when an IP/Subnet is added/removed to a VRF, and I would assume you are using iBGP to distribute these routes across the core to other core routers where other sites might be built to, so you could also trap BGP messages related to the VRF.. This can show flapping at a remote site that is part of the VRF since IP's are removed if the connection is down. I know this is a feature request that has been around for some time. Hopefully soon we will see BGP and MPLS monitoring capabilities!
Good suggestion Richard...
But in my case - we don't own our MPLS router but our vendor does. So, I can't get SYSLOG messages from it. I'm lucky to have an SNMP read string to it.
Ya, that is a downside if you are a LAN environment using a ISP provider for your MPLS.. No control over the MPLS PE/CE router hurts!!
We have the same issue, but luckily got the provider to give us SNMP and point syslogs for us to our IP's as well.
It was a battle, but when you pay a provider enough money they should at least give you visability via Read Community SNMP and syslog. There isn't any config passed from syslog or snmp that could leave their hands, and with Read Community SNMP only they don't have to worry about you send SNMP writes to change things.
Hopefully soon we get this information via SNMP and it's added to NPM!
I still would use syslog (if you can) though. Syslog is a listener service and when you alert upon them Support teams can quickly be proactive to action the alert before sites/management start to notice as opposed to waiting on an SNMP poll to come in and putting you in a reactive situation since the site may have been down for a bit depending on your polling times you can deploy, or that dreaded time management points out an issue that you aren't aware of yet because of reactive polling and waiting on SNMP to see the same issue.
I do like how you have started to monitor MPLS using Groups, and the IP's that are a part of the VRF. Creative way to get visibility to a protocol that is becoming widely used everywhere as opposed to S2S VPN's over the INET or expensive and older Frame Relay mesh clouds.
Thanks for the valuable information.
We are considering our own MPLS on top of ISP's, so we'll have SNMP access to the edge routers.
What MPLS/VRF specific parameters would be most critical to monitor?
Is it possible to monitor per VRF network traffic? How about Netflow?
Why not monitor the layer3VPN service intsted of the VRF tunnel??
IPSLA or Other to ping your net in the other side of the MPLS much better
If anyone has had a chance to check out the 10.7 beta, we are now pulling VRF table data. Sign up here: The specified item was not found.