O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Um dos identificadores comumente mais usado nos aplicativos de gerenciamento de rede com base em SNMP é o valor Interface Index (ifIndex). O ifIndex é um número de identificação exclusivo associado a uma interface física ou lógica. Para a maioria dos softwares, o ifIndex é o nome da interface. Embora as RFC relevantes não exijam que a correspondência entre valores específicos do ifIndex e suas interfaces seja mantida através de reinicializações, os aplicativos, como o inventário de dispositivos, faturamento e detecção de falhas, dependem desta correspondência.
O RFC1213 (MIB2) define um ifIndex inicial da seguinte forma:
"Cada interface é identificada por um valor exclusivo do objeto ifIndex e a descrição de ifIndex restringe seu valor da seguinte forma: Seu valor varia entre 1 e o valor de ifNumber. O valor de cada interface deve permanecer constante pelo menos desde uma reinicialização do sistema de gerenciamento de rede da entidade até a próxima reinicialização."
No entanto, de acordo com a mais recente RFC 2863 da IETF (The Interfaces Group MIB), a definição ifIndex foi alterada para acomodar o maior número de dispositivos que permitem a adição ou remoção dinâmica de interfaces de rede. A solução adotada no RFC 2863 é excluir o requisito de que o valor de ifIndex seja menor que o valor de ifNumber e reter ifNumber com sua definição atual.
Não existem requisitos específicos para este documento.
Para obter informações de suporte mais atualizadas para esse recurso pelas plataformas e imagens do IOS, você pode pesquisar por Interface Index Persistence na Feature Navigator Tool.
O suporte para este recurso começou a partir do Cisco IOS versão 12.1(5)T nas seguintes plataformas (mais recente na versão 12.2 do Cisco IOS):
Cisco série 800
Cisco série 1400
Cisco série 1600 (incluindo a série 1600R)
Cisco série 1700
Cisco série 2500
Cisco série 2600
Cisco série 2800
Cisco série 3600 (incluindo Cisco 3620, 3640 e 3660)
Cisco série 3800
Cisco série 4500
Cisco AS5300
Cisco AS5400
Cisco AS5800
Cisco série 7100
Cisco série 7200 (incluindo Cisco 7202, 7204 e 7206)
Cisco série 7500 (incluindo o Cisco RSP7000)
No Cisco IOS versão 12.0S, o suporte à persistência do índice de interface foi iniciado a partir do Cisco IOS versão 12.0(11)S nas seguintes plataformas:
Cisco 7200 Series
Cisco 7500 Series
Família Cisco 12000 GSR
Observação: para dispositivos CatOS, ifIndex persiste automaticamente para interfaces físicas e VLAN, mas não para interfaces EtherChannel. Esse recurso está ativado por padrão e não há como desativá-lo. O software IOS no MSFC não suporta a persistência ifIndex. O IOS do Catalyst 6000 (também chamado de modo nativo) suporta a persistência ifIndex a partir de 12.1(13)E.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Considere uma situação em que um software de monitoramento simples (como MRTG) está pesquisando as estatísticas de interface da interface serial específica do roteador que vai para a Internet.
Por exemplo, você pode ter estas condições antes da reinicialização:
porta física | ifIndex |
---|---|
porta de ethernet | 1 |
porta de tokenring | 2 |
porta serial | 3 |
Portanto, o aplicativo de gerenciamento está pesquisando o ifIndex 3, que corresponde à porta serial.
Após a reinicialização do roteador (reinicialização, recarregamento e assim por diante), as condições mudam para algo semelhante a isto:
porta física | ifIndex |
---|---|
porta de ethernet | 3 |
porta de tokenring | 1 |
porta serial | 2 |
O aplicativo de gerenciamento continua pesquisando o ifIndex 3, que corresponde agora à porta ethernet. Portanto, se o aplicativo de gerenciamento não for avisado por uma armadilha, por exemplo, que o roteador foi reinicializado, as estatísticas pesquisadas poderão estar completamente erradas.
A versão do Cisco IOS adiciona suporte a um valor ifIndex que pode persistir durante as reinicializações. O recurso Interface Index Persistence permite maior precisão quando coleta e processa dados de gerenciamento de rede identificando de forma exclusiva interfaces de entrada e saída para fluxos de tráfego e estatísticas de SNMP. Como ele relaciona cada interface a uma entidade conhecida (como um cliente ISP), o recurso Interface Index Persistence permite que os dados de gerenciamento de rede sejam utilizados com mais eficiência.
A persistência IfIndex significa que o mapeamento entre os valores do objeto ifDescr (ou ifName) e os valores do objeto ifIndex gerados a partir do IF-MIB é mantido durante as reinicializações.
Este recurso é particularmente útil para:
SNMP: monitorando os contadores de interfaces
Netflow: relatório da interface ifIndex
RMON: eventos/alarmes baseados em interfaces específicas
MIB DE EXPRESSÃO/EVENTO: criação de uma nova variável MIB com base em contadores de interface
Router(config)# snmp-server ifindex persist Router(config-if)# snmp-server ifindex persist
Para obter mais detalhes sobre a configuração, consulte SNMP IfIndex Persistence.
O comando de persistência ifIndex específico da interface ([no] snmp ifindex persistence) não pode ser usado em subinterfaces. Um comando aplicado a uma interface é aplicado automaticamente a todas as subinterfaces associadas a essa interface.
Para verificar se ifIndex está ativado corretamente, você pode exibir o conteúdo de ifIndex-table na nvram.
Router # dir nvram:ifIndex-table Directory of nvram:/ifIndex-table 2 -rw- 0 <no date> ifIndex-table 126968 bytes total (114116 bytes free)
Se o comprimento for 0, você omitiu a execução da cópia em execução, que copia a alocação ifIndexes na nvram. Depois de fazer isso, você verá o seguinte:
Router # dir nvram:ifIndex-table Directory of nvram:/ifIndex-table 2 -rw- 283 <no date> ifIndex-table 126968 bytes total (114088 bytes free)
O formato do arquivo é:
Nome | Tipo | Descrição |
tamanho | INTEGER32 | O tamanho desta linha |
ifIndex | INTEGER32 | Esta interface é ifIndex |
enablePersistência | INTEGER32 | 1 se a persistência estiver ativada |
ifDescr | STRING DE OCTETO | A descrição da interface |
Você pode copiar o arquivo para um servidor ftp e visualizar o conteúdo do arquivo binário. Mas não edite esse arquivo: não há suporte para todas as alterações. Em algumas plataformas, o arquivo pode ser mantido em formato compactado.
Esta é uma lista de exemplos de inserção e remoção de placas Ethernet.
1. Remova uma placa e substitua-a pelo mesmo tipo de placa.
O mesmo ifIndexes é alocado para a nova placa, desde que o ifDescr no novo hardware corresponda ao antigo
2. Remova uma placa e substitua-a por quase o mesmo tipo de placa.
Se você substituir uma placa Ethernet de quatro portas por uma placa Ethernet de oito portas, as primeiras quatro portas na placa de oito portas terão os mesmos valores ifIndex das quatro interfaces Ethernet de porta. As outras quatro portas recebem novos valores ifIndex.
3. Remova uma placa e substitua-a por outro tipo de placa.
Ao instalar um novo tipo de placa, como um novo ifDescr, você recebe novos valores ifIndex. O ifIndex anterior não é usado e cria uma lacuna na alocação ifIndex.
4. Remova uma placa e coloque-a em um slot diferente do mesmo roteador.
Quando você coloca uma placa em um slot diferente, há um novo ifDescr, então você recebe novos valores ifIndex. O ifIndex anterior não é usado e cria uma lacuna na alocação ifIndex.
Observação: você deve executar um comando copy running start para persistir nos valores ifIndex recém-atribuídos para os exemplos 2, 3 e 4.