Адзін і той жа iESI у межах сайта, унікальны паміж сайтамі: злучэнне Junos

Дзве пары шлюзаў абслугоўваюць два цэнтры апрацоўкі даных, і нехта мусіць вырашыць, колькі значэнняў interconnect ESI патрэбна праекту. Адказ — адно на групу шлюзаў, не адно на fabric і не адно на шлюз. Памылка тут стварае fabric, які выглядае сканфігураваным і выбірае няправільны forwarder, або злівае два сайты, якія мусілі застацца асобнымі. Правіла і яго выключэнні варта запісаць побач са спісам шлюзаў.

Два ахопы, два правілы

У межах сайта рэзервовыя interconnect-шлюзы дзейнічаюць як адзін multihomed канцавы пункт, таму яны падзяляюць адзін interconnect ESI. Іх peer-ы павінны бачыць аднаго лагічнага ўдзельніка, а не двух незалежных. У гэтым і ўвесь сэнс агульнага значэння.

Паміж сайтамі кожная група шлюзаў атрымлівае ўласнае значэнне. Два цэнтры даных, якія падзяляюць ідэнтыфікатар, становяцца адной multihomed групай у плоскасці кіравання, а гэта звычайна не тое, што мае на ўвазе схема злучэння праз WAN. Два сайты ў адной групе таксама атрымліваюць у спадчыну рэжымы адмовы адзін аднаго.

У межах сайта: адна ідэнтычнасць для групы

Дайце пары адно і тое ж значэнне на абодвух peer-ах, у адным кантэксце паслугі, і запішыце яго ў інвентары ідэнтыфікатараў сеткі, а не ў чаце. Няўзгодненасць паміж двума ўдзельнікамі — гэта рэжым адмовы, які дае групу з аднаго ўдзельніка і без відавочнай трывогі. Параўнайце абодвух удзельнікаў, перш чым верыць у працоўную сесію.

Падтрымліваная мадэль — all-active. Той жа даведнік выключае single-active працу, аўтаматычна вытворныя LACP-ідэнтыфікатары і опцыі source-bmac для гэтай ідэнтычнасці злучэння, таму праект, які меркаваў адну з гэтых магчымасцей, трэба перагледзець яшчэ да выбару ідэнтыфікатара. Гэтае абмежаванне — уваход праекта, а не зноска.

Паміж сайтамі: розныя значэнні або наўмыснае аб’яднанне

Унікальнае значэнне на сайт трымае дзве групы шлюзаў асобна. Калі намера сапраўды пашырыць адну multihomed групу на некалькі сайтаў, гэта іншая архітэктура з уласнымі наступствамі для затрымкі, адмоваў і перасылкі, і яе трэба вырашаць як архітэктуру, а не як выбар ідэнтыфікатара. Папрасіце гэтае рашэнне пісьмова да акна абслугоўвання.

Запішыце меркаванае адрозненне ў план, каб пазнейшы інжынер, капіюючы працоўны шаблон сайта, не пераняў разам з ім і яго ідэнтыфікатар.

Заява peer — частка ідэнтычнасці

Кожны шлюз у групе пералічвае сваіх лакальных peer-аў па адрасе loopback, і гэта ўзаемаадносіна жыве на глабальным узроўні EVPN, а не ўнутры асобнага MAC-VRF. Змясціць яе ў няправільную іерархію — звычайны спосаб атрымаць канфігурацыю, якая фіксуецца, але ніколі не ўтварае групу. Прачытайце даведачную іерархію аднойчы, потым трымайцеся яе.

Назва заявы таксама змянілася. Juniper перайменаваў заяву interconnect peer-gateways у 24.2R1 і аднавіў спецыфічную для interconnect форму для злучэння цэнтраў даных у 24.4R1. Таму фрагмент, узяты з прамежкавага рэлізу, можа выкарыстоўваць назву, якую разгорнутая версія не прымае, або наадварот. Запішыце рэліз, з якога ўзяты фрагмент, побач з самім фрагментам.

Што супольнае выкарыстанне iESI не робіць

Яно не вызначае за вас route target, VNI або лакальны экземпляр EVPN. Гэта застаецца асобнай канфігурацыяй, якая мусіць супадаць з абодвух бакоў, і ідэнтыфікатар, які супадае, тады як route target не супадае, стварае групу, што ўтвараецца і нічога не нясе. Параўнайце абодва бакі гэтых налад у адным праходзе.

Яно таксама не даказвае дасяжнасць peer-аў або выбары designated forwarder. Праверце unicast і патрэбныя broadcast і multicast паводзіны ў звычайным выпадку, затым паўтарыце, прыбраўшы адзін шлюз, каб удзельнік, што застаўся, нёс групу адзін.

Менавіта другі прагон даказвае, што група рэальная.

Трымайце назіранае членства і кантэкст паслугі разам з вынікамі тэстаў. Тады пазнейшае змяненне ідэнтыфікатара можна разглядаць як змяненне multihoming, чым яно і ёсць, а не як касметычную праўку радка. Вынікі — адзіны доказ таго, што ідэнтыфікатар робіць тое, што сказана на схеме.