Juniper France Tech Blog
Showing results for 
Search instead for 
Do you mean 

Approche d’automatisation réseau par France-IX

by Arnaud Fenioux (Afenioux) ‎06-09-2017 04:47 AM - edited ‎06-09-2017 07:18 AM

L’automatisation fait partie des tâches des administrateurs réseaux depuis longtemps. De la même manière que les ingénieurs systèmes sont passés des boucles ssh à des outils plus sophistiqués il y a des années, les NetOps évoluent maintenant des scripts rancid et expect vers des outils plus puissants et plus robustes.

 

France-IX est le le premier fournisseur de service de peering Internet en France, offrant des services d'interconnexion publics et privés via ses 11 points d'échange neutres à Paris et à Marseille. France-IX interconnecte plusieurs centaines d'opérateurs de télécommunications, de fournisseurs de services Internet, de contenu, de réseaux de distribution de contenu et et de tous les autres réseaux du monde entier avec un trafic significatif sur le marché Internet français. Ces réseaux réclament une qualité de réseau et des performances exceptionnelles.

 

Le défi chez France-IX consiste à gérer la croissance accrue du trafic et à répondre aux attentes de nos clients. C'est la raison pour laquelle nous avons abordé l'automatisation réseau sous différents angles : la première approche est plus proche du code, en utilisant Python et PyEZ alors que la seconde est plus abstraite, en utilisant Ansible.

 

Approche 1 : Automatisation avec Python et PyEZ

---

Dans notre processus actuel, nous utilisons des scripts Python avec la bibliothèque JunOS PyEZ afin de déployer la configuration sur notre équipement via Netconf. Junos PyEZ est connu sous le nom de « Bibliothèque Python pour l'automatisation Junos» : https://github.com/Juniper/py-junos-eznc. Un bon article d'introduction est disponible ici : https://stebe.info/2016/11/introduction-junos-pyez/ .

 

Par exemple, dans notre utilisation actuelle, toutes les configurations courantes telles que ntp, tacacs, syslog, et règles de filtrage sont déployées de cette façon pour assurer la cohérence sur l'ensemble de notre réseau. Cela nous permet également de modifier certaines configurations rapidement et efficacement en ne déployant qu’un fragment de configuration vers un ensemble d’équipements.

 

Comme vous pouvez le voir dans le schéma ci-dessous, nous utilisons un serveur où nous avons configuré l'environnement de développement afin de déployer les configurations via le réseau OOBM.

 graphic.png

 

Il est également possible d'exécuter un ensemble de commandes (format cli possible mais non recommandé). L'objectif n'est pas de faire la configuration ni de parser la sortie texte, mais cela peut être utile pour vérifier certains compteurs, remettre à zéro les compteurs de manière globale ou de collecter des données spécifiques.

 

Certains des scripts et exemples de France-IX sont disponibles ici (dans la section PyEZ) : https://github.com/afenioux/hackathon-evpn .

 

