Matt, What you might want to do is make a probe that monitors a single port on a single device. The probe file would take one parameter: ifIndex of port.
Then the same probe file could be used for any port. Now, to monitor eight ports of a switch, you'd create eight devices, all with the same switch IP address and different ifIndexes. To add eight more ports, add eight more devices to the map. Now, admittedly, I'm using an unlimited device license so I don't care how many devices I have on a map. You might care :) Another option would be a command-line probe, but as I have no experience with them I can't really give any hints on how to set one up to poll a list of ports. Hope this helps, Doug -- Doug Weathers Information Technology Network Administrator Cascade Healthcare Community 2500 NE Neff Road Bend, OR 97701 http://www.scmc.org mailto:[EMAIL PROTECTED] Desk: 541-383-6846 Cell: 541-480-0919 >>> [EMAIL PROTECTED] 4/14/2005 11:05:30 AM >>> Sorry for the delay in replying. How exactly could you write a probe currently to monitor multiple interfaces? I understand that I can write a probe that lets me specify ifIndexes by hand, and have multiple ifIndexes specified in the probe. But this doesn't work very well if I have a device with a lot of ports. And, if I have a device with 8 ports - which I make a probe that lets me specify 8 ifIndexes for - what happens when I add another 8 ports to the device? I have to rewrite the probe? Or am I misunderstanding? On the RFC1406 stuff (CSU/DSU monitoring) I've already replied to Jon privately about what would be nice. I can send a copy to the list if others would like to comment. -- matt Ian Struckhoff wrote: > Matt, > > You should be able to write custom probes now that will monitor > multiple specified interfaces. The probes that are out there now > monitoring a single interface specified by a parameter could be expanded > to monitor multiple interfaces. The only caveat is that each variable > defined in the probe needs to have a unique name, not just a unique > definition. > > We are also currently considering a feature that might address what > you are asking for even better. Currently, custom probes can't handle > showing an entire SNMP table, because we can't know the length. It > sounds like a capability to do something like that would provide the > kind of custom probes you are asking for. > > I am going to file your email in our system as an ER (enhancement > request). I am also going to link it to a central ticket tracking > interest in a tables system for custom probes. > > Regarding your last request, could you go into a little bit more > detail, to make sure we understand what you need? You can reply to the > list, to me personally, or send it in to [EMAIL PROTECTED] directly. > > Thanks, > Ian Struckhoff > Tech Support > Dartware, LLC > > On Mar 16, 2005, at 5:00 PM, Matt Stevens wrote: > >> I'd like to be able to write custom SNMP probes that will monitor >> things on a per-interface basis. >> >> Right now the only way to do this is to hard-code the ifIndex into the >> probe. Plus, you need to add a device for each interface you want to >> monitor the "extra" variables on. This is fine for one or two things, >> but gets out of hand quickly when you're monitoring a lot of interfaces. >> >> I'd like to propose that there be some sort of interface plug-in probe >> architecture. Basically a subset of the normal probe files that are >> applied to every interface on a device. Something along the lines of >> display SNMP variable X for every ifIndex. >> >> These could be enabled/disabled per device and/or interface. Each >> plug-in would append it's output to the end of the previous one, so >> you'd end up with a larger interface information window. Or you could >> possibly have each plug-in display its output on an individual tab. >> >> Along the same lines, I'd like to see support for the RFC1406 MIB - so >> I can get more information about my devices with integrated CSU/DSU's. >> >> Thoughts? >> -- >> matt >> >> >> >> >> ____________________________________________________________________ >> List archives: >> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >> To unsubscribe: send email to: [EMAIL PROTECTED] > > > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [EMAIL PROTECTED] ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED] ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED]
