From: Josef A (josefnet@gmail.com)
Date: Mon Mar 26 2007 - 21:08:58 ART
Actually the answer is Yes and No, depending on whether the trap is an
inform or a conventional trap. If it's an inform, ( a two way message), the
receiver (the manager) of the inform is authoritative; thus from
the router's perspective, this is remote engine ID. If it's a regular trap (
a one way message) then the sender of the message is authoritative, which in
this case will be the router's local engine ID.
HTH
On 3/26/07, Filyurin, Yan <yan.filyurin@eds.com> wrote:
>
> So would that mean if I were to define a remote engine ID and then
> specify SNMP traps going to that host and specify privacy, it would encrypt
> the message and use the remote engine ID as part of the encryption
> algorithm?
>
>
> ------------------------------
>
> *From:* Josef A [mailto:josefnet@gmail.com]
> *Sent:* Sunday, March 25, 2007 7:20 AM
> *To:* Filyurin, Yan
> *Cc:* ccielab@groupstudy.com
> *Subject:* Re: SNMP Engine ID and SNMPv3 in general
>
>
>
>
>
> In SNMPv3, the authoritative SNMP engine (or process) is the one
> designated to protect against message replay, delay, and redirection. The
> security keys used for authenticating and encrypting SNMPv3 packets are
> generated as a function of the authoritative SNMP engine's engine ID and
> user passwords.
>
>
>
> Thus the snmp action will determine whether the local or remote engines
> will be authoritative.
>
>
>
> When an snmp message expects a reply, like when the manager is polling the
> managed devices for some snmp data, the receiver of these messages should be
> authoritative. For example, an NMS polling a router for some MIBs, the
> router is the receiver, thus its engine ID should be authoritative. In the
> configuration this would be local engine ID. The onus is on the router to
> protect the information it is sending back.
>
>
>
> When an snmp message does not expect a reply.(a one way message) then the
> sender's engine ID should be authoritative, now it is the duty of the sender
> to protect the message before sending it. From the perspective of the
> router configuration, that could be the remote engine ID or local engine ID,
> depending on what the message is.
>
>
>
> Comments are welcome.
>
>
>
> thx
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 3/24/07, *Filyurin, Yan* < yan.filyurin@eds.com> wrote:
>
> I was recently reviewing SNMP and was looking into version 3 and I
> realized I am not completely sure I understand the most basic thing and
> that is the use of SNMP Engine ID command. Rom what I understand it is
> pretty much the SNMP process instance that runs on the router that is
> responsible for SNMP activities and I understand you can only have one
> in a router. What confuses me is the concept that you can have local
> SNMP engine and remote SNMP engine ID. I found an earlier post
> regarding this:
>
> http://www.groupstudy.com/archives/cisco/200111/msg02511.html
>
> but I am still a little confused. Maybe seriously confused. In other
> words, I can see why you would want to define local SNMP engine, but at
> what point would you ever want to define a remote engine ID. If you
> just want to send traps or informs to NMS, could you just define a user
> and just do something this:
>
> snmp-server host X.X.X.X version 3 auth remoteuser
>
> snmp-server host X.X.X.X informs version 3 noauth remoteuser
>
>
> And can an IOS device be used as an SNMP proxy?
>
>
> Also other than Cisco documentation, any good pointers to SNMP
> configuration examples would be great. For example I found this one and
> it helped a little:
>
> http://www.loriotpro.com/ServiceAndSupport/How_to/howto_snmpv3_cisco_EN .
> php
>
>
> thank you!
>
>
> Yan Filyurin
> EDS - Bank of America, Network Design
> MS: MA6-536-0501
> 1025 Main Street
> Waltham, MA 02451
> Office: +1-781-788-2207
> Cell: +1-617-875-4862
> yan.filyurin@eds.com
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:53 ART