Bahlkris

Right, I don't think we necessarily expect Orion to tell us why the error is occurring, more that it is. My problem in all of this was I was being told there were no errors when in fact there were. At closer inspection over the last 12 hours it appears the firmware on that c7000 is several versions behind.

I am a "press the big shiny red button" kind of guy, so I'll go play with that. Thanks.

That would be a great feature, we are migrating from another NMS(InMon) that had that and it was probably our most used feature next to alerting. Do you guys ever forsee LAN Surveyor being gobbled up by Orion as a module? Unfortunatly LANSurveyor isnt free so I cant even think about getting it till July :( If I know the…

Well I guess we will be getting the IP SLA Manager =)

We aren't on this end, I am having my AD guys look at auditpol to get those events added. If you are seeing those ID but your UDT is still wrong I would probably open a ticket. We may have different issues, or you just may be ahead of me.

So if we have to use the HrSysUptime OID, which appears to work, what number is the standard SysUptime OID reporting? And when that value zero's out what is happening to make it zero out?

Ok so here is the official word from TAC on our 6500 issue. It appears the affect is broad and they have no intention to fix it. I dont believe there is a VSS version that isnt 12.2, so this would appear to affect anyone running VSS. Removing ip sla probe (configured by SNMP) in CLI reloads Standby Sup Symptom: The standby…

What if you removed the interfaces from the device, but not orion. And they don't show up in the node management but they do show up in the system manager console on the server. -b

Right 2004, gotcha. Thanks for the information gorilla. :) -b

I'd be interested in that as well.

Wow you are way ahead of us on sources. What is your disk setup on your server? direct attached? SAN? Sas disk, sata, iscsi? I'm now wondering if i have a different problem.

**edit nm, appears to be a feature change between the version we had and the we now have. thanks

Yes. "Solarwinds-Orion-AdditionalPoller-2014.07.29-b109-SB" to be specific.

So can I assume you made this change in your environment? And if so what if any negative impact or change in the data did you see? Logging level and correlation makes me think there must be some sort of negative impact to this change.

Ahh ok thanks, I have a ticket open currently and I also have a call into Cisco to see if any of the "later than 33" versions support "pool". I'll report back. If anyone reading this has a 6500 VSS being monitored by the DHCP monitor I would really like to know, just so I know its possible. thanks -b

So really I guess IPSLA in general is a case by case basis sort of thing. We arent having any DHCP issue, but maybe 2 seconds for a M$ DHCP server is normal. I'll take your advice and baseline these operations and build my thresholds on errorless enviroments over time. Thanks for the detail =) b-

Yes, it was a bug that was in version 1. All better now. Sorry I said I would report back and I spaced it. b-

I was running 10.4.1 for about... 15 days, recently when to 10.4.2

I totally agree, Solarwinds can provide the short term solution and Cisco can provide the long term solution.

I just got this back from Cisco TAC, and based on it I would suggest maybe someone at Solarwinds contact their Cisco Partner resource. Cisco TAC wrote: I did research this and didn't find anything wrong on the switch side. All the 'X2-10GB-SR' transceivers are operating under the defined threshold values. While researching…

When you say normal PC are we just talking a windows box? And what polling method are you using for that PC?

Just as user feedback, it seems odd that RIP makes the list but EIGRP doesn't meanwhile 2 versions of OSPF do.

Do you ever work on something and miss something so basic that you feel the solution has to be complex then someone shows you how it isnt and you feel like goof? :P thanks ChrystalT -b

I'm under the impression from the docs that there is a default RO SNMP string in place on LEM, is it possible to get that string from support so I can put our LEM server in Orion NPM so we can monitor it for outages? Id rather not do straight ICMP monitoring but I will if I have to.

This is exactly what I was hoping to hear. Jacob if you are at live I am going to come down and hug you.

Definitely, we are still having a "back and forth" with regard to the issue. Bahlkris-- Since the case is still being investigated, please post back when you get an answer from Support. M

I opened a ticket with support, they are saying this issue will be fixed in the next service release. fyi -b

Are you talking about "active alerts" as in the program in the alert manager that runs on the Orion server? Or are you talking about the resource that you can add to the Orion web interface called "Active Alerts" under the "Alerts - Defined and Triggered Alerts"? Assuming you are talking about the latter, no I don't…

Ahhh ok, thanks for pointing me in a direction. So I talked a admin into going into that and it turns out there is a warning under memory in the hardware status. Sorry I don't normally have access to this and trusted someone telling me everything was ok. My hunch here is the warning is due to the memory status being…

I seem to remember the jump from NCM 6.x to 7.x being somewhat long, nothing over an hour or anything. I don't think you are going to need a 4 hour window but better safe then sorry, if its a situation where you are going to get chewed out for going over a timeframe dont take the word of a green alien off the internet as…