[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Routers and SNMP (was Re: snmpconf FW: November Milestones)
Bush, Randy might have said this:
>> i am not aware of significant operators using snmp to configure routers
I agree. For transit networks, this is absolutely true today.
Yet in the future, maybe it will be less true especially in areas where there is a
need for constant change to a configuration and using a CLI/expect script
does not offer the precision and speed needed over x generations
of a given vendors CLI. Most configurations are pretty much set-and-forget
on routers for the most part anyway today, but again that may change
with all the new traffic engineering/constraint based routing work, RSVP-TE stuff.
I see two major reasons why this state of affairs is so and why it remains that way
Reason 1) It has been my experience that an SNMP interface is more
costly, requires skills genererally not found in the vendors engineering groups
due to cross-disipline needs for both Net Mgmt AND Routing. Routing code
is hard enough thus any longer effort needed to deliver a working agent
than the average vendor's CLI means longer time to market.
....Sure would be very curious as to what would Greg Satz might say today...
So operators pay the cost in terms of operational pain but so far don't complain
too loudly about it if at all. Yet I bet anyone a nickle that operators running rtConfig
would prefer if a simpler tool that didn't have to keep up with vendor CLI
versions: cisco, bay, gated, rsd...so long as it remained easy to debug.
The cost of implementing read-write SNMP objects must be justified...
and it truely can be but the payback is not usually immediate.
Lastly, there is no artifical barrier to entry into the router market that says
you have to have SNMP configuration like there is with MSOs running HFC
networks which will make up the single largest group of network operators
using SNMP configuration today. Translation: DOCSIS Cable Modems and CMTSs.
And these folks really do need SNMP technology since their operations
staff, as CTO of a very large Tier 1 service provider to the MSO customer set
recently told me, tend to be on the less skilled side... The Internet Standard
Management Framework provides a precice, consistent managment interface
across vendor devices since DOCSIS mandates what MIB modules one must
support and the level of support is clear.
Reason 2) Routing configurations, if done wrong, have global impact on the
Internet. Randy's oft posts to NANOG mailing list about AS's advertising
prefixes they don't own, etc is evidence.
Unlike most of the systems SNMP configures today, configuring Routing
in the Internet is not something that has not been completely automated and
requires constant vigil by highly trained personnel.
I have hope that one day the routing working groups will get it right and
figure out how to design into the protocols ways/defaults of dealing with bad input to
configuration such that it will not cause outages on a more global scope.
Then eventually configuration of routers will become an ordinary procedure
and be capable of automation (CLI/SNMP) without worry that you can blank hole many
prefixes the next through three service providers you peer with.
Sure CLI's can be scripted, but everyone I know of would prefer a more precise
interface so long as it adheres to most of that is in the SNMPCONF BCP.... :-)