Further to Cory’s recent struggles to manage 6855 switch nodes via SAM, I started working on integrating our many 6855 nodes into a generic SNMP manager. In our case, we use SolarWinds to poll the nodes and generate alerts based on loss of connectivity, high ping latencies, or ports changing status (uplink ports). 
I started to review the steps Cory identified in his SAM posting earlier, but couldn’t make the switches respond. It was only then that we realized that the nodes would respond on the /30 router interface on the WAN link, and not on the LAN-side router. An email to Alcatel-Enterprise TAC brought forward the solution – 685X switches will only respond to SNMP polls on their primary interface (which I’m guessing is the first interface configured on the units). So, if you setup the WAN connection first, you need to be aware which interface will respond.
Next I wanted to ensure that we were polling the units using SNMP v2 and not v1 – this requires some config work on the 685X nodes to make them pollable. These steps are detailed next:
685X-CLI> aaa authentication snmp “local” – this ensures authentication checks are done against the local user database.
685X-CLI> snmp authentication trap enable – send in a trap when snmp authentication fails.
685X-CLI> snmp source ip preferred [xxx.xxx.xxx.xxx] – IP address of your preferred IP router interface. [In our case I selected the LAN-side IP router as if this works then I already know the WAN side is OK implicitly.]
685X-CLI> snmp security no security – ensure the switch will respond to snmp v2 requests.
685X-CLI> user [private] password [makeone] read-write snmp no auth – creates a new user and gives snmp privileges.
685X-CLI> user [private] password [makeone] read-write all – ensures this user account has access to all snmp rights. [This is important - miss this step and you won't be able to poll using this account.]
685X-CLI> snmp community map private user [private] on
685X-CLI> snmp station X.X.X.X 162 [private] v2 enable (where X.X.X.X is your snmp polling server IP)
685X-CLI> show user private (it should look like this)
User name = private,
Password expiration = None,
Password allow to be modified date = None,
Account lockout = None,
Password bad attempts = 0,
Read Only for domains = None,
Read/Write for domains = All , [***Make sure this reads 'All' and not 'snmp' - as it won't work with 'snmp'***]
Snmp allowed = YES,
Snmp authentication = NONE,
Snmp encryption = NONE
685X-CLI> trap 1 port link enable – this step can be added but isn’t necessary. This will have the 685X switch send a trap if any port on the switch changes state. [This can bombard you with traps if the switch is changing frequently.]
Save your work
685X-CLI> write memory
685X-CLI> copy working certified
685X-CLI> write terminal (to view working configuration)
*** 685X is now ready to be polled by SNMP v2 ***
Configuring the SNMP polling engine, the poller needs to be obviously set for SNMP v2c and the private user name entered as the base community string and read/write community string. Port 161 is used for SNMP polling and also needs to be verified open if there are firewalls in-between the poller and the remote host.
In our case, we also used a shareware utility called “Getif” to test out polling access and to verify that the config was indeed working. You can read more about it here. It’s a useful utility and has many more features than we were using in this configuration.
One last thing:
685X-CLI> show snmp community map – this will show what user accounts are mapped to which community names. You need to verify that the user account created in the steps above is mapped to the private snmp community string.
Hopefully this will get your nodes up and pollable via SNMP. More info to follow when we attempt to convert to SNMP v3.
Clint – Nov 4, 2009
