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 maneira:
"Cada interface é identificada por um valor exclusivo do objeto ifIndex, e a descrição de ifIndex restringe seu valor da seguinte maneira: Seu valor varia entre 1 e o valor de ifNumber. O valor de cada interface deve permanecer constante pelo menos de uma reinicialização do sistema de gerenciamento de rede da entidade até a próxima reinicialização."
No entanto, de acordo com o IETF RFC 2863 mais recente (The Interfaces Group MIB), a definição do 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 manter ifNumber com sua definição atual.
Não existem requisitos específicos para este documento.
Para obter informações de suporte mais atualizadas sobre esse recurso por plataformas e imagens do IOS, você pode procurar Interface Index Persistence na Feature Navigator Tool.
O suporte para esse recurso começou a partir do Cisco IOS versão 12.1(5)T nas seguintes plataformas (posteriormente incluídas no Cisco IOS versão 12.2):
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
Série Cisco 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
Série Cisco 7200 (incluindo Cisco 7202, 7204 e 7206)
Série Cisco 7500 (incluindo o Cisco RSP7000)
No Cisco IOS versão 12.0S, o suporte à persistência de índice de interface começou 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 Catalyst 6000 IOS (também chamado de modo nativo) suporta a persistência ifIndex a partir da 12.1(13)E.
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 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á fazendo o polling das 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á fazendo o polling do ifIndex 3, que corresponde à porta serial.
Após a reinicialização do roteador (reinicializar, recarregar 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 a sondar o ifIndex 3, que corresponde agora à porta ethernet. Portanto, se o aplicativo de gerenciamento não for avisado por uma armadilha, por exemplo, de que o roteador foi reinicializado, as estatísticas pesquisadas poderão estar completamente erradas.
A versão do Cisco IOS adiciona suporte para um valor ifIndex que pode persistir nas reinicializações. O recurso Interface Index Persistence permite maior precisão quando coleta e processa dados de gerenciamento de rede identificando exclusivamente interfaces de entrada e saída para fluxos de tráfego e estatísticas SNMP. À medida que relaciona cada interface a uma entidade conhecida (como um cliente do ISP), o recurso Interface Index Persistence permite que os dados de gerenciamento de rede sejam utilizados com mais eficiência.
A persistência de IfIndex significa que o mapeamento entre os valores de objeto ifDescr (ou ifName) e ifIndex gerados a partir do IF-MIB é retido nas reinicializações.
Esse 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 baseada 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 é automaticamente aplicado a todas as subinterfaces associadas a essa interface.
Para verificar se o ifIndex está habilitado 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 de copy running starting, que copia a alocação de 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 | Este é o ifIndex da interface |
enablePersistence | INTEGER32 | 1 se a persistência estiver habilitada |
ifDescr | CADEIA DE CARACTERES DO OCTETO | A descrição da interface |
Você pode copiar o arquivo para um servidor ftp e exibir 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.
Os mesmos ifIndexes são alocados para a nova placa, desde que os ifDescr no novo hardware correspondam 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 que as interfaces Ethernet de quatro portas. As outras quatro portas recebem novos valores ifIndex.
3. Remova uma placa e substitua-a por um tipo de placa diferente.
Quando você instala um novo tipo de placa, como um novo ifDescr, você recebe novos valores ifIndex. O ifIndex anterior não é usado e cria um intervalo 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, portanto, você recebe novos valores ifIndex. O ifIndex anterior não é usado e cria um intervalo na alocação ifIndex.
Observação: você deve executar um comando copy running starting para manter os valores ifIndex recém-atribuídos para os exemplos 2, 3 e 4.