Ugyanaz az iESI egy helyen belül, egyedi a helyek között: Junos-összevarrás
Egy interconnect ESI köti össze a helyet kiszolgáló átjárókat; a második helynek a sajátjára van szüksége. Az ezt az identitást hordozó peer utasítás kiadások között elmozdult.
Két átjárópár szolgál ki két adatközpontot, és valakinek el kell döntenie, hány interconnect ESI értékre van szüksége a tervezésnek. A válasz átjárócsoportonként egy, nem fabriconként egy és nem átjárónként egy. Ha ezt elrontják, olyan fabric jön létre, amely konfiguráltnak látszik és rossz forwardert választ, vagy két helyet von össze, amelyeknek külön kellett volna maradniuk. A szabályt és kivételeit érdemes az átjárók listája mellé leírni.
Két hatókör, két szabály
Egy helyen belül a redundáns interconnect átjárók egyetlen multihomed végpontként működnek, ezért egyetlen interconnect ESI-t osztanak meg. A peerjeiknek egy logikai tagot kell látniuk, nem kettő függetlent. Ez a megosztott érték egész lényege.
Helyek között minden átjárócsoport a saját értékét kapja. Két adatközpont, amely ugyanazt az azonosítót osztja, egy multihomed csoporttá válik a vezérlősíkon, ami általában nem az, amit egy WAN-on átnyúló összevarrás-tervezés szándékol. Az egy csoportban lévő két hely egymás hibaállapotait is örökli.
Egy helyen belül: egy identitás a csoportnak
Adja a párnak ugyanazt az értéket mindkét peeren, ugyanabban a szolgáltatáskörnyezetben, és rögzítse a hálózat azonosítóleltárában, ne egy csevegésszálban. A két tag közötti eltérés az a hibaállapot, amely egy tagból álló csoportot és semmilyen nyilvánvaló riasztást eredményez. Hasonlítsa össze mindkét tagot, mielőtt hisz egy működő munkamenetnek.
A támogatott modell az all-active. Ugyanaz a referencia kizárja a single-active működést, az automatikusan származtatott LACP-azonosítókat és a source-bmac beállításokat ehhez az összevarrás-identitáshoz, ezért az ilyet feltételező tervezést még az azonosító kiválasztása előtt felül kell vizsgálni. Ez a korlát tervezési bemenet, nem lábjegyzet.
Helyek között: eltérő értékek vagy szándékos összevonás
A helyenként egyedi érték külön tartja a két átjárócsoportot. Ha a szándék valóban egy multihomed csoport kiterjesztése helyek között, az más architektúra, saját késleltetési, hiba- és továbbítási következményekkel, és arról architektúraként kell dönteni, nem azonosítóválasztásként. Kérje ezt a döntést írásban a karbantartási ablak előtt.
Írja bele a szándékolt különbséget a tervbe, hogy egy későbbi mérnök, aki egy működő hely sablonját másolja, ne importálja vele az azonosítóját is.
A peer utasítás az identitás része
A csoport minden átjárója loopback-cím szerint listázza a helyi peerjeit, és ez a kapcsolat a globális EVPN szinten él, nem egyetlen MAC-VRF-en belül. Rossz hierarchiába tenni gyakori módja annak, hogy olyan konfiguráció szülessen, amely commitol, de soha nem alkotja meg a csoportot. Olvassa el egyszer a referencia-hierarchiát, aztán tartsa magát hozzá.
Az utasítás neve is elmozdult. A Juniper átnevezte az interconnect peer-gateways utasítást a 24.2R1-ben, és visszaállította az interconnect-specifikus formát az adatközponti interconnect számára a 24.4R1-ben. Egy köztes kiadásból vett részlet ezért olyan nevet használhat, amelyet a telepített verzió nem fogad el, vagy fordítva. Jegyezze fel a kiadást, amelyből a részlet származik, maga a részlet mellé.
Mit nem tesz meg az iESI megosztása
Nem definiálja Ön helyett a route targeteket, a VNI-ket vagy a helyi EVPN-példányt. Ezek külön konfigurációként maradnak, amelynek mindkét oldalon egyeznie kell, és az egyező azonosító, miközben egy route target nem egyezik, olyan csoportot hoz létre, amely megalakul és semmit nem szállít. Hasonlítsa össze ezeknek a beállításoknak mindkét oldalát ugyanabban a menetben.
Azt sem bizonyítja, hogy a peerek elérhetők, vagy hogy a designated forwarder megválasztása helyes. Tesztelje az unicastot és a szükséges broadcast- és multicast-viselkedést a normál esetben, majd ismételje meg egy átjáró eltávolításával, hogy a túlélő tag egyedül hordozza a csoportot.
Éppen a második futás bizonyítja, hogy a csoport valódi.
Őrizze meg a megfigyelt tagságot és a szolgáltatáskörnyezetet a teszteredményekkel együtt. Egy későbbi azonosítóváltozás így multihoming-változásként vizsgálható, ami is, és nem egy karakterlánc kozmetikai szerkesztéseként. Az eredmények az egyetlen bizonyíték arra, hogy az azonosító azt teszi, amit a rajz mond.