Sama iESI sivuston sisällä, ainutkertainen sivustojen välillä: Junos-ompelu

Kaksi yhdyskäytäväparia palvelee kahta datakeskusta, ja jonkun on päätettävä, kuinka monta interconnect ESI -arvoa suunnittelu tarvitsee. Vastaus on yksi yhdyskäytäväryhmää kohden, ei yksi fabricia kohden eikä yksi yhdyskäytävää kohden. Väärin tekeminen tuottaa fabricin, joka näyttää määritetyltä ja valitsee väärän forwarderin, tai yhdistää kaksi sivustoa, joiden piti pysyä erillään. Sääntö ja sen poikkeukset kannattaa kirjata yhdyskäytäväluettelon viereen.

Kaksi laajuutta, kaksi sääntöä

Sivuston sisällä redundantit interconnect-yhdyskäytävät toimivat yhtenä multihomed-päätepisteenä, joten ne jakavat yhden interconnect ESI:n. Niiden peerien on nähtävä yksi looginen jäsen kahden itsenäisen sijaan. Siinä on jaetun arvon koko pointti.

Sivustojen välillä jokainen yhdyskäytäväryhmä saa oman arvonsa. Kaksi datakeskusta, jotka jakavat tunnisteen, muuttuvat ohjaustasossa yhdeksi multihomed-ryhmäksi, mikä ei yleensä ole se, mitä WANin yli ompelava suunnittelu tarkoittaa. Kaksi sivustoa samassa ryhmässä perii myös toistensa vikatilat.

Sivuston sisällä: yksi identiteetti ryhmälle

Anna parille sama arvo molemmilla peereillä samassa palvelukontekstissa ja kirjaa se verkon tunnisteluetteloon, ei chat-ketjuun. Kahden jäsenen välinen epäjohdonmukaisuus on vikatila, joka tuottaa yhden jäsenen ryhmän ja ilman selvää hälytystä. Vertaa molempia jäseniä ennen kuin uskot toimivaan istuntoon.

Tuettu malli on all-active. Sama viite sulkee pois single-active-toiminnan, automaattisesti johdetut LACP-tunnisteet ja source-bmac-vaihtoehdot tälle ompeluidentiteetille, joten suunnittelu, joka oletti jonkin niistä, on tarkistettava ennen kuin tunniste edes valitaan. Tämä rajoitus on suunnittelun syöte, ei alaviite.

Sivustojen välillä: eri arvot tai tarkoituksellinen yhdistäminen

Ainutkertainen arvo sivustoa kohden pitää kaksi yhdyskäytäväryhmää erillään. Jos aikomus on todella laajentaa yhtä multihomed-ryhmää sivustojen välillä, se on eri arkkitehtuuri, jolla on omat seurauksensa viiveelle, vioille ja edelleenlähetykselle, ja siitä pitäisi päättää arkkitehtuurina eikä tunnisteen valintana. Pyydä se päätös kirjallisesti ennen huoltokatkoa.

Kirjoita aiottu ero suunnitelmaan, jotta myöhempi insinööri, joka kopioi toimivan sivustomallin, ei tuo sen tunnistetta mukanaan.

Peer-lause on osa identiteettiä

Jokainen ryhmän yhdyskäytävä luettelee paikalliset peerinsä loopback-osoitteen mukaan, ja tämä suhde elää globaalilla EVPN-tasolla eikä yksittäisen MAC-VRF:n sisällä. Sen sijoittaminen väärään hierarkiaan on tavallinen tapa tuottaa määritys, joka commitoidaan mutta ei koskaan muodosta ryhmää. Lue viitehierarkia kerran ja pidä siitä sitten kiinni.

Myös lauseen nimi siirtyi. Juniper nimesi interconnect peer-gateways -lauseen uudelleen versiossa 24.2R1 ja palautti interconnect-kohtaisen muodon datakeskusten interconnectille versiossa 24.4R1. Väli julkaisusta otettu katkelma voi siksi käyttää nimeä, jota käyttöön otettu versio ei hyväksy, tai päinvastoin. Kirjaa julkaisu, josta katkelma on peräisin, katkelman viereen.

Mitä iESIn jakaminen ei tee

Se ei määritä puolestasi route targeteja, VNI:itä tai paikallista EVPN-instanssia. Ne pysyvät erillisenä määrityksenä, jonka on oltava yhtäpitävä molemmilla puolilla, ja tunniste, joka täsmää, kun taas route target ei täsmää, tuottaa ryhmän, joka muodostuu eikä kanna mitään. Vertaa näiden asetusten molempia puolia samassa kierroksessa.

Se ei myöskään todista peerien tavoitettavuutta tai designated forwarderin valintaa. Testaa unicast sekä vaadittu broadcast- ja multicast-käyttäytyminen normaalitapauksessa ja toista sitten yksi yhdyskäytävä poistettuna, jotta jäljelle jäävä jäsen kantaa ryhmän yksin.

Juuri toinen ajo todistaa, että ryhmä on todellinen.

Säilytä havaittu jäsenyys ja palvelukonteksti testitulosten kanssa. Myöhempi tunnisteen muutos voidaan silloin tarkastella multihoming-muutoksena, jota se on, eikä merkkijonon kosmeettisena muokkauksena. Tulokset ovat ainoa todiste siitä, että tunniste tekee sen, mitä piirros sanoo.