IOS 15.0(2)SE – Catalyst access switches 2k & 3k

7 min read

Jerome Durand

Une très bonne nouvelle pour la rentrée, l’IOS 15.0(2)SE pour les plateformes d’accès non modulaires (Catalyst 2k et 3k) est sorti avec un peu d’avance! Je suppose que ce sont les bons effets de la “componentisation” du code Cisco: mise en place de modules pour les différentes features facilement réutilisables pour construire les différents IOS de nos nombreuses plateformes!

Pas mal de nouvelles choses intéressantes et attendues: notamment des fonctions autour de la sécurité (IPv6 First Hop Security et Trustsec), du multicast IPv6, et des fonctions de fast convergence IPv6. On voit bien qu’IPv6 est aujourd’hui un des principaux enjeux sur toutes les composantes du réseau dont l’accès au LAN. Au niveau lisibilité il y a peut-être des progrès à faire puisqu’on a 2 release notes différentes en fonction des plateformes. Si on se doute que toutes les plateformes d’accès ne peuvent pas implémenter les mêmes fonctionnalités (sinon on n’en ferait pas plusieurs, logique!) une présentation plus homogène eut été souhaitable. Allons un peu plus dans le détail…

Routage

Multicast IPv6 (plateformes 3k-X et 3k-E) Là c’est très impressionnant puisque toutes les fonctionnalités IPv6 multicast sont là: PIM-SM, PIM-SSM. On a même PIM-Bidir mais il n’est apparemment pas officiellement supporté. On a tout le panel de contrôle habituel au niveau MLD (équivalent d’IGMP pour IPv6). On dispose bien sur des routes statiques multicast, de BSR pour l’annonce des RP sur le réseau… Voir ici pour les détail (attention quelques erreurs sont présentes: pas de support dans les VRF et PIM Bidir pas officiellement supporté mais ça fonctionne)
Sécurisation d’OSPFv3 avec IPsec (plateformes 3k) On peut utiliser IPsec pour sécuriser les échanges OSPFv3 et éviter ainsi qu’une annonce soit modifiée par un équipement intermédiaire.
Support de 16 routes statiques IPv6 dans les produits en Lan Base. Comme pour IPv4 il reste possible de faire du routage simple à l’accès sans avoir a migrer en IP Base ou IP services.

Haute-disponibilité

OSPFv3 convergence tuning (plateformes 3k) Une bonne nouvelle pour la haute disponibilité des réseaux IPv6, il devient maintenant possible de “tuner” la convergence d’OSPFv3, c’est-à-dire de modifier les valeurs pour l’envoi des LSA et le calcul du SPF. Par exemple, en cas de panne qui va générer de nombreux LSA par plusieurs routeurs (ex: perte d’un noeud majeur sur le réseau) il est parfois préférable de ne pas recalculer la table de routage (algorithme SPF) trop vite: on va parfois préférer attendre de recevoir tous les LSA pour lancer ce calcul et converger plus rapidement au final. Je ne vais pas m’attarder davantage sur ce sujet assez complexe et sur lequel il faut réfléchir assez longuement avant de commencer a modifier les valeurs mises en oeuvre par défaut! C’est disponible sur 3k uniquement.
Support de REP (Resilient Ethernet protocol) (plateformes 3k-X et 3k-E) qui apporte une alternative a Spanning-Tree pour certaines topologies et assure une convergence optimale. Pour tout savoir sur REP jetez un coup d’oeil a ce whitepaper en français.

IPv6 first hop security

(plateformes 3k-X, 3k-E, 3k-C, 2960-S et 2960-C) C’est a mon avis le plus important à retenir de cette version aussi je dédie une section complète. Je devrais tester tout cela dans les jours à venir et poster les résultats sur le blog IPv6. Stay tuned!

Tout comme il existe pour IPv4 des mécanismes largement adoptés de protection au niveau 2 (DHCP snooping et Dynamic ARP Inspection) des équivalents sont disponibles pour IPv6. De nombreux terminaux ayant IPv6 activés par défaut, ce protocole peut devenir un vecteur pour compromettre la sécurité de l’entreprise. Par exemple, alors que le réseau IPv4 est intégralement sécurisé, un ordinateur connecté peut se faire passer pour un routeur IPv6, s’annoncer comme routeur par défaut IPv6, diffuser un préfixe IPv6 qui sera utilisé par l’ensemble des terminaux sur le lien pour s’auto-configurer et intercepter toutes les données qui seront échangées de manière privilégiée avec IPv6 (voir mon article “BYOD=IPv6” sur le blog IPv6). Comme pour IPv4 divers mécanismes existent pour sécuriser IPv6 au niveau 2:

IPv6 binding integrity Guard: le commutateur construit à partir des échanges NDP (Neighbor Discovery Protocol) et DHCPv6 une table associant les adresses IPv6 aux adresses MAC. Le switch vérifie ainsi que les mécanismes de résolution d’adresse (IPv6 vers MAC) sont conformes à cette table. Cela permet déviter le vol d’adresses.
IPv6 RA guard: le commutateur n’accepte les messages Router Advertisements (RA) que depuis les ports autorisés. Sur ces derniers le commutateur peut vérifier que le RA contient des informations conformes avec celles attendues, empêchant ainsi tout équipement du réseau de se faire passer pour un routeur IPv6. Cela permet d’éviter qu’un équipement créé un déni de service ou n’écoute les échanges d’informations réalisées sur le réseau.
IPv6 DHCP guard: le commutateur n’accepte les réponses DHCPv6 que depuis les ports sur lesquels l’administrateur a validé qu’un serveur était présent, et valide que les baux sont conformes avec ceux attendus sur le réseau. Cela permet également d’éviter des attaques par déni de service.
IPv6 source guard: pour chaque paquet reçu sur par le commutateur, ce dernier va valider que les adresses IPv6 et MAC sources sont conformes avec celles contenues dans la table de binding. Cela va permettre d’éviter le vol d’adresses et éviter qu’un équipement compromis ne soit source d’attaques par déni de service.

