OCI VCN Transit Routing – Part 1

Posted on by kral2 Publié dans Cloud — Aucun commentaire ↓

La fonctionnalité « VCN Transit Routing » introduite en novembre dernier sur OCI (Oracle Cloud Infrastructure) permet d’élaborer des architectures réseaux supportant des cas d’usages avancés, s’appuyant entre autre sur la topologie « Hub-and-Spoke ».

Dans cet article, je vous présente :
– les concepts d’architecture hub-and-spoke,
– les différences entre hub-and-spoke et full-mesh
– les caractéristiques et avantages de chacun,
– les différentes variantes de topologie hub-and-spoke possibles avec OCI,
– puis les mécanismes OCI permettant de mettre en oeuvre ces architectures.

Dans les prochains articles, j’aborderai les détails d’implémentation de chacun des scénarios présentés.

Qu’est ce qu’une topologie réseau Hub-and-Spoke?

Hub-and-Spoke fait référence à la roue de vélo, avec son moyeu (hub) et ses rayons (spoke).

Le modèle Hub-and-Spoke est un concept pouvant s’appliquer à tout type de réseau. Prenons l’exemple d’un réseau de vols pour une compagnie aérienne, organisé autour d’aéroports majeurs (hub), d’une constellation d’aéroports régionaux reliés aux hubs, avec néanmoins du point-à-point lorsque c’est pertinent. L’avantage principal est de pouvoir atteindre plus de destinations avec moins de liens.

En informatique, le modèle d’architecture hub-and-spoke (Également appelé « réseau en étoile ») permet d’interconnecter plusieurs réseaux entre eux, à l’aide d’un point central.

Le modèle hub-and-spoke s’oppose aux réseaux maillés (mesh networks), mettant en oeuvre une liaison directe entre chaque point du réseau.

Comparativement à un modèle maillé, la principale caractéristique d’un modèle hub-and-spoke est la réduction du nombre de liens nécessaires pour interconnecter l’ensemble des points d’un réseau. Cette caractéristique devient déterminante à mesure que le nombre de noeuds augmente.

A titre d’exemple, voici un tableau comparant le nombre de liens nécessaires pour interconnecter l’ensemble des noeuds du réseau :

Nombre de LiensHub-and-SpokeFull-Mesh
323
436
5410
6515
7621
8728

Un réseau full mesh suit la formule ci-dessous pour déterminer le nombre de liens nécessaires :

L = N x (N – 1)/2

*Avec L pour Liens et N pour Noeuds

Le nombre de liens nécessaire au fur-et-à-mesure que le réseau grandit est exponentiel.

Le modèle maillé (full-mesh) excelle lorsque la latence est le critère déterminant, grâce à une connexion directe et sans intermédiaire entre deux points du réseau.

Un réseau hub-and-spoke est linéaire, avec néanmoins un « coût » initial d’un noeud supplémentaire dans le réseau (induit par le hub) :

L = N – 1

Le modèle maillé a cependant comme avantage une connexion directe et sans intermédiaire entre deux points du réseau : il conserve donc tout son intérêt dans certains cas.

Il est bien évidemment possible de mixer les deux modèles d’interconnexion au sein d’une même architecture réseau afin d’obtenir une topologie spécifiquement adaptée à la situation.

Enfin, le modèle Hub-and-Spoke est un concept de mise en réseau au sens large : prenons l’exemple d’un réseau de vols pour une compagnie aérienne, organisé autour d’aéroports majeurs (hub), d’une constellation d’aéroports régionaux reliés aux hubs, avec néanmoins du point-à-point lorsque c’est pertinent. On comprend vite l’intérêt du modèle lorsqu’il est nécessaire d’interconnecter deux hubs : plus de destinations accessibles avec moins de liens.

Ce schéma peut aussi faire référence à plusieurs VCN et régions OCI : les concepts d’interconnexion restent les mêmes.

Pourquoi une topologie réseau Hub-and-Spoke dans OCI?

