On Tue, Dec 6, 2011 at 11:49 AM, Keegan Holley <keegan.hol...@sungard.com> wrote: > 2011/12/6 Christopher Morrow <morrowc.li...@gmail.com> >> >> On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <ja...@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 :(