Pour aller encore plus loin, nous aurions pu choisir d'utiliser les templates jinja, compléter ces templates avec Python et déployer le résultat comme nous l'avons fait avec le PyEZ (exemples disponibles ici: https://github.com/ksator/python-training-for-network-engineers). L'alternative que nous avons décidé d'utiliser chez France-IX est Ansible.

 

Approche 2 : Automatisation avec Ansible

---

Ansible est un logiciel d'orchestration open-source qui automatise le provisioning logiciel, la gestion de la configuration et le déploiement d'applications. Il utilise une architecture sans agent, ce qui signifie que les nœuds sont gérés par une machine maître via SSH, mais n'ont pas besoin d'installer ni d'exécuter de logiciel localement. Initialement utilisé pour la gestion de serveurs, des fonctionnalités supplémentaires ont été ajoutées pour la gestion d’ équipements réseau.

 

Nous utilisons des playbooks pour décrire les configurations, le déploiement et l'orchestration dans Ansible. Chaque playbook lie un groupe d'hôtes à un ensemble de rôles, et chaque rôle est découpé en tâches Ansible. La documentation est disponible à l'adresse suivante : http://docs.ansible.com/ansible/playbooks.html .

 

Il existe actuellement deux modules Ansible qui peuvent être utilisés pour gérer les équipements JunOS. Même si ces modules dépendent de scripts et de bibliothèques Python, il n'est pas nécessaire d'écrire de code Python pour les utiliser.

 

Le premier module a été développé par Juniper (http://junos-ansible-modules.readthedocs.io) et comprend une multitude de fonctionnalités (remise à zéro de l’équipement, installation de l'image JunOS, configuration, snapshot de la configuration et possibilité de faire des tests). Certaines fonctionnalités ne sont disponibles qu'avec ce module.

 

Le deuxième module a été développé par l'équipe Ansible. Bien qu'il soit limité en terme de fonctionnalités, il apporte une perspective intéressante car il respecte le principe de l'idempotence (peu importe combien de fois vous exécutez les instructions, le résultat sera toujours le même) et fait partie des modules de base. La documentation est disponible à l'adresse suivante: https://docs.ansible.com/ansible/list_of_network_modules.html#junos .

 

Ces deux modules ont été utilisés pour automatiser le déploiement de configuration sur un backbone de test avec MPLS et EVPN lors d'un hackathon de 3 jours organisé par Juniper France en Mars 2017. Grâce à cet ensemble de playbooks, nous avons déployé toute l'architecture (Routeurs P et PE, plus un Route-Reflector, avec ISIS, LDP, BGP et EVPN) sur 7 vMX en moins de 2 minutes. Nous avons également profité de la sortie XML fournie par les XML-RPC invoquée sur l'équipement pour effectuer des tests sur le réseau, tels que l'état des interfaces physiques, l'accessibilité des IP loopback et les adjacences ISIS et BGP. La configuration du lab, la topologie ainsi que les playbooks d’exemples sont disponibles ici : https://github.com/afenioux/hackathon-evpn dans la section Ansible-lab.

 

Perspectives

---

Comme vous pouvez le voir, beaucoup de choses peuvent déjà être réalisées d'une manière élégante avec ces outils, en moins de temps qu'on ne s'y attendrait. Vous êtes plus que bienvenu si vous souhaitez vous inspirer de nos exemples.

 

Chez France-IX, la prochaine étape consiste à récupérer des données de notre système interne basées sur Netbox (https://github.com/digitalocean/netbox) afin d'automatiser le provisioning de nouveaux clients en 2017. Nous réfléchissons déjà à d'autres projets d'automatisation pour 2018, restez à l’écoute !

 

A propos de l'auteur

---

Arnaud Fenioux est actuellement ingénieur réseau chez France-IX, le premier fournisseur de services de peering Internet en France. En charge de la gestion des opérations réseau, du déploiement à la maintenance (réseau MPLS/VPLS, réseau OOB), il est fortement impliqué dans les projets d'automatisation liés aux livraisons de service client et aux déploiements réseau. Avant de rejoindre France-IX, Arnaud a eu un rôle similaire au LyonIX (IXP régional français) et a débuté sa carrière dans l'administration de systèmes et de réseaux avec l'ISP Claranet et le site artprice.com.

 

Arnaud est diplômé de l’ESEO, école française d'ingénieurs basée à Angers. Il donne régulièrement des présentations dans des universités françaises et lors de conférences professionnelles et contribue activement aux hackathons organisés par le RIPE et Juniper par exemple.

speedometer-309118_640.pngLe piratage de voiture n'est pas un phénomène nouveau. En 2015 (et 2016), lors de la conférence Black Hat consacrée à la sécurité de l’information, il a été démontré que le moteur d'une voiture pouvait être coupé en prenant le contrôle d'un logiciel embarqué.

 

Ce qui est nouveau, c'est le nombre croissant de personnes qui achètent et conduisent des voitures connectées, se fiant à leurs logiciels et à leurs fonctions intelligentes. Et cette tendance ne fait qu'augmenter la visibilité de ces produits. Selon les estimations de BusinessInsider.com dans un rapport récent, 380 millions de voitures connectées seront sur les routes d'ici 2020. Ce chiffre ne peut que motiver les hackers à investir le temps et l'énergie nécessaires pour développer des kits exploits.

 

Nous devrions vraisemblablement bientôt assister à l'émergence d'attaques de sécurité ciblées sur les propriétaires de voitures connectées. Les hackers auraient recours à l'ingénierie sociale pour entrer en contact avec le conducteur dans le but de lui refuser l'accès à son véhicule ou de l'empêcher de l'utiliser, voire de prendre le contrôle de systèmes connectés. Cela pourrait se manifester par la désactivation de la navigation ou par des actes plus inquiétants, tels que la prise de contrôle via la technologie « by-wire », impliquant des commandes sans liaison mécanique, qui est utilisée aujourd'hui dans de nombreux véhicules pour le freinage et l'accélération.

 

Imaginez le scénario :

Vous vous rendez en voiture au travail et un message s'affiche sur l'écran de votre véhicule : « Révision prévue dans 30 jours, nous pouvons vous réserver un rendez-vous le xx/xx/xxxx. Cliquez pour accepter ou annuler ». Le message ne vous paraît pas suspicieux, vous sélectionnez « accepter ». Et vous venez juste d'être piraté. Au prochain arrêt de votre voiture, vous ne parviendrez pas à la redémarrer ou bien la climatisation se bloquera sur la température la plus froide. Et les failles ne s'arrêtent pas là. Les hackers pourraient avoir accès à distance aux systèmes embarqués à des fins d'enregistrement, de géolocalisation et potentiellement de chantage. Ce type d'attaque n'est limité que par les fonctionnalités du véhicule et la créativité du hacker.

 

La première attaque de ce genre ne sera certainement pas fortuite. La fenêtre d'opportunité se fermera dès que les constructeurs renforceront la sécurité des véhicules. Néanmoins, cela risque de n’avoir pour effet que de décupler la détermination des hackers. La première attaque ciblera peut-être une célébrité afin d'attirer l'attention. Il s'agira certainement de « l'expérience la plus traumatisante qu'il ou elle aura vécu », mais cela aura surtout pour conséquence de ternir l'image de marque du constructeur, tout en braquant les projecteurs sur la célébrité et le cybercriminel.

 

Jusqu'ici, les attaques sur les voitures connectés étaient limitées et nécessitaient une connexion physique à un port à l'intérieur du véhicule. Le fait que les voitures neuves vendues à l'heure actuelle intègrent la connectivité mobile et l'accès en ligne, augmente la probabilité d'une attaque. De nombreux constructeurs automobiles ont déjà implémenté des pare-feu et continuent d'en mettre au ... pour protéger les systèmes embarqués, mais ce n'est pas encore le cas de tous.

 

Comment les propriétaires de voitures connectées peuvent-ils mieux se protéger ?

  • Une sensibilisation aux questions de sécurité : De manière générale, nous avons pris l’habitude de ne pas répondre aux SMS ou aux e-mails non sollicités, et bien cela doit être similaire dans un véhicule. Si vous recevez un message inattendu par le biais de la technologie de votre voiture connectée, ne l'acceptez pas aveuglément. Au contraire, prenez le temps de le lire et de rechercher les erreurs évidentes de grammaire ou d'orthographe. Si un doute subsiste, demandez l'avis de votre concessionnaire avant d’accepter le message. Misez toujours sur la prudence avant tout.
  • La communication du constructeur : Les conducteurs sont enthousiastes à l'idée des opportunités offertes par les voitures connectées et les constructeurs développent des applications et des API (interfaces pour le développement d'applications personnalisées) afin d'étendre les fonctionnalités. Par conséquent, en cas de problème ou de panne, les constructeurs doivent communiquer rapidement et de manière transparente.

                                                                                 

D'ici 2018, davantage de voitures connectées seront en circulation, en particulier avec l'adoption de l'initiative eCall en Europe et l'étude de la technologie V2V (véhicule à véhicule) par le Département des Transports américain. Il s'agit d'une part d'une avancée pour les conducteurs, mais d’autre part d'un défi pour les constructeurs avec les multiples systèmes d'exploitation et les millions de lignes de code que cela implique. Les cybercriminels ont bien conscience que les conducteurs sont prêts à payer pour que leur voiture puisse continuer à rouler et cela représente un risque à ne pas négliger pour les prochaines années.

 

Mon conseil : réfléchissez avant de cliquer !

 

do-not-enter-1293296_640.pngL'année dernière, nous avions beaucoup entendu parler du malware Mirai. Mais saviez-vous que « Mirai » signifie « futur » en japonais ? Nous pouvons facilement penser à un présage : le futur des cyberattaques.

Read more...

key-43992_640.png

Si nous observons l’évolution des technologies informatiques au cours de 25 dernières années, il semble que le développement des malwares ou le vol de données suivent de près les avancées technologiques majeures. Examinons les exemples suivants :

  • Le développement des serveurs et des PC de bureau a rapidement été suivi par l’apparition des virus informatiques. Vous souvenez-vous de Cascade, l'un des premiers virus ?
  • Ensuite, nous avons vu l’émergence d’Internet, une invention révolutionnaire pour qui y avait accès en 1994, notamment pour les hackers qui trouvaient des données d'entreprise et des identités en ligne faciles à récupérer.
  • Aujourd'hui, nous avons l'IoT, qui entraîne l'adoption du cloud et de la mobilité mais qui entraine également des attaques DDoS, via des botnets et par le biais d’ingénierie sociale, car les acteurs malveillants suivent l'innovation.
Read more...

Si vous n'aviez pas déjà mis une alerte sur votre smartphone ou dans votre calendrier, de nouveaux bouquins Day One sont apparus pour la nouvelle année!!

Cliquez sur le Day One qui vous intéresse pour accéder directement à la page de téléchargement...

 

D1-cli-2nd-edition-cover.pngLa seconde édition du Day One Junos CLI:

 

Les deux bouquins Day One les plus téléchargés ont été mis à jour, révisés et regroupés en un seul Day One!

 

Tout ce que vous devez savoir pour configurer Junos OS dans votre équipement, modifier, sauvegarder, charger, fusionner des configurations et les vérifier!

 

Explorez toutes les capacités de Junos OS avec ce guide d'utilisation complet!

  

 

 D1-bgp-flowspec-cover.pngComment déployer BGP Flowspec:

  

Au moment où les attaques DDoS reprennent de plus belle sur Internet, et font perdre des centaines de milliers d'Euros, voire des millions, aux Entreprises connectées sur la toile, ce petit bouquin est le bienvenu pour mettre en place rapidement les outils de protection dans vos routeurs, afin de minimiser automatiquement l'impact de ce type d'attaques.

 

Utilisez la techonolgie Junos BGP Flowspec sans modération ;-)

 

 

D1-routing-internet-protocol.jpg

 Apprendre facilement à configurer RIP, OSPF, ISIS, BGP:

 

En quelques lignes d'explication, vous saurez configurer les différents protocoles de routage IP. Ce petit manuel vous rappelle les principes de ces algorithmes de routage et comment les utiliser et les mettre en place sur votre réseau de routeurs Junos.

 

Vous maîtriserez ainsi en l'espace d'une journée seulement tous les aspects

du routage IP.

  

 

ambassadors-cookbook-2017.pngL'édition Cookbook 2017 de nos ambassadeurs:

 

Nos ambassadeurs ont travaillé pour vous et vous donnent dans celle nouvelle édition leurs trucs et astuces pour gagner du temps à configurer par exemple de la QoS de base, migrer votre Cisco LNS vers un vLNS sur nos Juniper vMX Series, mais aussi faire vos premiers pas avec la technologie EVPN/VxLAN, travailler vos premiers scripts Python avec Junos PyEZ pour tester votre réseau ou encrore migrer votre coeur de réseau avec Segment Routing...

 

Avantage: ce sont des exemples de configuration testée et déployés par les auteurs ;-)  

 

 

