Routing information in NPM

http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol

I'd like to also see BGP. The thing I'm looking for the most is to see a link not routing traffic. For example, I have a remote site with 2 links. If the primary link stops routing, the traffic switches to the backup link. Currently in NPM, I can't see that this has occured. Both links are still showing as being up.

jspanitz

We'll add a +1 to Goliath's responses. The only addition would be Juniper support. We have Cisco and are moving more and more to Juniper. So supporting both is key to us.

NatroN

1) OSPF, EIGRP

2) Compare with older snapshots. Or definded "prefered next hops"

3)BOTH

4) Alerting is a must have. In my rather small network I've already implemented alerting for the most important routes in NPM - but as I'm working with very specific SNMP Traps this is almost impossible for big networks.
5) Cisco

sja

1.BGP
2.Arp or direct connected interface

3. probebly LLDP for switching networks

4.Intra AS Routing like OSPF/ISIS

sjocchiogrosso

1) OSPFv2, OSPFv3, EIGRP, BGPv4 -If you can add those routing protocols, adding RIP, RIPv2, RIPng should be easier but not important.

2) I'd be happy with the neighbor state would be fantastic.

3) I'd prefers tables, a nice simplier. However I can easier visualize a network in my head.

4) Yes, alerts to track the neighbor state. I currently have Pollers to poll neighbors but if they could be built in that would be great. Reports would be good in a sense of availability, think about enterprise's with MPLS providers and SLA's pulling a report that said the MPLS network was unavailable for X amount of time would be fantastic.

5) Cisco, HP, *nix flavors/Quagga.

--------

Unless there is a MIB to pull the routing table, I don't see how you could guys could do that (but you guys have impressed me many times in the past) The other problem is with routing protocol like EIGRP would the topology table (all links in the topology table not just the successor and feasible successor) and with OSPF would the entire OSPF database get pulled? Either way I'd be happy with neighbor tracking and alerting.

Stephen Occhiogrosso wrote:
Unless there is a MIB to pull the routing table, I don't see how you could guys could do that (but you guys have impressed me many times in the past) The other problem is with routing protocol like EIGRP would the topology table (all links in the topology table not just the successor and feasible successor) and with OSPF would the entire OSPF database get pulled? Either way I'd be happy with neighbor tracking and alerting.

A message gets logged into syslog, hopefully they'll be able to get the information from that to do neighbour tracking.

sjocchiogrosso

If the routing neighbor goes down, there is a chance the syslog message might not make it to the Orion. I've seen a lot of instances were the link stay up but the routing neighbor is down and everything looks good from Orion's point of view.

I've already got a custom poller (found in the content exchange section) in place that monitors the neighbor status of EIGRP/OSPF/BGP with proper alerts.

Stephen Occhiogrosso wrote:
If the routing neighbor goes down, there is a chance the syslog message might not make it to the Orion. I've seen a lot of instances were the link stay up but the routing neighbor is down and everything looks good from Orion's point of view.

You're right, syslog is not super reliable but can you please give me an example of these instances where a link is down (and there's no backup link) to routing but the remote site is still showing as up in Orion?

branfarm

1. OSPF and BGP

2. Neighbor state, prefixes received (for BGP)

3. Table

4. Neighbor state changes, prefix count change (raw count, delta, or % change)

5. Cisco

I currently use EEM and UDP's for this, but I run problems with EEM on some devices so my monitoring is incomplete.

Sure it would be able to alert on BGP dropping. If you are creating Syslog alerts off of this you should be creating the alert of the Ajacency change message. This message should come from both sides of the router that you have BGP operating with since adajacency has to be up on both sides to pass BGP traffic, so a link dropping wouldn't stop you from getting this message.. Maybe from the PE router that you don't control, but not the other router that it has adjacency with that you are monitoring in NPM.

