Configure o SNMP para instâncias de roteamento

O Junos OS permite que os gerentes de SNMP para todas as instâncias de roteamento solicitem e gerenciem dados SNMP relacionados às instâncias de roteamento e redes lógicas do sistema correspondentes.

No Junos OS:

• Clientes de instâncias de roteamento e/ou sistemas lógicos que não sejam o padrão podem acessar objetos MIB e realizar operações de SNMP apenas na instância de roteamento e/ou redes lógicas do sistema a que pertencem.

• Os clientes da instância de roteamento padrão podem acessar informações relacionadas a todas as instâncias de roteamento e redes lógicas de sistema.

• A instância de roteamento de gerenciamento junos () é uma instância especial.mgmt_junos Os clientes da instância de roteamento de gerenciamento são tratados como se estivessem na instância de roteamento padrão e podem acessar informações relacionadas a todas as instâncias de roteamento e redes lógicas de sistema.

Antes da versão 8.4 do Junos OS, apenas o gerente de SNMP na instância de roteamento padrão (inet.0) tinha acesso aos objetos MIB.

Com o aumento das ofertas de serviços de rede privada virtual (VPN), esse recurso é útil especialmente para provedores de serviços que precisam obter dados SNMP para instâncias de roteamento específicas (ver ).Figura 1 Os provedores de serviços podem usar essas informações para suas próprias necessidades de gerenciamento ou exportar os dados para uso por seus clientes.

Figura 1: Dados de SNMP para instâncias de roteamento

Se nenhuma instância de roteamento for especificada na solicitação, o agente SNMP opera como antes:

• Para objetos de tabela sem roteamento, todas as instâncias são expostas.

• Para objetos de tabela de roteamento, apenas aqueles associados à instância de roteamento padrão são expostos.

  Nota:

  As unidades de dados de protocolo (PDUs) reais ainda são trocadas pela instância de roteamento padrão (inet.0), mas o conteúdo dos dados devolvidos é ditado pela instância de roteamento especificada nas PDUs de solicitação.

A partir do Junos OS 19.4R1, você pode acessar informações relacionadas a todas as instâncias de roteamento e redes lógicas de sistema e não específicas para a instância de roteamento de entrada, configurando a interface de gerenciamento SNMPv3 em uma instância de roteamento necessária. Você pode configurar a declaração de configuração de instância de gerenciamento no nível de hierarquia.[edit snmp v3]

• Benefícios
• Habilite a instância de roteamento de gerenciamento
• Remova a instância de roteamento de gerenciamento

Tabela 1 mostra objetos MIB específicos da empresa suportados pelo Junos OS e fornece notas detalhando como eles são tratados quando uma instância de roteamento é especificada em uma solicitação de SNMP. Um en dash (-) indica que o item não é aplicável.

Tabela 2 mostra objetos MIB de classe 1 (MIBs padrão e específicos para empresas) suportados pelo Junos OS. Com objetos de Classe 1, apenas essas interfaces lógicas (e suas interfaces físicas dos pais) que pertencem a uma instância de roteamento específica são expostas.

Tabela 3 mostra objetos MIB de classe 2 (MIBs padrão e específicos para empresas) suportados pelo Junos OS. Com objetos de Classe 2, todas as instâncias de um sistema lógico são expostas. Os dados não serão segregados até o nível de instância de roteamento.

Tabela 4 mostra objetos MIB de classe 3 (MIBs padrão e específicos para empresas) suportados pelo Junos OS. Com a Classe 3, os objetos são expostos apenas para o sistema lógico padrão.

Tabela 5 mostra objetos MIB classe 4 (MIBs padrão e específicos para empresas) com o Junos OS. Com objetos de Classe 4, os dados não são segregados por instância de roteamento. Todas as instâncias são expostas.

Quando uma instância de roteamento é especificada, todos os objetos MIB relacionados ao roteamento retornam dados mantidos pela instância de roteamento na solicitação. Para todos os outros objetos MIB, os dados devolvidos são segregados de acordo com essa instância de roteamento. Por exemplo, apenas essas interfaces atribuídas a essa instância de roteamento (por exemplo, as interfaces lógicas [ifls] bem como suas interfaces físicas correspondentes [ifds]) são expostas pelo agente SNMP. Da mesma forma, objetos com um anexo inequívoco a uma interface (por exemplo, endereços) também são segregados.

Para aqueles objetos em que o anexo é ambíguo (por exemplo, objetos no sysApplMIB), nenhuma segregação é feita e todas as instâncias são visíveis em todos os casos.

Outra categoria de objetos só é visível quando nenhum sistema lógico é especificado (apenas dentro do sistema lógico padrão) independentemente da instância de roteamento dentro do sistema lógico padrão. Objetos nesta categoria são objetos Chassis MIB, objetos no grupo SNMP, alarme RMON, grupos de eventos e log, objetos Ping MIB, objetos de gerenciamento de configuração e objetos V3.

Em resumo, para oferecer suporte a instâncias de roteamento, os objetos MIB se enquadram em uma das seguintes categorias:

• Classe 1 — os dados são segregados de acordo com a instância de roteamento da solicitação. Esta é a mais granular das aulas de segregação.