cgnat-up-runnning-mx-series.pngLe CGNAT sur MX:

 

Les cartes MS-MPC et MS-MIC sur MX ont des fonctions avancées pour supporter le NAT dynamique, des fonctions NAT avancées comme le PAT, les ALG... tout cela à très grande échelle.

 

 Apprenez à configurer du NAT avancé pour vos différents besoins de translation réseau!

 

 

 

  

Et bien sûr, retrouvez tous nos autres Day One et Posters d'aide à la configuration Junos sur: 

http://www.juniper.net/uk/en/training/jnbooks/day-one/

http://www.juniper.net/uk/en/training/jnbooks/day-one/day-one-posters/

 

Bonne lecture!

 

arduino-1128227_640.jpg

L'Internet des objets est partout. On compte à l'heure actuelle environ 15 milliards d'appareils connectés dans le monde , représentant malheureusement presqu’autant d'occasions d’être victime d’une cyber-attaque.

Read more...

umbrella-158164_640.png

Il y a trois ans, le concept d’Internet des objets (Internet of Things ou IoT) était encore une nouveauté. On achetait des objets connectés parce qu’ils étaient à la mode ou pour le confort de vie qu’ils étaient censés nous procurer. Ce marché connaît une très forte croissance depuis et l’IoT a évolué. Presque tous les appareils sont dorénavant proposés avec cette nouvelle fonctionnalité, que l’on se procure un traditionnel smartphone ou une caméra de surveillance, voire même une cafetière ou encore un parapluie.