1. OSPF, iBGP/eBGP, EIGRP, Static Routing Tables (doesn't seem useful but I bet someone would love it)

2. See most of the above statements.

3. Table

4. I would expect these have logic built into the Advanced Alerting engine, so I can tailor the alerts to my needs. I hardly have used a built in alert except to customize the base of it to my own needs.

5. Cisco, Juniper, Huawei, HP, Extreme (just a few of the companies I see alot in Enterprise WAN/LANS

Forgot to add that #5 I listed them in a priority manner as to who I see used the most.

Message was edited by: Richard Nicholson

Guys, you are awesome! Thanks for all your great feedback. We are already actively investigating this topic and I'll keep you informed.

thanks,

Michal

got it, thanks.

Hi,

what causes link stopped working? Can you use interface/port traffic to unveil the problem?

Hi,

could you please send me your alerts definition on michal.hrncirik at solarwinds.com? It would be helpful to understand all the details.

thanks,

Michal

The link drops due to a carrier issue. Someone could have cut the link or some of the carrier's equipment has issues. In the logs you see that BGP drops its neighbour but the interface still shows as up as carrier's onsite router is still up.

So if the remote site only has a single link, the site would be down but when the remote site has a backup link, the router and interfaces can still be seen as being up even though now the traffic is going via the backup link.

Gustelj

1. EIGRP, BGP (VRF aware).

2. Current neighbor and route statuses (if possible, correlated with node names from NPM database).

3. Table.

4. Alerts on neighbor status change (configurable per neighbor).

5. Cisco (ISR, ISR2, 7600, ASR)

sja

question about the routing tabels

When the router is has full BGP table ?

I'm not sure that SW should monitor that table or just the 0.0.0.0 next hope?

/SJA

The 0.0.0.0 next hop would be a static default route for all traffic that can't find a route out, or used when all traffic has only 1 exit point needed to the ISP. This wouldn't be of any value when you have a Table full of BGP peers. If you are using BGP and have a Static 0.0.0.0 route then I hope you are changing the AD of the the static route. Since by default it has a lower AD then BGP it would be used for all routing over BGP until that route fails. This really defeats the purpose of BGP routing.

The only issue I see polling the routing table is when you have peering points at exchanges and your BGP tables can be upwards of 100k+ routing entries based on the peers you peer with and what geogrphical locations you are peering at. This could put some strain on the CPU as it pulls this information. Just like you see when you constantly draw the ARP table out of a router.

sja

Yes

That what i trying to point is the size of the table when you get the full BGP table from your peers ISPs.

Michal du you follow that?

When the customers get the global routing table from the peers that could be en issue/problem...

/SJA

ecklerwr1

The key is what Tomaz D said here "4. Alerts on neighbor status change (configurable per neighbor)."

Configure it on only on your two links BGP neighbors in the alert. You can get as fancy as you want with the advanced alert... combo of actual links and BGP neighbors peer status. There's NO reason to pull whole routing or BGP tables.

Customize the alerts for each specific peering location where you meet some other AS. It doesn't matter whether you have 2 or 20 (doubt this although 3 or 4 isn't unheard of) links to the other AS.

First off this has gone way off topic to discussing how effective alerts can be right now using syslog/traps.. This wasn't the Original post topic.

To clarify as well.

I would want to see my BGP peering table in full all the time if I was using this, and I'm not talking about the Prefixes or Full Routing table. I want to see my Neighbor tables. I used to work for a Global Video & VoIP provider that provided services through the Cloud and Public INET. The way we were able to have such a large global footprint and reach to other Geographic locations was due to BGP Peering at many Peering Exchanges. Do I care what routes they are exchanging with me?? Yes, but not on a SolarWinds level, but I would want to see my output of "show ip BGP neighbors".. This shows me if my Connection with the said peer is in an Active/Idle/Established state and passing prefixes or not.

This type of information would be huge for that company I worked for. Now I can quickly see what peer is down and with who. One way we got into China from the US was peering at the HKIX(Hong Kong Exchange) by doing this we could peer with ISPs and IP Transit providers that had direct links into Chinese territory and actually get past the "Great Red Wall" for VoIP and Video services based in the US. It was imperative that I kept an eye on all those Peers at this exchange and worked any outage as quickly as possible.

Also, many ISP that use BGP peer links for their INET/IP Transit gateways and are usually Fiber/Ethernet Gig/10Gig Links and will have multiple BGP Peers talking on the same link. We did this at a small CLEC and used a 10Gig Ethernet handoff from Global Crossing, but had 4 BGP peers talking on the same link. 1 with ATT, 1 with GBLX, 1 with Sprint, 1 with VZ. We were able to load balance and use priority routing on one link, and dynamically receive nicely segmented amounts of prefixes from each provider and at a peering exchange your single link to the Peering fabric can allow you to peer with 1000's of different AS numbers depending on the size of the Peering Exchange.

Routing as many different avenues of how it is used and configured. You really can't look at BGP on a single use case. BGP is used many many ways.

I do however agree with on the lack of integration and functionality of the Orion Syslog/Trap manager for alerting.

that's interesting. I can understand significant size of that table. So if we would not poll whole table, what's the minimum set of data you would like to see there? Or would you prefer to load some part of that table "on demand"?

thanks for explanation - this is a good discussion.

Michal

familyofcrowes

I agree. The ability to see your neighbors would be very helpful.then alerting can be built on a change in that table.

We are not big users of BGP, but I am more intrested in the same idea for EIGRP and OSPF. With multiple neighbors/paths, its good to know when one is having an issue.

Good examples...

RichardLetts

1) What protocols/routing data do you need to monitor?

BGP primarily, OSPF, LSP,

2) What value do you expect from this routing table monitoring (just actual state, do you want to compare it against older snapshots, what info are you looking for there)

Neighbor state; I do not want NPM to download the routing tables: Several of the routers here have close on a million routes access 36 routing tables. In NCM I'd like to be able to configure which devices it grabbed the routing tables from -- on L2 switches they should be small, but on the InternetCoreCoreRouters they are huge.

I would like it to periodically poll for statistcs (see #5)

Make use of SNMP traps for OSPF and BGP events

3) How would you like to display routing info (table, map,...)?

peer state, table size, AS prefix length.

Here the routing table size makes maps and tables too burdensome.

4) Would you expect any build in alerts or reports? If so, which ones?

alerts:

BGP neighbour down

BGP neighbour reset

BGP peer table size

BGP prefix length exceeded.

Reports:

Peer availability.

5) What vendor(s)/devices do you need to poll?

Juniper MX and T-Series (in MPLS mode); the jnxBgpM2 (1.3.6.1.4.1.2636.5.1.1 ) has many interesting counters and values for BGP peers that avoid the need to read and count the entire routing table.

thamizh85

1) What protocols/routing data do you need to monitor?

EIGRP, OSPF, Static Routes

2) What value do you expect from this routing table monitoring (just actual state, do you want to compare it against older snapshots, what info are you looking for there)

Grab the routing table periodically (Part of NCM inventory)

Compare it with previous polled version or baseline and send out a report on routing table updates

Monitor specific neighbors on critical devices (Using NPM. I am using Syslog based alerts for this purpose currently)

3) How would you like to display routing info (table, map,...)?

Both. If possible only summarized routes should be available on maps, to avoid overcrowding

4) Would you expect any build in alerts or reports? If so, which ones?

Alerts:

Neighbor down alert

Reports:

Routing table updates

Peer availability.

5) What vendor(s)/devices do you need to poll?

Cisco and Juniper gears

Beta with routing is available! Your feedback would be very useful -

Hi,

our beta 1 has support for OSPF, did you have a chance to test that? we are looking for a beta feedback.

thanks,

Michal