Ce document décrit le fonctionnement de la fonction de suivi des périphériques IP, qui inclut les déclencheurs à ajouter et supprimer un hôte. En outre, l'impact du suivi des périphériques sur la liste de contrôle d'accès téléchargeable (DACL) 802.1x est expliqué. Le comportement change entre les versions et les plates-formes.
La deuxième partie du document porte sur la liste de contrôle d'accès (ACL) renvoyée par le serveur AAA (Authentication, Authorization, and Accounting) et appliquée à la session 802.1x. Une comparaison entre la liste DACL, la liste de contrôle d'accès par utilisateur et la liste de contrôle d'accès Filter-ID est présentée. En outre, certaines mises en garde concernant la réécriture de la liste de contrôle d’accès et la liste de contrôle d’accès par défaut sont abordées.
Le suivi de périphérique ajoute une entrée lorsque :
Le suivi des périphériques supprime une entrée lorsqu'il n'y a pas de réponse pour une requête ARP (envoi d'une sonde pour chaque hôte dans la table de suivi des périphériques, par défaut toutes les 30 secondes).
ip dhcp excluded-address 192.168.0.1 192.168.0.240
ip dhcp pool POOL
network 192.168.0.0 255.255.255.0
!
ip dhcp snooping vlan 1
ip dhcp snooping
ip device tracking
!
interface Vlan1
ip address 192.168.0.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.48.66.1
!
interface FastEthernet0/1
description PC
BSNS-3560-1# show ip dhcp binding
IP address Client-ID/ Lease expiration Type
Hardware address
192.168.0.241 0100.5056.994e.a1 Mar 02 1993 02:31 AM Automatic
BSNS-3560-1# show ip device tracking all
IP Device Tracking = Enabled
--------------------------------------------------------------
IP Address MAC Address Interface STATE
--------------------------------------------------------------
192.168.0.241 0050.5699.4ea1 FastEthernet0/1 ACTIVE
La surveillance DHCP remplit la table de liaison :
BSNS-3560-1# show debugging
DHCP Snooping packet debugging is on
DHCP Snooping event debugging is on
DHCP server packet debugging is on.
DHCP server event debugging is on.
track:
IP device-tracking redundancy events debugging is on
IP device-tracking cache entry Creation debugging is on
IP device-tracking cache entry Destroy debugging is on
IP device-tracking cache events debugging is on
02:30:57: DHCP_SNOOPING: checking expired snoop binding entries
02:31:12: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Fa0/1 for pak. Was Vl1
02:31:12: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Vl1 for pak. Was Fa0/1
02:31:12: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Fa0/1 for pak. Was Vl1
02:31:12: DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/1)
02:31:12: DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input
interface: Fa0/1, MAC da: 001f.27e6.cfc0, MAC sa: 0050.5699.4ea1, IP da: 192.168.0.2,
IP sa: 192.168.0.241, DHCP ciaddr: 192.168.0.241, DHCP yiaddr: 0.0.0.0,
DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0050.5699.4ea1
02:31:12: DHCP_SNOOPING: add relay information option.
02:31:12: DHCP_SNOOPING_SW: Encoding opt82 CID in vlan-mod-port format
02:31:12: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format
02:31:12: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x1 0x1 0x3 0x2 0x8 0x0 0x6 0x0 0x1F 0x27 0xE6 0xCF 0x80
02:31:12: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: 001F.27E6.CFC0,
packet is flooded to ingress VLAN: (1)
02:31:12: DHCP_SNOOPING_SW: bridge packet send packet to cpu port: Vlan1.
02:31:12: DHCPD: DHCPREQUEST received from client 0100.5056.994e.a1.
02:31:12: DHCPD: Sending DHCPACK to client 0100.5056.994e.a1 (192.168.0.241).
02:31:12: DHCPD: unicasting BOOTREPLY to client 0050.5699.4ea1 (192.168.0.241).
02:31:12: DHCP_SNOOPING: received new DHCP packet from input interface (Vlan1)
02:31:12: DHCP_SNOOPING: process new DHCP packet, message type: DHCPACK, input interface:
Vl1, MAC da: 0050.5699.4ea1, MAC sa: 001f.27e6.cfc0, IP da: 192.168.0.241,
IP sa: 192.168.0.2, DHCP ciaddr: 192.168.0.241, DHCP yiaddr: 192.168.0.241,
DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0050.5699.4ea1
02:31:12: DHCP_SNOOPING: add binding on port FastEthernet0/1.
02:31:12: DHCP_SNOOPING: added entry to table (index 189)
02:31:12: DHCP_SNOOPING: dump binding entry: Mac=00:50:56:99:4E:A1 Ip=192.168.0.241
Lease=86400 ld Type=dhcp-snooping Vlan=1 If=FastEthernet0/1
Une fois la liaison DHCP ajoutée à la base de données, elle déclenche la notification pour le suivi des périphériques :
02:31:12: sw_host_track-ev:host_track_notification: Add event for host 0050.5699.4ea1,
192.168.0.241 on interface FastEthernet0/1
02:31:12: sw_host_track-ev:Async Add event for host 0050.5699.4ea1, 192.168.0.241
on interface FastEthernet0/1
02:31:12: sw_host_track-ev:MSG = 2
02:31:12: DHCP_SNOOPING_SW no entry found for 0050.5699.4ea1 0.0.0.1 FastEthernet0/1
02:31:12: DHCP_SNOOPING_SW host tracking not found for update add dynamic
(192.168.0.241, 0.0.0.0, 0050.5699.4ea1) vlan 1
02:31:12: DHCP_SNOOPING: direct forward dhcp reply to output port: FastEthernet0/1.
02:31:12: sw_host_track-ev:Add event: 0050.5699.4ea1, 192.168.0.241, FastEthernet0/1
02:31:12: sw_host_track-obj_create:0050.5699.4ea1(192.168.0.241) Cache entry created
02:31:12: sw_host_track-ev:Activating host 0050.5699.4ea1, 192.168.0.241 on
interface FastEthernet0/1
02:31:12: sw_host_track-ev:0050.5699.4ea1 Starting cache timer: 30 seconds
Les sondes ARP sont envoyées par défaut toutes les 30 secondes :
02:41:12: sw_host_track-ev:0050.5699.4ea1 Stopping cache timer
02:41:12: sw_host_track-ev:0050.5699.4ea1: Send Host probe (0)
02:41:12: sw_host_track-ev:0050.5699.4ea1 Starting cache timer: 30 seconds
02:41:42: sw_host_track-ev:0050.5699.4ea1 Stopping cache timer
02:41:42: sw_host_track-ev:0050.5699.4ea1: Send Host probe (1)
02:41:42: sw_host_track-ev:0050.5699.4ea1 Starting cache timer: 30 seconds
02:42:12: sw_host_track-ev:0050.5699.4ea1 Stopping cache timer
02:42:12: sw_host_track-ev:0050.5699.4ea1: Send Host probe (2)
02:42:12: sw_host_track-ev:0050.5699.4ea1 Starting cache timer: 30 seconds
02:42:42: sw_host_track-ev:0050.5699.4ea1 Stopping cache timer
02:42:42: sw_host_track-obj_destroy:0050.5699.4ea1(192.168.0.241): Cache entry deleted
02:42:42: sw_host_track-ev:0050.5699.4ea1 Stopping cache timer
Une fois l'entrée supprimée de la table de suivi des périphériques, l'entrée de liaison DHCP correspondante est toujours présente :
BSNS-3560-1#show ip device tracking all
IP Device Tracking = Enabled
--------------------------------------------------------------
IP Address MAC Address Interface STATE
--------------------------------------------------------------
BSNS-3560-1#show ip dhcp binding
IP address Client-ID/ Lease expiration Type
Hardware address
192.168.0.241 0100.5056.994e.a1 Mar 02 1993 03:06 AM Automatic
Il y a un problème lorsque vous avez une réponse ARP, mais l'entrée de suivi de périphérique est quand même supprimée. Ce bogue semble se trouver dans la version 12.2.33 et n'est pas apparu dans la version 12.2.55 ou 15.x du logiciel.
Il existe également certaines différences lors de la gestion avec le port L2 (port d'accès) et le port L3 (pas de port de commutation).
Suivi des périphériques avec la fonction de surveillance ARP :
BSNS-3560-1#show debugging
ARP:
ARP packet debugging is on
Arp Snoop:
Arp Snooping debugging is on
03:43:36: sw_host_track-ev:0050.5699.4ea1 Stopping cache timer
03:43:36: sw_host_track-ev:0050.5699.4ea1: Send Host probe (0)
03:43:36: IP ARP: sent req src 0.0.0.0 001f.27e6.cf83,
dst 192.168.0.241 0050.5699.4ea1 FastEthernet0/1
03:43:36: sw_host_track-ev:0050.5699.4ea1 Starting cache timer: 30 seconds
03:43:36: IP ARP: rcvd rep src 192.168.0.241 0050.5699.4ea1, dst 0.0.0.0 Vlan1
Pour la version 12.2, il peut être nécessaire d'utiliser une commande masquée pour l'activer :
BSNS-3560-1#show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 2
IP Device Tracking Probe Interval = 30
IP Device Tracking Probe Delay Interval = 0
-----------------------------------------------------------------------
IP Address MAC Address Vlan Interface STATE
-----------------------------------------------------------------------
192.168.0.244 0050.5699.4ea1 55 FastEthernet0/1 ACTIVE
Total number interfaces enabled: 1
Enabled interfaces:
Fa0/1
BSNS-3560-1#ip device tracking interface fa0/48
BSNS-3560-1#show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 2
IP Device Tracking Probe Interval = 30
IP Device Tracking Probe Delay Interval = 0
-----------------------------------------------------------------------
IP Address MAC Address Vlan Interface STATE
-----------------------------------------------------------------------
10.48.67.87 000c.2978.825d 1006 FastEthernet0/48 ACTIVE
10.48.67.31 020a.dada.dada 1006 FastEthernet0/48 ACTIVE
10.48.66.245 acf2.c5ed.8171 1006 FastEthernet0/48 ACTIVE
192.168.0.244 0050.5699.4ea1 55 FastEthernet0/1 ACTIVE
10.48.66.193 000c.2997.4ca1 1006 FastEthernet0/48 ACTIVE
10.48.66.186 0050.5699.3431 1006 FastEthernet0/48 ACTIVE
Total number interfaces enabled: 2
Enabled interfaces:
Fa0/1, Fa0/48
Dans cet exemple, le PC a été configuré avec une adresse IP statique. Les débogages montrent qu'après avoir obtenu une réponse ARP (MSG=2), l'entrée de suivi de périphérique est mise à jour.
01:03:16: sw_host_track-ev:0050.5699.4ea1 Stopping cache timer
01:03:16: sw_host_track-ev:0050.5699.4ea1: Send Host probe (0)
01:03:16: sw_host_track-ev:0050.5699.4ea1 Starting cache timer: 30 seconds
01:03:16: sw_host_track-ev:host_track_notification: Add event for host 0050.5699.4ea1,
192.168.0.241 on interface FastEthernet0/1, vlan 1
01:03:16: sw_host_track-ev:Async Add event for host 0050.5699.4ea1, 192.168.0.241
on interface FastEthernet0/1
01:03:16: sw_host_track-ev:MSG = 2
01:03:16: sw_host_track-ev:Add event: 0050.5699.4ea1, 192.168.0.241, FastEthernet0/1
01:03:16: sw_host_track-ev:0050.5699.4ea1: Cache entry refreshed
01:03:16: sw_host_track-ev:Activating host 0050.5699.4ea1, 192.168.0.241 on
interface FastEthernet0/1
01:03:16: sw_host_track-ev:0050.5699.4ea1 Starting cache timer: 30 seconds
Ainsi, chaque requête ARP du PC met à jour la table de suivi des périphériques (l'adresse MAC de l'expéditeur et l'adresse IP de l'expéditeur du paquet ARP).
Il est important de se rappeler que certaines des fonctionnalités telles que DACL pour 802.1x ne sont pas prises en charge dans la version LAN Lite (attention : Cisco Feature Navigator n'affiche pas toujours les informations correctes).
La commande masquée de la version 12.2 peut être exécutée, mais n'aura aucun effet. Dans la version 15.x du logiciel, le suivi des périphériques IP (IPDT) par défaut n'est activé que pour les interfaces pour lesquelles 802.1x est activé :
bsns-3750-5#show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 30
IP Device Tracking Probe Delay Interval = 0
-----------------------------------------------------------------------
IP Address MAC Address Vlan Interface STATE
-----------------------------------------------------------------------
192.168.10.12 0007.5032.6941 100 GigabitEthernet1/0/1 ACTIVE
192.168.2.200 000c.29d7.0617 1 GigabitEthernet1/0/1 ACTIVE
Total number interfaces enabled: 2
Enabled interfaces:
Gi1/0/1, Gi1/0/2
bsns-3750-5#show run int g1/0/3
Building configuration...
Current configuration : 38 bytes
!
interface GigabitEthernet1/0/3
bsns-3750-5(config)#int g1/0/3
bsns-3750-5(config-if)#switchport mode access
bsns-3750-5(config-if)#authentication port-control auto
bsns-3750-5(config-if)#do show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 30
IP Device Tracking Probe Delay Interval = 0
-----------------------------------------------------------------------
IP Address MAC Address Vlan Interface STATE
-----------------------------------------------------------------------
192.168.10.12 0007.5032.6941 100 GigabitEthernet1/0/1 ACTIVE
192.168.2.200 000c.29d7.0617 1 GigabitEthernet1/0/1 ACTIVE
Total number interfaces enabled: 3
Enabled interfaces:
Gi1/0/1, Gi1/0/2, Gi1/0/3
Après la suppression de la configuration 802.1x du port, IPDT sera également supprimé de ce port. L'état du port peut être « DOWN », il est donc nécessaire d'avoir « switchport mode access » et « authentication port-control auto » pour que le suivi du périphérique IP soit activé sur ce port. La limite maximale du périphérique d'interface est définie sur 10 :
bsns-3750-5(config-if)#ip device tracking maximum ?
<1-10> Maximum devices
Encore une fois, le comportement de Cisco IOS-XE 3.3 a changé par rapport à la version 15.x de Cisco IOS. La commande masquée de la version 12.2 est obsolète, mais cette erreur sera renvoyée :
3850-1# no ip device tracking int g1/0/48
% Command accepted but obsolete, unreleased or unsupported; see documentation.
Dans Cisco IOS-XE, le suivi des périphériques est activé pour toutes les interfaces (même celles qui n'ont pas configuré 802.1x) :
3850-1#show ip device tracking all
Global IP Device Tracking for clients = Enabled
Global IP Device Tracking Probe Count = 3
Global IP Device Tracking Probe Interval = 30
Global IP Device Tracking Probe Delay Interval = 0
---------------------------------------------------------------------------------------
IP Address MAC Address Vlan Interface Probe-Timeout
State Source
---------------------------------------------------------------------------------------
10.48.39.29 000c.29bd.3cfa 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.28 0016.9dca.e4a7 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.76.117 0021.a0ff.5540 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.21 00c0.9f87.7471 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.16 0050.5699.1093 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.76.191.247 0024.9769.58cf 20 GigabitEthernet1/0/48 30
ACTIVE ARP
192.168.99.4 d48c.b52f.4a1e 99 GigabitEthernet1/0/12 30
INACTIVE ARP
10.48.39.13 000c.296e.8dbc 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.15 0050.5699.128d 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.9 0012.da20.8c00 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.8 6c20.560e.1b64 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.11 000c.29e9.db25 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.5 0014.f15f.f7ca 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.4 000c.2972.57bc 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.7 5475.d029.74cf 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.76.108 001c.58de.9340 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.1 0006.f62a.c4a3 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.3 0050.5699.1bee 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.76.84 0015.58c5.e8b7 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.56 0015.fa13.9a40 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.59 0050.5699.1bf4 1 GigabitEthernet1/0/48 30
ACTIVE ARP
10.48.39.58 000c.2957.c7ad 1 GigabitEthernet1/0/48 30
ACTIVE ARP
Total number interfaces enabled: 57
Enabled interfaces:
Gi1/0/1, Gi1/0/2, Gi1/0/3, Gi1/0/4, Gi1/0/5, Gi1/0/6, Gi1/0/7,
Gi1/0/8, Gi1/0/9, Gi1/0/10, Gi1/0/11, Gi1/0/12, Gi1/0/13, Gi1/0/14,
Gi1/0/15, Gi1/0/16, Gi1/0/17, Gi1/0/18, Gi1/0/19, Gi1/0/20, Gi1/0/21,
Gi1/0/22, Gi1/0/23, Gi1/0/24, Gi1/0/25, Gi1/0/26, Gi1/0/27, Gi1/0/28,
Gi1/0/29, Gi1/0/30, Gi1/0/31, Gi1/0/32, Gi1/0/33, Gi1/0/34, Gi1/0/35,
Gi1/0/36, Gi1/0/37, Gi1/0/38, Gi1/0/39, Gi1/0/40, Gi1/0/41, Gi1/0/42,
Gi1/0/43, Gi1/0/44, Gi1/0/45, Gi1/0/46, Gi1/0/47, Gi1/0/48, Gi1/1/1,
Gi1/1/2, Gi1/1/3, Gi1/1/4, Te1/1/1, Te1/1/2, Te1/1/3, Te1/1/4
3850-1#$
3850-1#sh run int g1/0/48
Building configuration...
Current configuration : 39 bytes
!
interface GigabitEthernet1/0/48
end
3850-1(config-if)#ip device tracking maximum ?
<0-65535> Maximum devices (0 means disabled)
En outre, il n'y a aucune limite pour les entrées maximales par port (0 signifie désactivé).
Si 802.1x est configuré avec DACL, l'entrée de suivi de périphérique est utilisée afin de remplir l'adresse IP du périphérique. Cet exemple montre comment le suivi des périphériques fonctionne pour une adresse IP configurée de manière statique :
BSNS-3560-1#show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 2
IP Device Tracking Probe Interval = 30
IP Device Tracking Probe Delay Interval = 0
-----------------------------------------------------------------------
IP Address MAC Address Vlan Interface STATE
-----------------------------------------------------------------------
192.168.0.244 0050.5699.4ea1 2 FastEthernet0/1 ACTIVE
Total number interfaces enabled: 1
Enabled interfaces:
Fa0/1
Il s'agit d'une session 802.1x construite avec « permit icmp any any » DACL :
BSNS-3560-1# sh authentication sessions interface fa0/1
Interface: FastEthernet0/1
MAC Address: 0050.5699.4ea1
IP Address: 192.168.0.244
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 2
ACS ACL: xACSACLx-IP-DACL-516c2694
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A3042A900000008008900C5
Acct Session ID: 0x0000000D
Handle: 0x19000008
Runnable methods list:
Method State
dot1x Authc Success
BSNS-3560-1#show epm session summary
EPM Session Information
-----------------------
Total sessions seen so far : 1
Total active sessions : 1
Interface IP Address MAC Address Audit Session Id:
--------------------------------------------------------------------------
FastEthernet0/1 192.168.0.244 0050.5699.4ea1 0A3042A900000008008900C5
Ceci affiche une liste de contrôle d’accès appliquée :
BSNS-3560-1#show ip access-lists
Extended IP access list Auth-Default-ACL
10 permit udp any range bootps 65347 any range bootpc 65348
20 permit udp any any range bootps 65347
30 deny ip any any (8 matches)
Extended IP access list xACSACLx-IP-DACL-516c2694 (per-user)
10 permit icmp any any (6 matches)
En outre, la liste de contrôle d’accès sur l’interface fa0/1 est identique :
BSNS-3560-1#show ip access-lists interface fa0/1
permit icmp any any
Même si la valeur par défaut est dot1x ACL :
BSNS-3560-1#show ip interface fa0/1
FastEthernet0/1 is up, line protocol is up
Inbound access list is Auth-Default-ACL
Il est possible que la liste de contrôle d’accès utilise « any » comme 192.168.0.244. Cela fonctionne comme ceci pour le proxy auth, mais pour 802.1x DACL src « any » n'est pas changé en l'adresse IP détectée du PC.
Pour le proxy d'authentification, une liste de contrôle d'accès d'origine de l'ACS est mise en cache et affichée avec la commande show ip access-list et une liste de contrôle d'accès spécifique (par utilisateur avec IP spécifique) est appliquée sur l'interface à l'aide de la commande show ip access-list interface fa0/1. Cependant, le proxy d'authentification n'utilise pas le suivi IP des périphériques.
Que se passe-t-il si l’adresse IP n’est pas détectée correctement ? Une fois le suivi des périphériques désactivé :
BSNS-3560-1#show authentication sessions interface fa0/1
Interface: FastEthernet0/1
MAC Address: 0050.5699.4ea1
IP Address: Unknown
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 2
ACS ACL: xACSACLx-IP-DACL-516c2694
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A3042A9000000000000C775
Acct Session ID: 0x00000001
Handle: 0xB0000000
Runnable methods list:
Method State
dot1x Authc Success
Aucune adresse IP n'est donc jointe alors, mais la DACL est toujours appliquée :
BSNS-3560-1#show ip access-lists
Extended IP access list Auth-Default-ACL
10 permit udp any range bootps 65347 any range bootpc 65348
20 permit udp any any range bootps 65347
30 deny ip any any (4 matches)
Extended IP access list xACSACLx-IP-DACL-516c2694 (per-user)
10 permit icmp any any
Dans ce scénario, le suivi des périphériques pour 802.1x n'est pas requis. La seule différence est que la connaissance de l'adresse IP du client au début peut être utilisée pour une demande d'accès RADIUS. Une fois l'attribut 8 attaché :
radius-server attribute 8 include-in-access-req
Il existe dans Access-Request et sur ACS il sera possible de créer des règles d'autorisation plus granulaires :
00:17:44: RADIUS(00000001): Send Access-Request to 10.48.66.185:1645 id 1645/27, len 257
00:17:44: RADIUS: authenticator F8 17 06 CE C1 85 E8 E8 - CB 5B 57 96 6C 07 CE CA
00:17:44: RADIUS: User-Name [1] 7 "cisco"
00:17:44: RADIUS: Service-Type [6] 6 Framed [2]
00:17:44: RADIUS: Framed-IP-Address [8] 6 192.168.0.244
Gardez à l'esprit que TrustSec a également besoin d'un suivi des périphériques IP pour les liaisons IP à SGT.
Quelle est la différence entre la version 15.x et la version 12.2.55 dans DACL ? Dans le logiciel Version15.x, il fonctionne de la même manière que pour auth-proxy. La liste de contrôle d'accès générique peut être vue lorsque la commande show ip access-list est entrée (réponse mise en cache d'AAA), mais après la commande show ip access-list interface fa0/1, la commande src « any » est remplacée par l'adresse IP source de l'hôte (connue via le suivi des périphériques IP).
Voici l'exemple d'un téléphone et d'un PC sur un port (g1/0/1), de la version logicielle 15.0.2SE2 sur 3750X :
bsns-3750-5#sh authentication sessions interface g1/0/1
Interface: GigabitEthernet1/0/1
MAC Address: 0007.5032.6941
IP Address: 192.168.10.12
User-Name: 00-07-50-32-69-41
Status: Authz Success
Domain: VOICE
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 100
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-51134bb2
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A80001000001012B680D23
Acct Session ID: 0x0000017B
Handle: 0x99000102
Runnable methods list:
Method State
dot1x Failed over
mab Authc Success
----------------------------------------
Interface: GigabitEthernet1/0/1
MAC Address: 0050.5699.4ea1
IP Address: 192.168.2.200
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 20
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-51134bb2
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A80001000001BD336EC4D6
Acct Session ID: 0x000002F9
Handle: 0xF80001BE
Runnable methods list:
Method State
dot1x Authc Success
mab Not run
Le téléphone est authentifié via le contournement d'authentification MAC (MAB), tandis que le PC utilise dot1x. Le téléphone et le PC utilisent la même liste de contrôle d’accès :
bsns-3750-5#show ip access-lists xACSACLx-IP-PERMIT_ALL_TRAFFIC-51134bb2
Extended IP access list xACSACLx-IP-PERMIT_ALL_TRAFFIC-51134bb2 (per-user)
10 permit ip any any
Cependant, une fois vérifiée au niveau de l'interface, la source a été remplacée par l'adresse IP du périphérique. Le suivi des périphériques IP déclenche les modifications et peut se produire à tout moment (bien plus tard que la session d’authentification et le téléchargement de la liste de contrôle d’accès) :
bsns-3750-5#show ip access-lists interface g1/0/1
permit ip host 192.168.2.200 any (5 matches)
permit ip host 192.168.10.12 any
Les deux adresses MAC doivent être marquées comme statiques :
bsns-3750-5#sh mac address-table interface g1/0/1
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
20 0050.5699.4ea1 STATIC Gi1/0/1
100 0007.5032.6941 STATIC Gi1/0/1
Quand la source « any » de la DACL est-elle remplacée par l'adresse IP de l'hôte ? Uniquement lorsqu'il y a au moins deux sessions sur le même port (deux supplicants).
Il n'est pas nécessaire de remplacer la source « any » lorsqu'il n'y a qu'une seule session. Les problèmes peuvent apparaître lorsqu'il y a plusieurs sessions, et pour toutes, le suivi de périphérique IP ne connaît pas l'adresse IP de l'hôte. Dans ce scénario, il restera « any » pour certaines entrées.
Ce comportement est différent sur certaines plates-formes. Par exemple, sur le 2960X avec la version 15.0(2)EX, la liste de contrôle d’accès sera toujours spécifique même s’il n’y a qu’une seule session d’authentification par port. Cependant, pour les versions 3560X et 3750X 15.0(2)SE, vous devez avoir au moins deux sessions pour rendre cette liste de contrôle d'accès spécifique.
Par défaut, le contrôle-direction est de type deux :
bsns-3750-5(config)#int g1/0/1
bsns-3750-5(config-if)#authentication control-direction ?
both Control traffic in BOTH directions
in Control inbound traffic only
bsns-3750-5(config-if)#authentication control-direction both
Cela signifie qu'avant l'authentification du demandeur, le trafic ne peut pas être envoyé vers ou depuis le port. En mode « in », le trafic aurait pu être envoyé du port au demandeur, mais pas du demandeur au port (pourrait être utile pour la fonctionnalité WAKE sur LAN).
Néanmoins, le commutateur applique la liste de contrôle d’accès uniquement dans la direction « in ». Peu importe le mode utilisé.
bsns-3750-5#sh ip access-lists interface g1/0/1 out
bsns-3750-5#sh ip access-lists interface g1/0/1 in
permit ip host 192.168.2.200 any
permit ip host 192.168.10.12 any
Cela signifie qu’après authentification, la liste de contrôle d’accès est appliquée au trafic vers le port (en direction) et tout le trafic est autorisé à partir du port (en direction).
Il est également possible d'utiliser une liste de contrôle d'accès par utilisateur qui est transmise dans cisco-av-pair « ip : inacl » et « ip : outacl ».
Cet exemple de configuration est similaire à une configuration précédente, mais cette fois le téléphone utilise DACL et le PC utilise une ACL par utilisateur. Le profil ISE du PC est le suivant :
La DACL du téléphone est toujours appliquée :
bsns-3750-5#show authentication sessions interface g1/0/1
Interface: GigabitEthernet1/0/1
MAC Address: 0007.5032.6941
IP Address: 192.168.10.12
User-Name: 00-07-50-32-69-41
Status: Authz Success
Domain: VOICE
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 100
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-51134bb2
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A8000100000568431143D8
Acct Session ID: 0x000006D2
Handle: 0x84000569
Runnable methods list:
Method State
dot1x Failed over
mab Authc Success
bsns-3750-5#sh ip access-lists xACSACLx-IP-PERMIT_ALL_TRAFFIC-51134bb2
Extended IP access list xACSACLx-IP-PERMIT_ALL_TRAFFIC-51134bb2 (per-user)
10 permit ip any any
Cependant, le PC sur le même port utilise la liste de contrôle d’accès par utilisateur :
Interface: GigabitEthernet1/0/1
MAC Address: 0050.5699.4ea1
IP Address: 192.168.2.200
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 20
Per-User ACL: permit icmp any any log
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A80001000005674311400B
Acct Session ID: 0x000006D1
Handle: 0x9D000568
Afin de vérifier comment elle est fusionnée sur le port gig1/0/1 :
bsns-3750-5#show ip access-lists interface g1/0/1
permit icmp host 192.168.2.200 any log
permit ip host 192.168.10.12 any
La première entrée a été tirée de la liste de contrôle d'accès par utilisateur (notez le mot clé log) et la deuxième entrée provient de la liste de contrôle d'accès DACL. Les deux sont réécrits par le suivi des périphériques IP pour l'adresse IP spécifique.
La liste de contrôle d'accès par utilisateur a pu être vérifiée à l'aide de la commande debug epm all :
Apr 12 02:30:13.489: EPM_SESS_EVENT:IP Per-User ACE: permit icmp any any log received
Apr 12 02:30:13.489: EPM_SESS_EVENT:Recieved string GigabitEthernet1/0/1#IP#7844C6C
Apr 12 02:30:13.489: EPM_SESS_EVENT:Add ACE [permit icmp any any log] to ACL
[GigabitEthernet1/0/1#IP#7844C6C]
Apr 12 02:30:13.497: EPM_SESS_EVENT:Executed [ip access-list extended
GigabitEthernet1/0/1#IP#7844C6C] command through parse_cmd. Result= 0
Apr 12 02:30:13.497: EPM_SESS_EVENT:Executed [permit icmp any any log]
command through parse_cmd. Result= 0
Apr 12 02:30:13.497: EPM_SESS_EVENT:Executed [end] command through
parse_cmd. Result= 0
Apr 12 02:30:13.497: EPM_SESS_EVENT:Notifying PD regarding Policy (NAMED ACL)
application on the interface GigabitEthernet1/0/1
Et aussi via la commande show ip access-lists :
bsns-3750-5#show ip access-lists
Extended IP access list GigabitEthernet1/0/1#IP#7844C6C (per-user)
10 permit icmp any any log
Qu'en est-il de l'attribut ip:outacl ? Il est complètement omis dans la version 15.x. L'attribut a été reçu, mais le commutateur n'applique pas/ne traite pas cet attribut.
Comme indiqué dans l'ID de bogue Cisco CSCut25702, la liste de contrôle d'accès par utilisateur se comporte différemment de la liste DACL. DACL avec une seule entrée (« permit ip any any ») et un seul demandeur connecté à un port peut fonctionner correctement sans que le suivi des périphériques IP soit activé. L'argument « any » ne sera pas remplacé et tout le trafic sera autorisé. Cependant, pour la liste de contrôle d’accès par utilisateur, le suivi des périphériques IP doit être activé. Si elle est désactivée et que l'entrée « permit ip any any any » et un demandeur sont simplement activés, tout le trafic sera bloqué.
En outre, l'ID de filtre d'attribut IETF [11] peut être utilisé. Le serveur AAA renvoie le nom de la liste de contrôle d’accès, qui doit être défini localement sur le commutateur. Le profil ISE peut ressembler à ceci :
Notez que vous devez spécifier la direction (entrée ou sortie). Pour cela, il est nécessaire d'ajouter l'attribut manuellement :
Puis le débogage affiche :
debug epm all
Apr 12 23:41:05.170: EPM_SESS_EVENT:Filter-Id : Filter-ACL received
Apr 12 23:41:05.170: EPM_SESS_EVENT:Notifying PD regarding Policy (NAMED ACL)
application on the interface GigabitEthernet1/0/1
Cette liste de contrôle d’accès sera également affichée pour la session authentifiée :
bsns-3750-5#show authentication sessions interface g1/0/1
Interface: GigabitEthernet1/0/1
MAC Address: 0050.5699.4ea1
IP Address: 192.168.2.200
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: 20
Filter-Id: Filter-ACL
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A800010000059E47B77481
Acct Session ID: 0x00000733
Handle: 0x5E00059F
Runnable methods list:
Method State
dot1x Authc Success
mab Not run
Et, comme la liste de contrôle d’accès est liée à l’interface :
bsns-3750-5#show ip access-lists interface g1/0/1
permit icmp host 192.168.2.200 any log
permit tcp host 192.168.2.200 any log
Notez que cette liste de contrôle d’accès peut être fusionnée avec d’autres types de listes de contrôle d’accès sur la même interface. Par exemple, si vous avez sur le même port de commutateur un autre demandeur qui reçoit la DACL de ISE : « permit ip any any any », vous pouvez voir :
bsns-3750-5#show ip access-lists interface g1/0/1
permit icmp host 192.168.2.200 any log
permit tcp host 192.168.2.200 any log
permit ip host 192.168.10.12 any
Notez que le suivi du périphérique IP réécrit l'adresse IP source pour chaque source (demandeur).
Qu'en est-il de la liste de filtres « out » ? Encore une fois (comme ACL par utilisateur), elle ne sera pas utilisée par le commutateur.
Pour les versions antérieures à 15.2(1)E, avant qu'une fonctionnalité puisse utiliser IPDT, elle doit être activée globalement d'abord avec cette commande CLI :
(config)#ip device tracking
Pour les versions 15.2(1)E et ultérieures, la commande ip device tracking n'est plus nécessaire. IPDT n'est activé que si une fonctionnalité qui s'en appuie l'active. Si aucune fonction n'active IPDT, IPDT est désactivé. La commande « no ip device tracking » n'a aucun effet. La fonction spécifique dispose du contrôle permettant d'activer/de désactiver IPDT.
Lorsque vous activez IPDT, vous devez vous rappeler le problème de l'adresse IP dupliquée sur . Reportez-vous à Dépannage des messages d'erreur « Dupliquer l'adresse IP 0.0.0.0 » pour plus d'informations.
Il est recommandé de désactiver IPDT sur un port agrégé :
(config-if)# no ip device tracking
Sur la dernière version de Cisco IOS, il s’agit d’une commande différente :
(config-if)# ip device tracking maximum 0
Il est recommandé d'activer l'IPDT sur le port d'accès et de retarder les sondes ARP afin d'éviter le problème de l'« adresse IP dupliquée » :
(config-if)# ip device tracking probe delay 10
Pour la liste de contrôle d’accès d’interface, elle fonctionne avant l’authentification :
interface GigabitEthernet1/0/2
description windows7
switchport mode access
ip access-group test1 in
authentication order mab dot1x
authentication port-control auto
mab
dot1x pae authenticator
end
bsns-3750-5#show ip access-lists test1
Extended IP access list test1
10 permit tcp any any log-input
Cependant, une fois l'authentification réussie, elle est réécrite (écrasée) par la liste de contrôle d'accès renvoyée par le serveur AAA (peu importe qu'il s'agisse de DACL, ip : inacl ou filterid).
Cette liste de contrôle d’accès (test1) peut bloquer le trafic (qui serait normalement autorisé en mode ouvert), mais après l’authentification n’a plus d’importance. Même lorsqu’aucune liste de contrôle d’accès n’est renvoyée par le serveur AAA, la liste de contrôle d’accès de l’interface est écrasée et un accès complet est fourni. Cela est un peu trompeur car la mémoire TCAM (Ternary Content Addressable Memory) indique que la liste de contrôle d’accès est toujours liée au niveau de l’interface. Voici un exemple de la version 15.2.2 sur 3750X :
bsns-3750-6#show platform acl portlabels interface g1/0/2
Port based ACL: (asic 1)
----------------------------
Input Label: 5 Op Select Index: 255
Interface(s): Gi1/0/2
Access Group: test1, 4 VMRs
Ip Portal: 0 VMRs
IP Source Guard: 0 VMRs
LPIP: 0 VMRs
AUTH: 0 VMRs
C3PLACL: 0 VMRs
MAC Access Group: (none), 0 VMRs
Ces informations ne sont valides que pour le niveau interface et non pour le niveau session. Vous pouvez déduire plus d'informations (présente une liste de contrôle d'accès composée) à partir de :
bsns-3750-6#show ip access-lists interface g1/0/2
permit ip host 192.168.1.203 any
Extended IP access list test1
10 permit icmp host 2.2.2.2 host 1.1.1.1
La première entrée est créée en tant que « permit ip any any » DACL est renvoyée pour une authentification réussie (et « any » est remplacé par une entrée de la table de suivi des périphériques). La deuxième entrée est le résultat de la liste de contrôle d’accès de l’interface et est appliquée à toutes les nouvelles authentifications (avant autorisation).
Malheureusement, les deux listes de contrôle d’accès sont concaténées (dépendantes de la plate-forme). Cela se produit sur la version 15.2.2 sur 3750X. Cela signifie que pour les sessions autorisées, les deux sont appliquées. D’abord la DACL et ensuite la liste de contrôle d’accès de l’interface. C'est pourquoi lorsque vous ajoutez explicitement « deny ip any any any », la DACL ne prend pas en compte la liste de contrôle d'accès de l'interface. En règle générale, il n'y a pas de refus explicite dans la DACL, puis la liste de contrôle d'accès de l'interface est appliquée après cela.
Le comportement de la version 15.0.2 sur 3750X est le même, mais la commande sh ip access-list interface n'affiche plus la liste de contrôle d'accès de l'interface (mais elle sera toujours concaténée avec la liste de contrôle d'accès de l'interface, sauf s'il existe un refus explicite dans la liste de contrôle d'accès).
Il existe deux types de listes de contrôle d’accès par défaut :
Les deux méthodes auth-default-ACL et auth-default-ACL-OPEN sont utilisées lorsque le port est dans l'état non autorisé. Par défaut, l'accès fermé est utilisé. Cela signifie qu'avant l'authentification, tout le trafic est abandonné, sauf celui autorisé par la liste de contrôle d'accès auth-default-ACL. De cette manière, le trafic DHCP est autorisé avant l'autorisation réussie. L'adresse IP est allouée et la DACL téléchargée peut être appliquée correctement. Cette liste de contrôle d’accès est créée automatiquement et est introuvable dans la configuration.
bsns-3750-5#sh run | i Auth-Default
bsns-3750-5#sh ip access-lists Auth-Default-ACL
Extended IP access list Auth-Default-ACL
10 permit udp any range bootps 65347 any range bootpc 65348 (22 matches)
20 permit udp any any range bootps 65347 (12 matches)
30 deny ip any any
Il est créé dynamiquement pour la première authentification (entre la phase d'authentification et d'autorisation) et supprimé après la dernière session.
Auth-Default-ACL autorise uniquement le trafic DHCP. Une fois l'authentification réussie et la nouvelle DACL téléchargée, elle est appliquée à cette session.Lorsque le mode est modifié pour ouvrir auth-default-ACL-OPEN apparaît et est utilisé et fonctionne exactement de la même manière que Auth-Default-ACL :
bsns-3750-5(config)#int g1/0/2
bsns-3750-5(config-if)#authentication open
bsns-3750-5#show ip access-lists
Extended IP access list Auth-Default-ACL-OPEN
10 permit ip any any
Les deux listes de contrôle d’accès peuvent être personnalisées, mais elles ne seront jamais visibles dans la configuration.
bsns-3750-5(config)#ip access-list extended Auth-Default-ACL
bsns-3750-5(config-ext-nacl)#permit udp any any
bsns-3750-5#sh ip access-lists
Extended IP access list Auth-Default-ACL
10 permit udp any range bootps 65347 any range bootpc 65348 (22 matches)
20 permit udp any any range bootps 65347 (16 matches)
30 deny ip any any
40 permit udp any any
bsns-3750-5#sh run | i Auth-Def
bsns-3750-5#
La section précédente décrit le comportement des listes de contrôle d’accès (qui inclut celle utilisée par défaut pour le mode ouvert). Le comportement du mode ouvert est le suivant :
Pour plusieurs plates-formes 6500/4500, la liste de contrôle d'accès d'interface est obligatoire afin d'appliquer correctement la DACL.
Voici un exemple avec 4500 sup2 12.2.53SG6, pas de liste de contrôle d'accès d'interface :
brisk#show run int g2/3
!
interface GigabitEthernet2/3
switchport mode access
switchport voice vlan 10
authentication host-mode multi-auth
authentication open
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
mab
Une fois l’hôte authentifié, la DACL est téléchargée. Il ne sera pas appliqué et l'autorisation échouera.
*Apr 25 04:38:05.239: RADIUS: Received from id 1645/19 10.48.66.74:1645, Access-Accept,
len 209
*Apr 25 04:38:05.239: RADIUS: authenticator 35 8E 59 E4 D5 CF 8F 9A -
EE 1C FC 5A 9F 67 99 B2
*Apr 25 04:38:05.239: RADIUS: User-Name [1] 41
"#ACSACL#-IP-PERMIT_ALL_TRAFFIC-51ef7db1"
*Apr 25 04:38:05.239: RADIUS: State [24] 40
*Apr 25 04:38:05.239: RADIUS: 52 65 61 75 74 68 53 65 73 73 69 6F 6E 3A 30 61
[ReauthSession:0a]
*Apr 25 04:38:05.239: RADIUS: 33 30 34 32 34 61 30 30 30 45 46 35 30 46 35 33
[30424a000EF50F53]
*Apr 25 04:38:05.239: RADIUS: 35 41 36 36 39 33 [ 5A6693]
*Apr 25 04:38:05.239: RADIUS: Class [25] 54
*Apr 25 04:38:05.239: RADIUS: 43 41 43 53 3A 30 61 33 30 34 32 34 61 30 30 30
[CACS:0a30424a000]
*Apr 25 04:38:05.239: RADIUS: 45 46 35 30 46 35 33 35 41 36 36 39 33 3A 69 73
[EF50F535A6693:is]
*Apr 25 04:38:05.239: RADIUS: 65 32 2F 31 38 30 32 36 39 35 33 38 2F 31 32 38
[e2/180269538/128]
*Apr 25 04:38:05.239: RADIUS: 36 35 35 33 [ 6553]
*Apr 25 04:38:05.239: RADIUS: Message-Authenticato[80] 18
*Apr 25 04:38:05.239: RADIUS: AF 47 E2 20 65 2F 59 39 72 9A 61 5C C5 8B ED F5
[ G e/Y9ra\]
*Apr 25 04:38:05.239: RADIUS: Vendor, Cisco [26] 36
*Apr 25 04:38:05.239: RADIUS: Cisco AVpair [1] 30
"ip:inacl#1=permit ip any any"
*Apr 25 04:38:05.239: RADIUS(00000000): Received from id 1645/19
*Apr 25 04:38:05.247: EPM_SESS_ERR:Failed to apply ACL to interface
*Apr 25 04:38:05.247: EPM_API:In function epm_send_message_to_client
*Apr 25 04:38:05.247: EPM_SESS_EVENT:Sending response message to process
AUTH POLICY Framework
*Apr 25 04:38:05.247: EPM_SESS_EVENT:Returning feature config
*Apr 25 04:38:05.247: EPM_API:In function epm_acl_feature_free
*Apr 25 04:38:05.247: EPM_API:In function epm_policy_aaa_response
*Apr 25 04:38:05.247: EPM_FSM_EVENT:Event epm_ip_wait_event state changed from
policy-apply to ip-wait
*Apr 25 04:38:05.247: EPM_API:In function epm_session_action_ip_wait
*Apr 25 04:38:05.247: EPM_API:In function epm_send_ipwait_message_to_client
*Apr 25 04:38:05.247: EPM_SESS_ERR:NULL feature list for client ctx 1B2694B0
for type DOT1X
*Apr 25 04:38:05.247: %AUTHMGR-5-FAIL: Authorization failed for client
(0007.5032.6941) on Interface Gi2/3
AuditSessionID 0A304345000000060012C050
brisk#show authentication sessions
Interface MAC Address Method Domain Status Session ID
Gi2/3 0007.5032.6941 mab VOICE Authz Failed 0A304345000000060012C050
Une fois la liste de contrôle d’accès de l’interface ajoutée :
brisk#show ip access-lists all
Extended IP access list all
10 permit ip any any (63 matches)
brisk#sh run int g2/3
!
interface GigabitEthernet2/3
switchport mode access
switchport voice vlan 10
ip access-group all in
authentication host-mode multi-auth
authentication open
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
mab
L'authentification et l'autorisation réussiront et la DACL sera appliquée correctement :
brisk#show authentication sessions
Interface MAC Address Method Domain Status Session ID
Gi2/3 0007.5032.6941 mab VOICE Authz Success 0A30434500000008001A2CE4
Le comportement ne dépend pas de « authentication open ». Pour accepter la DACL, vous avez besoin de la liste de contrôle d’accès d’interface pour le mode ouvert/fermé.
Sur le 4500/6500, la DACL est appliquée avec les DACL acl_snoop. Un exemple avec 4500 sup2 12.2.53SG6 (téléphone + PC) est présenté ici. Il existe une liste de contrôle d’accès distincte pour les VLAN voix (10) et données (100) :
brisk#show ip access-lists
Extended IP access list acl_snoop_Gi2/3_10
10 permit ip host 192.168.2.200 any
20 deny ip any any
Extended IP access list acl_snoop_Gi2/3_100
10 permit ip host 192.168.10.12 any
20 deny ip any any
Les listes de contrôle d’accès sont spécifiques, car IPDT possède les entrées correctes :
brisk#show ip device tracking all
IP Device Tracking = Enabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 30
IP Device Tracking Probe Delay Interval = 0
---------------------------------------------------------------------
IP Address MAC Address Vlan Interface STATE
---------------------------------------------------------------------
192.168.10.12 0007.5032.6941 100 GigabitEthernet2/3 ACTIVE
192.168.2.200 000c.29d7.0617 10 GigabitEthernet2/3 ACTIVE
Les sessions authentifiées confirment les adresses :
brisk#show authentication sessions int g2/3
Interface: GigabitEthernet2/3
MAC Address: 000c.29d7.0617
IP Address: 192.168.2.200
User-Name: 00-0C-29-D7-06-17
Status: Authz Success
Domain: VOICE
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A3043450000003003258E0C
Acct Session ID: 0x00000034
Handle: 0x54000030
Runnable methods list:
Method State
mab Authc Success
dot1x Not run
----------------------------------------
Interface: GigabitEthernet2/3
MAC Address: 0007.5032.6941
IP Address: 192.168.10.12
User-Name: 00-07-50-32-69-41
Status: Authz Success
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A3043450000002E031D1DB8
Acct Session ID: 0x00000032
Handle: 0x4A00002E
Runnable methods list:
Method State
mab Authc Success
dot1x Not run
À ce stade, le PC et le téléphone répondent à l’écho ICMP, mais la liste de contrôle d’accès de l’interface présente uniquement :
brisk#show ip access-lists interface g2/3
permit ip host 192.168.10.12 any
Pourquoi ? Parce que la DACL a été poussée uniquement pour le téléphone (192.168.10.12). Pour le PC, la liste de contrôle d’accès de l’interface en mode ouvert est utilisée :
interface GigabitEthernet2/3
ip access-group all in
authentication open
brisk#show ip access-lists all
Extended IP access list all
10 permit ip any any (73 matches)
En résumé, acl_snoop sera créé pour le PC et le téléphone, mais la DACL est renvoyée uniquement pour le téléphone. C’est pourquoi cette liste de contrôle d’accès est considérée comme étant liée à l’interface.
Lorsque l'authentification 802.1x démarre, l'adresse MAC est toujours considérée comme DYNAMIQUE, mais l'action pour ce paquet est DROP :
bsns-3750-5#show authentication sessions
Interface MAC Address Method Domain Status Session ID
Gi1/0/1 0007.5032.6941 dot1x UNKNOWN Running C0A8000100000596479F4DCE
bsns-3750-5#show mac address-table interface g1/0/1
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
100 0007.5032.6941 DYNAMIC Drop
Total Mac Addresses for this criterion: 1
Après une authentification réussie, l'adresse MAC devient statique et le numéro de port est fourni :
bsns-3750-5#show authentication sessions
Interface MAC Address Method Domain Status Session ID
Gi1/0/1 0007.5032.6941 mab VOICE Authz Success C0A8000100000596479F4DCE
bsns-3750-5#show mac address-table interface g1/0/1
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
100 0007.5032.6941 STATIC Gi1/0/1
Cela est vrai pour toutes les sessions mab/dot1x pour les deux domaines (VOICE/DATA).
N'oubliez pas de lire le guide de configuration 802.1x pour connaître la version et la plate-forme de votre logiciel.
Si vous ouvrez un boîtier TAC, fournissez les résultats de ces commandes :
Il est également utile de collecter une capture de paquets de port SPAN et ces débogages :