Cela permet d’utiliser un VCN1 central pouvant offrir de la connectivité à d’autres VCN de la même région cloud. Sans cette capacité, un design à plusieurs VCN nécessiterait que chaque VCN ait sa propre connexion aux réseaux on-premises (n x VPN, n x liens FastConnect, etc …).

1. Mutualiser les accès on-premises

Le premier bénéfice est de mutualiser les accès au réseau on-premises pour plusieurs VCN :

  • le VCN central (HUB) porte les connexions vers les réseaux on-premises à l’aide de la DRG2,
  • Les autres VCN (SPOKE) établissent un peering avec le VCN HUB et accèdent par rebond aux réseaux derrière le VCN HUB.

Le VCN « HUB » n’est utilisé qu’en transit par les VCN « SPOKE » : il route le traffic selon les règles mises en place.

Réduire le nombre de liaisons aux réseaux distants (via VPN IPSec ou liaison dédiée), permet de :

  • réduire la charge administrative,
  • renforcer la sécurité globale en ayant moins de points d’entré à contrôler,
  • réduire les coûts dans le cas des liaisons dédiées.

Lorsque le traffic arrive depuis un VCN « SPOKE » dans le VCN HUB :

  1. Il peut être redirigé directement vers la DRG du VCN HUB (qui prendra à son tour la décision d’aiguillage selon la connectivité en place),
  2. Il peut être redirigé vers une instance présente dans un sous-réseau du VCN HUB.

La 2nd option permet par exemple de mettre en oeuvre une appliance de sécurité tierce pour tout traffic traversant le VCN HUB.

2. Simplifier les architectures multi-région/multi-VCN

Ce scénario s’apparente au premier, à la différence que la connexion au réseau tier sur le VCN HUB n’est pas un réseau on-premises, mais le réseau d’une autre région OCI : on connecte deux réseaux en étoile à l’aide d’une connexion point-à-point.

On cumule ici plusieurs fonctions OCI :

  • Remote Peering Connection (RPC) : pour interconnecter deux VCN HUB dans deux régions OCI, via le backbone privé OCI,
  • VCN Transit Routing : pour partager cette liaison RPC avec d’autres VCN dans chaque région.

3. Centraliser les liaisons de VCN à VCN d’une même région

Avant la fonctionnalité VCN Transit Routing, il était déjà possible d’effectuer des connexions point-à-point entre deux VCN (peering), à l’aide d’une LPG3. Cette topologie s’appuie sur le modèle de réseaux maillés, et comme vu précédemment peut vite atteindre des limites ou devenir compliqué à gérer en terme de nombre de liens.

La fonction « VCN Transit Routing » permet désormais d’interconnecter les VCNs d’une même région à l’aide d’un VCN central.

Un des intérêts de cette topologie est de pouvoir positionner un élément de sécurité central dans le VCN HUB, qui pourra contrôler le traffic Est/Ouest. Cela permet également d’interconnecter plusieurs VCNs ensemble, en allant au-delà des limites actuelles de LPG par VCN (par défaut, 10 LPG par VCN).

Comment créer une topologie Hub-and-Spoke dans OCI?

Dans le contexte OCI, une topologie hub-and-spoke se construit autour des VCNs, LPGs, DRGs et tables de routage. La nouveauté se matérialise par le fait que l’on peut désormais attacher une table de routage à une DRG et à une LPG, en plus de celles attachées aux sous-réseaux.

Ces deux nouveaux attachements de tables de routage utilisées de concert permettent de définir le chemin que devra emprunter chaque paquet entrant dans le VCN de transit :

  • le traffic arrivant sur une LPG peut être aiguillé :
    • vers la DRG du VCN (sortir de la région cloud),
    • vers l’IP d’une instance présente dans le VCN (ex: appliance réseau & sécurité).
  • le traffic arrivant sur une DRG peut être aiguillé vers une LPG du VCN (pour ressortir ensuite vers le VCN spoke associé) ou vers une IP d’instance présente dans le VCN HUB (ex: appliance réseau & sécurité).

Le schéma suivant illustre chacune des tables de routage à configurer afin d’activer une communication Est/Ouest entre les VCN 2 & VCN3.

