Este documento descreve como verificar as operações de rastreamento de dispositivo IP (IPDT) e algumas ações de solução de problemas.
Não existem requisitos específicos para este documento.
As saídas neste documento foram baseadas nestas versões de software e hardware:
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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
A principal tarefa do IPDT é rastrear os hosts conectados (associação de endereços MAC e IP). Para fazer isso, ele envia sondas de Protocolo de Resolução de Endereço (ARP) unicast com um intervalo padrão de 30 segundos. Esses testadores são enviados ao endereço MAC do host conectado no outro lado do link e usam a camada 2 (L2) como origem padrão. Isso permite o endereço MAC da interface física a partir da qual o ARP vai e um endereço IP do remetente de 0.0.0.0, com base na definição de prova ARP listada no RFC 5227.
Note: O IPDT foi preterido em favor do Rastreamento de dispositivo baseado em SISF (Switch Integrated Security Features). O SISF fornece rastreamento de IP avançado e suporta IPv4 e IPv6.
Começando com o Cisco IOS® XE Denali 16.1.1, os comandos existentes de rastreamento de dispositivo IPv6 e de rastreamento de dispositivo IP (IPDT) têm comandos de rastreamento de dispositivo baseados em SISF correspondentes que permitem aplicar sua configuração às famílias de endereços IPv4 e IPv6.
Este documento é preservado para referência pois pertence à funcionalidade de rastreamento de dispositivo IP (IPDT) herdada. As implantações atuais podem usar o rastreamento de dispositivo baseado em SISF, que substitui o IPDT nas plataformas Cisco IOS-XE modernas. Para obter orientação adicional sobre solução de problemas de SISF, consulte Solução de Problemas de SISF nos Catalyst 9000 Series Switches.
Neste documento, o termo Prova ARP é usado para se referir a um pacote de Solicitação ARP, transmitido no link local, com um endereço IP de remetente totalmente zero. O endereço de hardware do remetente DEVE conter o endereço de hardware da interface que envia o pacote. O campo de endereço IP do remetente DEVE ser definido como zero para evitar que o ARP seja corrompido por caches em outros hosts, no mesmo link, caso o endereço já esteja em uso por outro host. O campo de endereço IP de destino DEVE ser definido como o endereço que é testado. Uma Prova ARP transmite tanto uma pergunta (Alguém usa este endereço?) quanto uma instrução implícita (Este é o endereço que você espera usar.)
A finalidade do IPDT é que o switch obtenha e mantenha uma lista de dispositivos conectados ao switch por meio de um endereço IP. A sonda não preenche a entrada de rastreamento; é simplesmente usado para manter a entrada na tabela depois de ser aprendida através de uma solicitação/resposta ARP do host.
A Inspeção ARP IP é ativada automaticamente quando o IPDT é ativado. Ele detecta a presença de novos hosts quando monitora pacotes ARP. Se a inspeção ARP dinâmica estiver habilitada, somente os pacotes ARP que ela valida serão usados para detectar novos hosts para a tabela Rastreamento de dispositivo.
O rastreamento de DHCP IP, se habilitado, detecta a presença ou a remoção de novos hosts quando o DHCP designa ou revoga seus endereços IP. Quando o tráfego DHCP é visto para um determinado host, o temporizador de intervalo de prova ARP IPDT é reinicializado.
O IPDT é um recurso que sempre esteve disponível, no entanto, em versões mais recentes do Cisco IOS®, suas interdependências são habilitadas por padrão (consulte o bug da Cisco ID CSCuj04986). Ele pode ser extremamente útil quando seu banco de dados de associações de hosts IP/MAC é usado para preencher o IP de origem de ACLs (Access Control Lists, listas de controle de acesso) dinâmicas ou para manter uma ligação de um endereço IP a uma tag de grupo de segurança.
A prova ARP é enviada sob duas circunstâncias:
A prova de keepalive enviada pelo switch é uma verificação L2. Como tal, do ponto de vista do switch, os endereços IP usados como origem nos ARPs não são importantes: esse recurso pode ser usado em dispositivos sem um endereço IP configurado, portanto a origem IP de 0.0.0.0 não é relevante.
Quando o host recebe essas mensagens, ele responde e preenche o campo IP de destino com o único endereço IP disponível no pacote recebido, que é seu próprio endereço IP. Isso pode causar alertas falsos de endereço IP duplicado, pois o host que responde vê seu próprio endereço IP como origem e destino do pacote; consulte o artigo Troubleshooting "Duplicate IP Address 0.0.0.0" Error Messages para obter mais informações sobre cenários de endereços IP duplicados.
A configuração global ativada/desativada para IPDT é um comportamento herdado que causou problemas no campo, pois os clientes nem sempre sabiam que devem ativar o IPDT para que determinados recursos funcionem. Nas versões atuais, o IPDT é controlado exclusivamente no nível da interface quando ativa um recurso que exige IPDT.
O IPDT está ativado globalmente por padrão nessas versões; ou seja, nenhum comando de configuração global:
É importante observar que, mesmo que o IPDT esteja ativado globalmente, isso não implica necessariamente que ele monitore ativamente uma determinada porta.
Nas versões em que o IPDT está sempre ativo e em que o IPDT pode ser globalmente desligado/ligado quando o IPDT está ativado globalmente, outros recursos determinam se ele está ativo em uma interface específica (consulte a seção Áreas de funcionalidade).
O IPDT e seus testadores ARP enviados de uma determinada interface são usados para estes recursos:
| Platform |
Recurso |
Padrão ativado (Iniciar em) |
Desabilitar método |
Desabilitar CLI |
| Cat 2960/3750 (Cisco IOS) |
IPDT |
15.2(1)E * |
CLI global (versões mais antigas) * por interface |
No ip device tracking * (Sem rastreamento de dispositivo IP) Máximo de rastreamento de dispositivo IP 0 *** |
| Cat 2960/3750 (Cisco IOS) |
NMSP |
No |
CLI global ou CLI por interface |
Nenhum NMSP habilitado **** de supressão de anexo NMSP |
| Cat 2960/3750 (Cisco IOS) |
Sensor de dispositivo |
15.0(1)SE |
CLI global |
Sem monitoramento automático de macro |
| Cat 2960/3750 (Cisco IOS) |
Rastreamento ARP |
15.2(1)E ** |
N/A |
N/A |
| CAT 3850 |
IPDT |
Todas as versões * |
Por interface * |
IP device-tracking maximum 0 *** |
| CAT 3850 |
NMSP |
Todas as versões |
Por interface |
supressão de anexo NMSP |
| CAT 3850 |
Sensor de dispositivo |
No |
N/A |
N/A |
| CAT 3850 |
Rastreamento ARP |
Todas as versões ** |
N/A |
N/A |
| CAT 4500 |
IPDT |
15.2(1)E / 3.5.0E * |
CLI global (versões mais antigas) * por interface |
Sem rastreamento de dispositivo IP * IP device-tracking maximum 0 *** |
| CAT 4500 |
NMSP |
No |
CLI global ou CLI por interface |
Nenhum NMSP habilitado **** de supressão de anexo NMSP |
| CAT 4500 |
Sensor de dispositivo |
15.1(1)SG/3.3.0SG |
CLI global |
Sem monitoramento automático de macro |
| CAT 4500 |
Rastreamento ARP |
** 15.2(1)E / 3.5.0E |
N/A |
N/A |
Nas versões em que o IPDT não está ativado por padrão, ele pode ser desativado globalmente executando-se este comando:
Switch(config)#no ip device tracking
Nas versões em que o IPDT está sempre ativo, a execução do comando anterior não está disponível ou não permite desativar o IPDT (ID de bug Cisco CSCuj04986). Nesse caso, há várias maneiras de garantir que o IPDT não monitore uma porta específica ou não gere alertas IP duplicados.
Esse comando não permite que um switch envie uma sonda por 10 segundos quando detecta um link UP/flap, o que minimiza a possibilidade de que a sonda seja enviada enquanto o host no outro lado do link verifica se há endereços IP duplicados. O RFC especifica uma janela de 10 segundos para detecção de endereço duplicado. Se você atrasar a sonda de controle do dispositivo, o problema poderá ser resolvido na maioria dos casos.
Se o switch enviar uma Prova ARP para o cliente enquanto o host (por exemplo, um PC com Microsoft Windows) estiver em sua fase de Detecção de Endereço Duplicado, o host detectará a prova como um endereço IP duplicado e apresentará ao usuário uma mensagem de que um endereço IP duplicado foi encontrado na rede. Se o PC não obtiver um endereço e o usuário tiver que liberar/renovar manualmente o endereço; desconecte e reconecte à rede ou reinicialize o PC para obter acesso à rede.
Além do retardo de sonda, o retardo também é redefinido quando o switch detecta uma sonda do PC/host. Por exemplo, se o temporizador da sonda for contado em cinco segundos e detectar uma Sonda ARP do PC/host, o temporizador será redefinido para 10 segundos.
Essa configuração foi disponibilizada através da ID de bug da Cisco CSCtn27420.
Com esse comando, você pode configurar o switch para enviar um Probe ARP não compatível com RFC; a origem do IP não é 0.0.0.0, mas é a interface virtual do switch (SVI) na VLAN onde o host reside. As máquinas Microsoft Windows não veem mais a sonda como uma sonda conforme definido pelo RFC 5227 e não a sinaliza como possível IP duplicado.
Para clientes que não têm dispositivos finais previsíveis/controláveis ou para aqueles que têm muitos switches em uma função apenas de L2, a configuração de um SVI, que introduz uma variável de Camada 3 no projeto, não é uma solução adequada. Um aprimoramento introduzido na versão 15.2(2)E e posterior, a possibilidade de permitir a atribuição arbitrária de um endereço IP não precisa pertencer ao switch para uso como o endereço origem em testes ARP gerados por IPDT. Este aprimoramento introduz a chance de modificar o comportamento automático do sistema destas maneiras (esta lista mostra como o sistema se comporta automaticamente após cada comando ser usado):
Como exemplo dos cálculos anteriores, suponha que você sonde o host 192.168.1.200, com a máscara e os bits de host fornecidos, você gere um endereço de origem de 192.168.1.1. Se você sondar a entrada 10.5.5.20, você pode gerar um teste ARP com o endereço de origem 10.5.5.1 e assim por diante.
Esse comando não desabilita verdadeiramente o IPDT, no entanto, limita o número de hosts rastreados a zero. Essa não é uma solução recomendada e deve ser usada com cuidado, pois afeta todos os outros recursos que dependem do IPDT, o que inclui as configurações de canais de porta descritas no bug da Cisco ID CSCun81556.
Alguns recursos que podem acionar o IPDT incluem NMSP, sensor de dispositivos, dot1x/MAB, WebAuth e IPSG. Não é recomendável habilitar esses recursos em portas de tronco. Essa solução é reservada para as situações mais difíceis ou complexas, em que nem todas as soluções disponíveis anteriormente funcionavam conforme o esperado ou criavam problemas adicionais. Esta é, no entanto, a única solução que permite extrema granularidade quando você desabilita o IPDT, porque você pode desativar apenas os recursos relacionados ao IPDT que causam problemas e deixar tudo o resto não afetado.
No Cisco IOS mais recente, Versões 15.2(2)E e posteriores, você vê uma saída semelhante a esta:
Switch#show ip device tracking interface GigabitEthernet 1/0/9
--------------------------------------------
Interface GigabitEthernet1/0/9 is: STAND ALONE
IP Device Tracking = Disabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 180000
IPv6 Device Tracking Client Registered Handle: 75
IP Device Tracking Enabled Features:
HOST_TRACK_CLIENT_ATTACHMENT
HOST_TRACK_CLIENT_SM
As duas linhas em todas as letras maiúsculas na parte inferior da saída são aquelas que usam IPDT para funcionar. A maioria dos problemas criados quando você desabilita o rastreamento de dispositivo pode ser evitada se você desabilitar os serviços únicos executados na interface.
Em versões anteriores do Cisco IOS, a maneira fácil de saber quais módulos estão ativados em uma interface ainda não está disponível, portanto, você deve passar por um processo mais envolvido para obter os mesmos resultados. Você deve ativar o comando debug ip device track interface, que é um log de baixa frequência que deve ser seguro na maioria das configurações. Tome cuidado para não ativar o debug ip device tracking all porque, ao contrário, ele inunda o console em situações dimensionadas.
Quando a depuração estiver ativada, coloque uma interface de volta ao padrão e, em seguida, adicione e remova um serviço IPDT da configuração da interface. Os resultados das depurações informam qual serviço foi ativado/desativado com o comando usado.
Switch(config)#interface GigabitEthernet 1/0/9
Switch(config-if)#ip device tracking maximum 10
Switch(config-if)#
*Mar 27 09:58:49.470: sw_host_track-interface:Feature 00000008 enabled on port Gi1/0/9, mask now 0000004C, 65 ports enabled
*Mar 27 09:58:49.471: sw_host_track-interface:Gi1/0/9[L2 DOWN, IPHOST DIS]IP host tracking max set to 10
Switch(config-if)#
O que a saída revela é que você ativou o recurso 00000008 e que a nova máscara de recurso é 0000004C.
Agora, remova a configuração que acabou de adicionar:
Switch(config-if)#no ip device tracking maximum 10
Switch(config-if)#
*Mar 27 10:02:31.154: sw_host_track-interface:Feature 00000008 disabled on port
Gi1/0/9, mask now 00000044, 65 ports enabled
*Mar 27 10:02:31.154: sw_host_track-interface:Gi1/0/9[L2 DOWN, IPHOST DIS]IP
host tracking max cleared
*Mar 27 10:02:31.154: sw_host_track-interface:Max limit has been removed from
the interface GigabitEthernet1/0/9.
Switch(config-if)#
Depois de remover a 00000008 de recurso, você verá a máscara 00000044, que deve ter sido a máscara padrão original. O valor de 00000044 é esperado, já que o AIM é 0x00000004 e o SM é 0x00000040, o que, em conjunto, resulta em 0x00000044.
Há vários serviços IPDT que podem ser executados sob uma interface:
| Serviço IPT |
Interface |
| HOST_TRACK_CLIENT_IP_ADMISSIONS |
= 0x00000001 |
| HOST_TRACK_CLIENT_DOT1X |
= 0x00000002 |
| HOST_TRACK_CLIENT_ATTACHMENT |
= 0x00000004 |
| HOST_TRACK_CLIENT_TRACK_HOST_UPTO_MAX |
= 0x00000008 |
| HOST_TRACK_CLIENT_RSVP |
= 0x00000010 |
| HOST_TRACK_CLIENT_CTS |
= 0x00000020 |
| HOST_TRACK_CLIENT_SM |
= 0x00000040 |
| HOST_TRACK_CLIENT_WIRELESS |
= 0x00000080 |
No exemplo, HOST_TRACK_CLIENT_SM (SESSION-MANAGER) e HOST_TRACK_CLIENT_ATTACHMENT (também conhecido como AIM/NMSP), os módulos são configurados para IPDT. Para desativar o IPDT nesta interface, você deve desativar ambos porque o IPDT está desativado SOMENTE quando todas as funções que o utilizam também estão desativadas.
Depois de desativar esses recursos, você terá uma saída semelhante a esta:
Switch(config-if)#do show ip device tracking interface GigabitEthernet 1/0/9
--------------------------------------------
Interface GigabitEthernet1/0/9 is: STAND ALONE
IP Device Tracking = Disabled ß IPDT is disabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 180000
IP Device Tracking Enabled Features:
ß No active features
--------------------------------------------
Dessa forma, o IPDT é desativado com mais granularidade.
Aqui estão alguns exemplos de comandos usados para desativar algumas das funções discutidas anteriormente:
Execute estes comandos para verificar o status do IPDT em seu dispositivo:
| Revisão | Data de publicação | Comentários |
|---|---|---|
5.0 |
07-Jul-2026
|
Alertas atualizados de ortografia, gramática, espaçamento e CCW. |
4.0 |
04-Dec-2025
|
Tradução automática e SEO atualizados. |
3.0 |
19-Dec-2024
|
Formatação atualizada. |
2.0 |
21-Aug-2023
|
SEO atualizado, requisitos de estilo e formatação. |
1.0 |
25-Nov-2014
|
Versão inicial |