Cisco France Blog
Partager
tweet

Cisco France Blog > Réseaux

Réseaux

IOS 15.1(1)SY – Catalyst 6500 sup2T et sup720


29 October 2012

Je vous avais prévenus qu’on allait globalement vers de la simplification au niveau IOS: on converge entre les releases pour les 2 cartes de supervision sur le catalyst 6500, notre plateforme de coeur et de distribution principale pour les réseaux d’entreprise. Avec cette nouvelle release de nombreuses features sont ajoutées à toutes celles déjà disponibles sur la plateforme. On trouve notamment des évolutions sur les thématiques suivantes: haute disponibilité, IPv6, auto-configuration, sécurité, H-QoS… encore du neuf, et ça ne vas pas s’arrêter de sitôt !

Je vais me contenter de décrire les évolutions principales car  une fois n’est pas coutume les équipes de développement du cat6k n’ont pas fait dans la dentelle!

Hardware

  • Cette release permet de supporter également les châssis 7604 et 7613-S (en plus bien sûr des châssis 6500-E). Je rappelle qu’on supportait déjà le châssis 7609-S depuis la version précédente. Pour mieux comprendre cette nouvelle croisée des chemins lisez mon récent post.
  • Possibilité d’ajouter une carte de type 61xx (en mode bus) sur le slot de la sup standby du châssis 6513-E (il reste impossible d’insérer une carte 67xx, 68xx ou 69xx)
  • Support des SFP+ LRM et des X2-10G-T (10GE cuivre)

Routage

  • OSPFv3 PE-CE: permet d’activer le routage IPv6 OSPFv3 dans une VRF
  • OSPF for routed access (avec limite à 200 routes)
  • Address-families OSPFv3: permet de faire entre autres
  • NAT VRF-aware: on supportait déjà la fonction NAT pour des VRF multiples uniquement si les adresses ne se recoupaient pas entre ces dernières! Maintenant on n’a plus aucune limitation et le cat6k nous permet donc, sans nécessiter de module de service, de supporter cette fonction avancée. On peut à la fois la déployer au niveau d’un PE pour un backbone MPLS mais également à l’accès d’un réseau en VRF-lite (sans MPLS).
  • VRRPv3 pour offrir une redondance pour la passerelle par défaut IPv6
  • Policy-Based Routing pour IPv6

MPLS et VPN

  • A-VPLS. On supportait déjà la fonction VPLS sur un VSS qui est un moyen simple et efficace d’offrir une redondance VPLS. Ici on va ajouter 2 choses: tout d’abord une simplification de la configuration qui nous permet de configurer VPLS globalement au niveau du trunk (au lieu de répliquer la même configuration pour chaque VLAN où la configuration doit traditionnellement être faite). On supporte également un flow label MPLS qui va être ajouté par l’ingress PE. Ce flow label, qui dépendra directement du flux transporté, va nous assurer qu’en cas d’ECMP au sein du backbone MPLS, un flux sera toujours routé sur un seul chemin, cela afin d’éviter des dé-séquencements.
  • Auto-configuration VPLS par BGP. Plus besoin de configurer les remotes PE pour chaque VFI, on va les apprendre grâce à une SAFI BGP ad-hoc.
  • VPLSoGRE et EoMPLSoGRE. L’idée consiste simplement à offrir des services MPLS (EoMPLS ou VPLS) au dessus d’un backbone IP (sans MPLS). Pour cela on va s’appuyer sur des tunnels GRE qui transporteront nos labels MPLS de “service”. Peut-être vous rappelez vous de ce récent article qui illustre la même idée pour des services L3VPN.

Multicast

  • MSR (Multicast Service Reflection) – permet plus ou moins de NATer pour des flux multicast
  • mLDP (multicast LDP), permet d’établir des LSP point-à-multipoint ou multipoint-à-multipoint et s’affranchir de PIM au niveau du coeur pour un déploiement de MVPN.
  • Multicast live-live. 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 et la fonctionnalité permet globalement d’offrir simplement un transport fiable du multicast sans pertes de paquets. En mode live-live on va configurer le réseau pour router chaque flux sur des chemins différents: l’algorithme RPF va s’appuyer sur une table de routage différente en fonction du groupe multicast en question. On a donc le support du multi-topology routing maintenant sur cat6k.
  • HSRP-aware PIM, permet à PIM d’être synchronisé avec l’état HSRP du routeur. Le DR (Designated Router) PIM sera le même que l’Active Router HSRP ce qui offrira une cohérence des routes