Read more...

Première Partie : Les nouveaux investissements des DSI dans leur stratégie de Cyberdéfense

Read more...

Ce test a été réalisé en par l’université de Nantes (Yan Dupont) et RENATER.

 

RENATER, Réseau National de télécommunications pour la Technologie l’Enseignement et la Recherche, fédère les infrastructures de télécommunication pour la recherche et l’éducation. RENATER interconnecte les centres de recherche et d’éducation aux autres réseaux nationaux de la recherche (NREN) via le réseau pan-européen  GÉANT.

Le réseau RENATER permet la collaboration des chercheurs et enseignants français entre eux et avec leurs collègues dans le monde grâce à des services de vidéo-conférence, transfert de données ultra-performant.

 

L’interconnexion des centres de calcul (centres de données) est un sujet majeur pour l’éducation et la recherche. Par exemple, c’est grâce à la construction d’une grille mondiale de calcul composée de dizaines de centre de calculs travaillant en collaboration avec le CERN (Centre Européen de Recherche Nucléaire) que le Bosons de Higgs a été découvert. La science est par nature un gros consommateur de calcul et de données. Les réseaux de nationaux de la recherche considèrent que dans un futur proche les centres de calcul vont grossir et que le nombre de leurs utilisateurs va aussi croitre rapidement avec l’émergence des technologies liées au Cloud.

 