Les éléments réseaux définis dans notre topologie cloud sont logiques (ce sont des éléments du SDN OCI), et sont bien évidemment découplés de la topologie physique du réseau OCID . D’après les tests que j’ai pu effectuer, le modèle Hub-and-Spoke OCI et les DRG/LPG ajoutés à l’architecture n’ont pas d’impact sur la latence, comparativement à un modèle point-à-point : nous sommes toujours sous la millisecond pour des communications intra-région.

Les prochains articles traiterons en détail de l’implémentation des 3 scénarios présentés :

  1. Mutualiser les accès on-premises & multi-cloud,
  2. Simplifier les architectures OCI multi-région/multi-VCN,
  3. Centraliser les liaisons VCN à VCN d’une même région.

Ils comporterons un synoptique des actions de configurations ainsi que du code Terraform permettant de recréer la topologie présentée.

  1. VCN : Virtual Cloud Network
  2. DRG : Dynamic Routing Gateway
  3. LPG : Local Peering Gateway
Tagués avec : , , ,

Opérations de base sur Comware OS (switches HPE FlexFabric)

Posted on by kral2 Publié dans CLI — Aucun commentaire ↓

TL;DR

J’ai récemment eu l’occasion de travailler avec un switch HPE5700. Ce modèle est issu du catalogue H3C et tourne sous Comware OS.

Assez déroutant lorsque l’on a pris l’habitude de la cli Cisco. Ce billet traite de la mise en oeuvre initiale et des opérations de base pour un switch fonctionnant sous Comware OS7.

N’ayant qu’un seul switch, je n’ai malheureusement pas la possibilité de tester les fonctions avancées telles que IRF1.

Caractéristiques physiques du HPE 5700-48

Le 5700 48G (modèle JG894A) est un switch datacenre composé des ports suivants :
– face avant :
– 48 ports fixes GbE base-T,
– 4 ports 10GbE SFP+,
– 2 ports 40GbE QSFP+
– face arrière :
– 1 port GbE base-T pour le management (OOBM),
– 1 port console.

Voici un lien vers le document quickspec HP5700

Basculer entre les modes view/config, sauvegarder la config

On démarre en mode visualisation lors de la première connexion, appelé display mode. Cela correspond au mode show et on ne peut que afficher les paramètres actuels. Il faut exécuter la commande «system-view» pour basculer en mode configuration. Le prompt passe alors du signe \> au signe \#.

hpswitch>system-view
hpswitch#

La sauvegarde de la configuration s’effectuer à l’aide de la commande «save».

hpswitch# save force

Le paramètre «force» évite d’avoir à confirmer l’action et spécifier un nom de fichier.

Configuring remote out of band management

Cette partie est composée de 5 tâches :

  1. Configurer l’IP de l’interface de management,
  2. Définir la passerelle par défaut,
  3. Créer un utilisateur local de niveau administrateur,
  4. Activer un protocole de gestion à distance (ssh de préférence),
  5. Configurer les lignes de connexion vty (Virtual Teletype).

Configuration de l’IP sur l’interface de management

Après avoir basculé en mode system-view, il faut sélectionner l’interface de management puis définir adresse IP et masque de sous-réseau.

interface M-GigabitEthernet0/0/0
ip address 172.30.1.77 24

Ajout de la route par défaut pour l’interface de management

ip route-static 0.0.0.0 0 M-GigabitEthernet 0/0/0 172.30.1.250 permanent

création d’un utilisateur local, affectation du rôle « network-admin » (full feature) & autorisation d’accès via SSH

local-user admin
password simple service-type ssh
authorization-attribute user-role network-admin

Configuration SSH

Tout d’abord, on active le service SSH :

ssh server enable

Puis on génère les clés cryptographiques :

Public-key local create rss

Configuration des 15 premiers vty & autorisation SSH

line vty 0 15
authentication-mode scheme
protocol inbound ssh

Quelques commandes utiles

Configurer un uplink en mode trunk et véhiculer tous les VLANs

