[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
for Routing.

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.... :-)

Mike MacFaden