nv-l

Re: [NV-L] Advice on Monitoring Wireless Access Points

2006-09-28 03:47:07
Subject: Re: [NV-L] Advice on Monitoring Wireless Access Points
From: Denis Peuziat <dpeuziat AT amadeus DOT com>
To: Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>
Date: Thu, 28 Sep 2006 09:43:28 +0200

Hi,

You can use a MLM to filter the events before they reach your Netview and you can also easily use the MLM to define snmp collection rules and to trigger traps when the threshold you have defined are breached. MLM was the answer for me to a couple of tricky situations, especially to filter traps coming from source where you can't control them.
Check the MLM user guide, it will give you more insight on what you can do with MLM

Hope that helps

Regards,
Denis PEUZIAT
Enterprise Systems Management Engineer
DEV-IIS-OAU-NET
dpeuziat AT amadeus DOT com
phone: +33 4 97 15 46 92
fax: +33 4 97 23 04 79




Sue Young <syoung AT westpac.com DOT au>
To
Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>
cc
bcc
Subject
[NV-L] Advice on Monitoring Wireless Access Points


Sue Young <syoung AT westpac.com DOT au>  

Please respond to Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>

Sent by: nv-l-bounces AT lists.ca.ibm DOT com  
28/09/2006 03:39





Dear List,


Looking for advice on how others are managing these devices on Netview. We've recently installed 500 Cisco Aironet 1231 Access Points and have run into a few problems. Traps are being sent to a WLSE which in turn forwards traps to Netview. We receive 10 traps per second just to let us know an AP is running OK. If there's a problem, eg. snmp unreachable, we receive 120 traps per sec. (not good). These traps are taking up over 70% of the trapd.log (also not good).


>From reading the archives, it appears the WLSE modifies the trap before sending to Netview and a fair bit of work is required to parse these traps into a more meaningful trap to alert the Operators. We're also receiving all AP traps from the WLSE but we really only want to see link up/down and also problems on the radio side of the link. Not sure if the WLSE can be configured to only send these specific traps to Netview (another area looks after the WLSE).


Another option is for the APs to send traps directly to Netview but again we would get flooded with traps we don't want to see. I guess they could be filtered from appearing in the trapd.log but this may mask performance issues caused by the high volume of traps.


Also on the archives, there was mention of collecting SNMP data from the AP mibs (and using snmpColDump) for monitoring the radio side of the APs. Is this the only way (or the best way) to monitor if a radio goes down? This option sounds interesting but would require a fair bit of work in managing and processing the collected data. This would require the APS to be on the Netview maps (they aren't at present since they are DHCP - the ip addresses are only static for as long as the AP is active) so we'd have some ongoing management issues unless we convince the designers to change them to static ip addresses.


If we turn off receiving any traps from the WLSE we can still monitor link up/down on the APS as the switch they are connected to sends trps when a port goes down. However, we'd also like to see when a radio goes down.


How is everyone else handling this? Thanks in advance for any advice..


By the way, we're running 7.1.3 FP3 on unix.


Best Regards,

Sue Young


 





Please consider our environment before printing this email.

WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately.

It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments.

This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision.

Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency.

Westpac Banking Corporation ABN 33 007 457 141.
_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only)

_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)
<Prev in Thread] Current Thread [Next in Thread>