Verifica delle operazioni dei dispositivi IPDT
Sommario
Introduzione
In questo documento viene descritto come verificare le operazioni IPDT (IP Device Tracking) e alcune azioni per la risoluzione dei problemi.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Gli output di questo documento si basano sulle seguenti versioni software e hardware:
- Cisco WS-C2960X
- Cisco IOS® 15.2
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Panoramica di IPDT
Definizione e utilizzo
L'attività principale di IPDT consiste nel tenere traccia degli host connessi (associazione di MAC address e indirizzi IP). A tale scopo, invia richieste ARP (Address Resolution Protocol) unicast con un intervallo predefinito di 30 secondi. Queste sonde vengono inviate all'indirizzo MAC dell'host connesso sull'altro lato del collegamento e usano il layer 2 (L2) come origine predefinita. In questo modo è possibile specificare l'indirizzo MAC dell'interfaccia fisica in uscita dalla quale viene inviato l'ARP e l'indirizzo IP del mittente 0.0.0.0, in base alla definizione della sonda ARP riportata nella RFC 5227.
Nota: IPDT è stato dichiarato obsoleto ed è stato preferito al rilevamento dei dispositivi basato su SISF (Switch Integrated Security Features). SISF fornisce il monitoraggio IP avanzato e supporta sia IPv4 che IPv6.
A partire da Cisco IOS® XE Denali 16.1.1, i comandi IPv6 snooping e IP Device Tracking (IPDT) esistenti dispongono dei corrispondenti comandi di rilevamento dei dispositivi basati su SISF che consentono di applicare la configurazione sia alle famiglie di indirizzi IPv4 che IPv6.
Questo documento viene conservato come riferimento in quanto riguarda le funzionalità legacy di rilevamento dispositivi IP (IPDT). Le implementazioni correnti possono utilizzare il rilevamento dei dispositivi basato su SISF, che sostituisce IPDT nelle moderne piattaforme Cisco IOS-XE. Per ulteriori informazioni sulla risoluzione dei problemi relativi a SISF, vedere Risoluzione dei problemi relativi a SISF sugli switch Catalyst serie 9000.
Estratto
In questo documento, il termine ARP Probe viene usato per riferirsi a un pacchetto di richiesta ARP, trasmesso sul collegamento locale, con un indirizzo IP di un mittente tutto zero. L'indirizzo hardware del mittente DEVE contenere l'indirizzo hardware dell'interfaccia che invia il pacchetto. Il campo dell'indirizzo IP del mittente DEVE essere impostato su tutti gli zeri per evitare il danneggiamento che ARP memorizza nella cache di altri host sullo stesso collegamento, nel caso in cui l'indirizzo risulti già utilizzato da un altro host. Il campo dell'indirizzo IP di destinazione DEVE essere impostato sull'indirizzo sondato. Una sonda ARP trasmette sia una domanda (Qualcuno utilizza questo indirizzo?) che un'istruzione implicita (questo è l'indirizzo che si spera di utilizzare).
Lo scopo di IPDT è che lo switch ottenga e conservi un elenco di dispositivi connessi allo switch tramite un indirizzo IP. La richiesta non popola la voce di tracciamento; viene semplicemente utilizzato per mantenere la voce nella tabella dopo essere stata appresa tramite una richiesta/risposta ARP dall'host.
L'ispezione ARP di IP viene abilitata automaticamente quando IPDT è attivato. rileva la presenza di nuovi host quando quest'ultimo monitora i pacchetti ARP. Se l'ispezione ARP dinamica è abilitata, solo i pacchetti ARP convalidati vengono utilizzati per rilevare i nuovi host per la tabella Device Tracking.
Lo snooping DHCP di IP, se abilitato, rileva la presenza o la rimozione di nuovi host quando DHCP assegna o revoca i relativi indirizzi IP. Quando il traffico DHCP viene rilevato su un determinato host, il timer dell'intervallo di probe ARP IPDT viene reimpostato.
IPDT è una funzionalità sempre disponibile, tuttavia nelle versioni più recenti di Cisco IOS® le interdipendenze sono abilitate per impostazione predefinita (vedere l'ID bug Cisco CSCuj04986). Può essere estremamente utile quando il relativo database di associazioni host IP/MAC viene utilizzato per popolare l'IP di origine degli elenchi di controllo di accesso dinamici (ACL) o per mantenere un'associazione di un indirizzo IP a un tag del gruppo di sicurezza.
Il probe ARP viene inviato in due circostanze:
- Il collegamento associato a una voce corrente nel database IPDT passa da uno stato DOWN a uno UP e la voce ARP è stata popolata.
- Un collegamento già nello stato UP associato a una voce nel database IPDT ha un intervallo di richiesta scaduto.
Problema
La sonda keepalive inviata dallo switch è un controllo L2. Di conseguenza, dal punto di vista dello switch, gli indirizzi IP utilizzati come origine negli ARP non sono importanti: questa funzione può essere utilizzata su dispositivi senza un indirizzo IP configurato, quindi l'origine IP di 0.0.0.0 non è rilevante.
Quando l'host riceve questi messaggi, risponde e popola il campo relativo all'IP di destinazione con l'unico indirizzo IP disponibile nel pacchetto ricevuto, ossia il proprio indirizzo IP. Ciò può causare falsi avvisi relativi agli indirizzi IP duplicati in quanto l'host che risponde considera il proprio indirizzo IP sia come origine che come destinazione del pacchetto; Per ulteriori informazioni sugli scenari di indirizzi IP duplicati, fare riferimento all'articolo Risoluzione dei problemi relativi ai messaggi di errore "Duplicate IP address 0.0.0".
Stato e funzionamento predefiniti
La configurazione di accensione/spegnimento globale per IPDT è un comportamento legacy che ha causato problemi sul campo in quanto i clienti non erano sempre consapevoli di dover attivare IPDT per il funzionamento di alcune funzionalità. Nelle versioni correnti, IPDT è controllato esclusivamente a livello di interfaccia quando attiva una funzionalità che richiede IPDT.
In queste versioni, IPDT è attivo per impostazione predefinita a livello globale; in altre parole, nessun comando di configurazione globale:
- Catalyst 2000/3000: 15.2(1)E
- Catalyst 3850: 3.2.0SE
- Catalyst 4K: 15.2(1)E / 3.5.0E
È importante notare che, anche se IPDT è abilitato a livello globale, ciò non implica per forza che monitori attivamente una determinata porta.
Nelle versioni in cui IPDT è sempre attivo e in cui IPDT può essere attivato/disattivato a livello globale quando IPDT è attivato a livello globale, altre funzionalità determinano se IPDT è attivo su un'interfaccia specifica (vedere la sezione Aree funzionalità).
Aree di funzionalità
IPDT e le relative richieste ARP inviate da una determinata interfaccia vengono utilizzati per le seguenti funzioni:
- NMSP (Network Mobility Services Protocol), versioni 3.2.0E, 15.2(1)E, 3.5.0E e successive
- Device Sensor, versioni 15.2(1)E, 3.5.0E e successive
- 1X, MAB (MAC Authentication Bypass), gestore sessioni
- Autenticazione basata sul Web
- Auth-proxy
- IP Source Guard (IPSG) per host statici
- Flexible NetFlow
- CTS (Cisco TrustSec)
- Mediatrace
- Reindirizzamenti HTTP
Matrice
| Piattaforma |
Funzionalità |
Predefinito su (Inizia da) |
Disable, metodo |
Disabilita CLI |
| Cat 2960/3750 (Cisco IOS) |
IPDT |
15.2(1)E * |
CLI globale (versioni precedenti) * per interfaccia |
Nessun rilevamento dei dispositivi IP * Massimo rilevamento dispositivo IP 0 *** |
| Cat 2960/3750 (Cisco IOS) |
NMSP |
No |
CLI globale o CLI per interfaccia |
Nessuna abilitazione NMSP Eliminazione dell'allegato NMSP **** |
| Cat 2960/3750 (Cisco IOS) |
Sensore dispositivo |
15.0(1)SE |
CLI globale |
Nessun monitoraggio automatico macro |
| Cat 2960/3750 (Cisco IOS) |
Snooping ARP |
15.2(1)E ** |
N/D |
N/D |
| Cat 3850 |
IPDT |
Tutte le release * |
Per interfaccia * |
Tracciamento dispositivo IP massimo 0 *** |
| Cat 3850 |
NMSP |
Tutte le release |
Per interfaccia |
Eliminazione allegati NMSP |
| Cat 3850 |
Sensore dispositivo |
No |
N/D |
N/D |
| Cat 3850 |
Snooping ARP |
Tutte le release ** |
N/D |
N/D |
| Cat 4500 |
IPDT |
15.2(1)E / 3.5.0E * |
CLI globale (versioni precedenti) * per interfaccia |
Nessun rilevamento dei dispositivi IP * Tracciamento dispositivo IP massimo 0 *** |
| Cat 4500 |
NMSP |
No |
CLI globale o CLI per interfaccia |
Nessuna abilitazione NMSP Eliminazione dell'allegato NMSP **** |
| Cat 4500 |
Sensore dispositivo |
15.1(1)SG / 3.3.0SG |
CLI globale |
No macro auto monitor |
| Cat 4500 |
Snooping ARP |
15.2(1)E / 3.5.0E ** |
N/D |
N/D |
Caratteristiche
- Nelle versioni più recenti, IPDT non può essere disabilitato globalmente. Tuttavia, IPDT è attivo solo sulle porte se le funzionalità che lo richiedono sono attive.
- Lo snooping ARP è attivo solo se è possibile utilizzare combinazioni di caratteristiche specifiche.
- Se si disabilita IPDT per singole interfacce, lo snooping ARP non viene interrotto e non viene impedito il rilevamento IPDT. È disponibile nelle versioni 3.3.0SE, 15.2(1)E, 3.5.0E e successive.
- Per ogni interfaccia, la soppressione NMSP è disponibile solo se NMSP è abilitato globalmente.
Disattivazione di IPDT
Nelle versioni in cui IPDT non è abilitato per impostazione predefinita, è possibile disattivare IPDT a livello globale eseguendo questo comando:
Switch(config)#no ip device tracking
Nelle versioni in cui IPDT è sempre attivo, il comando precedente non è disponibile o non consente di disabilitare IPDT (ID bug Cisco CSCuj04986). In questo caso, esistono diversi modi per garantire che IPDT non esegua il monitoraggio di una porta specifica o non generi avvisi IP duplicati.
Immissione del comando ip device tracking probe delay 10
Questo comando impedisce a uno switch di inviare una richiesta per dieci secondi quando rileva un collegamento UP/flap, il che riduce al minimo la possibilità di inviare la richiesta mentre l'host dall'altro lato del collegamento controlla gli indirizzi IP duplicati. L'RFC specifica una finestra di 10 secondi per il rilevamento degli indirizzi duplicati. Se si ritarda la sonda di rilevamento del dispositivo, il problema può essere risolto nella maggior parte dei casi.
Se lo switch invia una richiesta ARP per il client mentre l'host (ad esempio, un computer Microsoft Windows) è in fase di rilevamento degli indirizzi duplicati, l'host rileva la richiesta come un indirizzo IP duplicato e mostra all'utente un messaggio che indica che è stato trovato un indirizzo IP duplicato sulla rete. Se il PC non ottiene un indirizzo e l'utente deve rilasciare/rinnovare manualmente l'indirizzo; disconnettersi e riconnettersi alla rete oppure riavviare il PC per ottenere l'accesso alla rete.
Oltre al ritardo della richiesta, il ritardo si reimposta automaticamente quando lo switch rileva una richiesta dal computer/host. Ad esempio, se il timer della sonda esegue il conto alla rovescia fino a cinque secondi e rileva una sonda ARP dal PC/host, il timer viene ripristinato a 10 secondi.
Questa configurazione è stata resa disponibile tramite l'ID bug Cisco CSCtn27420.
Immettere il comando IP Device Tracking Probe Use SVI
Con questo comando, è possibile configurare lo switch per inviare una sonda ARP non conforme alla RFC; l'origine IP non è 0.0.0.0, ma è l'interfaccia virtuale dello switch (SVI) nella VLAN in cui risiede l'host. Nei computer Microsoft Windows la sonda non viene più considerata come una sonda definita dalla RFC 5227 e non viene contrassegnata come potenziale IP duplicato.
Immissione del comando ip device tracking probe auto-source [fallback <host-ip> <mask>] [override]
Per i clienti che non dispongono di dispositivi terminali prevedibili/controllabili o per coloro che hanno molti switch con un ruolo solo L2, la configurazione di una SVI, che introduce una variabile di layer 3 nel progetto, non è una soluzione adatta. Un miglioramento introdotto nella versione 15.2(2)E e successive, la possibilità di consentire l'assegnazione arbitraria di un indirizzo IP non deve necessariamente appartenere allo switch per essere utilizzato come indirizzo di origine nelle sonde ARP generate da IPDT. Questo miglioramento consente di modificare il comportamento automatico del sistema in questi modi (questo elenco mostra come il comportamento automatico del sistema dopo l'uso di ogni comando):
Immissione del comando ip device tracking probe auto-source
- Impostare la sorgente sulla VLAN SVI, se presente.
- Cercare una coppia di origine/MAC nella tabella di host IP per la stessa subnet.
- Inviare l'origine IP zero come nello scenario predefinito.
Immissione del comando ip device tracking probe auto-source fallback 0.0.0.1 255.255.255.0
- Impostare la sorgente sulla VLAN SVI, se presente.
- Cercare una coppia di origine/MAC nella tabella di host IP per la stessa subnet.
- Calcolare l'IP di origine dall'IP di destinazione con la mask e il bit dell'host forniti.
Immissione del comando ip device tracking probe auto-source fallback 0.0.0.1 255.255.255.0 override
- Impostare la sorgente sulla VLAN SVI, se presente.
- Calcolare l'IP di origine dall'IP di destinazione con la mask e il bit dell'host forniti.
Come esempio dei calcoli precedenti, si supponga di eseguire la sonda dell'host 192.168.1.200, con la maschera e i bit dell'host forniti, e di generare l'indirizzo di origine 192.168.1.1. Se si esegue la sonda della voce 10.5.5.20, è possibile generare una sonda ARP con l'indirizzo di origine 10.5.5.1 e così via.
Immissione del comando ip device tracking maximum 0
Questo comando non disabilita realmente IPDT, tuttavia limita a zero il numero di host rilevati. Questa non è una soluzione consigliata e deve essere utilizzata con cautela perché influisce su tutte le altre funzionalità che si basano su IPDT, incluse le configurazioni dei canali delle porte descritte nell'ID bug Cisco CSCun81556.
Disattivazione delle funzioni attive che abilitano IPDT
Tra le funzionalità che possono attivare IPDT vi sono NMSP, il sensore dei dispositivi, dot1x/MAB, WebAuth e IPSG. Si consiglia di non abilitare queste funzionalità sulle porte trunk. Questa soluzione è riservata alle situazioni più difficili o complesse, in cui o tutte le soluzioni precedentemente disponibili non hanno funzionato come previsto, o hanno creato problemi aggiuntivi. Questa è, tuttavia, l'unica soluzione che consente la massima granularità quando si disabilita IPDT, perché è possibile disattivare solo le funzioni correlate a IPDT che causano problemi e lasciare tutto il resto inalterato.
Nella versione più recente di Cisco IOS, 15.2(2)E e versioni successive, viene visualizzato un output simile al seguente:
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
Le due righe scritte tutte in maiuscolo nella parte inferiore dell'output sono quelle che utilizzano IPDT per funzionare. La maggior parte dei problemi creati quando si disabilita la registrazione dei dispositivi può essere evitata, se si disabilitano i singoli servizi eseguiti nell'interfaccia.
Nelle versioni precedenti di Cisco IOS, il modo semplice per sapere quali moduli sono abilitati tramite un'interfaccia non è ancora disponibile, quindi è necessario eseguire un processo più complesso per ottenere gli stessi risultati. È necessario attivare debug ip device track interface, un file di registro a bassa frequenza che nella maggior parte delle configurazioni deve essere sicuro. Fare attenzione a non attivare il rilevamento dei dispositivi IP di debug, poiché in questo modo la console viene inondata in situazioni di scalabilità.
Una volta attivato il debug, ripristinare l'interfaccia predefinita, poi aggiungere e rimuovere un servizio IPDT dalla configurazione dell'interfaccia. I risultati dei debug indicano quale servizio è stato abilitato/disabilitato con il comando utilizzato.
Esempio:
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)#
L'output rivela che avete abilitato la feature 00000008 e che la nuova maschera è 0000004C.
A questo punto, rimuovere la configurazione appena aggiunta:
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)#
Una volta rimossa la funzione 00000008, viene visualizzata la maschera 0000044, che deve essere stata la maschera predefinita originale. Il valore di 00000044 è previsto poiché AIM è 0x00000004 e SM è 0x00000040. Il risultato complessivo è 0x00000044.
Esistono diversi servizi IPDT che possono essere eseguiti in un'interfaccia:
| Servizio IPT |
Interfaccia |
| 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 |
Nell'esempio, HOST_TRACK_CLIENT_SM (SESSION-MANAGER) e HOST_TRACK_CLIENT_ATTACHMENT (noto anche come AIM/NMSP), i moduli sono configurati per IPDT. Per disattivare IPDT su questa interfaccia, è necessario disattivarli entrambi perché IPDT è disattivato SOLO quando sono disattivate anche tutte le funzioni che lo utilizzano.
Dopo aver disabilitato queste funzioni, si ottiene un output simile al seguente:
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
--------------------------------------------
In questo modo, IPDT viene disabilitato con maggiore granularità.
Di seguito sono riportati alcuni esempi di comandi utilizzati per disabilitare alcune delle funzioni descritte in precedenza:
- nmsp attach suppress
- no macro auto monitor
Verifica del funzionamento di IPDT
Eseguire i seguenti comandi per verificare lo stato IPDT sul dispositivo:
- show ip device tracking
- Questo comando visualizza le interfacce dove IPDT è abilitato e dove sono attualmente tracciate le associazioni MAC/IP/interfaccia.
- clear ip device tracking
- Questo comando cancella le voci relative a IPDT.
- Questo comando cancella le voci relative a IPDT.
- debug ip device tracking
- Questo comando consente di raccogliere i debug per visualizzare l'attività IPDT in tempo reale.
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
5.0 |
07-Jul-2026
|
Aggiornati gli avvisi relativi a ortografia, grammatica, spaziatura e CCW. |
4.0 |
04-Dec-2025
|
Traduzione automatica aggiornata e SEO. |
3.0 |
19-Dec-2024
|
Formattazione aggiornata. |
2.0 |
21-Aug-2023
|
SEO, requisiti di stile e formattazione aggiornati. |
1.0 |
25-Nov-2014
|
Versione iniziale |
Feedback