For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get.
On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get.
Some of the problems is the bulk nature of some config changes (or transactional nature on those that support atomic operations) have been harder to automate. Anyone that has spent any quantity of time with ASN.1 generally would agree. I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device. The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly. Have you had a good experience with using SNMP-Write? I have not. - Jared
On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get.
Some of the problems is the bulk nature of some config changes (or transactional nature on those that support atomic operations) have been harder to automate.
Anyone that has spent any quantity of time with ASN.1 generally would agree.
I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device.
yea... same with cascade devices... icky things (both bay and cascade!)
The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly.
fun story/fact, you can send an snmp write to the broadcast address of a network of NT (at least, probably also post-nt versions of the OS) machines, and set their default-ttl to some arbitrary number. "Your network is too chatty... not anymore! now your internet is 5 hops across!"
Have you had a good experience with using SNMP-Write? I have not.
long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though. Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?) -chris
2011/12/6 Christopher Morrow <morrowc.lists@gmail.com>
On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
For a few years now I been wondering why more networks do not use
SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant
as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get.
Some of the problems is the bulk nature of some config changes (or
writable patches transactional
nature on those that support atomic operations) have been harder to automate.
Anyone that has spent any quantity of time with ASN.1 generally would agree.
I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device.
yea... same with cascade devices... icky things (both bay and cascade!)
The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly.
fun story/fact, you can send an snmp write to the broadcast address of a network of NT (at least, probably also post-nt versions of the OS) machines, and set their default-ttl to some arbitrary number. "Your network is too chatty... not anymore! now your internet is 5 hops across!"
Let's leave the legacy boxes out of this. Remember that SNMP bug that could keel over a cisco router? I forget the details other than the guy who wrote c code at black hat to kill routers after cisco refused to patch.
Have you had a good experience with using SNMP-Write? I have not.
long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though.
I can see the other comments about interactive commands and bulk read/writes, but what's the harm of doing it on internet connected boxes vs. non-internet boxes. Just about everyone uses snmp reads in the interwebs and as such filters it at their edges and hopefully on each platform. You'd secure it the same way you'd secure readable SNMP I assume.
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks?
lol, that could be a problem.
... (didn't the snmp incident in 2002 teach us something?)
Please elaborate.
-chris
On Tue, Dec 6, 2011 at 11:49 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
2011/12/6 Christopher Morrow <morrowc.lists@gmail.com>
On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get.
Some of the problems is the bulk nature of some config changes (or transactional nature on those that support atomic operations) have been harder to automate.
Anyone that has spent any quantity of time with ASN.1 generally would agree.
I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device.
yea... same with cascade devices... icky things (both bay and cascade!)
The errors/feedback tends to be very poor over SNMP as well as you may need to walk/revisit a large number of elements to make things happen properly.
fun story/fact, you can send an snmp write to the broadcast address of a network of NT (at least, probably also post-nt versions of the OS) machines, and set their default-ttl to some arbitrary number. "Your network is too chatty... not anymore! now your internet is 5 hops across!"
Let's leave the legacy boxes out of this. Remember that SNMP bug that could keel over a cisco router? I forget the details other than the guy who wrote c code at black hat to kill routers after cisco refused to patch.
Have you had a good experience with using SNMP-Write? I have not.
long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though.
I can see the other comments about interactive commands and bulk read/writes, but what's the harm of doing it on internet connected boxes vs. non-internet boxes. Just about everyone uses snmp reads in the interwebs
I think the general feeling is that snmp is udp so it's spoofable and your perimeter acls will never be 100% (or rather, are you willing to risk them not being 100%?)
and as such filters it at their edges and hopefully on each platform. You'd secure it the same way you'd secure readable SNMP I assume.
read is 'painful', write can be downright deadly (to your SLAs).
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks?
lol, that could be a problem.
yea, I bet the number of people that test, at scale/operations-pace, snmp WRITE is countable on a single hand.
... (didn't the snmp incident in 2002 teach us something?)
Please elaborate.
<http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml> oh, 2001... memory lag :(
I can see the other comments about interactive commands and bulk read/writes, but what's the harm of doing it on internet connected boxes vs. non-internet boxes. Just about everyone uses snmp reads in the interwebs
I think the general feeling is that snmp is udp so it's spoofable and your perimeter acls will never be 100% (or rather, are you willing to risk them not being 100%?)
That's a given even though there's still the string to deny the spoofed traffic someone could cause a fair amount of trouble if they knew what your acl's look like. That being said I don't think I've ever seen a company that doesn't at least use SNMP for billing and basic monitoring and many don't think to block it at their edge. It's hard to convince someone to change something that's been around for years though. SNMP is flawed though and enabling writes just makes it worse.
and as such filters it at their edges and hopefully on each platform. You'd secure it the same way you'd secure readable SNMP I assume.
read is 'painful', write can be downright deadly (to your SLAs).
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks?
lol, that could be a problem.
yea, I bet the number of people that test, at scale/operations-pace, snmp WRITE is countable on a single hand.
... (didn't the snmp incident in 2002 teach us something?)
Please elaborate.
< http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml
oh, 2001... memory lag :(
I don't remember hearing about this causing issues in a production network. According to the article you can just filter SNMP by IP which should be in place anyway. It's triggered by some sort of hidden string which would make it malicious, unless I'm missing something. In lieu of a software upgrade, a workaround can be applied to certain IOS releases by disabling the ILMI community or "**ilmi*" view and applying an access list to prevent unauthorized access to SNMP. Any affected system, regardless of software release, may be protected by filtering SNMP traffic at a network perimeter or on individual devices.
On Wed, Dec 7, 2011 at 11:29 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
I can see the other comments about interactive commands and bulk read/writes, but what's the harm of doing it on internet connected boxes vs. non-internet boxes. Just about everyone uses snmp reads in the interwebs
I think the general feeling is that snmp is udp so it's spoofable and your perimeter acls will never be 100% (or rather, are you willing to risk them not being 100%?)
That's a given even though there's still the string to deny the spoofed traffic someone could cause a fair amount of trouble if they knew what your
so... be cautious here, the 'acl' on the community string is really 'who can use this string' you have to still process the packet to some extent before you decide that the string doesn't match NMS1's ip address :( you need also to traffic filter (in Cisco CoPP, in Juniper LoopbackFilter)... that said, someone can bomb your loopback with 'public' and just spoof the src to your NMS, or your NOC or ... all easy to figure out :( (well the noc is at least :) ).
acl's look like. That being said I don't think I've ever seen a company that doesn't at least use SNMP for billing and basic monitoring and many don't think to block it at their edge. It's hard to convince someone to
yea, RO though, at least... though still, you process the packets to see 'oh yea, not my string' :(
change something that's been around for years though. SNMP is flawed though and enabling writes just makes it worse.
yes.
and as such filters it at their edges and hopefully on each platform. You'd secure it the same way you'd secure readable SNMP I assume.
read is 'painful', write can be downright deadly (to your SLAs).
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks?
lol, that could be a problem.
yea, I bet the number of people that test, at scale/operations-pace, snmp WRITE is countable on a single hand.
... (didn't the snmp incident in 2002 teach us something?)
Please elaborate.
<http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml>
oh, 2001... memory lag :(
I don't remember hearing about this causing issues in a production network.
There were lots of people with things changing on their devices without their knowledge :(
According to the article you can just filter SNMP by IP which should be in place anyway. It's triggered by some sort of hidden string which would make it malicious, unless I'm missing something.
yep, just 'hey there's a hidden community string, which isn't supposed to actually be available outside the local box, and is RW... whoops! the intern made it available :(' coupled with the fact that 90% of the industry had the same roots for snmp code;(
In lieu of a software upgrade, a workaround can be applied to certain IOS releases by disabling the ILMI community or "*ilmi" view and applying an access list to prevent unauthorized access to SNMP. Any affected system, regardless of software release, may be protected by filtering SNMP traffic at a network perimeter or on individual devices.
right, but as I said above, the community-string restrictions don't help you in cases where you haven't filtered source-addresses in loopback/copp :( people still get to grind on your router's snmp process, maybe there's another way in, maybe there's a bug in the snmpd :( -chris
In lieu of a software upgrade, a workaround can be applied to certain IOS releases by disabling the ILMI community or "*ilmi" view and applying an access list to prevent unauthorized access to SNMP. Any affected system, regardless of software release, may be protected by filtering SNMP traffic at a network perimeter or on individual devices.
right, but as I said above, the community-string restrictions don't help you in cases where you haven't filtered source-addresses in loopback/copp :( people still get to grind on your router's snmp process, maybe there's another way in, maybe there's a bug in the snmpd :(
even if you filtered you could still get spoofed traffic. What if some
employee wrote code to trace route across your network and send spoofed packets with or without a good string. Provided you aren't filtering snmp at your edge, which many don't they could pretty easily melt your network with a few boxes. This is true of the ever present snmp poll as well. (conspiracy theory over)
On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote:
long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though.
Many vendors have poor TFTP implementations, such that any additional latency creates very slow transfer rates. This is why things like the RCPD were done, and others use FTP/HTTP even. I am not sure if you can tell it to trigger some protocol other than TFTP in IOS. As someone who has moved large configs around in the past (1-16MB in cases) transfer speeds do matter.
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?)
This is also a whole other interesting problem. Part of it is lack of exposure to it. Part of it is ease of operation. Many people still telnet over when they should use ssh. (feedback is more immediate if you are not in the VTY ACL for example). People revert to what they are comfortable with. Some it's scripts, others its typing configure or conf t and hitting ? a lot. There's no reason one can't program a device with SNMP, the main issue IMHO has always been what I dubbed "config drift". You have your desired configuration and variances that happen over time. If you don't force a 'wr mem' or similar event after you trigger a 'copy tftp run' operation, you may have troubles that are not apparent if there is a power failure or other lossage. The boot-time parser doesn't interpret SNMP, it parses text. This and other reasons have made people fail-safe to using the language most easily interpreted by the device. - Jared
On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote:
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?)
There's no reason one can't program a device with SNMP, the main issue IMHO
There is one good reason. Every vendor seem to assign a junior intern to maintanining SNMP code, so you are interfacing with your router via a very suspect interface. -dorian
On Tue, Dec 6, 2011 at 12:39 PM, Dorian Kim <dorian@blackrose.org> wrote:
On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote:
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?)
There's no reason one can't program a device with SNMP, the main issue IMHO
There is one good reason. Every vendor seem to assign a junior intern to maintanining SNMP code, so you are interfacing with your router via a very suspect interface.
this is exactly my 'testing' commment... and you thought bgp bugs were painful :)
On Tue, 6 Dec 2011 12:39:34 -0500, Dorian Kim <dorian@blackrose.org> said:
DK> There is one good reason. Every vendor seem to assign a junior intern to DK> maintanining SNMP code, so you are interfacing with your router via a very DK> suspect interface. The marking folks believed that when X dollars had to be spent, most folks would rather buy a box where .99X was spent on a "new spiffy routing feature" rather than on a manageable device. To change that, people need to start writing RFPs very very differently so that more points (dollars) are given to boxes that have consistent, standardized management interfaces rather than to boxes with new feature Z. Unfortunately, I don't have high hopes for that as institutions don't make money from having manageable networks. They make money from having fast and furious networks and that's what drives industry progress. [note: I'm not saying this is right or wrong; just that it's true. I could argue, and have, both sides quite effectively] -- Wes Hardaker
On Tue, Dec 6, 2011 at 12:15 PM, Jared Mauch <jared@puck.nether.net> wrote:
On Dec 6, 2011, at 11:28 AM, Christopher Morrow wrote:
long ago, in a network far away (not on the interwebs) we used snmp write to trigger a tftp config load. It worked nicely... I'm fairly certain I'd not do this on an internet connected network today though.
Many vendors have poor TFTP implementations, such that any additional latency creates very slow transfer rates. This is why things like the RCPD were done, and others use FTP/HTTP even. I am not sure if you can tell it to trigger some protocol other than TFTP in IOS.
agreed, I did say 'long time ago' :) (like before 2000 long time ago) I get the impression we could have said copy http:// instead of tftp though. (if it were supported at the time, http I mean)
As someone who has moved large configs around in the past (1-16MB in cases) transfer speeds do matter.
agreed
Also, who tests snmp WRITE in their code? at scale? for daily operations tasks? ... (didn't the snmp incident in 2002 teach us something?)
This is also a whole other interesting problem. Part of it is lack of exposure to it. Part of it is ease of operation. Many people still telnet over when they should use ssh. (feedback is more immediate if you are not in the VTY ACL for example). People revert to what they are comfortable with. Some it's scripts, others its typing configure or conf t and hitting ? a lot.
There's no reason one can't program a device with SNMP, the main issue IMHO has always been what I dubbed "config drift". You have your desired configuration and variances that happen over time. If you don't force a 'wr mem' or similar event after you trigger a 'copy tftp run' operation, you may have troubles that are not apparent if there is a power failure or other lossage. The boot-time parser doesn't interpret SNMP, it parses text. This and other reasons have made people fail-safe to using the language most easily interpreted by the device.
Yup, I think the OP was maybe getting at: "Why can't I snmp configure my cisco/juniper/alteon device?" I took that to mean (probably naively?) that they also would validate configs and update drift out of the configuration. You CAN force a 'wr mem' via snmp as well, of course (in cisco world).
There's no reason one can't program a device with SNMP, the main issue IMHO has always been what I dubbed "config drift". You have your desired configuration and variances that happen over time. If you don't force a 'wr mem' or similar event after you trigger a 'copy tftp run' operation, you may have troubles that are not apparent if there is a power failure or other lossage. The boot-time parser doesn't interpret SNMP, it parses text. This and other reasons have made people fail-safe to using the language most easily interpreted by the device.
Yup, I think the OP was maybe getting at: "Why can't I snmp configure my cisco/juniper/alteon device?"
I took that to mean (probably naively?) that they also would validate configs and update drift out of the configuration. You CAN force a 'wr mem' via snmp as well, of course (in cisco world).
It was more curiosity. I'm looking in to scripting and starting to get tired of having to account for ssh/telnet, credentials, differences in platforms and code from the same vendor and my various failed attempts to do all of the above. Most of the automation suites I've seen work via logins, rancid,HP NA etc etc. Although there are better programmers that can and have made it work it still seems cumbersome to me. I've pretty much made the assumption that writable SNMP was a bad idea but have never actually tried it. I was curious what others were using, netconf or just scripted logins. I'm also fighting a losing battle to convince people that netconf isn't evil. It strikes me as odd that if I wanted to talk to a database/website full of credit card and billing info there's a long list of API's I could use, but if I wanted to talk to the router or firewall in front of it I can only use ssh or telnet.
On Wed, Dec 7, 2011 at 11:19 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
It was more curiosity. I'm looking in to scripting and starting to get tired of having to account for ssh/telnet, credentials, differences in
'write a library'... someone once said.
platforms and code from the same vendor and my various failed attempts to do all of the above. Most of the automation suites I've seen work via logins, rancid,HP NA etc etc. Although there are better programmers that can and have made it work it still seems cumbersome to me. I've pretty much made the
it is, somewhat, yes.
assumption that writable SNMP was a bad idea but have never actually tried it. I was curious what others were using, netconf or just scripted logins. I'm also fighting a losing battle to convince people that netconf isn't evil. It strikes me as odd that if I wanted to talk to a database/website full of credit card and billing info there's a long list of API's I could use, but if I wanted to talk to the router or firewall in front of it I can only use ssh or telnet.
sad, right? there are millions of restful program writers, only a few thousand network device programmers, and the vast majority of 'network management' is done by people perfectly happy with 'cisco-works' :(
assumption that writable SNMP was a bad idea but have never actually tried it. I was curious what others were using, netconf or just scripted logins. I'm also fighting a losing battle to convince people that netconf isn't evil. It strikes me as odd that if I wanted to talk to a database/website full of credit card and billing info there's a long list of API's I could use, but if I wanted to talk to the router or firewall in front of it I can only use ssh or telnet.
sad, right? there are millions of restful program writers, only a few thousand network device programmers, and the vast majority of 'network management' is done by people perfectly happy with 'cisco-works' :(
according to the law of supply and demand, that would be.... demand? right? ;)
On 12/9/11 18:22 , Keegan Holley wrote:
assumption that writable SNMP was a bad idea but have never actually tried it. I was curious what others were using, netconf or just scripted logins. I'm also fighting a losing battle to convince people that netconf isn't evil. It strikes me as odd that if I wanted to talk to a database/website full of credit card and billing info there's a long list of API's I could use, but if I wanted to talk to the router or firewall in front of it I can only use ssh or telnet.
http://www.juniper.net/support/products/netconf/
sad, right? there are millions of restful program writers, only a few thousand network device programmers, and the vast majority of 'network management' is done by people perfectly happy with 'cisco-works' :(
according to the law of supply and demand, that would be.... demand? right? ;)
2011/12/9 Joel jaeggli <joelja@bogus.com>
On 12/9/11 18:22 , Keegan Holley wrote:
assumption that writable SNMP was a bad idea but have never actually tried it. I was curious what others were using, netconf or just scripted logins. I'm also fighting a losing battle to convince people that netconf isn't evil. It strikes me as odd that if I wanted to talk to a database/website full of credit card and billing info there's a long list of API's I
could
use, but if I wanted to talk to the router or firewall in front of it I can only use ssh or telnet.
+1 sadly there are still those that think netconf is black magic hacker voodo though
On Tue, 6 Dec 2011, Jared Mauch wrote:
I recall some bay networks gear you could only program with the proper OID as the cli was basically a SNMP-SET operation on the device.
The mere mention of Bay Networks and Site Manager (read: Site Mangler or Site Damager) is enough to get my blood pressure up a few points, and I haven't touched that stuff since probably 1999 or 2000. The CLI was quite horrible, and their somewhat IOS-like command shell (BCC) was not much better.
Have you had a good experience with using SNMP-Write? I have not.
The most I've done using SNMP SETs is backed up configurations from network devices at my old job. That part worked (and works) very well, but I never tried pushing config changes out to devices that way. jms
Yes, Site Mangler. Do not stir that nest. Thar be dragons. -Blake On Tue, Dec 6, 2011 at 11:35, Justin M. Streiner <streiner@cluebyfour.org>wrote:
On Tue, 6 Dec 2011, Jared Mauch wrote:
I recall some bay networks gear you could only program with the proper OID
as the cli was basically a SNMP-SET operation on the device.
The mere mention of Bay Networks and Site Manager (read: Site Mangler or Site Damager) is enough to get my blood pressure up a few points, and I haven't touched that stuff since probably 1999 or 2000. The CLI was quite horrible, and their somewhat IOS-like command shell (BCC) was not much better.
Have you had a good experience with using SNMP-Write? I have not.
The most I've done using SNMP SETs is backed up configurations from network devices at my old job. That part worked (and works) very well, but I never tried pushing config changes out to devices that way.
jms
In a message written on Tue, Dec 06, 2011 at 11:16:02AM -0500, Jared Mauch wrote:
Anyone that has spent any quantity of time with ASN.1 generally would agree.
SNMP has two fatal flaws for large scale write based configuration. ASN.1 was basically obsolete before it was written. It was designed to be a compact data transfer format in the days of 56k lines, and is nothing but annoying in practice. Hard to write, hard to debug, hard to understand to save a little bandwidth which no longer matters. (Note, there is apparently an XML version of ASN.1 which may or may not make things better, but I have never seen a single bit of gear anywhere that implemented it.) But then on top of ASN.1, the transaction model is all wrong. No way to group writes together (e.g. commit a series of changes at once). One RTT incurred for each write/read-back (for verification, since it's UDP). If you try and configure a device with SNMP over a 500ms link it might take longer than the lifespan of the gear! :) Jared also makes a good point about the device not reading SNMP on boot, it reads a text file, and being able to alter that directly makes more sense. Lastly, let's not forget that at most vendors SNMP seems to be a low priority item. How many years was it after we had IPv6 BGP before there was an IPv6 BGP MIB actually implemented? I actually would submit SNMP was never the right tool for the job, just the tool we had. Even today where it's most popular use is to poll interfaces for statistics it would be easier on the device, programmer, and operator to make one tcp connection, send a list of things to poll, and get back a blob of text. I hesitate to say XML + Restful, becuse I think it need not be that specific solution, but that is a solution that meets the criteria. The only thing SNMP has going for it at this point in time is inertia. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
What SNMP does have for it is it is lightweight (to some extent) vs XML that can get quite bulky, and certainly is the case when trying to do many interfaces at once. I have seen better precision with snmp vs cli interaction/tcp based interaction. snmpbulkwalk has been my cruel mistress for several years... But does provide the detail/accuracy most days. Also keep in mind most hardware only pulls or pushes counters every 5s anyways... Jared Mauch On Dec 6, 2011, at 2:13 PM, Leo Bicknell <bicknell@ufp.org> wrote:
I actually would submit SNMP was never the right tool for the job, just the tool we had. Even today where it's most popular use is to poll interfaces for statistics it would be easier on the device, programmer, and operator to make one tcp connection, send a list of things to poll, and get back a blob of text. I hesitate to say XML + Restful, becuse I think it need not be that specific solution, but that is a solution that meets the criteria. The only thing SNMP has going for it at this point in time is inertia.
On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various
I've spent enough time writing code to deal with SNMP (our own stack, not using Net-SNMP or friends) to have a more in-depth understanding of SNMP's pitfalls than most people. It is TERRIBLE and should be totally gutted and replaced with something more sane, less likely to have bugs, etc. There is a good reason why many major bugs have popped up over the years allowing devices to be crashed with crafted SNMP packets -- it's honestly not that easy to get right, especially if you really implement every possible encoding so some random customer with a brain-damaged SNMP client stack won't come crying to you that his client won't work. Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Tue, 6 Dec 2011, Jeff Wheeler wrote:
On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various
...
Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all.
So what are the alternatives these days then for automation or batch operations? clogin etc from shrubbery's rancid? Net::Appliance::Session ... ? . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.
From: Jeff Wheeler <jsw@inconcepts.biz>
Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all.
If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP? I liked using them, but that's a special case... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On 06Dec2011, at 12.28, David Barak wrote:
From: Jeff Wheeler <jsw@inconcepts.biz>
Juniper does not support writing via SNMP. I am glad. Hopefully that is the first step toward not supporting SNMP at all.
If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP? I liked using them, but that's a special case...
Wellfleet
David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
-- 李柯睿 Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
On Tue, 06 Dec 2011 14:18:52 EST, Jeff Wheeler said:
I've spent enough time writing code to deal with SNMP (our own stack, not using Net-SNMP or friends) to have a more in-depth understanding of SNMP's pitfalls than most people. It is TERRIBLE and should be totally gutted and replaced with something more sane, less likely to have bugs, etc.
A number of years ago, I pointed out that the official rfc-index.txt listed the publication date of RFC1442 as April 1, 1993 rather than April 1993. Draw your own conclusions. ;)
On Tue, 6 Dec 2011 11:07:44 -0500, Keegan Holley <keegan.holley@sungard.com> said:
KH> Admittedly, you will have to deal with proprietary mibs and reformat KH> the data once it's returned. That's the nail in the coffin of just about every configuration protocol. Until multiple vendors implement a common model, no technology is going to work. SNMP certainly suffered from multiple vendors doing different things in their private MIBs while also implementing the standard MIBs is a standard way. You could probably get two vendors (X and Y) to agree that all devices have N interfaces with M-bit counters to represent traffic. The problem, especially with configuration, comes when vendor X uses virtual interfaces (eth0:1) to model interfaces with multiple addresses and vendor Y uses a single interface identifier with a sub-tail to list all the addresses assigned to the interface. Now this problem is at least solvable, given enough code, to take a configuration set from one device and covert it to the other, which in part is the goal of netconf: to enable a language that will hopefully allow a transformation process to succeed and thus bring about the holy grail of a singular management protocol. But in the end, every problem will still end up in the odd case where vendor X produces a config set with 2 "rows" and vendor Y produces a config set with 3 "rows" and no magical transformation can possibly get from point A to point B because the data models simply don't align. At all. When the internals aren't compatable, there isn't a data model to be written. No matter if it's in txt, SMIv2, XML, yang or moon dust. And hence the reason homogeneous networks with rdist distributed config files were born. -- Wes Hardaker
participants (14)
-
Blake Dunlap -
Christopher LILJENSTOLPE -
Christopher Morrow -
David Barak -
Dorian Kim -
Jared Mauch -
Jeff Wheeler -
Jethro R Binks -
Joel jaeggli -
Justin M. Streiner -
Keegan Holley -
Leo Bicknell -
Valdis.Kletnieks＠vt.edu -
Wes Hardaker