Configurar SNMP para instâncias de roteamento

O Junos OS permite que os gerenciadores SNMP de 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:

• Os clientes de instâncias de roteamento e/ou sistemas lógicos diferentes do padrão podem acessar objetos MIB e executar operações SNMP somente na instância de roteamento e/ou nas redes lógicas do sistema às quais 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 do sistema.

• A instância de roteamento de gerenciamento do Junos (mgmt_junos) é uma instância especial. 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 do sistema.

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 (consulte a 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 SNMP para instâncias de roteamento

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

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

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

  Observação:

  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 de dados retornado é ditado pela instância de roteamento especificada nas PDUs de solicitação.

Você pode acessar informações relacionadas a todas as instâncias de roteamento e redes lógicas do sistema e não específicas à 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 da instância de gerenciamento no nível da [edit snmp v3] hierarquia.

• Benefícios
• Habilitar a instância de roteamento de gerenciamento
• Remover a instância de roteamento de gerenciamento

A 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 SNMP. Um travessão (–) indica que o item não é aplicável.

A Tabela 2 mostra os objetos MIB de Classe 1 (MIBs padrão e específicos da empresa) suportados pelo Junos OS. Com objetos de Classe 1, somente as interfaces lógicas (e suas interfaces físicas pai) que pertencem a uma instância de roteamento específica são expostas.

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

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

A Tabela 5 mostra objetos MIB de Classe 4 (MIBs padrão e específicos da empresa) suportados pelo 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 retornados são segregados de acordo com essa instância de roteamento. Por exemplo, apenas as 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 os objetos em que o anexo é ambíguo (por exemplo, objetos em sysApplMIB), nenhuma segregação é feita e todas as instâncias são visíveis em todos os casos.

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

Em resumo, para dar 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 na solicitação. Esta é a mais granular das classes 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 retornados 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 da instância de roteamento ou em que 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 é retornado 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 dado será retornado. Normalmente, essa classe se aplica a objetos implementados em subagentes que não monitoram alterações lógicas do sistema e registram seus objetos usando apenas o contexto padrão (por exemplo, objetos MIB do Chassi).

• Classe 4 — Os dados não são segregados por instância de roteamento. Os mesmos dados são retornados para todas as instâncias de roteamento. Normalmente, isso se aplica a objetos implementados em subagentes que monitoram alterações lógicas do sistema e registram ou cancelam o registro de todos os seus objetos para cada alteração lógica do sistema. Os objetos cujos valores não podem ser segregados pela instância de roteamento se enquadram nessa classe.

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

Você pode impedir que os receptores de trap recebam traps que não estejam relacionados às redes do sistema lógico às quais eles pertencem. Para fazer isso, inclua a logical-system-trap-filter instrução no nível da [edit snmp] hierarquia:

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

Quando configuradas no objeto trap-group, 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 string da comunidade. A codificação é idêntica à usada em PDUs de solicitação.

Para armadilhas configuradas na 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 é transportado no cabeçalho da mensagem de interceptação (e não é codificado na cadeia de caracteres da comunidade).

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

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

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

Os sistemas lógicos executam um subconjunto das ações de um roteador físico e têm suas próprias tabelas de roteamento, interfaces, políticas e instâncias de roteamento exclusivas. Quando uma instância de roteamento é definida em 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 RI de roteamento estiver configurada no sistema LSlógico , essa instância de roteamento deverá ser codificada em uma string de comunidade como LS/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 (chamada default) é sempre criada dentro do sistema lógico. Esse nome deve ser usado ao consultar dados para essa instância de roteamento (por exemplo, LS/default@public). Para solicitações v3, o nome logical system/routing instance deve ser identificado diretamente no campo de contexto .

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

O comando a seguir snmpwalk 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 publicSNMP:

Este exemplo mostra a configuração de uma instância InBandManagement de roteamento para uma comunidade myCommunity1.

A instância de roteamento é restrita a uma interface et-0/0/16. Os clientes restritos são configurados como SNMPClients nas opções de política.

O comando a seguir snmpwalk mostra como enviar a solicitação SNMP do cliente configurado para a interface et-0/0/16 como routinginstance@community: