Community
Command Central
MVP Program
Monthly Mission
Blogs
Groups
Events
Media Vault
Products
Observability
Network Management
Application Management
IT Security
IT Service Management
System Management
Database Management
Content Exchange
SolarWinds Platform
Server & Application Monitor
Database Performance Analyzer
Server Configuration Monitor
Network Performance Monitor
Network Configuration Manager
SQL Sentry
Web Help Desk
Free Tools & Trials
Store
Home
Products
Network Performance Monitor (NPM)
Extreme Networks: ExtremeWare and XOS
FormerMember
Anyone else notice how much longer discovery takes when adding an XOS device vs an ExtremeWare device?
This problem seems consistant with the BlackDiamond 8810, a/k/a Black Diamond 8810, aka Aspen 8810 & the Summit 450.
Find more posts tagged with
Accepted answers
All comments
barend
We have got the same problem with Orion 7. The 48Si are working lighting fast in solarwinds, but the XS450 are dramatically slow when discovering the ports etc.
FormerMember
I too noticed that Ver7 was slow, but the Ver8 Orion that I'm now using in conjunction w/this switch is unsatisfactory. The S450 has been discovering for over 12hours & only 33 interfaces have been found thus far.
FormerMember
I'm seeing the same thing with the Summit 450. MRTG's cfgmaker enumerates the interfaces quickly, but Orion is so slow that it's practically unusable.
FormerMember
I have had the same problem on a x450. It took 32 hours to dicovery all interfaces. I was going from the US to Germany thru a VPN tunnel. I know that does not help but that was way too long to discover.
SZ
FormerMember
I did a packet capture & saw the NPM sending alot of SNMP get-requests to the XOS device that was failing to send SNMP get-responses to the querrys. The Extr.Net TAC indicated that my switch is defunct & suggested a RMA. This does not appear to be the kind of problem that can be cured w/a RMA as the problem looks to be consistant with those appliances running XOS.
FormerMember
We're still running Orion 7.8.5 and we're experiencing the same issues. If its a new XOS switch, its extremely slow discovering the interfaces. Any non-XOS switch works just fine. Our folks dread having to add a single port to Orion right now since it takes soooooo long. We're also migrating away from non-XOS switches to our new BD8810s and BD8806s.
There's also an issue with Cirrus and XOS switches. It errors out and isn't capable of downloading the conifgs. Again, non-XOS switches work just fine as always.
Something Extreme did with XOS doesn't agree with Solarwinds products at the moment.
Any ideas Solarwinds folks?!?!?!
-Steve
FormerMember
Steve,
In light of MY experience, reasonable deduction dicates you'll be compounding the same problem we share when it comes time for implementation of your Aspen/BlkDmnd 88xx.
Having explained the XOS variance to my leadership, our course of action, at this point, is this: monitor XOS devices via ICMP only. I know this really negates much of the Orion NPM functionality...but, that's where we are at, right now.
Moving forward, I have a meeting with my Extr.Net AE & SE on Mon.14may07 at which point I'm going to mention the preceedings.
Assuming you read the above thread...you saw where Extr.Net TAC suggest RMA. My problem with that resolution is that I am confident such action will NOT resolve the issue. I agree w/you that... "Something Extreme did with XOS doesn't agree with Solarwinds products at the moment.", realitive Orion NPM.
However, if all's working okay with MRTG, I can't rule out, with conviction, that there's not someting going on with Orion NPM. I WILL say that when I did a MIB querrys of my XOS devices & my ExtremeWare devices, with an independant SNMP-walker, my XOS devices consistantly failed.
I'd be curious to see packet captures from you upon config parsing with Cirrus in comparing ExtremeWare with your XOS appliance(s).
Based on the activity of this thread, it's looking like the problem's wide-spread with all OrionNPM users managing XOS devices &, in light of your recent comment, perhaps Cirrus users as well. That's not good, eh?
/martin; ENA, ENA-PS, ENS [former ccna/ccda/ccnp/ccdp...]
smgllp.it.staff@gmail.com
Quick Links
All Categories
Recent Posts
Activity
Unanswered
Groups
Help
Best Of