Dépannage du SISF sur les commutateurs de la gamme Catalyst 9000
Table des matières
Introduction
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.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
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.
Produits connexes
Ce document peut également être utilisé avec les versions de matériel et de logiciel suivantes :
- Catalyst 9200
- Catalyst 9300
- Catalyst 9400
- Catalyst 9500
- Catalyst 9600
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.
Informations générales
Aperçu
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 :
- Les hôtes IPv4 continuent à fonctionner, mais aucune entrée supérieure à la limite ne doit être ajoutée à la table SISF
- Les hôtes IPv6 qui n'entrent pas dans la table SISF ne sont pas autorisés à entrer dans le réseau et aucune nouvelle entrée ne doit être ajoutée à la table SISF.
À 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é supérieure sont appliquées. Les exceptions ici sont les paramètres « Limiter le nombre d'adresses pour IPv4/IPv6 par MAC », les paramètres de la stratégie avec la priorité la plus faible sont effectifs.
Voici quelques exemples de fonctionnalités qui nécessitent l'activation du suivi des périphériques :
- LISP/EVPN
- Point1x
- Authentification Web
- CTS
- Surveillance DHCP
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
Fonctionnalités de programmation et de client SISF
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.
Fonctionnalités IPv4 utilisant les informations SISF
- CTS
- IEEE 802.1x
- ZÉZAIEMENT
- EVPN
- Surveillance DHCP (active uniquement SISF mais ne l'utilise pas)
- Protection de la source IP
Fonctionnalités IPv6 qui consomment des informations SISF
- Protection de l'annonce de routeur IPv6
- Protection DHCP IPv6, relais DHCP de couche 2
- Proxy de détection d'adresse en double (DAD) IPv6
- Suppression Des Inondations
- Protection de la source IPv6
- Protection de la destination IPv6
- Limiteur RA
- Protection de préfixe IPv6
Suivi des périphériques
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 :
- DHCPv4
- DHCPv6
- ARP
- NDP
- Nettoyage des données
SISF sur un Port-Channel
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.
Réglage des sondes et des bases de données
Sonde :
- Dans IPDT, il y avait une commande pour aider à résoudre les problèmes d'adresse en double en retardant la sonde initiale de 10 secondes : « ip device tracking probe delay » upon link up.
- Dans SISF, il existe déjà un compteur d'attente intégré qui attend avant d'envoyer la première sonde. Il n'est pas configurable et résout le même problème. Comme il s'agit du code SISF, cette commande n'est plus nécessaire
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)
Suivi des périphériques IP
Cycle de vie d'une entrée dans laquelle l'hôte est interrogé :
- SISF maintient la liaison IPv4/IPv6 par mac, une fois que l'apprentissage IP a réussi, liant les transitions à REACHABLE province
- SISF assure le suivi du client actif en surveillant le paquet de contrôle
- S'il n'y a aucun paquet de contrôle du client pendant 5 minutes, Binding passe à l'état VERIFY et envoie analyse vers le client
- Si les clients ne répondent pas à la sonde, la liaison passe à l’état STALE sinon à l’état REACHABLE
- Le délai d'attente par défaut pour les entrées OBSOLÈTES est de 24 heures et peut être configuré
- Les entrées STALE sont supprimées après 24 heures (ou valeur de délai d'attente configurée)
Détection du vol
Types de vols de noeuds :
- Vol d'IP (même IP, mac différent, port différent/identique)
- VOL MAC (même MAC, IP différente, port différent)
- MAC IP THEFT (même mac, même ip, port différent)
Fonctionnalités de sécurité IP
Voici quelques-unes des fonctions dépendantes du SISF :
- Inspection NDP : messages Inspect IPv6 NDP
- Nettoyage d’adresses NPD : renseignez la table de liaison avec les informations collectées en surveillant le trafic NPD
- Suivi des périphériques : surveillance de l'activité des périphériques finaux, notamment par le biais d'un mécanisme d'activité
- Snooping : Glean les adresses dans les messages NDP, ARP et DHCP. Bloquer les messages non autorisés
- Relais DHCPv4 : relais du paquet DHCP diffusé vers l'adresse d'assistance configurée.
- Suppression de multidiffusion NDP et ARP : supprimez les messages NDP de multidiffusion en les convertissant en monodiffusion ou en répondant au nom des cibles.
- Proxy DAD : détection d’adresse dupliquée et envoi de l’adresse réseau pour le compte du client cible
- DHCPv4 requis : Elle impose au client d'obtenir l'adresse IP uniquement par DHCP
Avertissements SISF
Voici quelques-uns des comportements les plus fréquents associés au FSIS :
- SISF peut être activé en activant d'autres fonctionnalités telles que la surveillance DHCP
- Le comportement d'exploration par défaut de SISF peut avoir un impact sur l'attribution des adresses IP client.
- Lorsque le SISF est activé, il est également activé sur les ports de liaison ascendante, ce qui peut avoir un impact sur le réseau.
Dépannage
Topologie
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.
Configuration
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
Vérification
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#
Scénarios courants
Erreur d'adresse IPv4 dupliquée sur le périphérique hôte
Problème
La sonde « keepalive » envoyée par le commutateur est un contrôle de couche 2. Ainsi, 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é.
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
- Définissez la source sur VLAN SVI, le cas échéant.
- Recherchez une paire source/MAC dans la table d’hôtes IP pour le même sous-réseau. La sonde provient de l’interface physique MAC du commutateur + l’adresse IP d’un autre hôte du sous-réseau déjà présent dans la base de données.
- Calculez l’adresse IP source à partir de l’adresse IP de destination avec le bit et le masque d’hôte fournis. La sonde est générée à partir de l’écoute de l’IP client et de la création d’une sonde dans le sous-réseau avec les derniers bits configurés.
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>
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
Erreur d'adresse IPv6 en double
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 :
- Adresse link-local de l'interface SVI, si elle est configurée
- Utiliser 0:0:0:0:0:0:0:0:0
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, ce qui empêche le problème de doublon d'adresse IP.
interface vlan <vlan> ipv6 enable
Mémoire et utilisation CPU accrues
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.
Solution
Configurez une stratégie sur la liaison ascendante (trunk) pour arrêter les analyses et l'apprentissage des hôtes distants qui résident 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
Temps d'accès au suivi des périphériques trop court
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
Commutateurs intégrés à l'outil Meraki (augmentation du CPU et purges de ports)
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
Adresses IP avec le même MAC ne figurant pas dans la table SISF
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.
Exemple :
- L’adresse IP 10.0.0.1 avec l’adresse MAC 10b3.d5a9.bd9f est apprise sur la table SISF et autorisée à communiquer avec le périphérique réseau 10.0.0.3.
- Cependant, la deuxième adresse IP 10.0.0.2 et l'adresse IP virtuelle 10.0.0.100 qui partagent l'adresse MAC 10b3.d659.7858 ne sont pas programmées dans la table SISF et la communication avec le réseau n'est pas autorisée.
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 de périphérique.
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
Informations connexes
- Guide de configuration de la sécurité, Cisco IOS XE Bengaluru 17.6.x (commutateurs Catalyst 9300) : Configuration des fonctions de sécurité intégrées du commutateur
- Guide de configuration de la sécurité, Cisco IOS XE Cupertino 17.9.x (commutateurs Catalyst 9300) : Configuration des fonctions de sécurité intégrées du commutateur
- Livre blanc sur les fonctionnalités de sécurité intégrées (SISF) des commutateurs de la gamme Cisco Catalyst 9000
- ID de bogue Cisco CSCvx75602 - Fuite de mémoire SISF dans le relais AR et suppression ND
- ID de bogue Cisco CSCwf3293 - [EVPN SISF] Méthode personnalisée requise pour modifier les valeurs d'adresse limite pour IPv4/V6 avec EVPN + DHCP
- ID de bogue Cisco CSCvq22011 - IOS-XE abandonne la réponse ARP lorsque IPDT est glané à partir d'ARP
- ID de bogue Cisco CSCwc20488 - Limitation de 255 pseudo-ports par VLAN/Version
- ID de bogue Cisco CSCwh52315 - Le commutateur 9300 abandonne la réponse ARP lorsqu'une stratégie IPDT est présente sur le port
- ID de bogue Cisco CSCvd51480 - Désassociation de la surveillance ip dhcp et du suivi des périphériques
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
17-Jan-2024 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)