Même iESI dans un site, unique entre sites : couture Junos

Deux paires de passerelles desservent deux centres de données, et quelqu’un doit décider combien de valeurs interconnect ESI le design exige. La réponse est une par groupe de passerelles, pas une par fabric ni une par passerelle. Se tromper produit un fabric qui semble configuré et élit le mauvais forwarder, ou fusionne deux sites censés rester distincts. La règle et ses exceptions méritent d’être écrites à côté de la liste des passerelles.

Deux portées, deux règles

Dans un site, les passerelles interconnect redondantes agissent comme un seul point de terminaison multihomed, elles partagent donc un seul interconnect ESI. Leurs peers doivent voir un seul membre logique plutôt que deux indépendants. C’est tout l’intérêt de la valeur partagée.

Entre sites, chaque groupe de passerelles reçoit sa propre valeur. Deux centres de données qui partagent un identifiant deviennent un seul groupe multihomed dans le plan de contrôle, ce qui n’est généralement pas ce que vise un design de couture sur un WAN. Deux sites d’un même groupe héritent aussi des modes de défaillance l’un de l’autre.

Dans un site : une identité pour le groupe

Donnez au couple la même valeur sur les deux peers, dans le même contexte de service, et consignez-la dans l’inventaire des identifiants du réseau plutôt que dans un fil de discussion. Une divergence entre les deux membres est le mode de défaillance qui produit un groupe d’un seul membre et aucune alarme évidente. Comparez les deux membres avant de croire à une session qui fonctionne.

Le modèle pris en charge est all-active. La même référence exclut l’exploitation single-active, les identifiants LACP dérivés automatiquement et les options source-bmac pour cette identité de couture, si bien qu’un design qui supposait l’une de ces options doit être revu avant même le choix de l’identifiant. Cette contrainte est une donnée de conception, pas une note de bas de page.

Entre sites : des valeurs différentes, ou une fusion délibérée

Une valeur unique par site maintient les deux groupes de passerelles séparés. Si l’intention est réellement d’étendre un groupe multihomed entre sites, c’est une autre architecture, avec ses propres conséquences sur la latence, les pannes et le forwarding, et elle doit être décidée comme une architecture, non comme un choix d’identifiant. Demandez cette décision par écrit avant la fenêtre de maintenance.

Écrivez la distinction voulue dans le plan, afin qu’un ingénieur ultérieur qui copie un modèle de site qui fonctionne n’importe pas son identifiant avec lui.

La déclaration peer fait partie de l’identité

Chaque passerelle du groupe liste ses peers locaux par adresse de loopback, et cette relation vit au niveau global de l’EVPN plutôt qu’à l’intérieur d’un MAC-VRF individuel. La placer dans la mauvaise hiérarchie est un moyen courant de produire une configuration qui se valide mais ne forme jamais le groupe. Lisez la hiérarchie de référence une fois, puis tenez-vous-y.

Le nom de la déclaration a aussi bougé. Juniper a renommé la déclaration interconnect peer-gateways en 24.2R1 et rétabli la forme propre à l’interconnect pour l’interconnexion de centres de données en 24.4R1. Un extrait tiré de la version intermédiaire peut donc utiliser un nom que la version déployée n’accepte pas, ou inversement. Notez la version d’où vient l’extrait à côté de l’extrait lui-même.

Ce que le partage d’un iESI ne fait pas

Il ne définit pas pour vous les route targets, les VNI ni l’instance EVPN locale. Ils restent une configuration séparée qui doit concorder des deux côtés, et un identifiant qui concorde alors qu’un route target ne concorde pas produit un groupe qui se forme et ne transporte rien. Comparez les deux côtés de ces réglages dans la même passe.

Il ne prouve pas non plus l’accessibilité des peers ni l’élection du designated forwarder. Testez l’unicast et le comportement broadcast et multicast requis dans le cas normal, puis répétez avec une passerelle retirée pour que le membre survivant porte le groupe seul.

C’est cette seconde exécution qui prouve que le groupe est réel.

Conservez l’appartenance observée et le contexte de service avec les résultats des tests. Une modification ultérieure de l’identifiant pourra alors être relue comme un changement de multihoming, ce qu’elle est, et non comme une retouche cosmétique d’une chaîne. Les résultats sont la seule preuve que l’identifiant fait ce que dit le schéma.