Entre 2 couches ce serait dommage de ne pas donner des news du front! Plusieurs IOS sont sortis ou sont imminents. Pour ne pas déroger à la règle je vais faire un post pour chacun d’eux (non, je ne suis pas payé au nombre d’articles!) Comme d’habitude je ne présente que les aspects qui me semblent les plus importants aussi n’hésitez pas à vérifier dans les release notes l’intégralité des nouvelles fonctionnalités.
Routage
- Grosse avancée pour les fans du MVPN (multicast dans les VPN-MPLS), on supporte le Label Switched Multicast (LSM) via signalisation mLDP (multicast LDP). On reposait avant sur une solution basée sur tunneling GRE multicast (La fameuse solution “Rosen”) et on offre en plus maintenant l’équivalent nativement sur MPLS. Notez que le transport sur MPLS est supporté à la fois pour MVPNv4 et MVPNv6.
- Notre LSM peut aussi bien nous aider pour nos MVPN mais peut aussi fonctionner dans un mode de “transit” afin de s’affranchir complètement de PIM au niveau du coeur même sans VPN MPLS.
- Support de MVPNv6 extranet via la commande “rpf select” qui permet, pour chaque ensemble de groupe, de choisir la VRF dans laquelle on va faire le lookup pour le RPF. J’avais écrit cet article l’année dernière si vous avez besoin de vous rafraichir la mémoire.
- Support de la signalisation VPLS via BGP. On supportait l’auto-discovery des PE distants via BGP depuis l’été dernier. Maintenant on va pouvoir aussi s’appuyer sur BGP pour tout ce qui est signalisation du pseudowire entre les PE d’un VPLS (RFC4761). On a donc maintenant cette option pour ceux qui ne souhaitent pas utiliser la solution basées sur des sessions LDP (targeted LDP) entre chaque couple de PE d’un même VPLS.
- Vous vous rappelez peut-être qu’on a précédemment amélioré la manière de configurer des L2VPN. On va pouvoir maintenant configurer en premier lieu une interface pseudowire, qui va définir notre tunnel, puis ensuite la configurer comme membre d’un xconnect (pour les L2VPN point-à-point) ou d’une VFI (pour les L2VPN multipoint-multipoint – cad pour des VPLS). Cette nouvelle configuration permet du coup d’appliquer des configurations avancées par pseudowire et cette release 3.8S va nous permettre notamment d’avoir une QoS fine par pseudowire. Notez que pour appliquer la même configuration à plusieurs pseudowires on a la possibilité de créer une interface “template” qui agrégera les configurations.
- EIGRP add-path va permettre dans le cas d’un DMVPN redondé, de s’assurer que les hubs vont réannoncer l’ensemble des routes (jusqu’à 4) de chaque site et non juste une seule best qui effacerait les autres options disponibles.
- Possibilité pour un routeur BGP d’avoir plusieurs cluster-IDs (distincts selon les peers iBGP). On a aussi la possibilité de désactiver la réflexion de routes au sein d’un même cluster (par exemple dans le cas de migrations). Retenir qu’on conforte l’ASR1000 comme route-reflector BGP par excellence et qu’on peut plus ou moins tout lui demander.
- L’attribut BGP “VPN distinguisher” va permettre à 2 réseaux offrant des services MPLS-VPN interconnectés selon l’option B (peering MP-eBGP entre les domaines) de ne plus forcément s’envoyer leurs RT (Route-Targets). Chacun pourra transposer ses route-targets dans ce nouvel attribut “VPN distinguisher” et masquer à l’autre les RT utilisés.
- Filtrage des LSA de type 3 d’OSPFv3 qui permet de maîtriser les préfixes IPv6 que l’on va redistribuer d’une aire OSPFv3 à l’autre.
Haute disponibilité
- MDR (Minimal Disruptive Restart) permet d’améliorer le processus ISSU sur l’ASR1000. En effet lors d’un upgrade il est nécessaire à un moment de redémarrer SIP et SPA. Afin de ne pas souffrir de ce reload il est nécessaire de doubler chaque raccordement sur 2 interfaces sur 2 line cards distinctes. MDR va réduire considérablement le temps de redémarrage de la SIP40 et des SPA GE et 10GE.
- OSPFv3 graceful shutown va nous permettre d’arrêter en douceur OSPFv3 avant une maintenance par exemple, afin de ne perdre aucun paquet. Le routeur va cesser de former des adjacences avec ses voisins mais va garder les états pour router convenablement les paquets le temps que la convergence ait lieu.
- Support de HSRPv6 avec des adresses IPv6 globales
- Dans le même esprit support de VRRPv3 qui apporte le support d’IPv6 pour la sécurisation de la passerelle par défaut
- Support de redondance d’accès à un coeur VPLS (topologie H-VPLS) grâce à Multiple Spanning Tree Protocol (MST). C’est une des solutions que j’avais abordées ici pour la redondance VPLS. Notre ISR G2 d’accès va donc pouvoir se raccorder à 2 ASR1000 de coeur (via des tunnels QinQ ou alors des PW MPLS) et on va s’assurer qu’un seul de ces liens est actif.
- BFD dampening va nous éviter d’avoir trop de flappings en cas d’injoignabilité L3 sur un lien. On avait déjà “interface dampening” pour éviter les flaps vus au niveau L1/L2, BFD dampening va compléter notre arsenal anti flaps.
- BGP dampening pour MVPN. Vous vous rappelez qu’on supporte maintenant la SAFI 5 pour BGP qui nous permet en gros de faire tous nos Joins/Prunes avec BGP (au lieu d’un PIM en overlay). Ici le dampening va nous permettre d’éviter trop de flaps dans cette signalisation BGP qui pourrait agresser un peu trop des routeurs un peu sensibles.
Sécurité
- Redondance inter-chassis pour le zone based firewall IPv6. Il est donc possible d’avoir à l’accès 2 routeurs ASR1000 qui vont se synchroniser pour offrir un service de filtrage complet et redondant.
- Support des algorithmes “Suite-B” par le module crypto afin d’offrir un meilleur chiffrement des données. Je rappelle que ces algorithmes sont supportés sur nos ISR G2 via un module de service interne qui permet d’accélérer les opérations de chiffrement.
- On supporte maintenant les tunnels mGRE IPv6, ce qui nous permet de supporter les DMVPN sur un transport IPv6. Ca tombe a pic car certains clients ne disposent plus que d’une adresse IPv6 fournie par l’opérateur côté WAN… Grâce au transport IPv6 maintenant supporté pour les DMVPN on va pouvoir bâtir notre VPN (IPv4 et/ou IPv6) au dessus du réseau IPv6 de l’opérateur.
- Si l’on avait depuis longtemps l’unicast RPF en mode strict, on supporte maintenant le mode uRPF loose qui va vérifier uniquement l’existence de la route en question (sans vérifier que l’interface est conforme). Fonction indispensable pour l’implémentation d’une politique de sécurité RTBH (Remote Triggered Black Hole – voir l’article de Stephane Bortzmeyer sur le sujet ou lire la RFC 5635)
- On améliore la fonction Key Server GETVPN sur l’ASR 1000 avec des fonctions permettant d’éliminer des associations obsolètes ou bien de ré-échanger de nouvelles clés, mais aussi avec des nouvelles commandes pour faciliter le troubleshooting.
Performance applicative
- Je commence par les couches basses avec le support de fonctions Ethernet OAM (Operation Administration and Maintenance). On va supporter IEEE CFM, une sorte de traceroute/IP SLA de niveau 2 qui va nous aider à localiser précisément l’origine d’une panne dans des domaines Ethernet étendus sur plusieurs réseaux gérés par des personnes indépendantes. Intéressant si l’ASR1000 est utilisé pour faire du bridging Ethernet ou bien s’il est simplement à l’extrémité.
- IP SLA pour multicast: cela permet de faire des mesures actives sur du multicast (on va faire des tests de mesure depuis un routeur vers un groupe multicast où plusieurs routeurs pourront répondre). On peut donc tester que le multicast fonctionne bien sur son réseau simplement sans avoir à configurer des sondes additionnelles. On avait le support depuis l’été dernier sur ISR G2.
- On va pouvoir échanger entre sites gérés par PfR (performance routing) les capacités des liens, via peerings entre master controlers. Cela va nous aider notamment dans un scénario ADSL dans lequel un site central collectant des lignes de sites distants ne connait pas a priori le débit de chaque site. Ici chaque site distant va pouvoir annoncer au site central son débit DSL. Le site central utilisera cette information pour optimiser correctement le routage dans chaque lien.
- Flexible Netflow est maintenant capable de collecter les flux sortants dans une VRF (match sur l’ID de la VRF). Je rappelle qu’on pouvait déjà depuis un an voir les flux entrants dans une VRF.
- Support d’EPC (Embedded Packet Capture) qui permet en gros de faire un tcpdump sur le routeur. On a déjà le support sur cat6k et ISR G2. Si l’on ajoute que l’on peut maintenant installer Wireshark comme application embarquée sur cat4k ça nous offre un bel outil de troubleshooting de bout en bout de ce qui se passe dans le réseau.
- Grosse évolution: pour chaque flux on peut maintenant collecter de nombreuses métriques de performance TCP (ART – Application Response Time). Cette analyse fine qui était possible en premier lieu sur la NAM (Network Analysis Module) avait d’abord été portée sur ISR G2 l’année dernière sous le nom Performance Agent et est maintenant disponible sur ASR1k. Cette fonctionnalité va permettre à l’admin réseau de déterminer, en analysant finement les échanges au sein des flux TCP, si un éventuel problème de performance est dû au réseau ou à l’application. Intéressés? 🙂
- Je reviendrai prochainement sur les évolutions de notre outillage AVC (Application Visibility and Control), dont Performance Agent fait parti car on est maintenant passés dans une nouvelle étape AVC2.0 dans laquelle on a amélioré pas mal de choses sous le capot avec le MMA (Metric Mediation Agent) qui permet de mieux traiter et exploiter les nombreuses données mesurées par le routeur (IP SLA, Flexible Netflow, Performance Monitor…) Au final c’est une CLI simplifiée pour l’admin.
- Et comme à chaque fois on complète notre moteur DPI NBAR2 avec de nouvelles signatures. Je rappelle qu’on supporte depuis l’été dernier l’upgrade de la base de signature indépendamment de l’IOS.
Divers
- Support de LLDP
- Pénurie d’adresse oblige, on supporte maintenant les interfaces Ethernet “unnumbered” (et plus uniquement les interfaces point-à-point).
- Toujours dans l’esprit “je n’ai plus d’IPv4”, la feature MAP-T va permettre d’interconnecter des ilots IPv4 à travers un réseau IPv6, et sans tunneling je vous prie. Concrètement on aura un mapping sans état de IPv4 vers IPv6 via un algorithme prédéfini sur un routeur de bordure d’un site et on fera l’opération inverse à l’autre extrémité (on n’aura pas fini d’utiliser le fait qu’on peut insérer 32 bits dans 128 bits!)
Pour plus d’informations
Authors
Laisser un commentaire