Dezelfde iESI binnen een site, uniek tussen sites: Junos-stitching
Eén interconnect-ESI verbindt de gateways die een site bedienen; een tweede site heeft zijn eigen nodig. De peer-verklaring die die identiteit draagt, verschoof tussen releases.
Twee gateway-paren bedienen twee datacenters, en iemand moet beslissen hoeveel interconnect-ESI-waarden het ontwerp nodig heeft. Het antwoord is één per gateway-groep, niet één per fabric en niet één per gateway. Dat fout doen levert een fabric op dat geconfigureerd lijkt en de verkeerde forwarder kiest, of het voegt twee sites samen die gescheiden moesten blijven. De regel en zijn uitzonderingen zijn het waard om naast de gateway-lijst op te schrijven.
Twee bereiken, twee regels
Binnen een site treden de redundante interconnect-gateways op als één multihomed eindpunt, dus delen ze één interconnect-ESI. Hun peers moeten één logisch lid zien in plaats van twee onafhankelijke. Dat is het hele punt van de gedeelde waarde.
Tussen sites krijgt elke gateway-groep zijn eigen waarde. Twee datacenters die een identificatie delen worden één multihomed-groep in het controleplan, wat meestal niet is wat een stitching-ontwerp over een WAN bedoelt. Twee sites in één groep erven ook elkaars faalmodi.
Binnen een site: één identiteit voor de groep
Geef het paar dezelfde waarde op beide peers, in dezelfde servicecontext, en leg die vast in de identificatie-inventaris van het netwerk in plaats van in een chatthread. Een mismatch tussen de twee leden is de faalmodus die een groep van één oplevert en geen duidelijk alarm. Vergelijk beide leden voordat u een werkende sessie gelooft.
Het ondersteunde model is all-active. Dezelfde referentie sluit single-active werking, automatisch afgeleide LACP-identificaties en source-bmac-opties voor deze stitching-identiteit uit, dus een ontwerp dat een daarvan aannam, moet worden herzien voordat de identificatie zelfs wordt gekozen. Die beperking is een ontwerpuitgangspunt, geen voetnoot.
Tussen sites: verschillende waarden, of een bewuste samenvoeging
Een unieke waarde per site houdt de twee gateway-groepen gescheiden. Als de bedoeling echt is om één multihomed-groep over sites uit te breiden, is dat een andere architectuur met eigen gevolgen voor latentie, falen en doorsturen, en daarover moet als architectuur worden besloten, niet als identificatiekeuze. Vraag die beslissing schriftelijk aan vóór het onderhoudsvenster.
Schrijf het bedoelde onderscheid in het plan, zodat een latere ingenieur die een werkende site-template kopieert niet ook de identificatie meeneemt.
De peer-verklaring is deel van de identiteit
Elke gateway in de groep somt zijn lokale peers op per loopback-adres, en die relatie leeft op globaal EVPN-niveau in plaats van binnen een individuele MAC-VRF. Het in de verkeerde hiërarchie plaatsen is een veelvoorkomende manier om een configuratie te maken die commit maar nooit de groep vormt. Lees de referentiehiërarchie één keer en houd u er daarna aan.
De naam van de verklaring verschoof ook. Juniper hernoemde de verklaring interconnect peer-gateways in 24.2R1 en herstelde de interconnect-specifieke vorm voor datacenter-interconnect in 24.4R1. Een snippet uit de tussenliggende release kan daarom een naam gebruiken die de uitgerolde versie niet accepteert, of omgekeerd. Noteer de release waaruit de snippet komt naast de snippet zelf.
Wat het delen van een iESI niet doet
Het definieert niet voor u de route targets, VNI's of de lokale EVPN-instantie. Die blijven aparte configuratie die aan beide kanten moet overeenkomen, en een identificatie die overeenkomt terwijl een route target dat niet doet, levert een groep op die zich vormt en niets draagt. Vergelijk beide kanten van die instellingen in dezelfde pass.
Het bewijst ook geen peer-bereikbaarheid of verkiezing van de designated forwarder. Test unicast en het vereiste broadcast- en multicast-gedrag in het normale geval, en herhaal dan met één gateway verwijderd zodat het overgebleven lid de groep alleen draagt.
Die tweede run is degene die bewijst dat de groep echt is.
Bewaar het waargenomen lidmaatschap en de servicecontext bij de testresultaten. Een latere wijziging van de identificatie kan dan worden beoordeeld als een multihoming-wijziging, wat het is, en niet als een cosmetische bewerking van een string. De resultaten zijn het enige bewijs dat de identificatie doet wat de tekening zegt.