I'm not sure if this has already been covered somewhere else and I know there are quite a few posts related to this but there aren't many resources in the content exchange.. This resource will display the current BGP peer sessions that are not Established. NPM now comes with routing neighbor polling which also includes OSPF and EIGRP. I have selected BGP as I already have another IGRP monitoring resource set up. The resource below is displayed on our NOC view as well and provides a great glance into your managed network. Now to the small bits.
The routing information is polled every 180 minutes by default and neighbors are also kept for 30 days by default. you can check your retention settings by running the following query on your sql server's NetPerfMon DB:
select * from Settings where SettingID like '%rout%'
and you will get your retention periods for flaps/neighbors/default route flaps and table polling intervals.
you will see that on the NPM_settings_routing neighbor_retain_days set. Now before we go any further I'll say that I had to open a ticket with Solarwinds on this because there is no easy way of figuring this all out and they instructed me to modify the retention periods as well as check/change db maint. schedules. If you are unsure about any of these settings please ask a member of the solarwinds support team or even a SCP to help.
UPDATE Settings SET CurrentValue=3 WHERE SettingID='NPM_Settings_RoutingNeighbor_Retain_Days' <-- change the #3 to whatever amount of days you'd like the retention to be set at for the routing neighbor retention.
The below query works just fine with the exception that it will show you ALL of the removed bgp peers as they will stay in the tables until otherwise stated. I say fine because if there is a BGP peer that goes down or is in any other state but Established it will show up and when the neighbor is Established again the peer information will be removed from this resource. We'll go a little further and just check to see the information that you're looking for actually exists..
###############
SELECT
dns,
rn.autonomoussystem,
NeighborIP,
rp.DisplayName,
rpsm.displayname,
rn.lastchange
FROM NPM_RoutingNeighbor rn
LEFT JOIN NPM_RoutingProtocolStateMapping rpsm
ON rn.ProtocolID=rpsm.ProtocolID
AND rn.ProtocolStatus=rpsm.ProtocolStatus
left join npm_routingProtocol rp on rn.ProtocolID=rp.ProtocolID
left join Nodes on rn.NodeID=nodes.NodeID
where rn.protocolstatus <5
order by rn.lastchange desc
###############
It's important to note that an understanding of the different stages/states of the individual routing protocols as we're querying multiple tables to form this information. The above returns all of the peers that are not in an Established state. Even if a peer is coming up and going through the connection process it would be listed. if we then formatted the query for swql(below) then you could use this as a resource as is but you'll find that your retention periods will come into play as listed above.
This is the SWQL for your resource.
SELECT
dns,
rn.autonomoussystem,
NeighborIP,
rp.DisplayName,
rpsm.displayname as "status",
rn.lastchange
FROM orion.routing.Neighbors rn
LEFT JOIN orion.routing.RoutingProtocolStateMapping rpsm
ON rn.ProtocolID=rpsm.ProtocolID
AND rn.ProtocolStatus=rpsm.ProtocolStatus
left join orion.routing.RoutingProtocol rp on rn.ProtocolID=rp.ProtocolID
left join orion.Nodes on rn.NodeID=nodes.NodeID
where rpsm.orionstatus !=1 <------ this !=1 means that in the routingprotocolstatemapping and if you query only the rspm table you'll see 1 is the FULL and ESTABLISHED # for both BGP and OSPF and anything else will be shown.
order by rn.lastchange desc <------ last time that the neighbors state changed.
####################
now we have the resource up there are a few things to go over.. There are two things(one listed above) which will impede this resource from displaying information properly and acting as it should. 1. is your retention time. Mine is currently set to 3 days as I don't really want to know about peers that have been removed/deleted from our network and quite frankly if a neighbor has been down for 3 days then there's more of a problem at hand. 2. check your database maintenance settings as this will also come into play. It's important to also have a regular maint. schedule to make sure the tables/views don't have any kind of stale information.
you can even go further and get the resource to display more information but this is just the starter. if anyone has questions let me know. It does sound like Solarwinds is looking into having this sort of setup as a 'feature request' as i think everyone would benefit from this in one way or another.
hope this proves helpful to others.