Cisco France Blog
Partager
tweet

Cisco France Blog > Réseaux

Réseaux

IOS-XE 3.5.0E / IOS 15.2(1)E pour catalyst 4k, 3k et 2k


12 September 2013

On vous l’avais promis, ça converge sur le campus côté IOS! 🙂

Le train E (comme Ethernet) voit enfin le jour et écrit une belle page dans l’histoire de la convergence de l’IOS sur la LAN (le train E réunit les trains précédents SE et SG). C’est ce train qui va perdurer pour toutes les plateformes de commutation “campus” à l’avenir. Aujourd’hui ont convergé:

  • Catalyst 4k (sup7 et sup6 y compris en version light)
  • Catalyst 4500-X
  • Catalyst 4900M, 4948E/4948E-F
  • Catalyst 3k-X et 3k-C
  • Catalyst 2k-S

Les absents sont les toutes dernières plateformes (cat4k sup8, catalyst 3850 et 2960-X/XR). Comme pour la plupart des nouvelles plateformes, une version initiale est au préalable utilisée (“forkée” du train habituel). Cela permet entre autres de pouvoir plus aisément combiner la création de plateformes, l’ajout de nouvelles fonctionnalités et la correction de bugs. On fait ensuite recoller ces plateformes sur le même IOS et de bonnes nouvelles sont donc prochainement attendues là aussi!

Notons également que nous avons des plateformes en IOS, d’autres en IOS-XE. Pas de panique! L’IOS-XE est juste une architecture différente d’operating system qui permet de faire tourner au dessus d’un kernel (fonction de gestion de base de la machine, drivers…) des applications. L’IOSd (démon IOS) devient une application libérée de toutes les composantes hardware. L’avantage de cette architecture logicielle est qu’elle permet de faire tourner sur le routeur ou le commutateur d’autres applications que l’IOS. Aujourd’hui on a déjà Wireshark ou bien le Wireless LAN Controler (3850) qui sont des applications à part entière sur la plateforme. D’autres applications viendront (idées bienvenues d’ailleurs!) On sait donc allouer pour chaque application de la CPU sans altérer les fonctions control plane de base de l’équipement. Donc pour résumer il n’y a aucune différence entre opérer un commutateur en IOS 15.2(1)E d’un autre en IOS-XE 3.5.0E: le démon IOS tournant sur cet IOS-XE étant bien la version 15.2(1)E.

Vous le constatez, la stratégie est claire, on avance mais on doit y aller par étape pour garantir le principal: que le code soit stable et que les features demandées soient développées rapidement!

Jigsaw puzzle

Regardons maintenant ce qui est nouveau dans ce nouvel IOS… (informations détaillées disponibles dans le bulletin d’annonce de l’IOS qui est extrêmement bien fait et qui détaille les versions/licences nécessaires pour chaque nouveauté)

Performance applicative

  • Export des flux avec le standard IPFIX (en plus de Netflow v9 et v5)
  • Support des Metadata par port et du MSI proxy (faisant parti de la solution Medianet). L’idée est que le commutateur puisse associer à un flux le type d’application associée, en snoopant une partie du trafic (notamment les flux de contrôle). Ensuite il devient possible de faire des règles de QoS basées sur le type d’application au lieu de renseigner tous les ports/adresses. Attention on ne parle pas DPI ici. Seuls certains flux, notamment audio/vidéos sont concernés… ce qui tombe bien car c’est pour ceux-là qu’on fait généralement de la QoS sur nos switchs!

IPv6

IPv6 first hop security

Cela fait plus de 10 ans qu’on a compris le problème en IPv4 et que l’on se protège… Ne tardons pas pour IPv6. J’en ai largement parlé sur nos blogs à plusieurs reprises: là, là, là et encore là. Ici on rajoute plusieurs mécanismes de protection:

  • Source guard sur le 4500 (déjà présent sur 3k-X): on va vérifier que chaque paquet reçu sur un port correspond à la table de binding IPv6/MAC/Port construite sur le commutateur.
  • Destination guard sur le 3k-X (déjà présent sur 4500): c’est l’inverse! On va bloquer le trafic quand on ne connaît pas l’adresse de destination dans la table de binding.
  • Prefix Guard: ici au lieu de vérifier adresse par adresse on va juste s’assurer que les paquets viennent bien du/des préfixes utilisés.

Virtualisation

  • Support d’IPv6 dans les VRF ! Je sais que beaucoup l’attendaient et c’est maintenant fait.
  • Support des protocoles OSFPv3, EIGRPv3 et BGP (AFI IPv6) dans les VRF

Autres

  • Support de BGP pour IPv6 sur les 3k-X (ça marchait déjà mais ce n’était pas officiellement supporté. Maintenant c’est tout bon!)
  • Suport de ISIS pour IPv6 sur 3k-X
  • DNS sur IPv6, FTP sur IPv6…

Trustsec / sécurité

  • Support des SGT/SGACL sur le catalyst 4500 (déjà supporté sur 3k-X) avec possibilité de mapper des IP, vlans ou ports dans des SGT. Les SGT sont des tags de sécurité intégrés dans les trames en fonction du contexte de connexion (configurable). L’idée est d’utiliser ces tags ensuite pour les règles de sécurité. Cela permet de ne plus faire de la sécurité par VLAN ou adresses et de simplifier les déploiements (il devient inutile de créer des VLANs dans le seul but de s’en servir pour des règles de sécurité). Dans certains déploiements cela a permis de considérablement diminuer le nombre de règles de sécurité configurées sur le réseau (ratio de 20 à 50)
  • Chiffrement MACSEC sur les ports du 4500-X

Haute disponibilité et VSS

  • VSS – Support des MCEC de niveau 3 sur cat4k sup7 et 4500-X.
  • VSS – Support des line cards classiques
  • VSS – Support des châssis asymmetriques
  • VSS – Support des fast hellos pour le split brain detection. Les 2 switchs du VSS vont se pinguer continuellement sur un lien dédié pour vérifier le statut du site distant. Si le VSL tombe alors que les 2 switchs sont toujours up, alors ces derniers pourront s’en apercevoir et remédier à la situation (et éviter que les 2 équipements s’imaginent être seuls survivants – split brain)
  • Support de BFD sur le 4500 pour les protocoles OSPF, EIGRP et BGP (IPv4 et IPv6)

Simplicité opérationnelle

  • Support de smart install sans nécessiter la gestion de l’IOS. Le process ne va faire que configurer l’équipement sans changer son IOS afin de gagner du temps lors de l’installation.
  • Service discovery gateway. Permet de passereller et de contrôler les protocoles utilisant mDNS. On pourra permettre aux usagers sur le VLAN “prof” de découvrir une imprimante qui répond au protocole Bonjour sur le VLAN “print” tout en s’assurant que les élèves sur un VLAN différent ne puissent pas la voir.

Changements dans les licences

  • Toutes les fonctions multicast (IPv4 et IPv6) sont mainteannt bien dans IP Base
  • Idem pour IPv4 PBR et EIGRP stub routing (IP Base)
  • 1000 routes au lieu de 200 dans OSPF routed access (IP Base)

Matériel

  • GLC-T, SFP+ DWDM et ZR sur 2k-S et 3k-X (déjà supporté sur 4k)
  • Support des SFP FE (100Mbps) sur 2k-S/X, 3k-X/C et 4500E (sur ports GE uniquement)
  • DOM (Digital Optical Monitoring) pour SFP et SFP+

Références

Tags:
Laisser un commentaire