L’image est sortie le 29/11, et le titre risque déjà de vous interpeller: “Quoiiii? Il y a un ASR 903???” Ben non justement… mais il arrive bientôt et on est bien content de savoir qu’il y a un soft qui tournera dessus à sa sortie! En revanche il y a déjà un ASR 901 mais ne tourne pas IOS-XE… OK il y avait mieux pour commencer …Pour ceux qui entendent parler de ces plateformes pour la première fois jetez un coup d’oeil aux datasheets, vous serez surpris par ces plateformes dont le positionnement premier est de permettre la connexion de BTS (interfaces TDM) au réseau MPLS de l’opérateur:
Bon, concentrons-nous maintenant sur l’essentiel: qu’est-ce que la 3.5S apporte comme nouvelles fonctionnalités à mon ASR 1000…
Au niveau de l’interconnexion de datacenters, on a 2 options de plus:
- VPLS – Enfin c’est disponible (c’est pas trop tôt d’ailleurs!). On a d’ailleurs également le support de VPLS MAC withdrawal pour permettre une bascule rapide du lien primaire au lien secondaire sur l’accès redondant au coeur VPLS (topologie H-VPLS). On savait déjà gérer l’accès redondant, ici on accélère juste le mécanisme de bascule. Un nouveau message LDP permet de supprimer les adresses MAC concernées par le switchover dans la table de tous les routeurs du coeur VPLS.
- OTV – disponible également pour interconnecter des réseaux Ethernet au dessus d’une infrastructure IP multicast, sans étendre pour autant le spanning-tree entre les sites (ce dernier reste local à chaque site). Il est nécessaire que PIM soit activé sur le réseau interconnectant les différents sites.
Du neuf également sur le routage:
- Validation des AS d’origine avec la RPKI: cette fonction permet de s’assurer qu’un préfixe est bien annoncé par celui qui le détient. Dans un monde où les ressources IPv4 deviennent de plus en plus rares je ne serais pas surpris que des annonces de ce type se multiplient (on se souvient du Pakistan qui avait annoncé les préfixes de Youtube de manière plus explicite il y a plusieurs années, entraînant un arrêt du CDN vidéo le plus populaire au monde…) Cette fonction conforte l’ASR1000 comme LE route-reflector BGP par excellence!
- IGMP snooping: inhérent sans doute à l’arrivée du VPLS: on souhaite contrôler que le multicast n’est pas floodé sur le LAN étendu.
- Support de BFD sur les interfaces BDI
Pleins de nouveautés sur MPLS TE:
- Interarea: Possibilité de faire des tunnels entre aires OSPF ou “levels” IS-IS. On spécifie les ABR (Area Border Routers) comme noeuds intermédiaires forcés pour établir le tunnel.
- Inter-AS: Même principe mais entre 2 AS (on indiquera les ASBR comme noeuds intermédiaires)
- Autoroute: route automatiquement les paquets dans le tunnel si ceux-ci devaient initialement suivre le lien sous-jacent. Si un tunnel est établi entre les routeurs A et E (interconnectés par les routeurs B, C et D), tout les paquets qui devaient transiter entre les 2 routeurs A et E sont automatiquement encapsulés.
- DS-TE: là ça devient compliqué… L’idée est de pouvoir avoir différentes politiques en fonction du champ Diffserv. Par exemple des tunnels d’une certaine classe EF passeront sur des liens directs alors qu’on fera passer tout ce qui est scavenger (CS1) sur des liens moins importants. En pratique c’est un peu chaud, je ne m’attarde pas plus.
Au niveau sécurité:
- ZBFW (Zone Based Firewalling) basé sur les SGT: on continue d’étendre le support des security group tags (SGT) sur l’ensemble des plateformes. A l’instar de la 15.2(2)T sortie il y a peu sur ISR G2, on supporte maintenant la possibilité de faire des ACL basée sur le SGT, et tout cela bien sûr en mode zone-based firewall… On supporte déjà depuis la 3.4S la possibilité d’ajouter un SGT sur les interfaces ainsi que SXP (SGT eXchange Protocol), protocole qui permet de propager les SGT au dessus d’une infrastructure qui ne sait pas gérer le 802.1ae (le WAN par exemple…). Le support du SGT semble donc quasi complet sur ASR1000 maintenant.
- Possibilité d’avoir des classes de trafic hiérarchiques dans la configuration du ZBFW, ce qui permet de configurer une règle globale pour plusieurs classes.
- Possibilité de ne pas dropper les paquets qui arrivent dans le désordre (et éviter ainsi des retransmissions inutiles). Cette fonction n’est possible que quand les fonctionnalités DPI ne sont pas activées sur les règles du firewall.
Plusieurs nouveautés sur IPv6:
- NBAR – Fonctionnalité DPI pour le trafic IPv6 natif ou encapsulé
- DHCPv6 – Possibilité de chainer les relais DHCPv6 (chaque relai ajoute ou complète les informations fournies par le serveur/client)
- Proxy Mobile IPv6 – Support des clients mobiles IPv6
Performance applicative et visibilité, on avance également beaucoup:
- PfR – Support de PfR target discovery v1.0. Sans target discovery les différents sites PfR sont indépendants et ne se parlent pas pour décider ensemble d’optimiser des flux. Avec PfR target discovery on établit des peerings entre les MC (Master Controllers) des différents sites. Je n’en dis pas plus ici, j’aborderai ce point dans un post dédié une fois que j’aurais testé un peu…
- QoS – Possibilité dans une policy-map d’appliquer un champ DSCP pour un paquet GRE qui sort du routeur. A partir d’une policy-map en sortie sur une interface tunnel on peut donc à la fois configurer modifier le champ DSCP du paquet encapsulé mais également celui de paquet encapsulant.
- Medianet – Support de Performance Monitor – Cela nous permet de superviser finement la performance des flux médias (RTP) mais également TCP, en IPv4 comme en IPv6. On peut par exemple détecter des pertes de paquets dans les flux UDP/RTP ou TCP. Performance monitor nous permet également de déclencher automatiquement des actions depuis les équipements quand certains critères de qualité ne sont pas atteints.
- Medianet – Support de Mediatrace – Depuis un unique équipement on est capable de voir la performance pour un flux média donné: on déclenche à distance performance monitor sur tous les équipements traversés (routeurs ou switchs) par le flux en question et on récupère automatiquement toutes les statistiques.
- ERSPAN sur interfaces WAN – on peut maintenant rediriger les flux de tous types d’interfaces sur un serveur d’analyse via un tunnel GRE
- NBAR – en plus du support d’IPv6, de nombreuses applications ont été ajoutées à la liste.
- NBAR – peut faire du DPI sur des interfaces tunnel (GRE, DMVPN, IPsec)
- Netflow – possibilité d’exporter la catégorie et l’attribut NBAR d’un flux (cela permet de grouper des flux qui sont semblables: par exemple “applications web”)
- Netflow – possibilité d’exporter la VRF associée au flux
Sur la haute dispo, quelques petites améliorations:
- NAT64 et FTP64, disponibles depuis la 3.4S ne sont plus impactés par un switchover au sein du châssis (mode HA intra-chassis)
- Les stats de QoS sont conservées en cas de switchover dans le châssis
Et aussi:
- EEM 4.0 – comme sur la 15.2(2)T on supporte maintenant EEM4.0 qui permet entre autres de contrôler les ressources utilisables par chaque script, et éviter des dégâts en cas de mauvaise programmation…
- Plusieurs améliorations sur la voix (ALG SCCPv17, CAC…)
- On complète le support de protocoles ATM et FR pour avoir la parité avec le 7200 qui est en fin de vie
N’oubliez pas de consulter les release notes pour avoir le détail de ce que la 3.5S peut vous apporter: http://www.cisco.com/en/US/docs/ios/ios_xe/3/release/notes/asr1k_feats_important_notes_35s.html
Ceux qui suivent mes divers updates ne manqueront pas de voir les bénéfices de l’intégration de l’ASR1k et des ISRG2 au sein de la même BU (Business Unit): les fonctionnalités commencent à arriver en même temps sur les produits ce qui permet d’avoir un WAN homogène. Je n’oublie pas que j’ai promis un article abordant “Next-Gen WAN” sur ce blog…
Authors
2 commentaires