Parehong iESI sa loob ng isang site, natatangi sa pagitan ng mga site: pagtahi ng Junos

Dalawang pares ng gateway ang naglilingkod sa dalawang data center, at may kailangang magpasya kung ilang halaga ng interconnect ESI ang kailangan ng disenyo. Ang sagot ay isa sa bawat grupo ng gateway, hindi isa sa bawat fabric at hindi isa sa bawat gateway. Ang pagkakamali dito ay gumagawa ng fabric na mukhang na-configure at pumipili ng maling forwarder, o pinagsasama ang dalawang site na dapat sanang manatiling hiwalay. Sulit na isulat ang tuntunin at ang mga pagbubukod nito sa tabi ng listahan ng gateway.

Dalawang saklaw, dalawang tuntunin

Sa loob ng isang site, kumikilos ang mga redundant interconnect gateway bilang isang multihomed endpoint, kaya nagbabahagi sila ng isang interconnect ESI. Dapat makita ng kanilang mga peer ang isang lohikal na miyembro sa halip na dalawang independiyente. Iyon ang buong punto ng ibinahaging halaga.

Sa pagitan ng mga site, nakakakuha ang bawat grupo ng gateway ng sarili nitong halaga. Ang dalawang data center na nagbabahagi ng isang identifier ay nagiging isang multihomed group sa control plane, na kadalasan ay hindi ang intensyon ng isang disenyong pagtahi sa WAN. Ang dalawang site sa isang grupo ay nagmamana rin ng mga failure mode ng isa't isa.

Sa loob ng isang site: isang identidad para sa grupo

Bigyan ang pares ng parehong halaga sa dalawang peer, sa parehong konteksto ng serbisyo, at itala ito sa imbentaryo ng identifier ng network sa halip na sa isang chat thread. Ang hindi pagkakatugma sa pagitan ng dalawang miyembro ay ang failure mode na gumagawa ng grupong may isang miyembro at walang malinaw na alarma. Ihambing ang dalawang miyembro bago maniwala sa isang session na gumagana.

Ang sinusuportahang modelo ay all-active. Ibinubukod ng parehong reference ang single-active na operasyon, ang mga LACP identifier na awtomatikong hinango, at ang mga opsyon ng source-bmac para sa identidad ng pagtahi na ito, kaya ang disenyong nagpalagay ng isa sa mga iyon ay kailangang suriin muli bago pa man piliin ang identifier. Ang hadlang na iyon ay input ng disenyo, hindi isang talababa.

Sa pagitan ng mga site: magkaibang halaga, o sadyang pagsasama

Ang natatanging halaga sa bawat site ay nagpapanatiling hiwalay ang dalawang grupo ng gateway. Kung ang layunin ay tunay na palawakin ang isang multihomed group sa pagitan ng mga site, iyon ay ibang arkitektura na may sariling mga bunga sa latency, failure at forwarding, at dapat itong pasyahan bilang arkitektura, hindi bilang pagpili ng identifier. Hilingin ang pasyang iyon sa sulat bago ang maintenance window.

Isulat ang nilalayong pagkakaiba sa plano, upang ang engineer na mamaya ay kopyahin ang gumaganang site template ay hindi mag-import ng identifier nito kasama.

Ang peer statement ay bahagi ng identidad

Inililista ng bawat gateway sa grupo ang mga lokal na peer nito ayon sa loopback address, at ang relasyong iyon ay nabubuhay sa pandaigdigang antas ng EVPN sa halip na sa loob ng isang indibidwal na MAC-VRF. Ang paglalagay nito sa maling hierarchy ay karaniwang paraan ng paggawa ng configuration na nag-commit ngunit hindi kailanman bumubuo ng grupo. Basahin ang reference hierarchy nang isang beses, pagkatapos ay manatili rito.

Lumipat din ang pangalan ng statement. Pinalitan ng Juniper ang pangalan ng interconnect peer-gateways statement sa 24.2R1 at ibinalik ang form na partikular sa interconnect para sa datacenter interconnect sa 24.4R1. Kaya ang snippet na kinuha mula sa intermediate release ay maaaring gumamit ng pangalang hindi tinatanggap ng deployed na bersyon, o kabaliktaran. Itala ang release na pinagmulan ng snippet sa tabi ng snippet mismo.

Ano ang hindi ginagawa ng pagbabahagi ng iESI

Hindi nito tinutukoy para sa iyo ang route targets, VNIs o ang lokal na EVPN instance. Nananatili ang mga iyon na hiwalay na configuration na dapat magtugma sa dalawang panig, at ang identifier na tumutugma habang ang isang route target ay hindi, ay gumagawa ng grupong nabubuo at walang dinadala. Ihambing ang dalawang panig ng mga setting na iyon sa parehong pass.

Hindi rin nito pinapatunayan ang maabot ng peer o ang pagpili ng designated forwarder. Subukan ang unicast at ang kinakailangang pag-uugali ng broadcast at multicast sa normal na kaso, pagkatapos ulitin na may isang gateway na tinanggal upang ang natitirang miyembro ang magdala ng grupo nang mag-isa.

Ang ikalawang pagtakbo ang nagpapatunay na totoo ang grupo.

Itago ang naobserbahang membership at konteksto ng serbisyo kasama ng mga resulta ng pagsubok. Ang susunod na pagbabago ng identifier ay masusuri noon bilang pagbabago sa multihoming, na siyang tunay, at hindi bilang kosmetikong pag-edit sa isang string. Ang mga resulta ang tanging ebidensya na ginagawa ng identifier ang sinasabi ng guhit.