Ali, I am not sure about your OS and spectrum hotfix but I do have spectrum 9.2 H3 on windows 2003 which does not poll devices as well as interface in maintenance mode.
Logically, spectrum should not do anything if model is in a maintenance mode; Spectrum check the status of model only when you take it out from maintenance mode. You can simply find out communication with any device in maintenance mode by running wireshark on your spectrum. You do not need CA tech to confirm this ;) -----Original Message----- From: Aliabbas Syed [mailto:[email protected]] Sent: Friday, July 08, 2011 5:05 PM To: Lalit Tyagi; spectrum Subject: RE: [spectrum] Silence Ports I am not sure about Interfaces but Devices in maintenance mode are still polled. I've this info from CA tech when I went 9.2. I keep all decommissioned devices for 1 year in a container and list was quite large. Due to performance issues, CA tech had me get rid of all and explanation given was that Spectrum still check for status a device in maintenance to see if status has changed or not and can be factor in performance issues. Thanks / Cheers, Ali -----Original Message----- From: Lalit Tyagi [mailto:[email protected]] Sent: Friday, July 08, 2011 12:40 PM To: spectrum Subject: RE: [spectrum] Silence Ports Thanks for the explanation. I do not know about 9.0 but on 9.2 spectrum does not poll any model or interface if it is in maintenance mode. --Lalit Tyagi -----Original Message----- From: Pfleger, Jim [mailto:[email protected]] Sent: Friday, July 08, 2011 12:03 PM To: spectrum Subject: Re: [spectrum] Silence Ports 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] ---------------------------------------- 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] NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected. ---------------------------------------- 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]