Interface GigabitEthernet 1/0/48
port link-type trunk
port trunk permit vlan all

Créer une SVI pour un vlan

interface Vlan-interface
ip address 10.0.0.252 24

Split des interfaces 40GbE en 10GbE

Les interfaces 40GbE peuvent être divisées en 4 interfaces 10GbE. Cela nécessite un redémarrage du switch ainsi qu’un câble pieuvre (break-out cable).

Sélectionner une interface 40GbE et exécuter la commande suivante :

using tengige

Au reboot, les interfaces 10GbE sont présentes. Les 4 interfaces 10GbE sont numérotées à la manière d’une sous-interface (XX:X).

[HPE-5700]display interface brief
…
XGE1/0/53:1 UP 10G(a) F(a) A 1
XGE1/0/53:2 UP 10G(a) F(a) A 1
XGE1/0/53:3 UP 10G(a) F(a) A 1
XGE1/0/53:4 UP 10G(a) F(a) A 1
XGE1/0/54:1 UP 10G(a) F(a) A 1
XGE1/0/54:2 UP 10G(a) F(a) A 1
XGE1/0/54:3 UP 10G(a) F(a) A 1
XGE1/0/54:4 UP 10G(a) F(a) A 1

Configurer un port trunk avec un native vlan

La configuration d’un vlan natif sur un port trunk nécessite de placer le port en mode hybrid (requiert d’abord le mode access).

[HPE-5700-Ten-GigabitEthernet1/0/53:1]port link-type hybrid
Please set the link type of the port to access first.
[HPE-5700-Ten-GigabitEthernet1/0/53:1]port link-type access
[HPE-5700-Ten-GigabitEthernet1/0/53:1]port link-type hybrid

Configuration du native vlan

[HPE-5700-Ten-GigabitEthernet1/0/53:1]port hybrid vlan 500 untagged

Configuration du trunked vlan

[HPE-5700-Ten-GigabitEthernet1/0/53:1]port hybrid vlan 502 tagged

Résumé des commandes nécessaires pour la configuration d’un port Trunk avec un vlan natif

port link-type access
port link-type hybrid
port hybrid vlan 500 untagged
port hybrid vlan 502 tagged
  1. IRF : Intelligent Resilient Framework, la technologie mLAG d’HPE (comparable au vPC Cisco). ↩
Tagués avec : , , , ,

Configurer une interface en GbE sur Nexus 50xx/55xx/56xx

Posted on by kral2 Publié dans CLI — Aucun commentaire ↓

Les switchs Nexus constituent la gamme Datacenter chez Cisco. Ils sont optimisés pour les connexions 10GbE et supérieur, et présentent un bien meilleur prix au port 10GbE par rapport à la gamme Catalyst. Il est cependant parfois nécessaire d’avoir une connexion Gigabit Ethernet, entre autre pour se connecter à l’architecture existant.

Pour cela les modules GLC-T sont nécessaires.
Note : prolabs manufacture des Gbic compatibles, avec un prix intéressant.

L’erreur typique rencontrée est « SFP Validation Failed », malgré un SFP compatible. Afin d’avoir un port fonctionnel, il faut configurer le port avant d’insérer le SFP.

  1. Définir la vitesse du port avant insertion du SFP
conf
int e1/1
speed 1000
  1. Insérer le SFP dans un port compatible 1/10GbE :
  • Sur les Nexus 5010 : ports 1 à 8,
  • Sur les Nexus 5020 : ports 1 à 16,
  • Sur les Nexus 5500/5600 : ports 1 à 32.

Note : sur les 5500/5600, un port configuré en speed auto basculera automatiquement la configuration entre 1GbE et 10GbE.

