Subject: [dhcwg] DHCP Option for SNMP Notifications

From: Mark Bakke <[email-masked]>
Date: Wed, 11 Sep 2002 11:22:43 -0500

Hi-

I needed a method to configure a list of SNMP notification (AKA trap)
hosts for use by diskless workstations booting from a network device.
Since none of the usual SNMP configuration information is available
at this time, I would like to use a DHCP option to provide a list of
IP addresses to which to send notifications when, for instance, booting
from a network device fails for some reason.  This could also be used
to centrally configure the list of SNMP notification hosts, rather than
setting them individually on each machine.

Anyway, I've submitted a short draft describing the proposed option
as draft-bakke-dhc-snmp-trap-00.txt.  I'll forward the message to
these two groups when the draft is published.  In the mean time, it
is available at:

ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-00.txt

I'm guessing that these two mailing lists (dhcwg and mibs) are the
correct places to discuss this (please let me know if there's a more
appropriate list).

Regards,

Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Bakke <[email-masked]>
Date: Wed, 11 Sep 2002 16:40:28 -0500

Hi David-

My assumption was that in this case, we could get away with using
"public" for the community string, and that any defined traps would
be enabled (we would only send these when something failed, so
we shouldn't have to allow the user to configure which ones to
send).  That would take care of early boot, unless configuring the
community string was important.  Perhaps this would be enough.

Are there other things that might be important to set for an initial
boot implementation that only sends traps?

Thanks,

Mark

"David T. Perkins" wrote:
> 
> HI,
> 
> Mark,
> 
> Having only an IP address of a management target is insufficient for
> achieving your objective. What you need to add depends on how many
> "stages" that you have for your boot operation, and what you assume
> can be configured in persistent storage for the device.
> 
> At 11:22 AM 9/11/2002 -0500, Mark Bakke wrote:
> >Hi-
> >
> /david t. perkins

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Wed, 11 Sep 2002 16:47:48 -0500

On second thought, we would probably also want to configure whether
each host was to be sent a V1 or V2 trap.

--
Mark

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 11 Sep 2002 13:50:04 -0700

HI,

Mark,

Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 11 Sep 2002 14:27:14 -0700

HI,

So, you are developing a mechanism that works only for
SNMPv1 with no proxy or security. Note that SNMPv1 is
a "not recommended" protocol. It would be much more
valuable to create an approach that worked for SNMPv1,
SNMPv2, and SNMPv3 protocols, that supported security
parameters from the DHCP server and from local persistent
storage, and that allowed a multi-stage boot.

There are security trade-offs that need to be covered.

Regards,
/david t. perkins

---

From: Mark Bakke <[email-masked]>
Date: Wed, 11 Sep 2002 17:01:56 -0500

True; that's what I had in mind, although we would definitely need
to say which version was needed for each host.  I hadn't taken
proxies or security into account, since I have not thought beyond
version 2.  Anyway, we should do this right.  I assume that we
need to have a set of parameters that are global to the entity
being configured, as well as a set of parameters for each trap
or notification host.

Any pointers to what should be configured for security?

Thanks,

Mark