Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les fonctions de sécurité intégrées (SISF) des commutateurs de la gamme Catalyst 9000. Il explique également comment le SISF peut être utilisé et comment interagit avec d'autres fonctionnalités.
Aucune exigence spécifique n'est associée à ce document.
Les informations contenues dans ce document sont basées sur Cisco Catalyst 9300-48P qui exécute Cisco IOS® XE 17.3.x
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Remarque : consultez le guide de configuration approprié pour connaître les commandes utilisées afin d'activer ces fonctionnalités sur d'autres plates-formes Cisco.
Ce document peut également être utilisé avec les versions de matériel et de logiciel suivantes :
Avec 17.3.4 et versions ultérieures du logiciel Cisco IOS XE
Remarque : ce document s'applique également à la plupart des versions de Cisco IOS XE qui utilisent le SISF par rapport au suivi des périphériques.
Le protocole SISF fournit une table de liaison d'hôte et certains clients de fonctionnalités utilisent les informations qu'elle contient. Les entrées sont renseignées dans la table en glanant des paquets tels que DHCP, ARP, ND, RA qui suivent l'activité de l'hôte et aident à remplir dynamiquement la table. Si des hôtes silencieux sont présents dans le domaine L2, des entrées statiques peuvent être utilisées pour ajouter des entrées dans la table SISF.
Le SISF utilise un modèle de stratégie pour configurer les rôles des périphériques et des paramètres supplémentaires sur le commutateur. Une seule stratégie peut être appliquée au niveau de l'interface ou du VLAN. Si une stratégie est appliquée sur le VLAN et qu'une autre stratégie est appliquée sur l'interface, la stratégie d'interface est prioritaire.
SISF peut également être utilisé pour limiter le nombre d'hôtes dans la table, mais il existe des différences entre les comportements IPv4 et IPv6. Si la limite SISF est définie et qu'elle est atteinte :
À partir de la version 16.9.x et des versions plus récentes, une priorité de fonctionnalité client SISF est introduite. Il ajoute des options pour contrôler les mises à jour dans SISF et si deux clients ou plus utilisent la table de liaison, les mises à jour de la fonctionnalité de priorité plus élevée sont appliquées. Les exceptions ici sont les paramètres « limit address-count for IPv4/IPv6 per mac », les paramètres de la stratégie avec la priorité la plus basse sont effectifs.
Voici quelques exemples de fonctionnalités qui nécessitent l'activation du suivi des périphériques :
Remarque : la priorité est utilisée pour sélectionner les paramètres de stratégie.
La politique créée à partir de l'interface de ligne de commande a la priorité la plus élevée (128), ce qui permet aux utilisateurs d'appliquer un paramètre de politique différent de celui des politiques de programmation. Tous les paramètres configurables de la stratégie personnalisée peuvent être modifiés manuellement.
L'image suivante est un exemple de politique SISF et explique comment la lire :
À l'intérieur de la stratégie, sous mot-clé de protocole, vous avez la possibilité de voir quel type de paquets sont utilisés pour remplir la base de données SISF :
switch(config-device-tracking)#? device-tracking policy configuration mode: data-glean binding recovery by data traffic source address gleaning default Set a command to its defaults destination-glean binding recovery by data traffic destination address gleaning device-role Sets the role of the device attached to the port distribution-switch Distribution switch to sync with exit Exit from device-tracking policy configuration mode limit Specifies a limit medium-type-wireless Force medium type to wireless no Negate a command or set its defaults prefix-glean Glean prefixes in RA and DHCP-PD traffic protocol Sets the protocol to glean (default all) <-- security-level setup security level tracking Override default tracking behavior trusted-port setup trusted port vpc setup vpc port switch(config-device-tracking)#protocol ? arp Glean addresses in ARP packets dhcp4 Glean addresses in DHCPv4 packets dhcp6 Glean addresses in DHCPv6 packets ndp Glean addresses in NDP packets udp Gleaning from UDP packets
Les fonctions du tableau suivant activent le SISF par programme lorsqu'elles sont activées ou agissent comme des clients du SISF :
Fonction programmatique SISF |
Fonctionnalités du client SISF |
LISP sur VLAN |
Point1x |
EVPN sur VLAN |
Authentification Web |
Surveillance DHCP |
CTS |
Si une fonctionnalité client SISF est activée sur un périphérique configuré sans fonctionnalité qui active SISF, une stratégie personnalisée doit être configurée sur les interfaces se connectant aux hôtes.
Le rôle principal du suivi des périphériques est de suivre la présence, l'emplacement et le déplacement des noeuds d'extrémité dans le réseau. Le protocole SISF surveille le trafic reçu par le commutateur, extrait l'identité du périphérique (adresse MAC et adresse IP) et les stocke dans une table de liaison. De nombreuses fonctionnalités, telles que IEEE 802.1X, l'authentification Web, Cisco TrustSec et LISP, dépendent de la précision de ces informations pour fonctionner correctement. Le suivi des périphériques basé sur SISF prend en charge les protocoles IPv4 et IPv6. Il existe cinq méthodes prises en charge par le client pour apprendre l’IP :
Le suivi des périphériques sur port-channel (ou éther-channel) est pris en charge. Mais la configuration doit être appliquée au groupe de canaux, et non aux membres individuels du canal de port. La seule interface qui apparaît (et qui est connue) du point de vue de la liaison est le port-channel.
Sonde :
Base de données :
Dans SISF, vous pouvez configurer quelques options pour contrôler la durée de conservation d'une entrée dans la base de données :
tracking enable reachable-lifetime <second|infinite> <-- how long an entry is kept reachable (or keep permanently reachable)
tracking disable stale-lifetime <seconds|infinite> <-- how long and entry is kept inactive before deletion (or keep permanently inactive)
Cycle de vie d'une entrée dans laquelle l'hôte est interrogé :
Types de vols de noeuds :
Voici quelques-unes des fonctions dépendantes du SISF :
Voici quelques-uns des comportements les plus fréquents associés au FSIS :
Le schéma de topologie est utilisé dans le scénario SISF suivant. Les commutateurs 9300 sont uniquement de couche 2 et ne disposent PAS d'interface SVI configurée dans le VLAN client 10.
Remarque : SISF est activé manuellement dans ces travaux pratiques.
La configuration SISF par défaut a été configurée sur les deux commutateurs 9300 faisant face aux ports d'accès, tandis que la stratégie personnalisée a été appliquée aux ports d'agrégation pour illustrer les sorties SISF attendues.
Commutateur 9300-1 :
9300-1#show running-config interface GigabitEthernet 1/0/1 Building configuration... Current configuration : 111 bytes ! interface GigabitEthernet1/0/1 switchport access vlan 10 switchport mode access device-tracking <-- enable default SISF policy end
9300-1#
9300-1#show running-config | section trunk-policy
device-tracking policy trunk-policy <-- custom policy
trusted-port <-- custom policy parameters
device-role switch <-- custom policy parameters
no protocol udp
9300-1# 9300-1#show running-config interface tenGigabitEthernet 1/1/1 Building configuration... Current configuration : 109 bytes ! interface TenGigabitEthernet1/1/1 switchport mode trunk device-tracking attach-policy trunk-policy <-- enable custom SISF policy
end
Commutateur 9300-2 :
9300-2#show running-config interface GigabitEthernet 1/0/2 Building configuration... Current configuration : 105 bytes ! interface GigabitEthernet1/0/2 switchport access vlan 10 switchport mode access device-tracking <-- enable default SISF policy end
9300-2#show running-config | section trunk-policy
device-tracking policy trunk-policy <-- custom policy
trusted-port <-- custom policy parameters
device-role switch <-- custom policy parameters
no protocol udp
9300-2#show running-config interface tenGigabitEthernet 1/1/1 Building configuration... Current configuration : 109 bytes ! interface TenGigabitEthernet1/1/1 switchport mode trunk device-tracking attach-policy trunk-policy <-- custom policy applied to interface
end
Vous pouvez utiliser ces commandes pour valider les stratégies appliquées :
show device-tracking policy <policy name>
show device-tracking policies
show device-tracking database
Commutateur 9300-1 :
9300-1#show device-tracking policy default Device-tracking policy default configuration: security-level guard device-role node <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy default is applied on the following targets: Target Type Policy Feature Target range Gi1/0/1 PORT default Device-tracking vlan all
9300-1#show device-tracking policy trunk-policy Device-tracking policy trunk-policy configuration: trusted-port <-- security-level guard device-role switch <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy trunk-policy is applied on the following targets: Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all 9300-1#
9300-1#show device-tracking policies Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all Gi1/0/1 PORT default Device-tracking vlan all
9300-1#show device-tracking database Binding Table has 1 entries, 1 dynamic (limit 200000) Codes: L - Local, S - Static, ND - Neighbor Discovery, ARP - Address Resolution Protocol, DH4 - IPv4 DHCP, DH6 - IPv6 DHCP, PKT - Other Packet, API - API created Preflevel flags (prlvl): 0001:MAC and LLA match 0002:Orig trunk 0004:Orig access 0008:Orig trusted trunk 0010:Orig trusted access 0020:DHCP assigned 0040:Cga authenticated 0080:Cert authenticated 0100:Statically assigned Network Layer Address Link Layer Address Interface vlan prlvl age state Time left ARP 10.10.10.100 98a2.c07e.7902 Gi1/0/1 10 0005 8s REACHABLE 306 s 9300-1#
Commutateur 9300-2 :
9300-2#show device-tracking policy default Device-tracking policy default configuration: security-level guard device-role node <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy default is applied on the following targets: Target Type Policy Feature Target range Gi1/0/2 PORT default Device-tracking vlan all
9300-2#show device-tracking policy trunk-policy Device-tracking policy trunk-policy configuration: trusted-port <-- security-level guard device-role switch <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy trunk-policy is applied on the following targets: Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all 9300-2#
9300-2#show device-tracking policies Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all Gi1/0/2 PORT default Device-tracking vlan all
9300-2#show device-tracking database Binding Table has 1 entries, 1 dynamic (limit 200000) Codes: L - Local, S - Static, ND - Neighbor Discovery, ARP - Address Resolution Protocol, DH4 - IPv4 DHCP, DH6 - IPv6 DHCP, PKT - Other Packet, API - API created Preflevel flags (prlvl): 0001:MAC and LLA match 0002:Orig trunk 0004:Orig access 0008:Orig trusted trunk 0010:Orig trusted access 0020:DHCP assigned 0040:Cga authenticated 0080:Cert authenticated 0100:Statically assigned Network Layer Address Link Layer Address Interface vlan prlvl age state Time left ARP 10.10.10.101 98a2.c07e.9902 Gi1/0/2 10 0005 41s REACHABLE 273 s 9300-2#
Problème
La sonde « keepalive » envoyée par le commutateur est un contrôle de couche 2. En tant que telle, du point de vue du commutateur, les adresses IP utilisées comme source dans les ARP ne sont pas importantes : cette fonctionnalité peut être utilisée sur des périphériques sans aucune adresse IP configurée, de sorte que la source IP 0.0.0.0 n'est pas pertinente. Lorsque l'hôte reçoit ces messages, il répond et renseigne le champ IP de destination avec la seule adresse IP disponible dans le paquet reçu, qui est sa propre adresse IP. Cela peut entraîner de fausses alertes d'adresse IP dupliquée, car l'hôte qui répond voit sa propre adresse IP à la fois comme source et comme destination du paquet.
Il est recommandé de configurer la stratégie SISF pour qu'elle utilise une source automatique pour ses sondes de test d'activité.
Remarque : consultez cet article sur les problèmes d'adresses en double pour plus d'informations
Sonde par défaut
Il s'agit du paquet d'analyse lorsqu'aucune interface SVI locale n'est présente et que les paramètres d'analyse par défaut sont définis :
Ethernet II, Src: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02), Dst: Cisco_76:63:c6 (00:41:d2:76:63:c6) <-- Probe source MAC is the BIA of physical interface connected to client Destination: Cisco_76:63:c6 (00:41:d2:76:63:c6) Address: Cisco_76:63:c6 (00:41:d2:76:63:c6) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: 000000000000000000000000000000000000 Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Sender IP address: 0.0.0.0 <-- Sender IP is 0.0.0.0 (default) Target MAC address: Cisco_76:63:c6 (00:41:d2:76:63:c6) Target IP address: 10.10.10.101 <-- Target IP is client IP
Solution
Configurez la sonde de sorte qu'elle utilise une adresse autre que celle du PC hôte. Ces méthodes permettent d'y parvenir
Source automatique pour la sonde « Keep-Alive »
Configurez une source automatique pour les sondes « keep-alive » afin de réduire l'utilisation de 0.0.0.0 en tant qu'IP source :
device-tracking tracking auto-source fallback <IP> <MASK> [override]
La logique d'application de la commande auto-source fonctionne comme suit :
device-tracking tracking auto-source fallback 0.0.0.253 255.255.255.0 [override] <-- Optional parameter
Remarque : si la commande est appliquée avec <override>, nous passons toujours à l'étape 3.
Sonde modifiée
Le paramétrage de la configuration de secours auto-source pour utiliser une adresse IP dans le sous-réseau modifie la sonde. Puisqu'il n'y a pas d'interface SVI et aucun autre client sur le sous-réseau, nous revenons à l'IP/masque configuré dans la configuration.
switch(config)#device-tracking tracking auto-source fallback 0.0.0.253 255.255.255.0 <-- it uses .253 for all subnets where there is no existing client and no SVI
Il s'agit du paquet de sonde modifié :
Ethernet II, Src: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02), Dst: Cisco_76:63:c6 (00:41:d2:76:63:c6) <-- Probe source MAC is the BIA of physical interface connected to client Destination: Cisco_76:63:c6 (00:41:d2:76:63:c6) Address: Cisco_76:63:c6 (00:41:d2:76:63:c6) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: 000000000000000000000000000000000000 Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Sender IP address: 10.10.10.253 <-- Note the new sender IP is now using the fallback IP configured. Target MAC address: Cisco_76:63:c6 (00:41:d2:76:63:c6) Target IP address: 10.10.10.101
Détails supplémentaires sur le comportement de la sonde
Commande |
Action (Afin de sélectionner l'adresse IP et MAC source pour le suivi de périphérique sonde ARP) |
Remarques |
autosource de poursuite de poursuite de dispositif |
|
Nous vous recommandons de désactiver le suivi des périphériques sur tous les ports agrégés afin d'éviter le battement MAC. |
correction automatique de la source de poursuite du suivi des dispositifs |
|
Déconseillé en l'absence d'interface SVI. |
suivi du suivi de périphérique auto-source fallback <IP> <MASK> |
|
Nous vous recommandons de désactiver le suivi des périphériques sur tous les ports agrégés afin d'éviter le battement MAC. L'adresse IPv4 calculée ne doit être attribuée à aucun client ou périphérique réseau. |
suivi de suivi de périphérique auto-source fallback <IP> <MASK> override |
|
L'adresse IPv4 calculée ne doit être attribuée à aucun client ou périphérique réseau. |
Explication de la commande device-tracking auto-source fallback <IP> <MASK> [override] :
Selon l'adresse IP de l'hôte, une adresse IPv4 doit être réservée.
<reserved IPv4 address> = (<host-ip> & <MASK> ) | <IP>
Remarque : il s'agit d'une formule booléenne
Exemple .
Si nous utilisons la commande :
device-tracking tracking auto-source fallback 0.0.0.1 255.255.255.0 override
IP hôte = 10.152.140.25
IP = 0.0.0.1
masque = 24
Scindons la formule booléenne en deux parties.
1. 10.152.140.25 ET 255.255.255.0 fonctionnement :
10.152.140.25 = 00001010.10011000.10001100.00011001 AND 255.255.255.0 = 11111111.11111111.11111111.00000000 RESULT 10.152.140.0 = 00001010.10011000.10001100.00000000
2. 10.152.140.0 OU 0.0.0.1 opération :
10.152.140.0 = 00001010.10011000.10001100.00000000 OR 0.0.0.1 = 00000000.00000000.00000000.00000001 RESULT 10.152.140.1 = 00001010.10011000.10001100.00000001
Adresse IP réservée = 10.152.140.1
Adresse IP réservée = (10.152.140.25 & 255.255.255.0) | (0.0.0.1) = 10.152.140.1
Remarque : l'adresse utilisée comme source IP doit être étendue à partir des liaisons DHCP du sous-réseau.
Problème
Erreur d'adresse IPv6 dupliquée lorsque IPv6 est activé sur le réseau et qu'une interface virtuelle commutée (SVI) est configurée sur un VLAN.
Dans un paquet DAD IPv6 normal, le champ Adresse source de l'en-tête IPv6 est défini sur l'adresse non spécifiée (0:0:0:0:0:0:0:0:0). Similaire au cas IPv4.
L'ordre de sélection de l'adresse source dans la sonde SISF est le suivant :
Solution
Nous vous recommandons d'ajouter les commandes suivantes à la configuration SVI. Cela permet à l'interface SVI d'acquérir automatiquement une adresse link-local ; cette adresse est utilisée comme adresse IP source de la sonde SISF, évitant ainsi le problème de doublon d'adresse IP.
interface vlan <vlan> ipv6 enable
Problème
La sonde « keepalive » envoyée par le commutateur est diffusée à partir de tous les ports lorsqu'elle est activée par programme. Les commutateurs connectés dans le même domaine de couche 2 envoient ces diffusions à leurs hôtes, ce qui a pour effet que le commutateur d’origine ajoute des hôtes distants à sa base de données de suivi des périphériques. Les entrées d'hôte supplémentaires augmentent l'utilisation de la mémoire sur le périphérique et le processus d'ajout des hôtes distants augmente l'utilisation du processeur du périphérique.
Il est recommandé de définir la stratégie de programmation en configurant une stratégie sur la liaison ascendante vers les commutateurs connectés afin de définir le port comme étant sécurisé et connecté à un commutateur.
Remarque : sachez que les fonctionnalités dépendant du SISF, telles que la surveillance DHCP, permettent au SISF de fonctionner correctement, ce qui peut déclencher ce problème.
Solution
Configurez une stratégie sur la liaison ascendante (trunk) pour arrêter les analyses et l'apprentissage des hôtes distants qui aiment sur d'autres commutateurs (SISF est uniquement nécessaire pour gérer une table d'hôtes locale)
device-tracking policy DT_trunk_policy trusted-port device-role switch interface <interface> device-tracking policy DT_trunk_policy
Problème
En raison d'un problème de migration d'IPDT vers le suivi de périphérique basé sur SISF, un délai d'accessibilité non par défaut est parfois introduit lors de la migration d'une ancienne version vers 16.x et les versions plus récentes.
Solution
Il est recommandé de rétablir l'heure d'accessibilité par défaut en configurant :
no device-tracking binding reachable-time <seconds>
Problème
Lorsque des commutateurs sont intégrés à l'outil de surveillance cloud Meraki, celui-ci applique des politiques de suivi des périphériques personnalisées.
device-tracking policy MERAKI_POLICY security-level glean no protocol udp tracking enable
La politique est appliquée à toutes les interfaces sans distinction, ce qui signifie qu'elle ne fait pas de distinction entre les ports de périphérie et les ports agrégés qui font face à d'autres périphériques réseau (par exemple, commutateurs, pare-feu, routeurs, etc.). Le commutateur peut créer plusieurs entrées SISF sur les ports d'agrégation où MERAKI_POLICY est configuré, provoquant ainsi des vidages sur ces ports ainsi qu'une augmentation de l'utilisation du CPU.
switch#show interfaces port-channel 5
Port-channel5 is up, line protocol is up (connected)
<omitted output> Input queue: 0/2000/0/112327 (size/max/drops/flushes); Total output drops: 0 <-- we have many flushes <omitted output>
switch#show process cpu sorted CPU utilization for five seconds: 26%/2%; one minute: 22%; five minutes: 22% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 572 1508564 424873 3550 11.35% 8.73% 8.95% 0 SISF Main Thread 105 348502 284345 1225 2.39% 2.03% 2.09% 0 Crimson flush tr
Solution
Configurez la stratégie suivante sur toutes les interfaces non périphériques :
configure terminal device-tracking policy NOTRACK no protocol ndp no protocol dhcp6 no protocol arp no protocol dhcp4 no protocol udp exit
interface <interface> device-tracking policy NOTRACK end
Problème
Ce scénario est courant sur les appareils en mode haute disponibilité (HA) qui ont des adresses IP différentes, mais qui partagent la même adresse MAC. Elle est également observée dans les environnements de machines virtuelles qui partagent la même condition (adresse MAC unique pour deux adresses IP ou plus). Cette condition empêche la connectivité réseau à toutes les adresses IP qui n'ont pas d'entrée dans la table SISF lorsque la stratégie SISF personnalisée en mode de garde est en place.Selon la fonctionnalité SISF, une seule adresse IP est apprise par adresse MAC.
Remarque : ce problème est présent dans les versions 17.7.1 et ultérieures
Exemple :
politique de fonds d'investissement stratégiques
switch#show run | sec IPDT_POLICY device-tracking policy IPDT_POLICY no protocol udp tracking enable
switch#show device-tracking policy IPDT_POLICY Device-tracking policy IPDT_POLICY configuration: security-level guard <-- default mode device-role node gleaning from Neighbor Discovery gleaning from DHCP6 gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn tracking enable Policy IPDT_POLICY is applied on the following targets: Target Type Policy Feature Target range Gi1/0/1 PORT IPDT_POLICY Device-tracking vlan all Gi1/0/2 PORT IPDT_POLICY Device-tracking vlan all
Base de données SISF
switch#show device-tracking database Binding Table has 2 entries, 2 dynamic (limit 200000) Codes: L - Local, S - Static, ND - Neighbor Discovery, ARP - Address Resolution Protocol, DH4 - IPv4 DHCP, DH6 - IPv6 DHCP, PKT - Other Packet, API - API created Preflevel flags (prlvl): 0001:MAC and LLA match 0002:Orig trunk 0004:Orig access 0008:Orig trusted trunk 0010:Orig trusted access 0020:DHCP assigned 0040:Cga authenticated 0080:Cert authenticated 0100:Statically assigned Network Layer Address Link Layer Address Interface vlan prlvl age state Time left ARP 10.0.0.3 10b3.d659.7858 Gi1/0/3 10 0005 90s REACHABLE 222 s try 0 ARP 10.0.0.1 10b3.d5a9.bd9f Gi1/0/1 10 0005 84s REACHABLE 220 s try 0
Serveur de test d'accessibilité A
ServerA#ping 10.0.0.3 source 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
ServerA#ping 10.0.0.3 source 10.0.0.100 <-- entry for 10.0.0.100 is not on SISF table
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.100
.....
Test d'accessibilité Serveur B.
ServerB#ping 10.0.0.3 <-- entry for 10.0.0.2 is not on SISF table
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Validation des abandons sur le commutateur.
switch(config)#device-tracking logging
Journaux
switch#show logging
<omitted output>
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
<omitted output>
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
Solution
Option 1 : supprimer la stratégie IPDT du port permet aux paquets ARP et aux périphériques affectés d'être accessibles
switch(config)#interface gigabitEthernet 1/0/1
switch(config-if)#no device-tracking attach-policy IPDT_POLICY
switch(config-if)#interface gigabitEthernet 1/0/2
switch(config-if)#no device-tracking attach-policy IPDT_POLICY
Option 2 : supprimez le glanage arp de protocole de la stratégie de suivi des périphériques.
switch(config)#device-tracking policy IPDT_POLICY
switch(config-device-tracking)#no protocol arp
Option 3 : Modifiez le niveau de sécurité de IPDT_POLICY sur glean.
switch(config)#device-tracking policy IPDT_POLICY
switch(config-device-tracking)#security-level glean
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
17-Jan-2024 |
Première publication |