Erro de acesso imprevisível ao Juniper SNMPv3

8

Estamos com problemas em que o SNMPv3 deixa de aceitar solicitações de SNMP em nossos comutadores da série Juniper EX. No que parece ocorrências aleatórias, os nós do Juniper recusam as credenciais de autenticação SNMP.

É isso que acabamos recebendo:

rj@MHN00525SYS01:~$ snmpwalk -v 3 -a SHA -A "PASS" -l authPriv -x AES -X "PASS" 
  -u "username" mhn00416an01 iso.3.6.1.2.1.1.1.0
snmpwalk: Unknown user name
rj@MHN00525SYS01:~$

Nossos dispositivos estavam funcionando, mas depois paramos. Os nomes de usuário estão corretos e carregados no sistema.

rj@MHN00416AN01# run show snmp v3 users

Engine ID: 80 00 0a 4c 04 31 33 <...snip...>
    User                            Auth/Priv   Storage      Status
    username                         sha/aes128 nonvolatile  active

Depois de lidar com isso por algum tempo, finalmente decidimos investigar. Estou vendo esta entrada antes que o sistema pare de aceitar solicitações:

Nov  6 09:44:32  MHN00416AN01 mgd[7996]: UI_COMMIT: User 'rj' requested 'commit' 
  operation (comment: none)
Nov  6 09:44:35  MHN00416AN01 snmpd[1260]: LIBJSNMP_NS_LOG_ERR: ERR: snmpd: send_trap: USM 
  unknown security name (no such user exists) (plaintext scopedPDU header type 00: s/b 30)
Nov  6 09:44:35  MHN00416AN01 snmpd[1260]: SNMPD_ENGINE_ID_CHANGED: Warning: Local 
  engine ID has changed. Passwords for all the users under [edit snmp v3 usm local-engine] 
  need to be reconfigured.

Descobri que simplesmente reinserir o nome de usuário / senhas restaura o acesso ao dispositivo.

rj@MHN00416AN01# set snmp v3 usm local-engine user username 
  authentication-sha authentication-password PASS

{master:0}[edit]
rj@MHN00416AN01# set snmp v3 usm local-engine user username 
  privacy-aes128 privacy-password PASS

Após uma commitoperação, podemos acessá-lo novamente.

rj@MHN00525SYS01:~$ snmpwalk -v 3 -a SHA -A "PASS" -l authPriv -x AES -X "PASS" 
  -u "username" mhn00416an01 iso.3.6.1.2.1.1.1.0
iso.3.6.1.2.1.1.1.0 = STRING: "Juniper Networks, Inc. ex3300-48p Ethernet Switch, kernel 
  JUNOS 12.3R3.4, Build date: 2013-06-14 02:21:01 UTC Copyright (c) 1996-2013 Juniper 
  Networks, Inc."
rj@MHN00525SYS01:~$

Esse problema está ocorrendo em vários dispositivos diferentes. Os modelos incluem EX2200-c, EX3300, EX4200 e EX4550 na versão 12.3.

Por que isso está acontecendo e como posso parar?

Ryan Foley
fonte

Respostas:

6

Esse problema é resultado da alteração do ID do mecanismo. Se você se deparar com essa mensagem syslog, essa é a definição exata do problema.

Nov  6 09:44:35  MHN00416AN01 snmpd[1260]: SNMPD_ENGINE_ID_CHANGED: Warning: Local 
  engine ID has changed. Passwords for all the users under [edit snmp v3 usm local-engine] 
  need to be reconfigured.

Infelizmente, descobri que isso está acontecendo sem motivo aparente. A confirmação executada antes da alteração do ID do mecanismo foi uma syslog-hostadição simples que resultou na alteração do ID do mecanismo. O Juniper cobre a engine-idopção em sua TechLibrary , que diz que a opção padrão é usar o endereço IP padrão do dispositivo.

Depois de muito bater de cabeça na mesa, descobrimos que simplesmente definir um com uma configuração explícita é a melhor opção, pois permanece consistente.

rj@MHN00416AN01# set snmp engine-id local ***.**.244.245

{master:0}[edit]
rj@MHN00416AN01# commit
configuration check succeeds
commit complete

O Juniper também tem uma nota para alterar o ID do mecanismo que precisa ser feito antes de funcionar. Efetivamente significa que, depois de confirmar um novo ID de mecanismo, você também deve confirmar outro nome de usuário / senha.

Nota: As chaves de autenticação e criptografia SNMPv3 são geradas com base nas senhas associadas e no ID do mecanismo. Se você configurar ou alterar o ID do mecanismo, deverá confirmar o novo ID do mecanismo antes de configurar os usuários SNMPv3. Caso contrário, as chaves geradas a partir das senhas configuradas serão baseadas no ID do mecanismo anterior. Para o ID do mecanismo, recomendamos o uso do endereço MAC da porta de gerenciamento.

Você precisará confirmar novos usuários na configuração após a alteração do mecanismo. Isso é importante porque os usuários SNMPv3 não funcionarão se você não fizer isso, apesar do que é realmente dito no show snmp v3 users. Portanto, certifique-se de definir novos usuários.

rj@MHN00416AN01# set snmp v3 usm local-engine user username 
  authentication-sha authentication-password PASS

{master:0}[edit]
rj@MHN00416AN01# set snmp v3 usm local-engine user username 
  privacy-aes128 privacy-password PASS

{master:0}[edit]
rj@MHN00416AN01# commit
configuration check succeeds
commit complete

Antes da mudança:

rj@MHN00416AN01# run show snmp v3

Local engine ID: 80 00 0a 4c 01 ** ** f4 f5
Engine boots:           1
Engine time:       421043 seconds
Max msg size:       65507 bytes

Engine ID: 80 00 0a 4c 04 31 33 <...snip...>
    User                            Auth/Priv   Storage      Status
    Username                         sha/aes128 nonvolatile  active

Após a alteração:

Local engine ID: 80 00 0a 4c 04 31 33 <...snip...>   <---- previously Engine ID
Engine boots:           1
Engine time:       421110 seconds
Max msg size:       65507 bytes

Engine ID: local   <------ changed
    User                            Auth/Priv   Storage      Status
    Username                         sha/aes128 nonvolatile  active

Isso fornece uma configuração SNMP mais confiável, que não é propensa a alterações no ID do mecanismo e a eliminação do acesso. A Juniper recomenda que você use a use-mac-addressopção em oposição à local engine-id-suffix. Essa opção é suscetível a problemas em uma configuração de chassi virtual. Se um mecanismo de roteamento de backup assumir o controle, o ID do mecanismo SNMP mudará para a me0interface do novo mestre.

Ryan Foley
fonte