EIGRP support

What's the trigger condition you utilize for this?  Wondering if it would also work for other routing protocols ... specifically ISIS which is what we use (yea people actually do use it heh).

Opened up a ticket with SW to see if they could show me how to do this, but they weren't able to and said will need to be a feature request.  Since ISIS is barely used I doubt that will ever get done so looking to do it myself.

Appreciate any additional information you could provide on this.

I've been able to get what I need done with EIGRP. Wondering specifically what this post is asking for? I monitor my 'hubs' for when an EIGRP neighbor failed on them at remote sites. We use IWAN technologies so all our RBOs have redundant/multiple ISP connections with EIGRP neighbors. The branch doesn't have an outage and we have a ticket in our queue letting us know which site when down. The only thing I had to do custom was SQL to get the router that the EIGRP neighbor was down at. Here it is:

EIGRP neighbor ${N=SwisEntity;M=NeighborIP} (${N=SWQL;M=SELECT NIP.Node.Caption FROM Orion.NodeIPAddresses NIP WHERE (IPAddress = '${N=SwisEntity;M=NeighborIP}')}) gone down.

EIGRP was released as a standard to the general public in 2013 and is no longer Cisco proprietary.  However, other router manufacturers seem to have set a standard of not adopting it.  They still feel that Cisco's "Open EIGRP" standard tends to draw customers to Cisco routers.

I don't know which, if any, vendors besides Cisco sell or support EIGRP on their routers, and it's likely for that same reason.

I've talked with organizations that want to use EIGRP, but they fear it will impact their viability as targets for mergers or acquisitions by bigger companies that use OSPF or BGP instead of EIGRP.  It's a funny worry to have.

My guess is the only reason EIGRP wasn't added is that it's Cisco proprietary routing protocol but not sure why that should matter.  OSPF etc. are open source protocol.

Hello, community.

I just had a ticket for EIGRP closed under the guise of SolarWinds support considering my inquiry to be a "feature request."  I couldn't believe what they said was not currently supported by the product.  Get this: NPM can recognize that a node is participating and running an EIGRP routing process but, for whatever unfathomable reason, they do not record the Autonomous System (AS) ID of the EIGRP processes of which the node is a member.  I mean, that just seems like the most basic information to collect in the process of determining whether or not the node is running EIGRP.  Can this really be accurate?

The request in this current thread asks for EIGRP support.  What could be more basic than this?  This feature request is the #5 most requested for NPM, and it's been open since 2013.  Surely, a "mature" product like this could not have overlooked that piece of the puzzle.

If anyone from SolarWinds is reading this, my ticket was called "EIGRP Processes and Autonomous System (AS) Memberhip" (Ticket ID 38726).

Routers report EIGRP neighbor changes to my NPM via syslog.  They could also report via traps.  And either could cause NPM to fire off an e-mail, send a text or a pager message, or even perform a script.

I wonder what specific functionality the original requestor familyofcrowes​ imagined?

This request is rather vague (and old), so I'm not sure what it's looking to achieve.  That could be why it hasn't garnered a qualified response.

To add 2-cents on version 12.2, it does appear NPM recognizes the node is participating in "Cisco EIGRP" and has neighbors (indicated by IP).  However, it doesn't look like it's parsing/recognizing the EIGRP AS Number(s) of which the node is a member.  I have a ticket open on the issue now, but it's unknown whether or not this is a part of the current feature set.

By contrast, a node participating in BGP does indicate the Autonomous System (AS) number.  While I haven't checked all the routing protocols, it appears OSPF doesn't collect the AS number (or Area) either.  Sounds like this may be a can of worms for SolarWinds to address, but competing products do this already (and have for years).

Also bump.

ThwackCamp Bump!!

I'll bet that there's no number at which SW "has to do something", but I also believe that the higher the vote count goes, and the more frequently bumps occur (to indicate this is not a deprecated technology), the more interest SW understands we have towards making this feature request come true.

Given Cisco's predominance in the router market, and that EIGRP is not longer Cisco-proprietary, one would think EIGRP support in NPM would be on some team's front burner.