jared at puck.nether.net
Tue Dec 6 11:15:35 CST 2011
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
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.
More information about the NANOG