Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration

["David Harrington" <ietfdbh at comcast.net>]

Hi,

RFC3014 "Notification Log MIB" provides a pollable log of SNMP traps,
and statistics that could be checked to see if the manager and agent
are in sync.

The Notification Log MIB also allows for aggregators, so all
trap-generation devices do not need to keep historical logs; the
Notification Log MIB can be implemented in a node that has greater
storage capacity.

If ISMS adopts a subscription-style approach, we could recommend or
require the Notification Log MIB be used as the buffering and replay
mechanism using a polling approach.

dbh

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas at netcore.fi] 
> Sent: Thursday, June 05, 2008 3:05 PM
> To: Phil Shafer
> Cc: David Harrington; ops-dir at ietf.org; isms at ietf.org; 'OPS Area'
> Subject: Re: [OPS-DIR] SNMP notification configuration
> 
> On Tue, 3 Jun 2008, Phil Shafer wrote:
> > "David Harrington" writes:
> >> SNMP can send notifications when an event happens, without 
> having to
> >> wait for a manager to initiate a connection first. This
distinction
> >> can be important, especially during startup.
> >
> > Sure, but in practice, startup is a painful time to send 
> notifications,
> > since the delays of interface bringup and learning routes may mean
> > your manager is unreachable.  Waiting for a connection turns out
> > to be more useful than firing off packets into nowhere.
> 
> FWIW my take on this is:
> 
> We (our network) are happy enough with SNMP traps over UDP from the 
> security (confidentiality etc.) perspective.  I realize that some 
> other operators, especially if their borders are not easily
definable 
> or have equipment all over the globe without virtual management 
> interfaces (through tunnels etc.) may have a different perspective.
> 
> The main problem with SNMP traps, syslog, etc. is that when a system

> reboots or a line goes down, they get lost.  If the amount of loss
is 
> infrequent (every event does not cause loss), you can live with it
as 
> long as you can verify the correct operations using other, reliable 
> means.  On the other hand, if every event caused significant loss of

> information, the manual procedures would become more burdensome and 
> you would need to use a different management model (e.g. almost 
> exclusively polling based) to get the job done.
> 
> This is to say that traps/notifications over TCP is not to _us_ very

> interesting if it doesn't also do something else -- i.e. make 
> practically certain that all traps/notifications will in fact be 
> delivered.
> 
> If we examine how unreliable syslog can be made to work we may learn

> something for other protocols.
> 
> Mostly unreliable syslog is fine.  Some implementations AFAIK buffer

> syslog data and don't send it if there is no route to the 
> destination. 
> That helps a bit but not much if you're using default routes your 
> network.  But because syslog is also stored locally, you can 
> either 1) 
> go check the local syslog manually if in doubt, or 2) configure 
> scripts to pull in devices' local syslog automatically after certain

> kinds of events to ensure that the syslog data you have should be 
> complete.
> 
> That makes me think that (unless this is already being done) an SNMP

> agent should also store traps/notifications locally at least for the

> duration of O(days), and that a management system could poll them 
> after the fact to synchronize notification "state".
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 

_______________________________________________
OPS-AREA mailing list
OPS-AREA at ietf.org
https://www.ietf.org/mailman/listinfo/ops-area