You'll want to be careful unmanaging all your interfaces. We've done something similar to you and we found out the hard way that you will not get alarms for subinterface failures if their parent interfaces are not also managed. Instead you'll get an event (no alarm) that says something along the lines of "the interface is having a problem, but no alarm will be generated because a parent interface is not managed."
This behavior is expected to change in 9.5 as a result of swbug024193, if you'd like to weigh in with CA on it. We ended up solving this in the meantime with a daemon using the Java CORBA API. The daemon listens for interfaces changing to "managed" and then manages all of their parents. HTH, Jim -- JIM PFLEGER | Application Architect | Insight | insight.com t. 480.889.9680 f. 480.889.9599 [email protected] On 7/12/11 9:00 AM, "[email protected]" <[email protected]> wrote: > I have already configured port status monitor based on "Modeling and Managing > your IT Infrastructure Administration guide CHAPTER 7 - Configuring port > status monitoring" on page 210 to 217. Based on this, apart from port polling > you need to be aware on traps from device ports. > > Try this: > 1. Disable port polling on ports > 2. Disable alarm on link down traps on all ports (Alarmonlinkdowniftypes, help > to define default value based on port type) > 3. Enable live links on selected links (this enable ok_to_poll attribute on > related ports) > 4. With policy manager or based on search criteria (ok_to_pool = yes) enable > port polling and alarm_on_link_down_trap on related ports. > > Regards, > John Vásquez V. > > > -----Original Message----- > From: Diego Pereyra [mailto:[email protected]] > Sent: lunes, 11 de julio de 2011 13:38 > To: spectrum > Cc: spectrum; Rajasekhar_Allala > Subject: Re: [spectrum] Silence Ports - Email found in subject > > Hi Ken > > Normaly i put into maintenance, but that dont stop the monitoring, just > the alarms. Anyway... to reconfigure the reduce the monitoring thought > the Policy Manager > > enter here http://www.dachsug.ch/wiki/index.php/PolicyManager and read > about "How to reduce Bad Link Error with the Policy Manager" > > Hope that help to! > > Diego Pereyra > Netsol International > > On 07/08/2011 12:50 AM, Kenneth Kirchner 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] > > --- > 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]
