Articles on this Page
- 01/15/19--13:52: _Re: SWQL not workin...
- 01/15/19--13:54: _Cisco devices false...
- 01/15/19--14:03: _How to fix a miside...
- 01/15/19--14:13: _Re: False Routing N...
- 01/15/19--14:11: _Re: False Routing N...
- 01/15/19--14:34: _Re: Need to create ...
- 01/15/19--14:46: _Re: False Routing N...
- 01/15/19--16:33: _Report Help?
- 01/15/19--20:33: _Re: ESX Host with 6...
- 01/15/19--20:36: _Re: Multi-Subnet Fa...
- 01/15/19--13:52: Re: SWQL not working properly in 2018.4 (NPM 12.4)
- 01/15/19--13:54: Cisco devices falsely reporting 100% packet loss.
- 01/15/19--14:03: How to fix a misidentified device/node
- 01/15/19--14:13: Re: False Routing Neighbor Down Alerts
- 01/15/19--14:11: Re: False Routing Neighbor Down Alerts
- 01/15/19--14:46: Re: False Routing Neighbor Down Alerts
- 01/15/19--16:33: Report Help?
- 01/15/19--20:33: Re: ESX Host with 6.7 version-- Help needed on multiple issues
- 01/15/19--20:36: Re: Multi-Subnet Failover (WAN/DR) Deployment
Great! Thanks you for looking into it.
Spent quite a bit of time doing and redoing to see if somehow a special character got in there or if I'm doing something wrong. It's strange it worked on NPM 12.3 and not on 12.4.
Excited to see what you find out.
Wondering if anyone has come across this issue and what steps you took to fix it. Periodically groups of Cisco devices (Mostly 3700 series and ASA series) in our remote offices will all report as down down all with 100% packet loss. I know that this cannot be true as I can still ping these devices, and have been in communication with the local admins who have told me on each occasion that there is nothing wrong with that set of devices.
I have also experimented in changing the polling rate, in case there were any latency issues causing the packets to not be delivered.
I assume then, that there is some issue with our firewall blocking the polling traffic. I do not have experience working with firewalls, so I'm unsure really where to start trouble shooting this.
Basically I want to know whether anyone has had a similar issue, steps they took to resolve it, and whether or not I'm on the right track with the troubleshooting process.
I appreciate any help you'd be willing to contribute and will provide any necessary info to help troubleshoot.
I've researched high & low but cannot find how to fix a misidentified device/node. For example, I have several physical servers & VM's that are discovered as ASA's. No matter what I do, I cannot remedy. I'm sure I'm gonna feel dumb that it's something very easy but researching Thwack came up empty.
Thanks in advance!
Heh yeah it doesn't exactly instill confidence when it does this. For what it's worth this has been happening to me since well before 12.x
I'm having the exact same issues and it is causing my network engineers to doubt NPM. I'm on NPM v12.3 and have an active ticket with support, but so far I've not been able to escape level 1 to get better help. I too see the the state changes on interfaces that have been shutoff per my engineers. There is clearly something going on here. I don't think I saw this problem prior to upgrading from v12.1 to v12.3 a few months back.
Worth noting, When I look at the 'Last Change' timestamps in NPM they are changing and its every 30 days-ish almost on the money. Which is where I'm at odds with my network folks as they claim it's shutdown and shouldn't be flapping at all. It should consistently be in idle.
The query, as-is, should only show physical servers. It looks for nodes that don't have a virtual machine ID linking them to the table of VMs, and it shows ESX hosts, which are physical servers.
I alert on link status and Neighbor status changes in EIGRP and BGP. Seems to work well.
I am trying to run a report that will show me all the most recently worked tickets by tech. However everything I have made is not calculating correctly. The report I want would be the same thing each rep sees when they look at their recent tickets. Something that would show me every ticket they worked, closed, updated, during a set time frame. Please help
Fault is not at Solarwinds this time... VMware has a bug in this version and they are yet to confirm on when this would be resolved.. We have our tech team who had raised a case with VMware regd this as they are also not able to see hardware sensor details in Vcenter...
Thanks David for the explanation
I will observe the behavior in next patching and provide feedback if i find something abnormal...