Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
The only good, if there is one, for Trango using different OID for the RSSI is that I believe you can get the slave RSSI from the master. Now, I would agree, there should be a common path to the RSSI in the 2 devices and there should be an additional path in the master to get the slave value. Scott Reed Owner NewWays Wireless Networking Network Design, Installation and Administration www.nwwnet.net -- Original Message --- From: Nigel Bruin [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Fri, 4 Nov 2005 07:47:41 + Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. I could be mis-remembering this, or confusing things (say, a tower where we replaced a 5800 with a 5830 or vice-versa), and if I'm wrong I'll cop to it. But I truly believe, with religious fervor and zeal, that Trango has changed their MIBs with different point releases of the firmware. I can't comment on Trango changing a MIB, but the MIBs have peculiarities such as different OIDs for the Master and Slave units for the same parameter. So the OID for RSSI is different for each end of the PtP link. That's just bad MIB design IMHO. -- Nigel. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ --- End of Original Message --- -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
There are 2 fundamentally different approaches for monitoring. [1] Poll parameters and strip-chart them displaying some specific duration of history. In this approach data rolls off the end of the strip-chart and is not retained. Only numerical data can be displayed graphically is appropriate for strip-charting. It's strength is that charts are updated at the moment of polling, so all charts are already made and it's easy to review many charts at a time (since there's no waiting time at the time you want to view). [2] Poll parameters and save them in a continuous log file. The strength of this approach is any kind of data can be recorded (numeric or text), and performance can be reviewed for any recorded data (you can look back in time, zoom in on any previous moment). The disadvantage of this approach is that data is graphed at the moment of viewing and therefore not as convenient for perusing multiple graphs at a time since graphing time must be waited at the time of viewing. Don't confuse long-term strip charting for an equivalent. While you can indeed make a strip-chart display data for a whole year, typically strip-charts only record the last 400 datapoints over history ... while polling every 5 minutes may provide a history of a couple days retaining all data, charts that display longer term are only retaining average data over longer and longer periods (you lose the actual data polled every 5 minutes). A good tool is one that can do both as appropriate for a given parameter. As far as SNMP, that's just an access protocol. Typically devices provide diagnostics on a web page, or in an SNMP agent. Some devices support both, some support only one. A good tool is one that can poll for data by either access protocol which will serve you best with any collection of equipment. Rich - Original Message - From: John Scrivner [EMAIL PROTECTED] To: wireless@wispa.org Sent: Thursday, November 03, 2005 11:32 AM Subject: [WISPA] Tracking Signal / Noise / Resends / Etc. I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
For StarOS we use MRTG and Starutil. You should be able to graph anything that Starutil can provide. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Scrivner Sent: 03 November 2005 17:33 To: wireless@wispa.org Subject: [WISPA] Tracking Signal / Noise / Resends / Etc. I am starting to feel the pains of trying to accurately trace problems in a network that is getting increasingly larger all the time. We have roughly 20 tower locations now. We have a pretty good picture of what we are getting for bandwidth use through our MRTG graphs. We can see when any link completely drops thanks to our What's Up monitoring. We can easily track and isolate peer to peer abuse and such with traffic analysis tools in Star OS and Mikrotik as needed. What we need though is a way to track the other parameters of our network over time. It would be invaluable to me to be able to look over historical records from a hour long window up to a year long window for link integrity information. What I mean is this. I would like to see how a signal level, noise level, number of retransmits, etc. changes over time in a graph format like MRTG does with bits in and out. It would be nice to add other parameters as needed. I know SNMP is supposed to be able to do this but I do not have the slightest bit of experience using that. Is there anyone out there who knows an easy way of getting a rudimentary level of understanding about using SNMP to extract data such as this? Maybe someone has a package they use that provides this information on your network? If any WISPs out there have any answers to this please respond on this list. If you are a vendor and your product can do specifically what I am asking for above then I am sure we would like to hear about that too. Maybe if a few of us buy your products you will consider buying a vendor membership to WISPA also.:-) Thanks guys, Scriv -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? Sure. TrangoLINK-10 integrated with Nagios and MRTG. However, I had to write a wrapper perl script around the Nagios RSSI check_command because it would report spurious error values (-99dBm) causing false alerts. The script just re-issues the SNMP query again to get the correct value. -- Nigel. -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
StarOS isn't great for SNMP but Starutil works really well for various stuff. We have been using it to graph with MRTG the signal levels for individual clients and backhaul links as well as throughput. Cheers, P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David E. Smith Sent: 03 November 2005 20:10 To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/159 - Release Date: 02/11/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
Dave, I monitor all my Trango backhauls traffic via MRTG. I downloaded their MRTG instructions and followed them. It was fairly painless. Todd Barber Skylink Broadband Internet [EMAIL PROTECTED] 970-454-9499 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David E. Smith Sent: Thursday, November 03, 2005 1:10 PM To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/160 - Release Date: 11/3/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
RE: [WISPA] Tracking Signal / Noise / Resends / Etc.
http://www.trangobroadband.com/pdfs/TrangoMRTG.pdf Todd Barber Skylink Broadband Internet [EMAIL PROTECTED] 970-454-9499 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Scrivner Sent: Thursday, November 03, 2005 3:17 PM To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. Thank you Paul. This is exactly what I was looking for in regard o customer links. If we take a service call it would be nice to see what a customer's historical data has been in regard to signal levels, bandwidth used, etc. It sounds like you hit this one right on the head. Doing the same for Trango would be sweet also. I do not know what the Trangolink-10 is that was referenced earlier as a solution to tracking details on Trango.. Can anyone elaborate on how to graph these things on Trango? I need links to actual data if you guys do not mind. Thanks guys, Scriv Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1250; format=flowed Paul Hendry wrote: StarOS isn't great for SNMP but Starutil works really well for various stuff. We have been using it to graph with MRTG the signal levels for individual clients and backhaul links as well as throughput. Cheers, P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David E. Smith Sent: 03 November 2005 20:10 To: WISPA General List Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: There are 2 fundamentally different approaches for monitoring. [ stuff ] For reference, in the network Scriv is describing, there's a nasty mixture of gear. Backhaul is primarily Trango (though that's likely to change at some point), and the customer APs are all either StarOS running on RouterBoard 200 hardware, or realy old Lucent APs with Karlnet software installed. StarOS doesn't export a lot of the data we're looking for, as far as I and my copy of snmpwalk can tell. (If I can read my boss's mind as well as I think I can, though, he's probably looking more for backhaul stats than for individual customer APs.) Trango supposedly does, but even their own forums are filled with people who can't make any sense out of Trango's provided MIBs and such. (I can usually get one-shot queries with snmpwalk and similar tools to work, but when you put the exact same parameters into an MRTG configuration file, I get back nothing but crazy bizarre errors. The fact that Trango changes their MIBs between hardware versions and occasionally even between firmware releases only compounds the problem.) At the risk of derailing (sorry, boss), has anyone gotten MRTG or something similar (PRTG, Denika, or whatever) to reliably track *anything* on a Trango? dave -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/160 - Release Date: 11/3/2005 -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
rcomroe wrote: Under no circumstances should any manufacturer CHANGE THE DEFINITION OF A PREVIOUSLY DEFINED OID. and yet... Trango's MIBs for the 5800 and 5830 are wildly different. Never mind that they're substantially the same hardware (from the point of view of how you use them in your network, at least). And don't even get me started on the fact that they don't use the same Enterprise MIBs that pretty much everyone else on the planet uses for 'interface.InOctets' and so on. Since you can only download MIBs for the current software versions, you'll have to take me at my word that they've changed them in the past (for the 5800 AP, between firmware versions 1.4 and 1.64 they were different). I could be mis-remembering this, or confusing things (say, a tower where we replaced a 5800 with a 5830 or vice-versa), and if I'm wrong I'll cop to it. But I truly believe, with religious fervor and zeal, that Trango has changed their MIBs with different point releases of the firmware. Sorry, I didn't mean for this to turn into a Trango rant. David Smith MVN.net -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
I'm of course familiar with the Motorola enterprise MIBs which they constantly add to. But here's the issue why I soapbox'ed that changing a previously defined OIDs is shameful. Take the effort to develop an snmp management function ... update some device's firmware and the management function CEASES TO WORK (only happens if the manufacturer changes previously defined objects). I can't see any excuse for this. OIDs once defined should not change. If you want to provide a new model with radically different MIBs, they must spawn from a new branch under the manufacturer's enterprise MIB. No changes permitted, no exceptions, zero tolerance. I've no knowledge that Trango did this ... I'm just providing justification for my quotation that David replied to. On another part of David's reply he comments on interface.InOctets. And don't even get me started on the fact that they don't use the same Enterprise MIBs that pretty much everyone else on the planet uses for 'interface.InOctets' and so on. The interfaces MIB is a standard part of the MIB-II set of objects (OIDs) which is not part of the manufacturer's enterprise proprietary objects. There's no problem with a device containing both (the MIB-II set and an enterprise set / I've seen several radios that contain both), but if a device includes the MIB-II set it's not in the manufacturer's authority to redefine them ... they only get to make up their own definition of their enterprise objects. Is the interface.InOctets MIB you referred to part of the standardized MIB-II or just a similarly named object of the manufacturer's proprietary enterprise MIB? Rich - Original Message - From: David E. Smith [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Thursday, November 03, 2005 5:13 PM Subject: Re: [WISPA] Tracking Signal / Noise / Resends / Etc. rcomroe wrote: Under no circumstances should any manufacturer CHANGE THE DEFINITION OF A PREVIOUSLY DEFINED OID. and yet... Trango's MIBs for the 5800 and 5830 are wildly different. Never mind that they're substantially the same hardware (from the point of view of how you use them in your network, at least). And don't even get me started on the fact that they don't use the same Enterprise MIBs that pretty much everyone else on the planet uses for 'interface.InOctets' and so on. Since you can only download MIBs for the current software versions, you'll have to take me at my word that they've changed them in the past (for the 5800 AP, between firmware versions 1.4 and 1.64 they were different). I could be mis-remembering this, or confusing things (say, a tower where we replaced a 5800 with a 5830 or vice-versa), and if I'm wrong I'll cop to it. But I truly believe, with religious fervor and zeal, that Trango has changed their MIBs with different point releases of the firmware. Sorry, I didn't mean for this to turn into a Trango rant. David Smith MVN.net -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Tracking Signal / Noise / Resends / Etc.
rcomroe wrote: On another part of David's reply he comments on interface.InOctets. And don't even get me started on the fact that they don't use the same Enterprise MIBs that pretty much everyone else on the planet uses for 'interface.InOctets' and so on. The interfaces MIB is a standard part of the MIB-II set of objects (OIDs) which is not part of the manufacturer's enterprise proprietary objects. I don't claim to be an expert on SNMP by any means. I just know that things like snmpwalk and MRTG's cfgmaker work with basically every network device I have, except Trango gear, without passing weird command-line options or going out of my way to install MIB files. If Trango wants to have their own MIBs for things like RF levels, that's their right (and since very few things are standardized, it's darn near required). But it'd be swell if they also exported standard stuff too. If I mis-spoke (mis-typed?) I apologize. Listen to what I mean, not what I say. :) David Smith MVN.net -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