Les centres de calculs sont très importants pour nous et nous avons la chance de posséder des relations fortes avec nos utilisateurs. Nous travaillons à leur fournir des services qui correspondent à leur besoin mais nous essayons d’aller au-delà en leur proposant des services innovants qui pourraient leur offrir de nouvelle opportunité de développement. Nous étudions Ethernet VPN (EVPN) pressenti comme futur protocole pour l’interconnexion des centres de calcul. Il est crucial de vérifier auprès de ces centres de calcul si EVPN correspond à leur attente et à leur cas d’usage. La capacité de pouvoir démontrer grâce à un PoC (Proof of Concept) les nouvelles fonctionnalités est un atout important. Un centre de calcul est opérationnel 24/7, il est vital de démontrer la fiabilité de toute brique ou service que nous proposons à nos utilisateurs.  

 

L’utilisation de routeur virtuel comme les Juniper Networks® vMX 3D Universal Edge Router correspond à notre besoin en terme de simulation pour notre ingénierie. Nous pouvons créer facilement des backbone complets permettant de valider le control plane et le forwarding plane. La démonstration de concept de mobilité de machine virtuelle sur EVPN nous permet notamment de juger la maturité de l’implémentation. Ce type de testbed n’est pas utilisé dans notre environnement comme test de performance. La mobilité de Machine Virtuelle (VM) est attendue depuis longtemps dans le monde des centres de calcul notamment pour développer de nouveau paradigme de services.

Démonstration de mobilité de machine virtuel

Démonstration

Objectifs et dispositif

Le but est de démontrer une mobilité de VM entre 2 sites sur un backbone EVPN.  Le routage à l’intérieur de l’instance EVPN doit être maintenu opérationnel après la migration. Le routage entre l’intérieur de l’instance EVPN et l’extérieure de l’instance (Internet) doit être maintenu opérationnel et optimal après la migration.

 

