Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SNMP v2c to v3 conversion #25

Closed
jamie4361 opened this issue Sep 18, 2018 · 7 comments
Closed

SNMP v2c to v3 conversion #25

jamie4361 opened this issue Sep 18, 2018 · 7 comments

Comments

@jamie4361
Copy link

Hi there,
I have an SNMP Manager that supports only v2c, and now I have to manage multiple devices that only support v3. Would it be possible for you to post an example configuration showing how to do this using SNMP Forwarder?
@etingof
Copy link
Owner

etingof commented Sep 18, 2018

I can do that of course. Meanwhile, if you take the reverse example comfiguration and flip SNMP config between client and server files, that should suffice.

This part goes from client to server:

  snmp-community-name: public
  snmp-security-name: public
  snmp-security-model: 2
  snmp-security-level: 1

This part goes from server to client:


  snmp-security-model: 3
  snmp-security-level: 3

  snmp-security-name: test-user
  snmp-usm-user: test-user
  snmp-usm-auth-protocol: md5
  snmp-usm-auth-key: authkey1
  snmp-usm-priv-protocol: des
  snmp-usm-priv-key: privkey1

I may overlook some details, but may be not. ;-)

@jamie4361
Copy link
Author

jamie4361 commented Sep 18, 2018 via email

@etingof
Copy link
Owner

etingof commented Sep 18, 2018

Here is SNMPv2c -> SNMPv3 proxy example configuration.

Hope this helps.

@jamie4361
Copy link
Author

jamie4361 commented Sep 19, 2018 via email

@jamie4361
Copy link
Author

jamie4361 commented Sep 20, 2018 via email

@etingof
Copy link
Owner

etingof commented Sep 20, 2018 •
edited
Loading

There are multiple ways to do that mostly depending on how do you want to represent each of the v3 agents at the snmpfwd server side. Choices include:

  • Based on server transport endpoint (dedicated address/port at v2c agent per v3 agent)
  • Based on distinct SNMPv2c community names
  • Based on v2c client source transport endpoint
  • Based on something matching in the request var-binds

For the first two approaches you would need (as you say) distinct transport or community settings bound to snmp-credentials-id: key e.g.

snmp-credentials-group {
  snmp-engine-id: 0x0102030405070809

  snmp-transport-domain: 1.3.6.1.6.1.1.100
  snmp-bind-address: 127.0.0.1:1161

  snmp-security-model: 2
  snmp-security-level: 1

  # block names never matter, what matters is the scoping and the IDs
  agent-1 { 
    snmp-community-name: public
    snmp-security-name: public

    snmp-credentials-id: snmp-credentials-1
  }

  agent-2 { 
    snmp-community-name: cilbup
    snmp-security-name: cilbup

    snmp-credentials-id: snmp-credentials-2
  }
}

Similarly for snmp-bind-address.

Then you need to route those distinct snmp-credentials-id to your client similarly to how it's done for a single entry.

On the client side you need to define blocks for each of your v3 agents with distinct snmp-peer-id IDs.

You could use a single snmp-engine-id or many of them - this should not matter unless your v3 agents care about that (what's unlikely).

The crucial part at the client side is to route the queries coming from server to client towards proper v3 agent. You can do that by either:

  • Matching v1 manager parameters as seen by the server (see orig-snmp-peer-id key)
  • Matching configuration IDs chosen by the server when serving the v1 manager (see server-classification-id key)

Here is the example configuration I am referring to here.

There is also some documentation on these settings.

Does it make sense?

If your v3 agents sit on different/distant networks, the other option could be that you have one snmpfwd-client peering with many snmpfwd-servers over TCP/IP links what should work a bit more reliably perhaps. With that layout you would probably have to route v2c messages at the snmpfwd-server side over trunks based on similar conditions. Your snmpfwd-client configuration would be very straightforward then.

@jamie4361
Copy link
Author

jamie4361 commented Sep 20, 2018 via email

@etingof etingof closed this as completed Oct 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jamie4361 @etingof