J’ai testé pour vous Autoconf – ou comment cesser de configurer les interfaces des switchs
La configuration des ports d’accès est une tâche réc
urrente sur les réseaux d’entreprise. Certes ce n’est pas forcément très compliqué: on réplique des modèles et on peut même utiliser les interfaces templates pour cela (cf ce post) mais ça prend du temps, et il faut synchroniser les opérations de branchement et de configuration… Gros projet de déploiement de caméras de vidéosurveillance? A chaque branchement la synchronisation entre le technicien sur le terrain et l’équipe informatique qui réalise la configuration n’est pas toujours indolore: “- Utilise bien le port Gi 2/0/3. – C’est lequel? – Regarde bien! – Celui la? – Non ça ne monte pas! – Attends je n’ai pas encore branché, là? – Non mais je vois un autre port qui est monté…” Et si le port s’auto-configurait selon le type d’équipement branché? C’est bien l’objectif d’Autoconf que je me propose de vous démontrer aujourd’hui…
Autoconf en quelques mots
Autoconf ? La fonctionnalité a fait son apparition l’été dernier sur l’ensemble de nos commutateurs d’accès. Cela succède à auto-smartports et améliore plusieurs points, notamment la manageabilité. Je reviendrai sur ce point, regardons d’abord comment fonctionne Autoconf…
Pour avancer avec Autoconf il faut au préalable comprendre les interface templates. Aussi je vous renvoie à ce post précédent. Comme leur nom l’indique les interfaces templates sont des modèles de configuration que l’on va pouvoir ensuite appeler pour configurer les ports des switchs. Cela évite de répéter n fois la même configuration sur tous les ports et simplifie grandement les opérations tout en améliorant la lisibilité de ce que l’on configure et limite les risques de configurations erronées. Les interface templates peuvent être appliqués statiquement, mais également dynamiquement et c’est exactement le rôle d’autoconf. On va positionner le template désiré en fonction de l’équipement reconnu. Des templates ainsi que les règles d’application de ces derniers sont prédéfinis sur les commutateurs pour les équipements les plus souvent rencontrés. On part donc sur quelque chose de simple par défaut, en laissant l’ensemble intégralement paramétrable pour s’adapter à tous les cas de figure.
Le lab
Mon lab est très simple, un switch d’accès 2960-X en pur L2, avec un port d’uplink et tous les autres ports downlink. Je vais configurer Autoconf pour configurer automatiquement les ports en fonction du device que je vais connecter. Je vais notamment rajouter un point d’accès WiFi, une caméra, un téléphone et également un petit module Arduino, juste afin de montrer que la solution s’adapte à tout type d’équipement (et pas seulement ceux de Cisco).
Test simple
Première opération: désactiver tout comportement automatique sur mon lien d’uplink. Je recommande de commencer par là pour éviter toute surprise… Théoriquement on sait reconnaître la connexion d’un switch et donner la bonne configuration également sur l’uplink. Les plus ambitieux pourront tester. Sur mon setup je vais me contenter d’auto-configurer l’accès.
interface GigabitEthernet1/0/28 description ----- UPLINK switchport mode trunk access-session inherit disable autoconf end
Deuxième opération, activer autoconf globalement. Attention tous les ports sont concernés (sauf sur ceux où l’on va faire du 802.1X, du MAB ou ce que l’on appelle génération l’identity based networking). Ca sera d’ailleurs l’objet d’un prochain poste. Notez la complexité de la commande:
autoconf enable
Une fois cette opération terminée on a un mapping par défaut entre des devices reconnus et des templates de configurations. Ce mapping, s’il n’est pas modifié n’apparaît pas dans la running config.
INFRA-2960X#sh parameter-map type subscriber attribute-to-service all Parameter-map name: BUILTIN_DEVICE_TO_TEMPLATE Map: 10 map device-type regex "Cisco-IP-Phone" Action(s): 20 interface-template IP_PHONE_INTERFACE_TEMPLATE Map: 20 map device-type regex "Cisco-IP-Camera" Action(s): 20 interface-template IP_CAMERA_INTERFACE_TEMPLATE Map: 30 map device-type regex "Cisco-DMP" Action(s): 20 interface-template DMP_INTERFACE_TEMPLATE Map: 40 map oui eq 00.0f.44 Action(s): 20 interface-template DMP_INTERFACE_TEMPLATE Map: 50 map oui eq 00.23.ac Action(s): 20 interface-template DMP_INTERFACE_TEMPLATE Map: 60 map device-type regex "Cisco-AIR-AP" Action(s): 20 interface-template AP_INTERFACE_TEMPLATE Map: 70 map device-type regex "Cisco-AIR-LAP" Action(s): 20 interface-template LAP_INTERFACE_TEMPLATE Map: 80 map device-type regex "Cisco-TelePresence" Action(s): 20 interface-template TP_INTERFACE_TEMPLATE Map: 90 map device-type regex "Surveillance-Camera" Action(s): 10 interface-template MSP_CAMERA_INTERFACE_TEMPLATE Map: 100 map device-type regex "Video-Conference" Action(s): 10 interface-template MSP_VC_INTERFACE_TEMPLATE
A partir de ce moment, quand le switch reconnait un device qui contient le nom Video-Conference le template MSP_VC_INTERFACE_TEMPLATE est automatiquement appliqué. A ce stade vous devriez vous poser une question… Reconnaissance de device sur le switch? Oui les commutateurs d’accès effectuent localement un profiling de l’équipement grâce au device classifier qui s’active sur le switch via la commande du même nom “device classifier”. Le device classifier est également activé dès la configuration d’autoconf: sans device classifier, difficile de faire de l’autoconf. Le device classifier va faire le profiling en fonction de l’adresse MAC (et l’OUI), des attributes CDP, LLDP etDHCP. Il est possible de voir les devices profilés sur les ports d’accès par le device classifier:
INFRA-2960X#sh device classifier attached Summary: MAC_Address Port_Id Profile Name Device Name ============== ========== =============================== ======================= 4403.a739.6f92 Gi1/0/15 Cisco-Transparent-Bridge CISCO 90a2.da0e.10d7 Gi1/0/19 Un-Classified Device Unknown Device aca0.16fd.5393 Gi1/0/17 Cisco-IP-Phone CISCO SYSTEMS, INC. 0022.bddf.0cf0 Gi1/0/23 Cisco-Device CISCO SYSTEMS, INC. 0016.d4d4.32ae Gi1/0/17 Un-Classified Device Unknown Device ===========================================================================
On remarque que plusieurs équipements peuvent être profilés derrière un même port. Nous avons l’exemple ci-dessus d’un téléphone connecté sur le ports Gi1/0/17 et le PC connecté derrière qui lui n’est pas reconnu.
Regardons maintenant du côté des templates… Nous avons des templates prédéfinies qui intègrent les configurations appropriées pour les devices les plus habituellement connectés (QoS, port security, etc…) Ces derniers n’apparaissent par défaut pas dans la configuration. Il est possible de les voir simplement via la commande “sh template interface source built-in all”. Il est possible également de voir un template particulier, par exemple celui correspondant à un IP Phone.
INFRA-2960X#sh template interface source built-in IP_PHONE_INTERFACE_TEMPLATE Building configuration... Template Name : IP_PHONE_INTERFACE_TEMPLATE Modified : No Template Definition : spanning-tree portfast spanning-tree bpduguard enable switchport mode access switchport block unicast switchport port-security maximum 3 switchport port-security maximum 2 vlan access switchport port-security violation restrict switchport port-security aging time 2 switchport port-security aging type inactivity switchport port-security storm-control broadcast level pps 1k storm-control multicast level pps 2k storm-control action trap mls qos trust cos service-policy input AUTOCONF-SRND4-CISCOPHONE-POLICY ip dhcp snooping limit rate 15 load-interval 30 srr-queue bandwidth share 1 30 35 5 priority-queue out
On remarque un élément important: il manque les VLANs. Ni data, ni voice VLAN configurés sur les templates… et pour cause le switch ne peut pas les deviner. Par défaut tout tombe dans le VLAN 1. Pas extra mais rien de plus simple pour les spécifier, il suffit de configurer le template:
INFRA-2960X#conf t INFRA-2960X(config)#template IP_PHONE_INTERFACE_TEMPLATE INFRA-2960X(config-template)#switchport access vlan 193 INFRA-2960X(config-template)#switchport voice vlan 194
A partir de là les modifications sont bien prises en compte:
INFRA-2960X#sh template interface source built-in IP_PHONE_INTERFACE_TEMPLATE Building configuration... Template Name : IP_PHONE_INTERFACE_TEMPLATE Modified : Yes Template Definition : spanning-tree portfast spanning-tree bpduguard enable switchport access vlan 193 switchport mode access switchport block unicast switchport voice vlan 194 switchport port-security maximum 3 switchport port-security maximum 2 vlan access switchport port-security violation restrict switchport port-security aging time 2 switchport port-security aging type inactivity switchport port-security storm-control broadcast level pps 1k storm-control multicast level pps 2k storm-control action trap mls qos trust cos service-policy input AUTOCONF-SRND4-CISCOPHONE-POLICY ip dhcp snooping limit rate 15 load-interval 30 srr-queue bandwidth share 1 30 35 5 priority-queue out
Notez que le template intégral modifié apparaît ensuite dans la running config:
INFRA-2960X#sh run | s ^template IP_PHONE_INTERFACE_TEMPLATE template IP_PHONE_INTERFACE_TEMPLATE spanning-tree portfast spanning-tree bpduguard enable switchport access vlan 193 switchport mode access switchport block unicast switchport voice vlan 194 switchport port-security maximum 3 switchport port-security maximum 2 vlan access switchport port-security violation restrict switchport port-security aging time 2 switchport port-security aging type inactivity switchport port-security storm-control broadcast level pps 1k storm-control multicast level pps 2k storm-control action trap mls qos trust cos service-policy input AUTOCONF-SRND4-CISCOPHONE-POLICY ip dhcp snooping limit rate 15 load-interval 30 srr-queue bandwidth share 1 30 35 5 priority-queue out
Si Autoconf a bien fait son travail j’ai normalement le template IP_PHONE_INTERFACE_TEMPLATE activé sur l’interface Gi1/0/17. Vérifions…
interface GigabitEthernet1/0/17 end
Rien? Normal 🙂 Contrairement à Auto-smartports qui modifiait la running-config ce qui pouvait être un peu pénible côté management de configuration, ici on ne touche pas la running! Alors comment voir ce qui se passe? Une commande permet de vérifier quel template est poussé sur un port.
INFRA-2960X#sh template binding target gigabitEthernet 1/0/17 Interface Templates =================== Interface: Gi1/0/17 Method Source Template-Name ------ ------ ------------- dynamic Modified Built-in IP_PHONE_INTERFACE_TEMPLATE Service Templates ================= Interface: Gi1/0/17 Session Source Template-Name ------- ------ -------------
On voit bien que l’interface template a bien été appliqué. Ne faites pas attention à ce stade aux service templates. J’en ai déjà parlé dans ce post un peu ancien et je reviendrai la dessus bientôt. On peut voir la configuration de l’interface en regardant non pas la running config mais la derived config:
INFRA-2960X#sh derived-config interface gi 1/0/17 interface GigabitEthernet1/0/17 description AUTO-CONF switchport access vlan 193 switchport mode access switchport block unicast switchport voice vlan 194 switchport port-security maximum 3 switchport port-security maximum 2 vlan access switchport port-security violation restrict switchport port-security aging time 2 switchport port-security aging type inactivity switchport port-security load-interval 30 srr-queue bandwidth share 1 30 35 5 priority-queue out mls qos trust cos storm-control broadcast level pps 1k storm-control multicast level pps 2k storm-control action trap spanning-tree portfast spanning-tree bpduguard enable service-policy input AUTOCONF-SRND4-CISCOPHONE-POLICY ip dhcp snooping limit rate 15 end
Personnalisation du profiling
Comme indiqué plus haut, j’ai un module Arduino connecté sur le port Gi 1/0/19 qui n’est pas profilé par le device classifier. Pour autant j’aimerais utiliser Autoconf pour configurer le port. Notez bien que je prends l’exemple d’Autoconf mais vous extrapolerez pour les équipements présents chez vous que le device classifier ne profilera pas. Tout d’abord il faut définir le template qui sera appelé lorsque le module Arduino sera branché. Ici un template basic CUSTOM_DEVICE_TEMPLATE:
template CUSTOM_DEVICE_TEMPLATE switchport access vlan 195 switchport mode access
Deuxième étape, modifier le parameter-map appelle les templates en fonction de certains attributs sur l’interface (device type, MAC, OUI…) Ici pour simplifier je paramètre le mapping pour l’adresse MAC exacte de mon module Arduino.
INFRA-2960X#conf t INFRA-2960X(config)#parameter-map type subscriber attribute-to-service BUILTIN_DEVICE_TO_TEMPLATE INFRA-2960X(config-parameter-map-filter)# 110 map mac-address eq 90a2.da0e.10d7 INFRA-2960X(config-parameter-map-filter-submode)# 10 interface-template CUSTOM_DEVICE_TEMPLATE
Tout comme lorsque pour les templates par défaut, le paramater-map apparaît également dans la running une fois modifié. Un petit shut / no shut sur le port Gi 1/0/19 et on voit que le port est bien configuré.
INFRA-2960X#sh template interface binding target gi 1/0/19 Interface Templates =================== Interface: Gi1/0/19 Method Source Template-Name ------ ------ ------------- dynamic User CUSTOM_DEVICE_TEMPLATE
Et la derived configuration prend bien en compte le template défini:
INFRA-2960X#sh derived-config int gi 1/0/19 interface GigabitEthernet1/0/19 switchport access vlan 195 switchport mode access end
On voit bient le côté simple et paramétrable d’Autoconf.
Différences entre Autoconf et Auto-smartports
J’ai abordé le fait qu’Autoconf, contrairement à Auto-smartports ne modifiait pas la configuration ce qui rendait la solution davantage manageable (pas de traps à chaque template appliqué par exemple…) Vous avez également pu constater la simplicité de configuration d’Autoconf. Pour Auto-smartports c’était un peu plus confus, notamment avec le device classifier qui n’était pas exposé/visible. Il fonctionnait sous le capot et impossible de voir ce qu’il se passait.
Un autre intérêt est qu’Autoconf peut exister en parallèle de configurations sur le port. Il est par exemple possible de rajouter un VLAN par défaut sur un port (VLAN de quarantaine) qui sera modifié lorsque Autoconf aura appliqué le template approprié: les configurations du template appliqué dynamiquement a une précédence plus forte que la configuration statique, qui a une précédence plus forte qu’un template appliqué manuellement. L’avantage est que lorsque le device est débranché, le template est retiré et le port est à nouveau configuré avec le VLAN de quarantaine. Avec auto-smartports il était impossible de faire ce type d’opérations puisque l’on faisait tout dans la running configuration. Pour illustrer tout cela, je configure mon port Gi 1/0/19 dans mon VLAN de quarantaine:
INFRA-2960X#sh run int gi 1/0/19 interface GigabitEthernet1/0/19 switchport access vlan 666 end
Device Arduino branché, le port est dans le VLAN 195 correspondant bien à mon template.
INFRA-2960X#sh int gi 1/0/19 switchport | i Access Access Mode VLAN: 195 (ARDUINO)
On voit bien la derived configuration qui intègre le template et override la configuration statique.
INFRA-2960X#sh derived-config int gi 1/0/19 interface GigabitEthernet1/0/19 switchport access vlan 195 switchport mode access end
Je débranche le module Arduino, le port retombe bien dans le VLAN 666
INFRA-2960X#sh int gi 1/0/19 switchport | i Access Access Mode VLAN: 666 (QUARANTAINE)
Et la configuration dans la running configuration reprend ses droits:
INFRA-2960X#sh derived-config int gi 1/0/19 interface GigabitEthernet1/0/19 switchport access vlan 666 end
Un autre avantage est qu’Autoconf ne va pas empêcher le fonctionnement de NEAT (Network Edge Authentication Topology) mais je ne vais pas m’étendre sur ce point.
Support d’autoconf
Notez bien que j’ai utilisé ici un 2960-X mais j’ai également testé avec un 3850, un catalyst 4500E en sup7L-E avec le même comportement. Il est important de souligner que toutes les fonctions de simplifications sont disponibles dès l’entrée de gamme de nos commutateurs et que l’on va trouver la fonction sur toute la gamme d’accès. Le support sur le catalyst 6k est imminent. On combinera donc dans les jours à venir la simplicité d’Instant Access et d’Autoconf. C’est prometteur, stay tuned!
En savoir plus ?
- Configuration guide d’Autoconf
- Venez à Cisco Live assister au technical seminar TECCRS-2404 – “Campus network made simple” que j’animerai le 26 janvier dans lequel on parlera entre autres d’Autoconf mais de bien d’autres solutions pour simplifier le réseau (802.1X, MAB, EVN, IP LFA, SDN…)
@JeromeDurand
Tags:
