Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

MPLS awareness and Orion

Hi all, We are migrating to our own MPLS core environment (we will be looking after both PE and CE devices) and I was curious if Solarwinds Orion is MPLS aware. We would like MPLS to monitor devices in different VRFs. I would be interesting in hearing from anyone who currently uses Orion in this sort of scenario and what they have to say about it.

Cheers

Find more posts tagged with

netflow

orion_npm

mpls

Accepted answers

All comments

bschurr

We are in the process of purchasing the NetFlow module for Orion and I was wondering if the collector is capable of interpreting MPLS-Aware NetFlow data.

mcbridea

Not today. MPLS aware NetFlow requires templates and we don't support that now. You can only get MPLS NetFlow data if you are on an LSR. Are you in an environment where you can send data from the LSR to a NetFlow collector. I would like to understand your use case better.

Andy

bschurr

Yes, we have our own MPLS network and would like to turn on NetFlow Version 9 export format on the LSR to increase the statistical reporting ablity on the device. We were hoping that the Orion NetFlow collector was capable of displaying MPLS-aware NetFlow export packets in Version 9 format. The link below explains what we are looking for in greater depth.

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsmnf24.html

bschurr

I know that the v9 format is supported, but the following note in the administrator's manual leads me to believe NTA will not display the MPLS label or vrf information. Am I correct?

Cisco devices using NetFlow version 5 or 9 Note: Orion NTA only recognizes NetFlow version 9 templates that include all fields utilized by NetFlow version 5.

ctopaloglu

Any update with this?

RichardLetts

I use Orion extensively in an VRF environment, for NPM and NCM it does this fairly well for most of the out-of-the-box functions (at least with JunOS devices). Where it falls down are on the vrf-specific tables (notably the ARP table that affects IPAM, UDT, NCM), and the Routing tables (that affects NCM), and if you have any custom pollers that access VRF-specific information.

If you have a small number of VRFs you can get around these limitations (by using one poller per VRF).

I have a product enhancement vote out for MPLS support for JunOS.

sja

Hi Mustafa & Richard

I think you 2 should explain what are the objectives

1.Monitor L2/3 tunnels ?

2.Monitor MPLS label ?

3.Monitor the LDP signal protocol?

And so on.....

As anet guy I sure like to get as much info as i can but some how MPLS is not so high priority.

remeber the ISO model

1.Better layer 1 (when fiber/SFP) start getting bad I like to know...

2.Better layer 2 Data link info /MAC /STP/Interfaces there are so many l2 info you can use out of the box.

2.5 MPLS networks

3.Better layer3 Well SW are on the way to do something about it I use ISIS/BGP and I dont see ISIS that on the roadmap.

What I trying to say is NO MPLS if you have problem with layer 1,2, or 3.

RichardLetts

Please read more on how a MPLS network works because you have some invalid assumptions in your comment.

In much the same way that VLANs virtualized a switch infrastructure MPLS virtualizes a router infrastructure

In much the same way as vmWare virtualized hosts onto server hardware VRFs (part of MPLS) virtualized the routers onto router hardware.

If a router running is a MPLS/VRF mode one will find many 'virtual routers', each with its *own* set of ARP and routing tables. This means that polling the 'router' for information like NPM, UDT, IPAM currently polls for is more complex because the information does not 'leak' into the 'host' router. (in the same way that polling for disk or CPU on a vmWare server doesn't tell you about the disk or per-process usage of the guest's virtual disks or processes)

The physical layer is common to the 'host' router, the other layers are virtualized

ARP (L2/L3) are per-VRF
L3 routing tables are per VRF

Monitoring of MPLS state (LDP, tunnel state, etc) can mostly be taken care of with existing monitoring -- this is akin to monitoring a VMware server for its interface and process state.

Tunnels are simply interfaces that can currently be monitored
LDP, if it works packets move, if it doesn't routers are down and BGP stops working
BGP (for which there are traps) to transport the labels and associate them with the L3 routing entries can be monitored using traps.

Citing the ISO model and simply putting MPLS in at 2.5, like you have, doesn't describe how it works at all.

Richard