C’est ce qui est bien avec l’IOS 15: tous les 4 mois on a une nouvelle release! Alors quoi de neuf cette fois-ci? La liste est longue avec de nombreuses fonctionnalités “réseau” qui nous intéressent ici… Attention il y a du lourd!!!
Routage:
- BGP route-server: pour les petits points d’échange internet, une bonne solution pour éviter que tous les membres n’aient à peerer entre eux (plus d’infos ici)
- BGP best external: le routeur annoncera ainsi sa meilleure route parmi ses peers externes (même si une route interne a par exemple une local-pref plus élevée). Cela permet au peer de recevoir toutes les routes externes et de basculer de l’une à l’autre plus rapidement quand l’une est perdue (BGP PIC edge, activé dans le GRT va se baser sur ces 2 routes par exemple)
- BGP diverse path intègre plusieurs choses, toujours dans l’idée de pouvoir gérer la réception de plusieurs routes BGP et d’améliorer la convergence du réseau (IPv4/IPv6/VPN-MPLS):
- Au niveau des route-reflectors BGP – best-external décrit plus haut permet d’avoir sur les route-reflectors (RR) plusieurs routes externes pour un préfixe de destination (si bien sûr il y a des chemins de backup). Chaque RR calcule la “best” et la distribue à tous les routeurs du réseau, donc si l’on ne fait rien de spécial chaque RR choisit la même best et tous les routeurs n’ont finalement qu’une route (on perd la possibilité de backuper rapidement). “Diverse path pour les RR” va nous permettre sur l’un des deux route-reflectors de d’annoncer le chemin de backup: ainsi tous les routeurs du réseau reçoivent de chaque RR une route différente (avec par exemple 2 local-pref différentes).
- Au niveau des PE – Une fois que chaque routeur reçoit 2 routes via le mécanisme décrit ci-dessus, “Diverse path” permet d’installer ces 2 routes dans la RIB et de basculer rapidement sur le chemin de backup (BGP PIC).
- Dans le même esprit on va pouvoir décider pour OSPFv3 si l’on veut toujours préférer joindre une route d’une aire via un NH dans cette même aire où bien si l’on choisit parmi toutes les routes de toutes les aires.
- Filtrage des annonces BGP depuis les route-reflectors en fonction des RT configurés sur les PE. Les PE vont à travers une nouvelle SAFI dire au route-reflector quelles sont les RT ils veulent importer dans leurs divers VPN. Ainsi le RR ne leur enverra que les updates BGP concernant les routes d’intérêt et non toutes les routes de la SAFI vpnv4 (pour IPv4)
Multicast:
- Solution pour faire de l’anycast RP en IPv6 avec PIM (comme on n’a pas MSDP en IPv6 c’est la seule solution pour avoir de la redondance)
- Fast reroute pour le multicast (MoFRR – Multicast only Fast Re-Route). Le routeur à l’edge d’un site peut envoyer des PIM join sur 2 liens et reçoit donc 2 flux multicast. En cas de coupure sur le lien primaire le routeur peut transmettre immédiatement le flux multicast reçu sur le lien de backup.
- Multicast live-live. Pour ceux qui étaient restés sur un RPF une peu “bricolé” sur le train 12 on voit clairement avec cette feature toute la puissance de la MRIB apportée par le train 15. On peut maintenant créer plusieurs topologies multicast (MRIB) auxquelles on pourra associer diverses interfaces. On pourra peupler ces MRIBs via par exemple autant de topologies multicast IS-IS. En mode live-live, l’émetteur va transmettre 2 fois le même flux multicast et les récepteurs recevront 2 fois le flux. Ils feront le tri pour n’en garder qu’un au niveau applicatif. En mode live-live on va configurer le réseau pour router chaque flux sur des chemins différents en utilisant la flexibilité apportée par les topologies multicast sus-citées.
Performance applicative:
- Encore des améliorations sur Performance Monitor (qui nous permet de voir les perfs sur des flux RTP et TCP). Notamment on gagne énormément en visibilité sur les flux TCP avec entre autres l’observation des paquets désordonnés. On a également une fusion avec la reconnaissance applicative puisqu’on peut analyser des flux directement à partir du nom de l’application associée.
- Niveau optimisation WAN, on a quelques améliorations sur WAAS express (optimisation embarquée sur l’IOS qui ne nécessite pas de service-module). Notamment on a maintenant quelques “application optimizers”, c’est-à-dire des mécanismes d’optimisation spécifiques aux applications (et pas uniquement des améliorations globales au lien). On peut aussi optimiser sur plusieurs liens WAN à la fois.
- Support de TWAMP responder (Two Ways Active Measurement Protocol), protocole standardisé par l’IETF pour des mesures actives.
- Ajout de nouveaux tests IPv6 pour IPSLA (DNS, HTTP, FTP, Path-echo et Path-Jitter). Les deux derniers sont particulièrement utiles pour détecter/troubleshooter des problèmes de performance IPv6 en collectant les statistiques (loss, jitter) sur chaque segment jusqu’à la destination vers laquelle on constate un problème.
- Support de PfR target discovery pour simplifier grandement les configurations PfR (Performance Routing), solution qui permet de router les paquets en fonction de la performance des liens et leur adéquation par rapport aux applications transportées. Avec PfR target discovery, les master controllers des différents sites vont “peerer” entre eux et s’échanger les classes de trafic configurées, et par exemple les adresses des responders IPSLA associées.
- On reste sur PfR avec de nombreuses simplifications qui ont été apportées. Il devient par exemple inutile de configurer les 2 Border Routers (BR) sur le même lien: des tunnel vont se créer automatiquement pour permettre le re-routage entre BR quand ceux-ci ne sont pas sur le même lien. Beaucoup de configurations sont supprimées et sont activées par défaut car elles représentent presque la totalité des déploiements rencontrés.
- Fonction Media service proxy: le routeur qui possède des mécanismes d’inspection approfondis des flux (NBAR2) pourra construire des Metadata pour les différents flux et les envoyer aux divers équipements sur le réseau pour qu’ils traitent ces flux de la meilleure manière qui soit pour garantir la performance de l’application transportée.
Sécurité:
- Haute dispo pour le Zone-Based firewall (possibilité de configurer 2 ISR G2 en accès avec FW et d’échanger les états entre ceux-ci pour offrir une redondance sur le filtrage).
- Support du trafic asymétrique en cas de présence de 2 ISR G2 configurés en firewall (en gros les mécanismes de haute dispo décrits plus haut permettent d’échanger les états et on s’en sert pour permettre l’asymétrie)
- GETVPN pour le trafic IPv6 (GETVPN permet de chiffrer entre plusieurs routeurs, par exemple les flux sur un L3VPN any-any ou échangés via LISP) sans nécessiter de tunnel de chiffrement
- Possibilité de filtrer les extensions hop-by-hop IPv6 par des ACL (important car ces extensions peuvent être utilisées pour des denis de service.
- Support d’IPv6 pour FlexVPN
Management:
- Pour les allergiques à nos protocoles propriétaires on a maintenant le support de LLDP avec les MIB idoines. On supporte également la découverte des adresses IPv6 et des informations détaillées pour les endpoints via LLDP-MED.
- Support du “dying gasp” sur certaines EHWIC. En cas de coupure d’électricité, l’interface va pouvoir envoyer un signal sur les interfaces pour indiquer que la fin est proche… Cela permet aux routeurs distants suffisamment “aware” de déclencher un reroutage avant même que le routeur soit down et donc dans l’idéal re-converger sans perdre aucun paquet.
- Nouvelle MIB pour BGP (IPv4, IPv6, VPNv4, VPNv6…)
Divers:
- Support de WCCPv2 pour IPv6 et d’autres améliorations sur le protocole WCCP
- Support d’IPv6 sur le lien entre service-module et le routeur. On peut donc maintenant activer des services IPv6 sur les VM embarquées (voir ce post pour un test de VM sur ISR G2)
- Possibilité d’envoyer/recevoir des paquets 802.1Q avec un VLAN de 0 et d’avoir ainsi la possibilité de donner des informations sur la QoS voulues via le champ 802.1p (contrairement à ce que l’on a sur avec le VLAN natif qui se retrouve non taggué)
Release notes: http://www.cisco.com/en/US/docs/ios/15_2m_and_t/release/notes/152-3TNEWF.html
Laisser un commentaire