Réseaux
IOS 15.0(1)SY1 – Catalyst 6500 sup2T
Je m’étais engagé à continuer à vous tenir informés des nouveautés IOS, et je risque d’avoir pas mal de pain sur la planche car beaucoup de plateformes se refont une beauté en ce moment. Le premier à dégainer a été le catalyst 6500 avec sup2T pour lequel vient tout juste de sortir la version 15.0(1)SY1 (je rappelle aujourd’hui: SY = Catalyst 6500 avec sup2T) Alors qu’est-ce qui change?
Tout d’abord on supporte plus de hardware:
- Service module ASA (firewall)
- NAM-3 (carte d’analyse réseau)
- La nouvelle carte 4 ports 40GE (CFP) qui peut aussi intégrer des CFP 4x10GE et offrir ainsi 16 ports 10GE (oversubscription 2:1). Cette carte supporte MACSEC sur tous ses ports (chiffrement line-rate du trafic)
- La carte 96 ports 10/100 RJ21 (WS-X6196-RJ-21)
Côté fonctionnalités on a encore beaucoup de nouveautés. Cette fois-ci les informations relatives à IPv6 seront le plus souvent réparties dans les diverses sections (virtualisation, sécurité, haute-dispo, visibilité). Rappelez-vous bien que IPv6 doit être vu comme orthogonal et non comme une simple feature de plus. On voit encore trop de CCTP mentionnant “Support d’IPv6 : OUI/NON”. Pensez bien à demander des détails! Fin de la parenthèse, commençons par les nouveautés qui concernent la virtualisation:
- On supporte maintenant EVN (Easy Virtual Networks) afin de simplifier la mise en place de réseaux virtuels au sein de l’entreprise (sans MPLS). Je n’ai pas beaucoup parlé d’EVN encore sur ce blog alors tâchons d’y voir plus clair. EVN n’est pas en soit une grande innovation technologique mais ça simplifie grandement les configurations. Aujourd’hui pour faire un réseau L3 virtualisé on va créer des VRF et pour faire parler 2 équipements on va les interconnecter avec un VLAN (si on ne veut pas rentrer dans la complexité de MPLS). Sur chaque interface on doit donc configurer autant de sous-interfaces que de VRF et mapper chacune d’entre elle dans la VRF idoine, avec à chaque fois une bonne chance de se tromper… Avec EVN on associe notre VRF à un tag qui n’est rien d’autre qu’un numéro de VLAN. On définira ensuite sur le réseau des trunks EVN (vnet trunks) sur lesquels les flux de chaque VRF seront automatiquement placés dans le bon VLAN, sans ne rien avoir à configurer sur l’interface. Pour échanger du trafic entre les VRF, pas besoin de RT on utilise simplement des fonctions de réplication de routes. Ce n’est pas sorcier mais ça aide et on aime! Notez que pour que tout cela marche il faut un équipement capable d’utiliser plusieurs fois le même numéro de VLAN sur des interfaces distinctes tout en routant entre elles… Promis je posterai quelque chose sur le sujet avant l’été!
- Adaptation d’OSPF et d’EIGRP pour EVN. il est maintenant possible d’activer OSPF ou EIGRP sur une interface trunk EVN, et que cela ait une incidence sur toutes les VRF associées au trunk. Comme on n’a plus de sous-interfaces il fallait bien inventer une solution pour continuer à appliquer notre IGP préféré.
- Support de la fonction traceroute en utilisant le nom de la VRF. On a déployé EVN, les protocoles de routage sont configurés il faut être capable de troubleshooter. Cette commande est là pour cela.
- Support d’EIGRPv6 dans une VRF.
- mVPN (multicast VPN) supporté sur un design L3VPN over mGRE. La techno L3VPN over mGRE permet en gros d’étendre ses VRF au delà du LAN sans faire appel à son opérateur. On supportait déjà la fonctionnalité et on ajoute maintenant le support du multicast. Je vous conseille de regarder de près cette techno qui peut simplifier vos designs. Ici aussi je ferai un post plus détaillé sur cette techno qui va.
- Support du NAT44 pour les VRF dans le cas où les adresses dans les différentes VRF sont distinctes. Pour le support complet il faudra attendre un petit peu.
Sur les fonctions de sécurité:
- Trustsec / SGT: on peut mapper un VLAN ou un subnet dans un SGT (Security Group Tag). On peut donc aisément convertir d’anciennes règles de sécurité pour des subnets ou des VLANs dans des règles de filtrage basées sur le SGT associé.
- Support de VLAN ACLs (VACLs) pour IPv6
Parlons fast-convergence:
- Support de BFD pour une route statique (Si le next-hop n’est plus joignable on le détecte rapidement et on converge). Dans le cas où il y a plusieurs équipements actifs entre les deux noeuds IP ça peut éviter des scripts EEM et éviter de mettre en place un protocole de routage dynamique… Notons que cette fonction est suportées pour les routes statiques IPv4 et IPv6.
- Possibilité de faire tourner BFD dans une VRF. On simplifie la mise en place de réseaux virtuels au sein de l’entreprise (cf EVN plus haut) sans vouloir perdre en disponibilité
- Support de Fast UDLD
Spécifique à IPv6:
- Optimisation de NDP (Neighbor Discovery Protocol) via un caching réalisé par le switch. Le switch va par exemple être capable de répondre aux neighbor sollicitations à la place de l’hôte distant ce qui évite des échanges inutiles d’informations sur le réseau. On reprend ici des concepts introduits par la release 7.2 de nos Wireless LAN controller qui cachent également les données pour éviter de charger inutilement les liens radio.
Et pour terminer pour ce qui concerne la visibilité des applications:
- Support des AS sur 32 bits par Flexible Netflow. Je rappelle ici que si l’on parle beaucoup de l’exhaustion d’adresses IPv4, on a également une exhaustion des numéros d’AS initialement sur 16 bits. On est donc passés sur des AS de 32 bits. La migration reste moins complexe que celle d’IPv6 car elle ne concerne fort heureusement que les réseaux! Notez que si vous demandez un numéro d’AS au RIPE NCC, vous avez de très fortes chances de recevoir un AS sur 32 bits: assurez-vous que vos opérateurs seront capables de peerer avec vous!
- On aura maintenant Flexible Netflow dès IP base: quelques économies en perspective!
Release notes: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.0SY/release_notes.html
Tags:
3 commentaires