SNMP Trapping Question - What is Best Tool for the Job?
list Wiskbroom
Hello; I've gotten devmon to work on my current Xymon setup; the only drawback in my opinion is lack of device support in devmon. I'd like to roll-out something else that would allow me to receive SNMP traps from a device, and send out alerts via Xymon. I'd also like to be able to use WeatherMap, and of course want to make the three of these work together as seamlessly as possible. Thank you all in advance, .vp
list Buchan Milne
▸
On Monday, 21 June 2010 13:55:53 user-ddebaeecde97@xymon.invalid wrote:
Hello; I've gotten devmon to work on my current Xymon setup; the only drawback in my opinion is lack of device support in devmon.
Templates are created for devices people have access to, who are willing to do some work to create a template. I try and add all templates that are submitted. Even if devmon had MIB support, templates would still be required to a degree. Feel free to assist in improving devmon.
▸
I'd like to roll-out something else that would allow me to receive SNMP traps from a device, and send out alerts via Xymon.
I need to implement some trap support. The snmptrapd->snmptt->sec->xymon method (at http://cerebro.victoriacollege.edu/hobbit-trap.html) is a bit heavy for my current environment. I have been wondering if a dedicated perl script using NetSNMP::TrapReceiver (IOW, running inside snmptrapd) reporting directly to Xymon would be better. However, the question is, exactly how should it behave? How should traps be mapped to tests (all traps to a single 'trap' test, or to individual tests, and how)? Should traps be stored to a database as well (so they can be ACK'ed etc.)?
▸
I'd also like to be able to use WeatherMap, and of course want to make the three of these work together as seamlessly as possible.
While I would like to improve Weathermap (to require less manual work in creating map configurations), it works well enough for me http://staff.telkomsa.net/~bgmilne/xymon/ Have you run into problems with it? Regards, Buchan
list Josh Luthman
What do you mean device support, predone copy and paste templates? I find the templates to be of the creator's best use and I do my own. Note that I don't use devmon or Xymon for SNMP.
▸
On 6/21/10, Buchan Milne <user-9b139aff4dec@xymon.invalid> wrote:On Monday, 21 June 2010 13:55:53 user-ddebaeecde97@xymon.invalid wrote:Hello; I've gotten devmon to work on my current Xymon setup; the only drawback in my opinion is lack of device support in devmon.Templates are created for devices people have access to, who are willing to do some work to create a template. I try and add all templates that are submitted. Even if devmon had MIB support, templates would still be required to a degree. Feel free to assist in improving devmon.I'd like to roll-out something else that would allow me to receive SNMP traps from a device, and send out alerts via Xymon.I need to implement some trap support. The snmptrapd->snmptt->sec->xymon method (at http://cerebro.victoriacollege.edu/hobbit-trap.html) is a bit heavy for my current environment. I have been wondering if a dedicated perl script using NetSNMP::TrapReceiver (IOW, running inside snmptrapd) reporting directly to Xymon would be better. However, the question is, exactly how should it behave? How should traps be mapped to tests (all traps to a single 'trap' test, or to individual tests, and how)? Should traps be stored to a database as well (so they can be ACK'ed etc.)?I'd also like to be able to use WeatherMap, and of course want to make the three of these work together as seamlessly as possible.While I would like to improve Weathermap (to require less manual work in creating map configurations), it works well enough for me http://staff.telkomsa.net/~bgmilne/xymon/ Have you run into problems with it? Regards, Buchan
--
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX
“Success is not final, failure is not fatal: it is the courage to
continue that counts.”
--- Winston Churchill
list Wiskbroom
▸
On Monday, 21 June 2010 13:55:53 user-ddebaeecde97@xymon.invalid wrote:Hello; I've gotten devmon to work on my current Xymon setup; the only drawback in my opinion is lack of device support in devmon.Templates are created for devices people have access to, who are willing to do some work to create a template. I try and add all templates that are submitted. Even if devmon had MIB support, templates would still be required to a degree. Feel free to assist in improving devmon.
I will try, but have found the task of creating MIBs a daunting one. Yes, I want to use someone elses MIB's for my devices.
▸
I'd like to roll-out something else that would allow me to receive SNMP traps from a device, and send out alerts via Xymon.I need to implement some trap support. The snmptrapd->snmptt->sec->xymon method (at http://cerebro.victoriacollege.edu/hobbit-trap.html) is a bit heavy for my current environment. I have been wondering if a dedicated perl script using NetSNMP::TrapReceiver (IOW, running inside snmptrapd) reporting directly to Xymon would be better. However, the question is, exactly how should it behave? How should traps be mapped to tests (all traps to a single 'trap' test, or to individual tests, and how)? Should traps be stored to a database as well (so they can be ACK'ed etc.)?
I wish I could help here, and agree that the "snmptrapd->snmptt->sec->xymon" is a bit conplicated, especially with SEC, but probably the most powerful design I've seen yet. The problem I see here is the ability to create SEC rules for alerting and properly testing them.
▸
I'd also like to be able to use WeatherMap, and of course want to make the three of these work together as seamlessly as possible.While I would like to improve Weathermap (to require less manual work in creating map configurations), it works well enough for me http://staff.telkomsa.net/~bgmilne/xymon/ Have you run into problems with it?
I love the weathermap feature (thank you) and is why I want to keep it. The only issue I have with the present weathermap feature for xymon/devmon is that the weathermap GUI-editor is not implemented.
list Buchan Milne
▸
On Monday, 21 June 2010 16:54:10 user-ddebaeecde97@xymon.invalid wrote:
On Monday, 21 June 2010 13:55:53 user-ddebaeecde97@xymon.invalid wrote:Hello; I've gotten devmon to work on my current Xymon setup; the only drawback in my opinion is lack of device support in devmon.Templates are created for devices people have access to, who are willing to do some work to create a template. I try and add all templates that are submitted. Even if devmon had MIB support, templates would still be required to a degree. Feel free to assist in improving devmon.I will try, but have found the task of creating MIBs a daunting one. Yes, I want to use someone elses MIB's for my devices.
You shouldn't need to create MIBs, they shouldbe provided by the device vendor. However, while the MIBs contain a lot of information, they don't tell you what data to present to the user ... so even with MIB support, there would still be a bit of work (e.g., the message file would have to stay). I would like to look at removing the need for the 'oids' file though (by MIB support).
▸
I'd like to roll-out something else that would allow me to receive SNMP traps from a device, and send out alerts via Xymon.I need to implement some trap support. The snmptrapd->snmptt->sec->xymon method (at http://cerebro.victoriacollege.edu/hobbit-trap.html) is a bit heavy for my current environment. I have been wondering if a dedicated perl script using NetSNMP::TrapReceiver (IOW, running inside snmptrapd) reporting directly to Xymon would be better. However, the question is, exactly how should it behave? How should traps be mapped to tests (all traps to a single 'trap' test, or to individual tests, and how)? Should traps be stored to a database as well (so they can be ACK'ed etc.)?I wish I could help here, and agree that the "snmptrapd->snmptt->sec->xymon" is a bit conplicated, especially with SEC, but probably the most powerful design I've seen yet. The problem I see here is the ability to create SEC rules for alerting and properly testing them.
Ideally, alerting should be handled the same as for other xymon events.
▸
I'd also like to be able to use WeatherMap, and of course want to make the three of these work together as seamlessly as possible.While I would like to improve Weathermap (to require less manual work in creating map configurations), it works well enough for me http://staff.telkomsa.net/~bgmilne/xymon/ Have you run into problems with it?I love the weathermap feature (thank you) and is why I want to keep it. The only issue I have with the present weathermap feature for xymon/devmon is that the weathermap GUI-editor is not implemented.
Do your network devices have CDP support? I have a cdp test that works on a number of devices here, and I may consider pulling that info in to the weathermap script, so you don't have to manually create connections between devices ... Regards, Buchan
list Buchan Milne
On Monday, 21 June 2010 16:18:57 Josh Luthman wrote:
What do you mean device support, predone copy and paste templates?
Devmon uses "templates" to define what data (OIDs) to poll, any transformation required on the data, what the thresholds should be, and how to format the data returned to Xymon.
▸
I find the templates to be of the creator's best use and I do my own. Note that I don't use devmon or Xymon for SNMP.
Regards,
Buchan
list Wiskbroom
▸
On Monday, 21 June 2010 16:18:57 Josh Luthman wrote:What do you mean device support, predone copy and paste templates?Devmon uses "templates" to define what data (OIDs) to poll, any transformation required on the data, what the thresholds should be, and how to format the data returned to Xymon.
I guess the ability to easily transform an existing MIB into a devmon template would be a great start. Perhaps this exists already? If so, then I've overlooked that and I apologize.
▸
I find the templates to be of the creator's best use and I do my own. Note that I don't use devmon or Xymon for SNMP.
Thus far everything I've seen in Devmon and weathermap has been top shelf. Again, I only wish I were able to use the weathermap GUI editor :-) .vp
list Wiskbroom
▸
On Monday, 21 June 2010 16:54:10 user-ddebaeecde97@xymon.invalid wrote:On Monday, 21 June 2010 13:55:53 user-ddebaeecde97@xymon.invalid wrote:Hello; I've gotten devmon to work on my current Xymon setup; the only drawback in my opinion is lack of device support in devmon.Templates are created for devices people have access to, who are willing to do some work to create a template. I try and add all templates that are submitted. Even if devmon had MIB support, templates would still be required to a degree. Feel free to assist in improving devmon.I will try, but have found the task of creating MIBs a daunting one. Yes, I want to use someone elses MIB's for my devices.You shouldn't need to create MIBs, they shouldbe provided by the device vendor. However, while the MIBs contain a lot of information, they don't tell you what data to present to the user ... so even with MIB support, there would still be a bit of work (e.g., the message file would have to stay). I would like to look at removing the need for the 'oids' file though (by MIB support).
Any suggestions how I might be able to easily transform a MIB into a devmon template?
▸
I'd like to roll-out something else that would allow me to receive SNMP traps from a device, and send out alerts via Xymon.I need to implement some trap support. The snmptrapd->snmptt->sec->xymon method (at http://cerebro.victoriacollege.edu/hobbit-trap.html) is a bit heavy for my current environment. I have been wondering if a dedicated perl script using NetSNMP::TrapReceiver (IOW, running inside snmptrapd) reporting directly to Xymon would be better. However, the question is, exactly how should it behave? How should traps be mapped to tests (all traps to a single 'trap' test, or to individual tests, and how)? Should traps be stored to a database as well (so they can be ACK'ed etc.)?I wish I could help here, and agree that the "snmptrapd->snmptt->sec->xymon" is a bit conplicated, especially with SEC, but probably the most powerful design I've seen yet. The problem I see here is the ability to create SEC rules for alerting and properly testing them.Ideally, alerting should be handled the same as for other xymon events.
Perhaps a SEC/REGEX editor? I don't know of any, but I am sure they exists in php-format somewhere.
▸
I'd also like to be able to use WeatherMap, and of course want to make the three of these work together as seamlessly as possible.While I would like to improve Weathermap (to require less manual work in creating map configurations), it works well enough for me http://staff.telkomsa.net/~bgmilne/xymon/ Have you run into problems with it?I love the weathermap feature (thank you) and is why I want to keep it. The only issue I have with the present weathermap feature for xymon/devmon is that the weathermap GUI-editor is not implemented.Do your network devices have CDP support? I have a cdp test that works on a number of devices here, and I may consider pulling that info in to the weathermap script, so you don't have to manually create connections between devices ...
Yes, my devices have CDP enabled, at least those not on a "insecure" network. Is CDP info attainable via SNMP? Or would your work require using ssh with expect, or similar? .vp
list David Baldwin
▸
user-ddebaeecde97@xymon.invalid wrote:
On Monday, 21 June 2010 16:18:57 Josh Luthman wrote:What do you mean device support, predone copy and paste templates?Devmon uses "templates" to define what data (OIDs) to poll, any transformation required on the data, what the thresholds should be, and how to format the data returned to Xymon.I guess the ability to easily transform an existing MIB into a devmon template would be a great start. Perhaps this exists already? If so, then I've overlooked that and I apologize.
I wrote a perl script "templatebuilder.pl" to generate skeleton files for oids, transforms and thresholds files for a template. You need to create the messages file yourself. exceptions is usually empty. You can get it from the repository if it's not in the devmon/extras directory already: http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/ Here's the README: To run: ./templatebuilder.pl [snmpargs...] <host> <oid> e.g. ./templatebuilder.pl -cpublic -v2c localhost enterprises * runs snmpwalk over the MIB tree (needs MIB files installed) * translates symbolic and numeric correspondences * displays values found from host MIB agent * generates barebones of oids, transforms and thresholds. A work in progress... $ ./templatebuilder.pl localhost ifTable snmpwalk -OE localhost ifTable ifIndex : .1.3.6.1.2.1.2.2.1.1 : branch RFC1213-MIB::ifIndex.1 (.1.3.6.1.2.1.2.2.1.1.1) = INTEGER: 1 RFC1213-MIB::ifIndex.2 (.1.3.6.1.2.1.2.2.1.1.2) = INTEGER: 2 RFC1213-MIB::ifIndex.3 (.1.3.6.1.2.1.2.2.1.1.3) = INTEGER: 3 RFC1213-MIB::ifIndex.4 (.1.3.6.1.2.1.2.2.1.1.4) = INTEGER: 4 ifDescr : .1.3.6.1.2.1.2.2.1.2 : branch RFC1213-MIB::ifDescr.1 (.1.3.6.1.2.1.2.2.1.2.1) = STRING: "lo" RFC1213-MIB::ifDescr.2 (.1.3.6.1.2.1.2.2.1.2.2) = STRING: "eth0" RFC1213-MIB::ifDescr.3 (.1.3.6.1.2.1.2.2.1.2.3) = STRING: "eth1" RFC1213-MIB::ifDescr.4 (.1.3.6.1.2.1.2.2.1.2.4) = STRING: "sit0" ifType : .1.3.6.1.2.1.2.2.1.3 : branch ## Values: other(1), regular1822(2), hdh1822(3), ddn-x25(4), rfc877-x25(5), ethernet-csmacd(6), iso88023-csmacd(7), iso88024-tokenBus(8), iso88025-tokenRing(9), iso88026-ma n(10), starLan(11), proteon-10Mbit(12), proteon-80Mbit(13), hyperchannel(14), fddi(15), lapb(16), sdlc(17), ds1(18), e1(19), basicISDN(20), primaryISDN(21), propPointToPoint Serial(22), ppp(23), softwareLoopback(24), eon(25), ethernet-3Mbit(26), nsip(27), slip(28), ultra(29), ds3(30), sip(31), frame-relay(32) ifTypeTxt : SWITCH : {ifType} 1=other,2=regular1822,3=hdh1822,4=ddn-x25,5=rfc877-x25,6=ethernet-csmacd,7=iso88023-csmacd,8=iso88024-tokenBus,9=iso88025-tokenRin g,10=iso88026-man,11=starLan,12=proteon-10Mbit,13=proteon-80Mbit,14=hyperchannel,15=fddi,16=lapb,17=sdlc,18=ds1,19=e1,20=basicISDN,21=primaryISDN,22=propPointToPointSerial,2 3=ppp,24=softwareLoopback,25=eon,26=ethernet-3Mbit,27=nsip,28=slip,29=ultra,30=ds3,31=sip,32=frame-relay RFC1213-MIB::ifType.1 (.1.3.6.1.2.1.2.2.1.3.1) = INTEGER: softwareLoopback(24) RFC1213-MIB::ifType.2 (.1.3.6.1.2.1.2.2.1.3.2) = INTEGER: ethernet-csmacd(6) RFC1213-MIB::ifType.3 (.1.3.6.1.2.1.2.2.1.3.3) = INTEGER: ethernet-csmacd(6) RFC1213-MIB::ifType.4 (.1.3.6.1.2.1.2.2.1.3.4) = INTEGER: 131 ifMtu : .1.3.6.1.2.1.2.2.1.4 : branch RFC1213-MIB::ifMtu.1 (.1.3.6.1.2.1.2.2.1.4.1) = INTEGER: 16436 RFC1213-MIB::ifMtu.2 (.1.3.6.1.2.1.2.2.1.4.2) = INTEGER: 1500 RFC1213-MIB::ifMtu.3 (.1.3.6.1.2.1.2.2.1.4.3) = INTEGER: 1500 RFC1213-MIB::ifMtu.4 (.1.3.6.1.2.1.2.2.1.4.4) = INTEGER: 1480 ifSpeed : .1.3.6.1.2.1.2.2.1.5 : branch RFC1213-MIB::ifSpeed.1 (.1.3.6.1.2.1.2.2.1.5.1) = Gauge32: 10000000 RFC1213-MIB::ifSpeed.2 (.1.3.6.1.2.1.2.2.1.5.2) = Gauge32: 1000000000 RFC1213-MIB::ifSpeed.3 (.1.3.6.1.2.1.2.2.1.5.3) = Gauge32: 0 RFC1213-MIB::ifSpeed.4 (.1.3.6.1.2.1.2.2.1.5.4) = Gauge32: 0 ifPhysAddress : .1.3.6.1.2.1.2.2.1.6 : branch RFC1213-MIB::ifPhysAddress.1 (.1.3.6.1.2.1.2.2.1.6.1) = "" RFC1213-MIB::ifPhysAddress.2 (.1.3.6.1.2.1.2.2.1.6.2) = Hex-STRING: 00 16 35 5B 89 60 RFC1213-MIB::ifPhysAddress.3 (.1.3.6.1.2.1.2.2.1.6.3) = Hex-STRING: 00 16 35 5B 89 5F RFC1213-MIB::ifPhysAddress.4 (.1.3.6.1.2.1.2.2.1.6.4) = Hex-STRING: 00 00 00 00 89 5F ifAdminStatus : .1.3.6.1.2.1.2.2.1.7 : branch ## Values: up(1), down(2), testing(3) ifAdminStatusTxt : SWITCH : {ifAdminStatus} 1=up,2=down,3=testing RFC1213-MIB::ifAdminStatus.1 (.1.3.6.1.2.1.2.2.1.7.1) = INTEGER: up(1) RFC1213-MIB::ifAdminStatus.2 (.1.3.6.1.2.1.2.2.1.7.2) = INTEGER: up(1) RFC1213-MIB::ifAdminStatus.3 (.1.3.6.1.2.1.2.2.1.7.3) = INTEGER: down(2) RFC1213-MIB::ifAdminStatus.4 (.1.3.6.1.2.1.2.2.1.7.4) = INTEGER: down(2) ifOperStatus : .1.3.6.1.2.1.2.2.1.8 : branch ## Values: up(1), down(2), testing(3) ifOperStatusTxt : SWITCH : {ifOperStatus} 1=up,2=down,3=testing RFC1213-MIB::ifOperStatus.1 (.1.3.6.1.2.1.2.2.1.8.1) = INTEGER: up(1) RFC1213-MIB::ifOperStatus.2 (.1.3.6.1.2.1.2.2.1.8.2) = INTEGER: up(1) RFC1213-MIB::ifOperStatus.3 (.1.3.6.1.2.1.2.2.1.8.3) = INTEGER: down(2) RFC1213-MIB::ifOperStatus.4 (.1.3.6.1.2.1.2.2.1.8.4) = INTEGER: down(2) ifInOctets : .1.3.6.1.2.1.2.2.1.10 : branch RFC1213-MIB::ifInOctets.1 (.1.3.6.1.2.1.2.2.1.10.1) = Counter32: 1747840320 RFC1213-MIB::ifInOctets.2 (.1.3.6.1.2.1.2.2.1.10.2) = Counter32: 1897765870 RFC1213-MIB::ifInOctets.3 (.1.3.6.1.2.1.2.2.1.10.3) = Counter32: 0 RFC1213-MIB::ifInOctets.4 (.1.3.6.1.2.1.2.2.1.10.4) = Counter32: 0 ifInUcastPkts : .1.3.6.1.2.1.2.2.1.11 : branch RFC1213-MIB::ifInUcastPkts.1 (.1.3.6.1.2.1.2.2.1.11.1) = Counter32: 369931020 RFC1213-MIB::ifInUcastPkts.2 (.1.3.6.1.2.1.2.2.1.11.2) = Counter32: 3742681648 RFC1213-MIB::ifInUcastPkts.3 (.1.3.6.1.2.1.2.2.1.11.3) = Counter32: 0 RFC1213-MIB::ifInUcastPkts.4 (.1.3.6.1.2.1.2.2.1.11.4) = Counter32: 0 ifInDiscards : .1.3.6.1.2.1.2.2.1.13 : branch RFC1213-MIB::ifInDiscards.1 (.1.3.6.1.2.1.2.2.1.13.1) = Counter32: 0 RFC1213-MIB::ifInDiscards.2 (.1.3.6.1.2.1.2.2.1.13.2) = Counter32: 498 RFC1213-MIB::ifInDiscards.3 (.1.3.6.1.2.1.2.2.1.13.3) = Counter32: 0 RFC1213-MIB::ifInDiscards.4 (.1.3.6.1.2.1.2.2.1.13.4) = Counter32: 0 ifInErrors : .1.3.6.1.2.1.2.2.1.14 : branch RFC1213-MIB::ifInErrors.1 (.1.3.6.1.2.1.2.2.1.14.1) = Counter32: 0 RFC1213-MIB::ifInErrors.2 (.1.3.6.1.2.1.2.2.1.14.2) = Counter32: 0 RFC1213-MIB::ifInErrors.3 (.1.3.6.1.2.1.2.2.1.14.3) = Counter32: 0 RFC1213-MIB::ifInErrors.4 (.1.3.6.1.2.1.2.2.1.14.4) = Counter32: 0 ifOutOctets : .1.3.6.1.2.1.2.2.1.16 : branch RFC1213-MIB::ifOutOctets.1 (.1.3.6.1.2.1.2.2.1.16.1) = Counter32: 1747842686 RFC1213-MIB::ifOutOctets.2 (.1.3.6.1.2.1.2.2.1.16.2) = Counter32: 538554096 RFC1213-MIB::ifOutOctets.3 (.1.3.6.1.2.1.2.2.1.16.3) = Counter32: 0 RFC1213-MIB::ifOutOctets.4 (.1.3.6.1.2.1.2.2.1.16.4) = Counter32: 0 ifOutUcastPkts : .1.3.6.1.2.1.2.2.1.17 : branch RFC1213-MIB::ifOutUcastPkts.1 (.1.3.6.1.2.1.2.2.1.17.1) = Counter32: 369931052 RFC1213-MIB::ifOutUcastPkts.2 (.1.3.6.1.2.1.2.2.1.17.2) = Counter32: 2398891222 RFC1213-MIB::ifOutUcastPkts.3 (.1.3.6.1.2.1.2.2.1.17.3) = Counter32: 0 RFC1213-MIB::ifOutUcastPkts.4 (.1.3.6.1.2.1.2.2.1.17.4) = Counter32: 0 ifOutDiscards : .1.3.6.1.2.1.2.2.1.19 : branch RFC1213-MIB::ifOutDiscards.1 (.1.3.6.1.2.1.2.2.1.19.1) = Counter32: 0 RFC1213-MIB::ifOutDiscards.2 (.1.3.6.1.2.1.2.2.1.19.2) = Counter32: 0 RFC1213-MIB::ifOutDiscards.3 (.1.3.6.1.2.1.2.2.1.19.3) = Counter32: 0 RFC1213-MIB::ifOutDiscards.4 (.1.3.6.1.2.1.2.2.1.19.4) = Counter32: 0 ifOutErrors : .1.3.6.1.2.1.2.2.1.20 : branch RFC1213-MIB::ifOutErrors.1 (.1.3.6.1.2.1.2.2.1.20.1) = Counter32: 0 RFC1213-MIB::ifOutErrors.2 (.1.3.6.1.2.1.2.2.1.20.2) = Counter32: 0 RFC1213-MIB::ifOutErrors.3 (.1.3.6.1.2.1.2.2.1.20.3) = Counter32: 0 RFC1213-MIB::ifOutErrors.4 (.1.3.6.1.2.1.2.2.1.20.4) = Counter32: 0 ifOutQLen : .1.3.6.1.2.1.2.2.1.21 : branch RFC1213-MIB::ifOutQLen.1 (.1.3.6.1.2.1.2.2.1.21.1) = Gauge32: 0 RFC1213-MIB::ifOutQLen.2 (.1.3.6.1.2.1.2.2.1.21.2) = Gauge32: 0 RFC1213-MIB::ifOutQLen.3 (.1.3.6.1.2.1.2.2.1.21.3) = Gauge32: 0 RFC1213-MIB::ifOutQLen.4 (.1.3.6.1.2.1.2.2.1.21.4) = Gauge32: 0 ifSpecific : .1.3.6.1.2.1.2.2.1.22 : branch RFC1213-MIB::ifSpecific.1 (.1.3.6.1.2.1.2.2.1.22.1) = OID: SNMPv2-SMI::zeroDotZero RFC1213-MIB::ifSpecific.2 (.1.3.6.1.2.1.2.2.1.22.2) = OID: SNMPv2-SMI::zeroDotZero RFC1213-MIB::ifSpecific.3 (.1.3.6.1.2.1.2.2.1.22.3) = OID: SNMPv2-SMI::zeroDotZero RFC1213-MIB::ifSpecific.4 (.1.3.6.1.2.1.2.2.1.22.4) = OID: SNMPv2-SMI::zeroDotZero oids file:: ifIndex : .1.3.6.1.2.1.2.2.1.1 : branch ifDescr : .1.3.6.1.2.1.2.2.1.2 : branch ifType : .1.3.6.1.2.1.2.2.1.3 : branch ifMtu : .1.3.6.1.2.1.2.2.1.4 : branch ifSpeed : .1.3.6.1.2.1.2.2.1.5 : branch ifPhysAddress : .1.3.6.1.2.1.2.2.1.6 : branch ifAdminStatus : .1.3.6.1.2.1.2.2.1.7 : branch ifOperStatus : .1.3.6.1.2.1.2.2.1.8 : branch ifInOctets : .1.3.6.1.2.1.2.2.1.10 : branch ifInUcastPkts : .1.3.6.1.2.1.2.2.1.11 : branch ifInDiscards : .1.3.6.1.2.1.2.2.1.13 : branch ifInErrors : .1.3.6.1.2.1.2.2.1.14 : branch ifOutOctets : .1.3.6.1.2.1.2.2.1.16 : branch ifOutUcastPkts : .1.3.6.1.2.1.2.2.1.17 : branch ifOutDiscards : .1.3.6.1.2.1.2.2.1.19 : branch ifOutErrors : .1.3.6.1.2.1.2.2.1.20 : branch ifOutQLen : .1.3.6.1.2.1.2.2.1.21 : branch ifSpecific : .1.3.6.1.2.1.2.2.1.22 : branch transforms file:: ifTypeTxt : SWITCH : {ifType} 1=other,2=regular1822,3=hdh1822,4=ddn-x25,5=rfc877-x25,6=ethernet-csmacd,7=iso88023-csmacd,8=iso88024-tokenBus,9=iso88025-tokenRin g,10=iso88026-man,11=starLan,12=proteon-10Mbit,13=proteon-80Mbit,14=hyperchannel,15=fddi,16=lapb,17=sdlc,18=ds1,19=e1,20=basicISDN,21=primaryISDN,22=propPointToPointSerial,2 3=ppp,24=softwareLoopback,25=eon,26=ethernet-3Mbit,27=nsip,28=slip,29=ultra,30=ds3,31=sip,32=frame-relay ifAdminStatusTxt : SWITCH : {ifAdminStatus} 1=up,2=down,3=testing ifOperStatusTxt : SWITCH : {ifOperStatus} 1=up,2=down,3=testing thresholds file:: ifTypeTxt : green : iso88024-tokenBus|iso88025-tokenRing : ifTypeTxt : yellow : other|regular1822|hdh1822|ddn-x25|rfc877-x25|ethernet-csmacd|iso88023-csmacd|iso88026-man|starLan|proteon-10Mbit|proteon-80Mbit|hyperchannel|fddi| lapb|sdlc|ds1|e1|basicISDN|primaryISDN|propPointToPointSerial|ppp|softwareLoopback|eon|ethernet-3Mbit|nsip|slip|ultra|ds3|sip|frame-relay : ifTypeTxt : red : : ifAdminStatusTxt : green : : ifAdminStatusTxt : yellow : up|down|testing : ifAdminStatusTxt : red : : ifOperStatusTxt : green : : ifOperStatusTxt : yellow : up|down|testing : ifOperStatusTxt : red : : -- David Baldwin - IT Unit Australian Sports Commission www.ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 user-cbbf693f2c89@xymon.invalid Leverrier Street Bruce ACT 2617 Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.