Notre installation est la suivante. Trois serveurs x86 jouent le rôle de 2 centre de calcul et le backbone EVPN :

  • Serveur Testbed-renater-a jouera le rôle du centre de calcul 1
  • Serveur Testbed-renater-c jouera le rôle du centre de calcul 1
  • Serveur Testbed-renater-b jouera le rôle du backbone EVPN + celui de l’Internet. Dans Testbed-renater-b, nous utilisons des virtual MXs :
    • vMX1 est un PE (Provider Edge) qui connecte le DC1 et une instance EVPN (EVI) appelée “BD3”
    • vMX2 est un PE (Provider Edge) qui connecte le DC2 et une instance EVPN (EVI) appelé e“BD3”
    • vMX3 est un PE qui interconnecte l’EVI “BD3” à l’Internet public.
      • Sur vMX3 un Logical System “VM133” (avec pour adresse IP 77.77.77.77) émule un “pseudo Internet” afin de vérifier le routage optimal entre l’instance EVPN et le reste du monde. VM133 échange via BGP de préfixes avec vMX3
      • Du point de vue de vMX3, VM133 est client de la VRF appelé IPVPN-1

 Visio 1 hi res.jpg

Figure 1: Nantes University Testbed (source RENATER®)

 

Visio 2 hi res.jpg

Visio 3 hi res.jpg

 

Figure 2: Final objective – Keeping routing optimal in VM mobility context (source RENATER®)

 

Après la mobilité de la VM, le trafic issu de l’Internet reste optimal. Ce trafic utilize le chemin direct (optimal) vers l’endroit où la VM a été déplacée sans passer par le PE où la VM était connecté orginellement. La flèche pointillée rouge de la Figure 2 illustre ce point.

 

Design

Le design suit principalement la documentation Juniper : DAY ONE: Using Ethernet VPNS for Data Center Interconnect. La différence principale est que l’EVI “BD3” n’est pas du type VLAN-aware bundle service mais VLAN-based service. Ce point n’a pas d’influence sur l’objectif de la démonstration.

 

Protocole implémenté sur le backbone : OSPF, BGP avec la family EVPN, MPLS, RSVP.

 

Les 3 serveurs utilisent KVM comme hyperviseur mais de toute façon EVPN est agnostique à la technologie de virtualisation employée. Pour la machine testbed-renater-b qu’héberge les vMX, nous avons choisi le para-virtualization qui permet la mobilité de machine d’un hyperviseur vers un autre sans reconfiguration de la VM. Nous avons implémenté les vMX routeurs en utilisant virtio. Pour la migration de VM d’un hyperviseur à l’autre, nous avons utilisé les outils standards de “KVM”.

 

Conclusion

Le test été un succès important pour nous. Il va nous aider à déployer de nouveaux services réseaux à la pointe du développement dans notre portfolio de services. L’utilisation de routeurs virtuels MX a démontré son utilité pour notre activité d’ingénierie réseau. Cela ouvre de nouvelles opportunités notamment dans le contexte des Network Function Virtualization (NFV).

 

Le déploiement d’Ethernet VPN est très important pour RENATER et cette expérience démontre que l’implémentation d’EVPN fourni par Juniper a un bon niveau de maturité. Grâce à Juniper, nous avons pu démontrer à nos utilisateurs que RENATER travaille à fournir des nouveaux services réseaux adaptés à leur besoin. Ils ont apprécié cette démonstration et nous espérons démarrer bientôt avec eux une collaboration sur ce sujet EVPN. Cette preuve de concept a été très utile, mais nous devons prendre en considération que cette fonctionnalité nécessite de fortes performances notamment lorsque les centres de calcul sont éloignés et la latence importante. Nous allons donc continuer notre étude sur EVPN dans ce cas mais aussi à propos d’autres fonctionnalités comme le load balancing par flow.

 


EVPN_VM_Mobility_demo_RENATER by xavier-jeannin

Network Test a réalisé cet automne des tests de capacité et de performances sur notre nouveau switch de coeur Datacenter Juniper QFX10002-72Q. Celui-ci a été testé à pleine charge, soit dans sa configuration 72 ports 40GE, soit dans sa configuration 24 ports 100GE, connectés sur un testeur Spirent N11U avec le même type d’interfaces.

 

 

