Hi,
I want to share with the community a couple of private replay I've received:
-> Many of my discovery problems are related with Enterasys devives.
"There is a problem after 9.2 with Enterasys and the LLDP protocol and
you must switch of the LLDP Protocol on the VNM Model . You find it in
the information tab under Autodiscovery control-->Modeling and
protocol options-->Discovery Protocol Table-->no. Also you must switch
of these option in your existing Discovery Profiles.
You can test it by make an SNMP walk on the device and the SNMP walk
never come back (we abort it after 30h). Also there are an Option you
can set on the switch itself called snmp_timebreak but this didn´t
work on all switches"
I think snmp_timebreak is a config command available only in Enterasys
MatrixN and newer switches.
Be aware that that if you disable Discovery Protocol Table, you are
disabling not only LLDP Protocol, but also CDP and other proprietary
protocols that are very useful when discovering connections.
-> Other symptoms I've noticed too are that OneClick and other
Specturm services can't connect to SS process and RAM is growing.
"In this case - you can solve this problem with following steps:
1.) create an Online Backup and copy latest SSDB to $SPECROOT/SS/
2.) set Spectrum back to "Legacy DB"
Spectrum Control Panel / File / "Initialize to Legacy DB"
3.) in Shell/CMD go to $SPECROOT/SS/
4.) Load only models into SSDB from latest SSDB
Execute: `../SS-Tools/SSdbload -m [path_to_latest_SSDB]`
5.) Start SS
6.) Leave it running for some time - look at "Spectrum Performance
View" if RAM grows
7.) Try Stop SS
Should stop within minutes.
(Stop SS only when Spectrum has all models activated
1.) .vnmrc -> wait_active=yes -> Spectrum gets only in Running
State when all models activated
2.) OneClick / VNM / General Information / Percent Models
Activated -> 100%
It should be fine now!"
I haven't done what you say right now, but when I upgraded to 9.2 I
run SSdbload -m in order to have a fresh modeling catalog. The problem
when you follow your procedure is that you lose your watches (and your
own developed model types if any).
Thanks to everybody. As Jim said initially, if you have discovered
more estrange behaviors in 9.2, we can share with the community.
Regards.
James.
On Wed, Mar 30, 2011 at 12:21 PM, James Garthek <[email protected]> wrote:
> Hi,
>
> In Spectrum 9.2H03 I have a lots of problems with discovery related
> tasks (autodiscovery, discover connections and connect with). A lot of
> times, this tasks never end. So I cannot launch other discovery
> process (a popup window tells me discovery is already running). And
> memory starts growing until finally SS dies!!! In this cases I cannot
> either stop SS manually. I have to kill -9 the process.
>
> When is there going to be a new HotFix or ServicePack to fix this
> great amount of bugs in Spectrum 9.2???? It's unusual that CA doesn't
> release anything in so long time!!! And it's also unusual that CA
> release a Spectrum version with so many bugs!!!
>
> Regards.
> James.
>
>
>
> On Mon, Mar 28, 2011 at 8:22 PM, Pfleger, Jim <[email protected]> wrote:
>> I wanted to share with everyone some of the problems we’ve had with Spectrum
>> that we’re currently working with CA in the hopes that knowing about them
>> will help out others. I don’t know if they are specific to 9.2 H03, but I do
>> know that they all exist on this version.
>>
>> SRM missing alarms. The SRM alarm table is missing alarms that the SRM event
>> and outage tables say should be there. We originally found this when going
>> through the outages table and trying to match up outages to alarms so we
>> could get their trouble ticket IDs. As we’ve continued to work this, we’ve
>> been able to craft a query that matches the number of 0x10701 events (“Alarm
>> will be generated”) with the number of alarms actually in SRM for the same
>> time period. If anyone would like to check the consistency of their SRM
>> databases, contact me directly for the query. CA has accepted this as an
>> issue and is working to determine a cause.
>> Condition correlation engine does not resuppress. This one takes a bit of
>> explaining, so please bear with me. Suppose you have a simple network like
>> this:
>>
>> SS --- A --- B
>>
>> If B goes down, you will get several alarms, including “blade status
>> unknown”, “chassis down”, and “device not responding to polls”. In our
>> environment, we have a condition correlation that will use “device not
>> responding” to suppress the other two, so the operators see one root cause,
>> and two hidden symptoms. Now if A goes down, it will suppress B.
>> Specifically, the “device not responding” alarm on B is cleared and
>> immediately replaced with an “all device connections are unreachable” alarm.
>> The problem is that, with the original “device not responding” alarm on B
>> now cleared, there is nothing to suppress the “blade status unknown” and
>> “chassis down” alarms, which now display to the operators. Logically, the
>> alarm on A that is suppressing B should also be used to resuppress all the
>> alarms on B, but this doesn’t happen. CA has accepted this as an issue, and
>> created a patch that we’re currently testing.
>>
>> Notifier duplicating or not sending alarms. We’ve received two different
>> patches for Notifier – one was for it occasionally acting on an alarm twice
>> (about 1.5% of alarms), and the other was for it not acting on an alarm at
>> all (about 0.1% of alarms). These patches were merged together into D89a.
>>
>> These are the ones that I think will be of wide interest. When I have
>> substantial updates to share with the group, I will definitely do so.
>>
>> If you’re seeing other strange behaviors, or have any questions about these,
>> please contact me to discuss. I think that an open flow of information about
>> these sorts of issues benefits us all.
>>
>> Jim
>>
>>
>> --
>> JIM PFLEGER | Application Architect | Insight | insight.com
>>
>> t. 480.889.9680 f. 480.889.9599 [email protected]
>>
>> --To unsubscribe from spectrum, send email to [email protected] with the
>> body: unsubscribe spectrum [email protected]
>
> ---
> To unsubscribe from spectrum, send email to [email protected] with the body:
> unsubscribe spectrum [email protected]
>
---
To unsubscribe from spectrum, send email to [email protected] with the body:
unsubscribe spectrum [email protected]