Références

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/BasicEthernet.html
A Cisco Nexus 5000 Series switch has a number of fixed 10-Gigabit ports, each equipped with SFP+ interface adapters. The Nexus 5010 switch has 20 fixed ports, the first eight of which are switchable 1-Gigabit/10-Gigabit ports. The Nexus 5020 switch has 40 fixed ports, the first 16 of which are switchable 1-Gigabit/10-Gigabit ports.

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/interfaces/7x/b_5500_Interfaces_Config_Guide_Release_7x/b_5500_Interfaces_Config_Guide_Release_7x_chapter_01.html
The 5596T switch has 48 base board ports and 3 GEM slots. The first 32 ports are 10GBase-T ports the last 16 ports are SFP+ ports. The 10GBase-T ports support a speed of 1-Gigabit, 10-Gigabit, or Auto. The Auto setting automatically negotiates with the link parser to select either 1-Gigabit or 10-Gigabit speed.

http://serverfault.com/questions/339957/how-do-i-get-past-sfp-validation-failed-on-a-sfp-ge-t-transceiver-on-a-nexus-5
https://supportforums.cisco.com/discussion/11510966/nexus-5020-and-glc-t

Tagués avec : , , , ,

Crash Test – Que se passe-t-il lorsque vous perdez L1&L2 sur un cluster UCSM?

Posted on by kral2 Publié dans Design, Infrastructure — Aucun commentaire ↓

Nexus-L1L2L1 & L2, c’est quoi?

Les liens L1 et L2 sont des ports physiques dédiés (GbE) sur les platefome UCS Fabric Interconnect, véhiculant le traffic de heartbeat de l’application en cluster UCSM. Autant dire qu’ils sont cruciaux à la survie du cluster!

L’image du post est bien un Nexus, et ce n’est pas une erreur :-). Pour la petite histoire, les Fabric Interconnect (ou FI), sont basés sur une plateforme matérielle Nexus, adaptée pour la situation :

  • Les FI Gen 1 (6100XP) sont basés sur les plateformes matérielles Nexus 5000,
  • Les FI Gen 2 (6200UP) sont basés sur les plateformes matérielles Nexus 5500.

Si vous vous demandiez « à quoi servent les ports L1 & L2 sur mon joli Nexus tout neuf? », vous avez votre réponse : ils ne servent à rien (sur un Nexus). Ils sont présents depuis le début sur les Nexus, car la vision moyen terme prévoyait déjà une déclinaison du boîtier pour servir de base matérielle aux futur Fabric Interconnects.

Il faut y voir une simple rationalisation des chaînes de production : il est plus rentable de laisser ces 4 ports GbE sur l’ensemble des boites plutôt que de gérer l’exception.

Et oui, la société à la genèse de la gamme Nexus (Nuova Systems, qui a été racheté par Cisco en 2008) pensait aigle UCS dès le départ. Si l’on se penche un peu sur le parcours des fondateurs de Nuova, le puzzle devient tout de suite plus clair. Ce sont trois anciens cerveaux de chez Cisco, Mario Mazzola, Prem Jaim & Luca Cafiero, que j’aime appeler les trois mousquetaires 🙂 (même si le trio est à majorité italienne), et ils n’en sont pas à leur coup d’essai. Mais ceci est une autre histoire – à destination d’un autre billet pourquoi pas.

Pour revenir aux ports L1 & L2, tout en restant dans l’analogie avec les plateformes Nexus, les liens L1 & L2 pourrait être assimilés aux liens VPC Peer-Links, à quelques détails près. Dit comme ça, je suis certains que ça parle à tout le monde 🙂

Note : les connexions des ports L1 & L2 sur chaque FI se fait de la manière suivante :

  • FI-A L1 <–> FI-B L1,
  • FI-A L2 <–> FI-B L2.

Autre détail (de taille), pas de switch sur le chemin des connexions L1 & L2!!! Ces ports sont configurés en bonding et attendent à l’autre bout de la connexion : un autre Fabric Interconnect. Ne pensez pas à configurer du port-channel côté switch, placer les bons vlans, etc : c’est une configuration explicitement hors support.

Le traffic de heartbeat

UCSM est le logiciel de gestion de la plateforme UCS. Il est embarqué au sein de chaque Fabric Interconnect et fonctionne en mode Actif/Passif. La motivation et la pertinence de ce choix, plutôt que d’opter pour une application à installer ou exécuter au sein d’une VM, pourrait alimenter tout une tribu de troll.

