Același iESI într-un sit, unic între situri: cusătura Junos

Două perechi de gatewayuri deservesc două centre de date, iar cineva trebuie să decidă câte valori interconnect ESI necesită proiectarea. Răspunsul este una pe grup de gatewayuri, nu una pe fabric și nu una pe gateway. Greșeala aici produce un fabric care pare configurat și alege forwarderul greșit, sau unește două situri care trebuiau să rămână separate. Regula și excepțiile ei merită scrise lângă lista de gatewayuri.

Două domenii, două reguli

În interiorul unui sit, gatewayurile interconnect redundante acționează ca un singur punct final multihomed, așa că partajează un singur interconnect ESI. Peerii lor trebuie să vadă un singur membru logic în loc de doi independenți. Acesta este tot rostul valorii comune.

Între situri, fiecare grup de gatewayuri primește propria valoare. Două centre de date care partajează un identificator devin un singur grup multihomed în planul de control, ceea ce de obicei nu este ce intenționează o proiectare de cusătură peste un WAN. Două situri într-un grup moștenesc și modurile de defectare ale celuilalt.

În interiorul unui sit: o identitate pentru grup

Dați perechii aceeași valoare pe ambii peers, în același context de serviciu, și înregistrați-o în inventarul de identificatori al rețelei, nu într-un fir de chat. O nepotrivire între cei doi membri este modul de defectare care produce un grup de un singur membru și nicio alarmă evidentă. Comparați ambii membri înainte de a crede într-o sesiune funcțională.

Modelul acceptat este all-active. Aceeași referință exclude funcționarea single-active, identificatorii LACP derivați automat și opțiunile source-bmac pentru această identitate de cusătură, așa că o proiectare care a presupus una dintre ele trebuie revizuită înainte ca identificatorul să fie ales. Această constrângere este o intrare de proiectare, nu o notă de subsol.

Între situri: valori diferite sau o fuziune deliberată

O valoare unică pe sit ține cele două grupuri de gatewayuri separate. Dacă intenția este cu adevărat să extinzi un grup multihomed între situri, aceasta este o altă arhitectură, cu propriile consecințe asupra latenței, defecțiunilor și direcționării, și trebuie decisă ca arhitectură, nu ca alegere de identificator. Cereți această decizie în scris înainte de fereastra de mentenanță.

Scrieți distincția dorită în plan, astfel încât un inginer ulterior care copiază un șablon de sit funcțional să nu importe și identificatorul acestuia.

Declarația peer face parte din identitate

Fiecare gateway din grup își listează peerii locali după adresa de loopback, iar această relație trăiește la nivel global EVPN, nu în interiorul unui MAC-VRF individual. Plasarea ei în ierarhia greșită este o modalitate obișnuită de a produce o configurație care se commită, dar nu formează niciodată grupul. Citiți ierarhia de referință o dată, apoi țineți-vă de ea.

Și numele declarației s-a mutat. Juniper a redenumit declarația interconnect peer-gateways în 24.2R1 și a restaurat forma specifică interconnect pentru interconnectul centrelor de date în 24.4R1. Așadar, un fragment luat din versiunea intermediară poate folosi un nume pe care versiunea implementată nu îl acceptă, sau invers. Înregistrați versiunea din care provine fragmentul lângă fragmentul însuși.

Ce nu face partajarea unui iESI

Nu definește pentru dumneavoastră route targeturile, VNI-urile sau instanța EVPN locală. Acestea rămân configurație separată care trebuie să coincidă pe ambele părți, iar un identificator care coincide în timp ce un route target nu coincide produce un grup care se formează și nu transportă nimic. Comparați ambele părți ale acestor setări în aceeași trecere.

De asemenea, nu dovedește accesibilitatea peerilor sau alegerea designated forwarderului. Testați unicastul și comportamentul broadcast și multicast necesar în cazul normal, apoi repetați cu un gateway eliminat, astfel încât membrul supraviețuitor să ducă grupul singur.

Tocmai a doua rulare dovedește că grupul este real.

Păstrați apartenența observată și contextul de serviciu împreună cu rezultatele testelor. O modificare ulterioară a identificatorului poate fi apoi revizuită ca schimbare de multihoming, ceea ce este, și nu ca o editare cosmetică a unui șir. Rezultatele sunt singura dovadă că identificatorul face ce spune desenul.