Auto-configuration

  • Support de la fonction smart-install director. Avec smart-install, un switch va automatiquement récupérer le bon IOS et la bonne configuration quand il est connecté sur le réseau. Ca permet notamment de déployer rapidement nos palettes de switchs d’accès (juste en les branchant). Smart install nécessite un director qui maintenant peut être sur nos 6k de coeur et/ou d’agrégation.

Haute disponibilité

  • BFD dans des tunnels GRE (permet de détecter très rapidement quand le tunnel est down et faire tomber les adjacences associées)
  • BFD pour les routes statiques: avec BFD on va vérifier que le next-hop statiquement défini est bien joignable (à la poubelle les scripts!) Fonctionne pour IPv4 et IPv6.
  • BFD pour les port-channels: idem on va pouvoir détecter plus rapidement la perte d’un port-channel qu’avec un tuning de LACP. BFD va être transporté sur un des liens selon le hashing. Tant qu’il y a un port physique dans le port-channel dans lequel BFD peut fonctionner ça marche. Et oui, ça marche en VSS quand les ports membres sont sur des châssis distincts!
  • BFD dans les VRF: pour améliorer la convergence entre PE et CE
  • BGP PIC Core & Edge : PIC (Prefix Independent Convergence) va permettre d’accélérer grandement la convergence BGP. Grâce à l’introduction entre autres d’une hiérarchie au niveau de la FIB, la convergence BGP ne va plus dépendre du nombre de routes présentes dans la table.
  • BGP best-external: lié avec la feature précédente, un routeur va continuer d’annoncer sa meilleure route externe (apprise via eBGP) même s’il reçoit une meilleure route par iBGP. Ainsi cela permet aux autres routeurs du réseau d’avoir dans la table BGP une route de backup.
  • SSO pour les tunnels IPv4 et IPv6 (en cas de bascule entre 2 Sup l’impact sur les tunnels devient donc quasi nul)
  • NSF et BGP graceful restart pour les address-families IPv6
  • OSPFv2 NSR (Non-Stop Routing): ici c’est l’intégralité de l’état du protocole OSPFv2 qui est synchronisé entre 2 sup. En cas de bascule on n’a plus besoin de NSF pour reconstruire les états protocolaires.
  • OSPF graceful shutdown: pour faire une maintenance sur un équipement, on va pouvoir simplement passer toutes les métriques OSPF avec une valeur infinie pour que le trafic soit re-routé. Ainsi les maintenances n’ont plus aucun impact! Ceux qui faisaient ça manuellement avant vont apprécier 🙂

Sécurité

  • Pour le trafic IPv6 avec l’extension hop-by-hop on va pouvoir filtrer de manière sélective le type de protocole transporté.
  • Extensions IPsec pour OSPFv3
  • Possibilité de supprimer la procédure de password-recovery afin d’éviter que quiconque avec un accès console puisse récupérer la main et modifier les passwords.
  • SGACL monitor mode: possibilité de tester une ACL basée sur les SGT (Security Group Tags) avant de l’appliquer. On a déjà ces features pour les ACL classiques et on l’étend donc pour les SGT. On limite ainsi le risque de tout casser lors de la mise en place de règles de sécurité.

Performance applicative

  • Support de la H-QoS sur la carte 6904 (4 ports 40GE/16 ports 10GE SFP+). On ne garde que 8 files d’attente mais on va avoir la possibilité d’avoir un premier niveau de shaping avant d’avoir notre scheduling. Plus besoin de cartes “ES” donc (d’ailleurs pas supportées en sup2T) quand est dans un cas de figure classique dans lequel le débit contractuel offert par l’opérateur est plus faible que le débit de l’interface. Une nouvelle raison de privilégier la carte 6904 (qui d’ailleurs nous offrira encore des surprises dans la prochaine release!!!)
  • Support de Flexible Netflow pour des flux IPv6 bridgés
  • Visibilité avec Flexible Netflow (FNF) des flux IP sur le backbone MPLS. On avait déjà le suport de FNF dans les VRF, c’est-à-dire sur les PE, et maintenant on a la visibilité sur tout le backbone.
  • Export par FNF des adresses MAC et des informations sur le port (LTL) associées à un flux (permet de détecter un spoofing d’adresse par exemple)

Management

  • Management dans la VRF pour: FTP client, TFTP serveur et client, syslog, exports Netflow, NTP
  • Support de FTP, TFTP et de NTPv4 sur IPv6
  • EEM 4.0 – augmente le nombre d’objets à disposition pour scripter
  • IP SLA VRF aware 2.0 (augmente le nombre de tests qui peuvent être faits dans les VRF)

Divers

  • Energywise 2.5
  • POE+: négociation de la puissance LLDP

Références

Tags:
Laisser un commentaire