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
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
>
>
>> 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 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.
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
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
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
Yes, Site Mangler. Do not stir that nest. Thar be dragons.
-Blake
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.
> 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.
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).
>
>
>> 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.
<Networking, Cloud, and Cybersecurity Solutions - Cisco;
oh, 2001... memory lag 
this is exactly my 'testing' commment... and you thought bgp bugs were
painful 
netconf!
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.
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
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
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. 
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.
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]