– Ici on aime les trolls mais ils seront nourris une autre fois dans un autre billet (encore!) –

Comme toute application en cluster, un lien de signalisation est nécessaire afin de pouvoir maintenir une bonne connaissance de l’état de santé de chaque membre : cela se fait généralement via un lien de heartbeat redondé, autrement dit un bus de communication.

Nous sommes donc ici en présence d’un cluster à deux membres, et ce n’est pas un détail.

Perte d’un membre et Split-Brain

Le cluster surveille l’état de santé de chaque membre via le lien de heartbeat, et bascule les services sur un membre réputé sein en cas de panne. Sans entrer dans les détails et transformer cet article en un essai sur les clusters (c’est bien prétentieux :-)), un membre est réputé sein si le quorum (voir la définition stricte, et ne pas faire d’amalgame avec du jargon Microsoft) est atteint au sein des membres. Pour un cluster à deux membres, c’est la parole d’un bandit contre un autre … Il faut donc faire recours à un arbitre (appelé suivant les technologies : « Tie-Breaker », « Failover Monitor », etc …), afin d’éviter le phénomène de Split-brain.  Dans un cluster UCSM, c’est la passerelle par défaut qui fait office d’arbitre lorsqu’un membre n’arrive pas à joindre l’autre.

Note : le cluster UCSM effectue un test supplémentaire, visant à vérifier le lien entre le FI et le/les châssis. Il s’appuie pour cela sur la SEEPROM (Serial EEPROM) : espace de stockage en mémoire non-volatile, accessible par chaque FI. L’article suivant chez UCSGuru explique un peu plus en détail les différents tests menés, ainsi que le cas particulier de serveurs C-Series (format rack), qui ne disposent pas de SEEPROM : HA with UCSM Integrated Rack Mounts.

Que se passe-t-il lorsque l’on perd les liens L1&L2 sur un cluster UCSM?

Toute cette introduction pour arriver à la question initiale. Quel est l’effet concret constaté, d’un point de vue opérateur/administrateur?

Lorsque un des deux liens n’est plus disponible, une alerte de type « majeur » est remontée dans UCSM pour chaque FI : « HA Cluster interconnect Link Failure »

  • Erreur visible « immédiatement »,
  • Pas d’impact sur le data path.

Lorsque les deux liens ne sont plus disponibles (L1 & L2), après une période de timeout (En minutes) :

  • Une nouvelle erreur de type « Critique » est levée : « HAClusterInterconnectTotallinkfailure »,
    • Le FI subordinate est déclaré « injoignable »,
    • Toutes la partie B est « shut » (en admettant que c’était la partie passive (subordinate) du cluster UCSM) DATA PATH compris :
      • FEX,
      • Uplinks LAN & SAN.

Attention donc à vos liens L1 & L2, il faut les choyer et assurer la présence d’au-moins un lien sur deux, sinon effets surprise-party garanti!

Je n’ai malheureusement pas connaissance de la durée exacte du timeout avant coupure complète de la partie « passive ». L’ordre de grandeur est en minutes, j’essayerai de reproduire le test à l’occasion, équipé d’un super chronographe mécanique 😀

Toujours pour rester dans l’analogie avec les Nexus et le mécanisme VPC, c’est un comportement similaire qui est observé lorsque l’on perd le sacro-saint VPC Peer-Link : le secondary est sacrifié sur l’autel du split-brain.

Retour à la normale

Lorsqu’au moins un des liens est de nouveau présent :

  • Resync du FI subordinate sur le primary,
  • Réactivation des liens,
  • Rétablissement du cluster UCSM.

Notes et recommandations sur L1&L2

  • Les connexions L1-L1 et L2-L2 doivent être en DIRECT, pas de switchs sur le chemin,
  • En cas de migration/déménagement, on peut être amené à fonctionner avec seulement L1, mais essayez de garder cette période aussi courte que possible et rendez lui au plus vite son copain L2,
  • Média Ethernet : les limitations usuelles s’appliquent, ne dépassez pas les 100m!
Tagués avec : , ,
Top