• Classe 2 — os dados são segregados de acordo com o sistema lógico especificado na solicitação. Os mesmos dados são devolvidos para todas as instâncias de roteamento que pertencem a um sistema lógico específico. Normalmente, isso se aplica a objetos de tabela de roteamento em que é difícil extrair informações de instâncias de roteamento ou onde as instâncias de roteamento não se aplicam.

• Classe 3 — os dados são expostos apenas para o sistema lógico padrão. O mesmo conjunto de dados é devolvido para todas as instâncias de roteamento que pertencem ao sistema lógico padrão. Se você especificar outro sistema lógico (não o padrão), nenhum dados será devolvido. Normalmente, essa classe se aplica a objetos implementados em subagentes que não monitoram mudanças lógicas do sistema e registram seus objetos usando apenas o contexto padrão (por exemplo, objetos Chassis MIB).

• Classe 4 — os dados não são segregados por instância de roteamento. Os mesmos dados são devolvidos para todas as instâncias de roteamento. Normalmente, isso se aplica a objetos implementados em subagentes que monitoram mudanças lógicas do sistema e registram ou desregistram todos os seus objetos para cada mudança lógica do sistema. Objetos cujos valores não podem ser segregados por instância de roteamento caem nesta classe.

Consulte MIBs SNMP com suporte para instâncias de roteamento para uma lista dos objetos associados a cada classe.

Você pode restringir os receptores de armadilha de receber armadilhas que não estão relacionadas com as redes lógicas do sistema a que pertencem. Para fazer isso, inclua a declaração no nível hierárquica :logical-system-trap-filter[edit snmp]

Se a declaração não estiver incluída na configuração SNMP, todas as armadilhas serão encaminhadas para os destinos de instâncias de roteamento configuradas.logical-system-trap-filter No entanto, mesmo quando essa declaração estiver configurada, o receptor de armadilha associado à instância de roteamento padrão receberá todas as armadilhas SNMP.

Quando configuradas sob o objeto do grupo trap, todas as armadilhas v1 e v2c que se aplicam a instâncias de roteamento (ou interfaces pertencentes a uma instância de roteamento) têm o nome da instância de roteamento codificado na cadeia da comunidade. A codificação é idêntica à usada em PDUs de solicitação.

Para armadilhas configuradas sob a estrutura v3, o nome da instância de roteamento é transportado no campo de contexto quando o modelo de processamento de mensagens v3 foi configurado. Para outros modelos de processamento de mensagens (v1 ou v2c), o nome da instância de roteamento não é carregado no cabeçalho de mensagem de armadilha (e não codificado na cadeia da comunidade).

Com esse recurso, as instâncias de roteamento são identificadas pelo campo de contexto em solicitações v3 ou codificadas na string da comunidade em solicitações v1 ou v2c.

Quando codificado em uma string da comunidade, o nome da instância de roteamento aparece primeiro e é separado da cadeia da comunidade real pelo personagem.@

Para evitar conflitos com strings de comunidade válidos que contêm o personagem, a comunidade só é analisada se o processamento típico de strings da comunidade falhar.@ Por exemplo, se uma instância de roteamento nomeada estiver configurada, uma solicitação de SNMP com ela é processada no contexto da instância de roteamento.RIRI@publicRI O controle de acesso (visualizações, restrições de endereços de origem, privilégios de acesso e assim por diante) é aplicado de acordo com a cadeia da comunidade real (o conjunto de dados após o caractere — neste caso ).@public No entanto, se a cadeia da comunidade estiver configurada, a unidade de dados de protocolo (PDU) é processada de acordo com essa comunidade e o nome da instância de roteamento incorporado é ignorado.RI@public

Os sistemas lógicos executam um subconjunto das ações de um roteador físico e têm suas próprias tabelas de roteamento exclusivas, interfaces, políticas e instâncias de roteamento. Quando uma instância de roteamento é definida dentro de um sistema lógico, o nome do sistema lógico deve ser codificado junto com a instância de roteamento usando uma barra ( ) para separar os dois./ Por exemplo, se a instância de roteamento estiver configurada dentro do sistema lógico, essa instância de roteamento deve ser codificada dentro de uma string da comunidade como .RILSLS/RI@public Quando uma instância de roteamento é configurada fora de um sistema lógico (dentro do sistema lógico padrão), nenhum nome de sistema lógico (ou caractere) é necessário./

Além disso, quando um sistema lógico é criado, uma instância de roteamento padrão (nomeada ) é sempre criada dentro do sistema lógico.default Esse nome deve ser usado na consulta de dados para aquela instância de roteamento (por exemplo ).LS/default@public Para solicitações v3, o nome deve ser identificado diretamente no campo de contexto.logical system/routing instance

Este exemplo mostra uma configuração de interface ae0 802.3ad alocada para uma instância de roteamento chamada INFrtd:

O comando a seguir mostra como recuperar informações relacionadas ao SNMP do roteador1 e da interface do pacote 802.3ae pertencente à instância de roteamento INFrtd com a comunidade SNMP:snmpwalkpublic