Network Test est un organisme indépendant et reconnu pour ses services de mesure et tests d'équipements réseaux des constructeurs ou directement dans les environnements réseaux opérateurs ou grandes entreprises.

 

Ces tests sont disponibles en détail ici: http://networktest.com/jnprqfx10k/ et ont consisté à évaluer les éléments suivants:

- ses capacités de routage 40GE EVPN à travers des tunnels VxLAN

- son throughput 40GE et 100GE selon la RFC2544 unicast

- son throughput 40GE et 100GE selon la RFC3918 multicast

- sa consommation électrique

- sa capacité de buffering à 40GE et 100GE

- ses capacités en nombre d’ARP, de MAC RFC2889, d’IPv4/v6, de FW Filters (ACL)

- le nombre d'instances L3VPN et VRF lite en OSPF ou BGP associé à BFD

 

Tous ces tests devaient durer 2 semaines selon Network Test mais ils ont été finalement effectués en seulement 4 jours !

Grâce notamment à des outils d’automatisation, comme la création de templates Jinja2 et l’utilisation de PyEZ sur JunOS, les configurations de tests ont pu être préparées à l'avance et ainsi exécutées rapidement à la demande.

 

Le premier test EVPN/VxLAN était important car c'est le premier réalisé publiquement. EVPN/VxLAN est en effet devenu le standard maintenant adopté par les acteurs du Cloud et Datacenter hautes performances, c’est pourquoi Juniper tenait à démontrer comment et jusqu’à quel niveau de capacité, le QFX pouvait supporter ce type de technologie. Les hautes performances obtenues pour ces tests sont la preuve que Juniper a bien fait de choisir de développer son propre ASIC Q5 pour la nouvelle gamme de switchs QFX10000 de Datacenter, contrairement à ses concurrents qui continuent de s’appuyer sur les développements de Broadcom.

 

En effet, grâce à sa capacité mémoire embarquée directement sur l’ASIC Q5 pour faire des lookups, le QFX10002 obtient des résultats line-rate dès la taille de 400 octets par paquet routé à travers des tunnels VxLAN.

En ce qui concerne les RFC 2544, et RFC 3918, le QFX10002 atteint des valeurs line-rate en unicast et en multicast pour du trafic IMIX mais aussi pour des tailles de paquets plus petites à compter de 160 octets par paquet.

Le QFX10002 se positionne donc également comme un très bon équipement de diffusion vidéo avec plus de 128000 groupes multicast supportés.

 

Il est capable de supporter jusque 434000 MACs sans aucune collision et peut enregistrer jusque 512000 adresses.

Le QFX10002 a été capable d’enregistrer jusque 500000 routes IPv4 et IPv6 simultanément et d'acheminer sans perte le trafic envoyé vers ces destinations.

 

Les tests concernant le plan de contrôle ont pu démontrer la capacité à monter 4000 L3VPN avec 4000 instances VRF-lite, que ce soit en utilisant OSPF ou BGP comme protocole.

BFD a également été testé avec 4000 sessions en parallèle de celles en OSPF ou BGP en configurant un intervalle de détection à 3x1s.

60000 FW filters (ACL) ont pu être configurés (2500 par port 100GE) sans réduire les capacités de throughput de la machine.

 

Enfin, le QFX10002 consomme un peu moins de 1kW à pleine charge, ce qui est moins qu’indiqué dans nos datasheets qui précisent le pire des cas possibles (température anormalement élevée, ventilateurs à pleine vitesse).

 

Le QFX10002 présente déjà des références à peine sorti des usines de production de Juniper, notamment chez les grands acteurs du Cloud et de l'hébergement. Il est principalement déployé comme coeur de Fabric IP/BGP Datacenter pour interconnecter en 40GE plusieurs dizaines de switchs ToR 10GE déployés dans les baies de serveurs.

Le support à grande échelle de EVPN/VxLAN est donc essentiel dans ce cas de déploiement pour interconnecter en niveau 2 au-dessus de la Fabric IP tous les serveurs physiques ou virtuels qui y sont interconnectés dans un ou plusieurs Datacenters !