Ten sam iESI w obrębie lokacji, unikalny między lokacjami: zszywanie Junos

Dwie pary bram obsługują dwa centra danych i ktoś musi zdecydować, ile wartości interconnect ESI potrzebuje projekt. Odpowiedź to jedna na grupę bram, nie jedna na fabric i nie jedna na bramę. Błąd w tym względzie daje fabric, który wygląda na skonfigurowany i wybiera niewłaściwy forwarder, albo łączy dwie lokacje, które miały pozostać odrębne. Regułę i jej wyjątki warto zapisać obok listy bram.

Dwa zakresy, dwie reguły

W obrębie lokacji nadmiarowe bramy interconnect działają jako jeden punkt końcowy multihomed, więc dzielą jeden interconnect ESI. Ich peery muszą widzieć jednego logicznego członka, a nie dwa niezależne. W tym tkwi cały sens wspólnej wartości.

Między lokacjami każda grupa bram otrzymuje własną wartość. Dwa centra danych, które dzielą identyfikator, stają się jedną grupą multihomed w płaszczyźnie sterowania, co zwykle nie jest tym, co zamierza projekt zszywania przez WAN. Dwie lokacje w jednej grupie dziedziczą też nawzajem swoje tryby awarii.

W obrębie lokacji: jedna tożsamość dla grupy

Nadaj parze tę samą wartość na obu peerach, w tym samym kontekście usługi, i zapisz ją w inwentarzu identyfikatorów sieci, a nie w wątku czatu. Niezgodność między dwoma członkami to tryb awarii, który daje grupę z jednego członka i bez wyraźnego alarmu. Porównaj oba członki, zanim uwierzysz w działającą sesję.

Obsługiwany model to all-active. Ta sama referencja wyklucza pracę single-active, automatycznie wyliczane identyfikatory LACP i opcje source-bmac dla tej tożsamości zszywania, więc projekt, który zakładał którąś z nich, wymaga przeglądu jeszcze przed wyborem identyfikatora. To ograniczenie jest daną wejściową projektu, a nie przypisem.

Między lokacjami: różne wartości albo świadome połączenie

Unikalna wartość na lokację utrzymuje dwie grupy bram osobno. Jeśli zamiarem naprawdę jest rozszerzenie jednej grupy multihomed między lokacjami, to inna architektura z własnymi konsekwencjami dla opóźnień, awarii i przekazywania, i należy o niej zdecydować jako o architekturze, a nie jako o wyborze identyfikatora. Poproś o tę decyzję na piśmie przed oknem serwisowym.

Zapisz zamierzone rozróżnienie w planie, aby późniejszy inżynier kopiujący działający szablon lokacji nie zaimportował razem z nim jego identyfikatora.

Instrukcja peer jest częścią tożsamości

Każda brama w grupie wymienia swoje lokalne peery według adresu loopback, a ta relacja żyje na globalnym poziomie EVPN, a nie wewnątrz pojedynczego MAC-VRF. Umieszczenie jej w niewłaściwej hierarchii to częsty sposób na uzyskanie konfiguracji, która się commituje, ale nigdy nie tworzy grupy. Przeczytaj hierarchię referencyjną raz, a potem się jej trzymaj.

Nazwa instrukcji też się przesunęła. Juniper zmienił nazwę instrukcji interconnect peer-gateways w 24.2R1 i przywrócił formę właściwą dla interconnect w interkonekcie centrów danych w 24.4R1. Fragment wzięty z wydania pośredniego może więc używać nazwy, której wdrożona wersja nie akceptuje, albo odwrotnie. Zapisz wydanie, z którego pochodzi fragment, obok samego fragmentu.

Czego nie robi współdzielenie iESI

Nie definiuje za ciebie route targetów, VNI ani lokalnej instancji EVPN. Pozostają osobną konfiguracją, która musi się zgadzać po obu stronach, a identyfikator, który się zgadza, podczas gdy route target się nie zgadza, tworzy grupę, która się formuje i nic nie przenosi. Porównaj obie strony tych ustawień w tym samym przebiegu.

Nie dowodzi też osiągalności peerów ani wyboru designated forwardera. Przetestuj unicast oraz wymagane zachowanie broadcast i multicast w normalnym przypadku, a potem powtórz z jedną bramą usuniętą, aby pozostały członek niósł grupę sam.

Właśnie drugi przebieg dowodzi, że grupa jest rzeczywista.

Zachowaj zaobserwowane członkostwo i kontekst usługi razem z wynikami testów. Późniejszą zmianę identyfikatora można wtedy przejrzeć jako zmianę multihomingu, którą ona jest, a nie jako kosmetyczną edycję ciągu znaków. Wyniki są jedynym dowodem, że identyfikator robi to, co mówi rysunek.