Il reste une dernière feature d’IPv6 FHS qui n’est pour le moment pas supportée: IPv6 destination guard. Pour chaque paquet reçu sur par le commutateur, ce dernier va valider que les adresses IPv6 et MAC de destination sont conformes avec celles contenues dans la table de binding

Cette release apporte le support sur les plateformes 3k-X, 3k-E, 3k-C, 2960-S et 2960-C. Attention pour ceux en 2960 (non -S) ce n’est pas disponible. Je rappelle qu’on a un support des fonctions IPv6 FHS sur notre solution WiFi depuis la release 7.2 du controleur. On a également les fonctions RA-Guard sur Catalyst 6500 et 4500.

Sécurité

Support des fonctions port-security sur les Etherchannels (entre autres limitation du nombre d’adresses MAC, possibilité de spécifier les adresses MAC autorisées… et définition du comportement du port en cas de non respect des règles définies)
Support d’IP source guard sur les Etherchannels. Si vous avez compris IPv6 source guard décrit plus haut c’est la même chose pour IPv4 avec du DHCP. On va vérifier pour chaque paquet reçu sur un port client que l’adresse IP source et sa MAC correspondent à la table maintenue via le DHCP snooping.
Trustsec: support des SGT (Plateformes 3k-X) SGT signifie Security Group Tag – Tag de sécurité qui peut ensuite être utilisé au niveau de commutateurs, routeurs ou firewalls pour gérer des règles de sécurité. Un des intérêts du tag de sécurité est que la politique de sécurité devient indépendante de la structure du réseau (VLANs, adresses IP) et que l’on simplifie ainsi grandement les règles de filtrage: on place les individus dans des groupes de sécurité (quelque soit leur VLAN, adresse IP) et on gère les règles par groupe. La bonne nouvelle sur les 3k-X est que SGT est fait dans l’ASIC et est disponible sur tous les ports downlink mais également sur les ports d’uplink du network module 10GE (pas besoin d’avoir le service module C3KX-SM-10G qui par contre apporte le support de MACSEC et de Flexible Netflow) Attention toutefois les plateformes d’agrégation 3k-X fibre (12 ou 24 ports SFP) ne supportent pas les SGT dans cette version d’IOS.
Trustsec: support de SXP (2960-S) SXP signifie SGT eXchange Protocol. Une fois le SGT assigné, celui-ci est inséré dans les trames Ethernet si les équipements aux extrémités sont capables de le faire. Dans le cas contraire SXP permet d’échanger entre équipements une table de mapping (adresse IP, tag) afin que l’équipement distant puisse replacer le bon tag à réception d’un paquet. Si sur le 3k-X on a le support des SGT en natif ce n’est pas le cas sur le 2960-S où SXP devient indispensable (le switch peut être SXP speaker ou listener). On avait déjà le suport de SXP sur 3k depuis la dernière release.
Trustsec: support des SGACLs (Plateformes 3k-X uniquement) Les SGACLs sont des ACLs qui permettent de s’appliquer entre groupes de sécurité. On va pouvoir par exemple placer tous les personnels de l’entreprise sur un même VLAN mais garder des règles entre personnes connectées via des SGACLs. Ca peut être pratique dans une logique BYOD: si un employé s’authentifie mais n’utilise pas le laptop fourni par l’entreprise alors on peut lui assigner un SGT différent et appliquer la SGACL adéquate pour l’isoler des autres.
Trustsec: support de MACSEC (plateforme 3560-C). Le chiffrement MACSEC (802.3AE) est maintenant supporté sur tous les ports du 3560-C. Je rappelle que c’est déjà supporté sur tous les ports downlink des 3k-X et les ports du service module C3KX-SM-10G.
Trustsec: ajout de flexibilité dans le MAB (MAC Authentication Bypass) afin de pouvoir s’adapter à plus de cas de figure.

Divers

Je rappelle que StackPower est maintenant disponible en Lan Base ce qui va je suppose être grandement apprécié pour améliorer la disponibilité des stacks sans pour autant faire gonfler les prix de la solution!
Support de la classe class-default sur 2960-S qui permet au sein d’une policy-map d’appliquer un comportement pour tous les paquets qui n’ont pas été matchés par les classes précédemment listées.
Support des SFP+ ER sur les 3k-X (sur tous les ports: les uplinks mais aussi sur les ports des modèles 12 et 24 ports SFP)
Possibilité de spécifier le VLAN pour le processus de smart-install (toutes les plateformes). C’est important car c’était un point assez pénible pour tous ceux qui voulaient essayer le smart-install et qui souffraient un peu de l’obligation d’utiliser le VLAN 1. On avait mis à jour les CVD pour clarifier comment faire mais ca restait pour quelques clients trop compliqué. Je rappelle que Smart-install permet de sortir le switch du carton, de le brancher et de le laisser s’auto-configurer (téléchargement IOS, config…) Généralement on installe les switchs d’accès par palettes donc on fait largement baisser l’OPEX. Maintenant qu’on a cette option je suppose que je n’ai plus d’excuse pour ne pas tester dans mon lab… 🙂
Support de la négociation UPOE (60W par port) sur les ports d’uplink des 3560-X et 2960-X. Le switch peut à la fois être alimenté en UPOE mais peut aussi alimenter un autre équipement en UPOE.