cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1100
Views
0
Helpful
4
Replies

Setup issues for SNMP v3 /w LMS 2.5.1 on windows 2k3

jpeterson6
Level 2
Level 2

I'm trying to set up snmp v3 on my switch network and I seem to be hitting a bit of a brick wall. I'm very new to snmp in general so I spent some time researching and I did manage to get some progress, I think.

Anyways, I am unable to pull data from a test switch ever since I tried implementing snmp v3 (it was working when I was just using v2 communities), and I was wondering if anyone could help me.

My snmp configs on my switch (a 2950T 24 port) are:

snmp-server engineID local xxx

snmp-server engineID remote xxx.xxx.2.240 000000000100000000000000

snmp-server group tscgrp v3 auth notify *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF

snmp-server community -------- RO

snmp-server community -------- RW

snmp-server contact TSC (x9149)

snmp-server system-shutdown

snmp-server enable traps config

snmp-server host xxx.xxx.2.240 version 3 auth tscusr

snmp-server manager

and a 'show snmp user' command:

User name: tscusr

Engine ID: 800000090300001A6DCD8440

storage-type: nonvolatile

Rowstatus: active

Authentication Protocol: MD5

Group-name: tscgrp

Is there anything I'm doing wrong here? The local engineID seemed to appear on it's own but I'm not sure how to set up the remote engineID (in terms of finding out what it is). What is needed to get it working on the 2k3 server that ciscoworks is sitting on, if anything? Or is it something to do with ciscoworks itself? This is a new (full) CWS install on a new server box, and the switch is on the same C-class subnet. There is no issue with blocked ports or reachability as far as I know.

Any help is greatly appreciated, thanks in advance!

1 Accepted Solution

Accepted Solutions

The only way to obfuscate the SNMP credentials is with SNMPv3. The credentials are not encrypted in this case, but rather hashed using either MD5 or SHA-1.

SNMP contexts allow access to a MIB branch on varying conditions. For example, certain MIB branches may be replicated across different subsystems or different logical entries within the same device. Examples include MPLS VRFs, clustered switch devices, and VLANs. In the latter case, each VLAN has its own context. In order for User Tracking to get the users on each VLAN on the switch, it polls the BRIDGE-MIB using each VLAN's context. Since the 2950 series do not support contexts, this will fail, and it will appear as if there are no end users on the switch.

With SNMPv1/v2c, this same thing was accomplished using community string indexing. This was a hack Cisco developed to workaround the limitations in these early versions of SNMP. Community string indexing worked by appending an '@' followed by the VLAN number to the community string.

View solution in original post

4 Replies 4

Joe Clarke
Cisco Employee
Cisco Employee

First off, using SNMPv3 on a 2950 series switch will mean no User Tracking support. The problem with SNMPv3 and 2950 switches is that there is no SNMP context support for these switches, nor will there ever be. If that is not acceptable to you, you will have to continue to use SNMPv1/v2c for the time being.

Next, forget about the remote engineID. It's not needed for polling.

Everything else looks okay. Just make sure that your user has a password of at least eight characters.

Thanks for the reply.

The main reason we've been thinking of switching to snmpv3 was because we noticed that with snmpv2, the passwords are being sent through clear text. I don't suppose there's a way to encrypt v2 passwords is there? I haven't had much luck finding an answer to that question.

Also, when you say that there is no snmpv3 context support on 2950's, what exactly does that mean?

The only way to obfuscate the SNMP credentials is with SNMPv3. The credentials are not encrypted in this case, but rather hashed using either MD5 or SHA-1.

SNMP contexts allow access to a MIB branch on varying conditions. For example, certain MIB branches may be replicated across different subsystems or different logical entries within the same device. Examples include MPLS VRFs, clustered switch devices, and VLANs. In the latter case, each VLAN has its own context. In order for User Tracking to get the users on each VLAN on the switch, it polls the BRIDGE-MIB using each VLAN's context. Since the 2950 series do not support contexts, this will fail, and it will appear as if there are no end users on the switch.

With SNMPv1/v2c, this same thing was accomplished using community string indexing. This was a hack Cisco developed to workaround the limitations in these early versions of SNMP. Community string indexing worked by appending an '@' followed by the VLAN number to the community string.

Thanks again for the information - you've been a huge help for me since I started the implementation of new equipment at my job to get some of the tougher questions answered. It's very appreciated.

The info for the SNMP that you provided will help alot in the final decision that we make here with what we want to do.

Thanks again,

Jeff

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: