Cisco France Blog / Réseaux / IOS-XE 3.7S – ASR 1000

Cette nouvelle release est importante pour l’ASR1000 tout d’abord puisqu’elle a un support étendu de 48 mois (la dernière version à support étendue était la 3.4S de l’année passée) Pour ceux qui veulent se caler sur un IOS et ne plus y toucher la 3.7S est peut-être le bon choix! J’ai un peu tardé pour publier ce post le temps de vérifier quelques informations… Voyons les nouveautés!

Nouveaux hardwares supportés

L’IOS XE 3.7S offre le support des prochaines innovations hardware sur l’ASR 1000 (Rebuild 3.7.1 prévu pour octobre):

• ESP-100Gbps: l’Embedded Services Processor (ou ESP) est la carte de forwarding de l’ASR 1000 qui permet avec le QFP (Quantum Flow Processor) de combiner un haut niveau de performance (100Gb/s pour cette nouvelle carte ESP 100-Gbps) et un large panel de fonctionnalités.
• ASR 1002-X: ce nouvel ASR de 2 RU est le successeur désigné de l’ASR 1002. Il permet de s’adapter à des bande passantes de 5 à 36 Gbit/s. Contrairement à l’ASR-1002 l’ESP (Embedded Service Processor), le module de forwarding, est maintenant intégré. Comme sur l’ASR 1001, on peut monter en capacité de forwarding par simple licence logicielle.

Nouvelles fonctionnalités

A nouveau beaucoup d’IPv6! Donc plutôt que de faire une grosse section IPv6 j’ai ventilé ça dans des fonctionnalités. A méditer quand on rédige son CCTP: IPv6 doit être une colonne (pour chaque feature demandée) et non une simple ligne “support d’IPv6” comme je vois encore trop souvent…

Routage

• Support de l’auto-discovery VPLS basé sur BGP. Disponible depuis quelque temps sur d’autres plateformes cette feature permet sur un PE VPLS de ne pas déclarer tous les autres PE distants. On va utiliser BGP (address family l2vpn vpls) pour échanger ces informations entre routeurs.
• On supporte maintenant la SAFI MCAST-VPN BGP (SAFI 5) qui permet de faire toute la signalisation multicast en BGP (au lieu de PIM). Pour certains designs nécessitant de très nombreux groupes multicast (par exemple des réseaux de vidéo-surveillance – 1 groupe par caméra) PIM devient trop bavard car il est nécessaire de maintenir les états en envoyant périodiquement des Joins pas toujours utiles. Par contre pas d’informations à ce sujet encore dans les release notes et pas de configuration guide donc je suis dans filets! Je donnerai plus d’informations quand j’y verrai plus clair. C’est dispo pour IPv4 et IPv6.

Virtualisation

• Support des tunnels GRE sur un transport IPv6. Il est bien sûr possible de protéger ces tunnels via chiffrement IPsec.
• Du coup on supporte maintenant les multicast VPN IPv6 (MVPNv6) sur un transport GRE (draft-rosen…) Pour ceux qui ont virtualisé leur infrastructure plus de raison de ne pas faire d’IPv6 dans les VPN. Là non plus pas encore d’informations dans les release notes et le configuration guide mais ceux qui connaissent ma passion pour le multicast IPv6 savent que je vais revenir là-dessus!

Sécurité

• Support du firewall IPv6 sur des interfaces VASI (VRF-Aware Service Infrastructure). Cette fonction permet d’activer le firewall IPv6 entre 2 VRF sur le routeur, la communication entre ces VRF se faisant à travers un couple d’interface VASI (VASIleft et VASIright), chacune appartenant à sa VRF.

Performance applicative

• Possibilité d’exporter les flux Flexible Netflow vers une adresse IPv6. Si on peut depuis longtemps voir les flux IPv6 avec Netflow l’export se faisait uniquement en IPv4. Une étape de plus donc pour permettre une bascule du management plane en IPv6.
• Support d’IPFIX, standard IETF (RFC 5101) d’export de flux très similaire dans sa structure à Netflow v9 développé par Cisco. Dans la configuration Flexible Netflow du routeur il sera donc possible de choisir son format d’export entre Netflow v9 et IPFIX.
• On annonce d’ailleurs progressivement la fin de Traditional Netflow (en 3.10S l’année prochaine) et on rappelle de passer en configuration Flexible Netflow. Voir ce guide pour migrer.
• IP SLA QFP time stamping: l’idée ici est d’améliorer la précision des mesures actives IP SLA faites par les routeurs en ajoutant le temps de passage du paquet de test non plus sur la RP (software) mais directement sur l’ESP, par notre fameux QFP (Quantum Flow Processor). Donc maintenant même quand la précision demandée est très fine (de l’ordre de la micro-seconde) on peut utiliser l’instrumentation en place sur le routeur et on s’affranchit de l’installation d’une sonde de mesure dédiée.
• NBAR2 est amélioré avec une classification progressive des applications. Pour certaines applications complexes, le moteur DPI a besoin de plusieurs paquets avant de pouvoir déterminer l’application avec exactitude. Si auparavant l’application était “unknown” pendant ce laps de temps, il est maintenant pré-classifié et certaines règles d’optimisation peuvent alors être appliquées avant d’avoir l’application exacte.
• On supporte maintenant sur l’ASR1000 la possibilité d’utiliser NBAR pour classifier le trafic pour PfR (Performance Routing). Pour être plus clair cela permet de faire des optimisations de routage directement par application (Ex: on route Skype et BitTorrent en priorité sur le lien de backup). Vous verrez dans les release notes NBAR/CCE, ce qui n’est à mon sens pas très clair: NBAR est utilisé pour classifier le trafic et CCE est le mécanisme sous le capot qui permet de changer le next-hop en utilisant l’information de NBAR (une sorte de règle de QoS dynamique avec un attribut set next-hop). Cette fonction était déjà supportée sur ISR G2 depuis la 12.4(20)T et on apprécie la convergence des plateformes! Attention seul un sous-ensemble des applications reconnues par NBAR2 peut être optimisé. Voir les release notes pour le détail.
• Support du Protocol Pack upgrade pour NBAR. Il sera possible d’upgrader la base de signatures NBAR sans avoir a changer l’IOS.

Références

Release notes

Authors

Jerome Durand

Technical Solutions Architect