IP : Simple Network Management Protocol (SNMP)

Controle múltiplas instâncias do OSPF com contextos SNMP

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento fornecem configurações de amostra para SNMPv2 e o SNMPv3 que descrevem como usar contextos SNMP para controlar múltiplas instâncias do Open Shortest Path First (OSPF).

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Informações de Apoio

O OSPF MIB definido pelo IETF (RFC 1850leavingcisco.com ) foi projetado trabalhar com somente uns processo de OSPF/exemplo em um roteador dado.

Por exemplo, há somente um único objeto do ospfRouterId, não uma tabela deles. A fim tratar múltiplas instâncias, o RFC 4750leavingcisco.com sugere que você use os contextos SNMPv3 para fornecer opiniões do por-exemplo.

Contexto SNMP ciente

Antes de fazer o contexto do código IO OSPF SNMP ciente, o sistema escolheria o exemplo mais ou menos aleatório do “padrão” quando retornou os objetos escalares e algumas tabelas. Nesses casos, a informação dos outros exemplos não estava disponível através do SNMP. Para algumas outras tabelas, o SNMP trituraria junto as entradas de todos os exemplos sem nenhuma maneira de distinguir qual era qual. Em muitos casos, isto podia conduzir a ambíguo ou às entradas duplicadas. Não era especialmente boa prática nas configurações PE-CE onde os endereços IP de Um ou Mais Servidores Cisco ICM NT e o vizinho roteador-ID não puderam ser originais. Isto fez a monitoração e o Troubleshooting CE individual cita como exemplo difícil ou impossível.

Com o código IOS contexto-ciente atual (quando nenhum contexto é especificado), o comportamento velho para objetos escalares ainda existe. A única mudança é que limita agora tudo um pouco do que apenas algumas das tabelas ao mesmo exemplo OSPF do “padrão” que os scalars. Quando os contextos são fornecidos, as perguntas SNMP podem ser visadas a um exemplo particular OSPF, e toda a informação para esse exemplo pode ser recuperada em uma maneira consistente e inequívoca.

Se o SNMPv3 é usado, a corda do contexto pode ser fornecida diretamente com a votação. O SNMPv2C não fornece um contexto. Contudo, você pode traçar séries de comunidade snmp aos contextos na configuração do IOS, e estes contextos podem ser usados para dirigir as votações SNMPv2 a um exemplo específico OSPF.

Configuração

Este exemplo de configuração é baseado em SNMPv2:

Roteador 1
Router1#
 
router ospf 1
 router-id 1.1.1.111
 log-adjacency-changes
 snmp context context1
!
router ospf 2
 router-id 4.4.4.111
 log-adjacency-changes
 snmp context context2

!--- Associates the SNMP context with the instance.


!
snmp-server user u2 g2 v2c

!--- Configures the user u2 to the SNMP group g2 and


!--- specifies the group is using the SNMPv2c security model.

snmp-server group g2 v2c

!--- Configures the SNMP group g2 and specifies


!--- the group is using the SNMPv2c security model.

snmp-server group g2 v2c context context1
snmp-server group g2 v2c context context2
snmp-server community public RO

!--- Community access string to permit access


!--- to the SNMP.

snmp-server community cx1 RO
snmp-server community cx2 RO
snmp-server context context1
snmp-server context context2
snmp mib community-map cx1 context context1 security-name u2

!--- Associates the SNMP community cx1 with


!--- the context context 1.

snmp mib community-map cx2 context context2 security-name u2

Este exemplo de configuração é baseado no SNMPv3:

Roteador 1
Router1#
 
router ospf 1
 router-id 1.1.1.111
 log-adjacency-changes
 snmp context context1
!
router ospf 2
 router-id 4.4.4.111
 log-adjacency-changes
 snmp context context2
!
snmp-server user u1 g1 v3
snmp-server group g1 v3 noauth
snmp-server group g1 v3 noauth context context1
snmp-server group g1 v3 noauth context context2
snmp-server context context1
snmp-server context context2

Nota: Use a ferramenta Command Lookup Tool (apenas para clientes registrados) para obter mais informações sobre os comandos usados neste documento.

Verificar

Você pode usar o comando snmpwalk em toda a máquina cliente a fim verificar a saída.

Nota: A Output Interpreter Tool (apenas para clientes registrados) (OIT) suporta determinados comandos show. Use a OIT para exibir uma análise da saída do comando show.

Verificação SNMPv2

SNMPv2
linux>snmpwalk -c public -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

linux>snmpwalk -c cx1 -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 1.1.1.111

linux>snmpwalk -c cx2 -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

Verificação SNMPv3

SNMPv3
linux>snmpwalk -u u1 -v3 irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

linux>snmpwalk -u u1 -v3 -n context1 irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 1.1.1.111

linux>snmpwalk -u u1 -v3 -n context2 irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 111869