Lalit-

As an MSP we only manage a tiny fraction of the total number of interfaces
on our customers' devices. We found when we started with Spectrum 9.0 that
setting a port into maintenance was not sufficient to prevent a lot of
events from being generated for traps. As I recall, the interfaces were
still being polled as well; the maintenance flag just prevented alarms from
being generated. We set all these additional flags to reduce the number of
events, and more generally the workload, in our SpectroServers.

It may be that, since we're now on 9.2, we no longer need to fiddle with all
these additional settings. However, what we have is still working so we
haven't looked into changing it.

HTH,
Jim



On 7/8/11 8:48 AM, "Lalit Tyagi" <[email protected]> wrote:

> Jim,
> 
> I am not sure why you have these policy setting for any interface which is in
> maintenance mode. Can you please explain it as I understand that if any device
> or interface is in maintenance mode then spectrum stop polling for that model,
> ignored any trap coming for it and not registered any event\alarm for it?
> 
> Our Networking team has prepend {{Y}} tag on interface alias (interface
> description) for those interface which they want alarm. We have following
> policy in spectrum which run on those interfaces which does not have the tag
> on it. 
> 
>     <policy-settings name="XX Disabled Port Monitoring">
>         <set-attr-value id="0x1280a" value="FALSE" />
>         <set-attr-value id="0x11dd8" value="FALSE" />
>         <set-attr-value id="0x11fc2" value="0" />
>         <set-attr-value id="0x12957" value="FALSE" />
>         <set-attr-value id="0x12a54" value="FALSE" />
>     </policy-settings>
>    
> 
> And ,we do have another opposite policy which looks for the tag to enable
> these settings. These polices work for us and we are not getting any alarm on
> any unwanted interface.
> 
> Thanks
> Lalit Tyagi
> 
> 
> -----Original Message-----
> From: Pfleger, Jim [mailto:[email protected]]
> Sent: Friday, July 08, 2011 10:55 AM
> To: spectrum
> Subject: Re: [spectrum] Silence Ports
> 
> Ken-
> 
> We ran into a similar problem trying to disable all possible events/alarms
> on unmanaged interfaces. We have a handful of attributes that we set by
> policy if an interface is in maintenance. This way users can set just one
> flag, which they already have access to, and everything else gets set
> appropriately.
> 
> DisableTrapEvents                   0x11cd0 = TRUE
> ok_to_poll                          0x11dd8 = FALSE
> PollPortStatus                      0x1280a = FALSE
> AlarmOnLinkDownTrap                 0x11fc2 = 0
> AssertLinkDownAlarm (on device)     0x12957 = FALSE
> GeneratePortStatusAlarms (on port)  0x12a54 = FALSE
> 
> We then have a second set of settings, which is just the opposite for when
> the interface is not in maintenance.
> 
> Jim
> 
> 
> 
> On 7/7/11 8:50 PM, "Kenneth Kirchner" <[email protected]> wrote:
> 
>> I finally got around to trying this.  It does not seem to have any effect.
>> Alarms continue to generate for these switch ports with polling=no and
>> poll_port_status=no. Actually, I checked a few of the other ports on the
>> switch and the poll port status attribute looks like it is no by default.
>> What is the purpose of the polling toggle? It certainly does not seem
>> intuitive.  I could understand if polling was set to no, but a trap still
>> caused an alarm (maybe "Disable trap-based events" would stop that!
>> Naaaaaaah!
>> Thats crazy talk!).  That does not appear to be the case here.  Spectrum is
>> polling the device, seeing the port down, ignoring the poll status, and
>> generating an alarm ("BAD LINK DETECTED"). I can't find anything in my 59
>> Spectrum documents that says what the "Generate Alarm on Port" and "Generate
>> Alarm on Device" do.
>> 
>> I have hyper-extended my middle finger in the direction of my Spectrum
>> server.
>> 
>> -Ken
>> 
>> On Jun 19, 2011, at 11:03 PM, Rajasekhar_Allala wrote:
>> 
>>> Hi Ken,
>>> 
>>> Set polling status as well as poll port status (port) values to No.
>>> 
>>> I hope, it helps.
>>> 
>>> Regards
>>> Rajashekar
>>> 
>>> 
>>> -----Original Message-----
>>> From: Kenneth Kirchner [mailto:[email protected]]
>>> Sent: Monday, June 20, 2011 11:22 AM
>>> To: spectrum
>>> Subject: [spectrum] Silence Ports
>>> 
>>> What is the best way to silence a port on a switch or router that you never
>>> want to hear from again? Is it as simple as disabling polling? Will that
>>> prevent traps on that interface from generating alarms as well?  We have a
>>> few ports with devices that we have no control over and no responsibility to
>>> monitor, so we want to remove that noise from our monitoring.  We are
>>> currently stuffing these in maintenance mode, but that does not appear
>>> optimal.
>>> 
>>> -Ken
>>> Spectrum 9.2 H03
>>> 
>>> 
>>> ---
>>> To unsubscribe from spectrum, send email to [email protected] with the body:
>>> unsubscribe spectrum [email protected]
>>> 
>>> 
>>> ________________________________
>>> 
>>> DISCLAIMER:
>>> This email (including any attachments) is intended for the sole use of the
>>> intended recipient/s and may contain material that is CONFIDENTIAL AND
>>> PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
>>> distribution or forwarding of any or all of the contents in this message is
>>> STRICTLY PROHIBITED. If you are not the intended recipient, please contact
>>> the sender by email and delete all copies; your cooperation in this regard
>>> is
>>> appreciated.
>>> 
>>> ---
>>> 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]
> 
> ----------------------------------------
> 
> This message is intended exclusively for the individual(s) or entity to
> which it is addressed. It may contain information that is proprietary,
> privileged or confidential or otherwise legally exempt from disclosure.
> If you are not the named addressee, you are not authorized to read,
> print, retain, copy or disseminate this message or any part of it.
> If you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
> 


---
To unsubscribe from spectrum, send email to [email protected] with the body: 
unsubscribe spectrum [email protected]

Reply via email to