Samma iESI inom en site, unik mellan sites: Junos-sömnad

Två gateway-par betjänar två datacenter, och någon måste avgöra hur många interconnect-ESI-värden designen behöver. Svaret är en per gateway-grupp, inte en per fabric och inte en per gateway. Gör man fel får man ett fabric som ser konfigurerat ut och väljer fel forwarder, eller slår ihop två sites som skulle hållas åtskilda. Regeln och dess undantag är värda att skriva ned bredvid gateway-listan.

Två omfång, två regler

Inom en site fungerar de redundanta interconnect-gatewayerna som en enda multihomed-ändpunkt, så de delar en enda interconnect-ESI. Deras peers måste se en logisk medlem i stället för två oberoende. Det är hela poängen med det delade värdet.

Mellan sites får varje gateway-grupp sitt eget värde. Två datacenter som delar en identifierare blir en multihomed-grupp i kontrollplanet, vilket vanligtvis inte är vad en sömnadsdesign över ett WAN avser. Två sites i en grupp ärver också varandras felmoder.

Inom en site: en identitet för gruppen

Ge paret samma värde på båda peers, i samma tjänstekontext, och registrera det i nätets identifierarinventarium i stället för i en chattråd. Avvikelse mellan de två medlemmarna är den felmod som ger en grupp på en och ingen tydlig larm. Jämför båda medlemmarna innan du tror på en fungerande session.

Den stödda modellen är all-active. Samma referens utesluter single-active drift, automatiskt härledda LACP-identifierare och source-bmac-alternativ för denna sömnadsidentitet, så en design som antog något av dessa måste ses över innan identifieraren ens väljs. Den begränsningen är ett designindata, inte en fotnot.

Mellan sites: olika värden eller en medveten sammanslagning

Ett unikt värde per site håller de två gateway-grupperna åtskilda. Om avsikten verkligen är att utöka en multihomed-grupp mellan sites är det en annan arkitektur med egna konsekvenser för latens, fel och vidarebefordran, och den bör beslutas som en arkitektur och inte som ett identifierarval. Be om det beslutet skriftligt före underhållsfönstret.

Skriv den avsedda skillnaden i planen, så att en senare ingenjör som kopierar en fungerande site-mall inte importerar dess identifierare med.

Peer-uttalandet är en del av identiteten

Varje gateway i gruppen listar sina lokala peers efter loopback-adress, och den relationen lever på global EVPN-nivå i stället för inne i en individuell MAC-VRF. Att placera den i fel hierarki är ett vanligt sätt att skapa en konfiguration som committar men aldrig bildar gruppen. Läs referenshierarkin en gång och håll dig sedan till den.

Även uttalandets namn flyttade. Juniper bytte namn på uttalandet interconnect peer-gateways i 24.2R1 och återställde den interconnect-specifika formen för datacenter-interconnect i 24.4R1. Ett utdrag från mellanutgåvan kan därför använda ett namn som den utrullade versionen inte accepterar, eller tvärtom. Notera utgåvan utdraget kommer från bredvid själva utdraget.

Vad delning av en iESI inte gör

Den definierar inte route targets, VNI:er eller den lokala EVPN-instansen åt dig. De förblir separat konfiguration som måste stämma på båda sidor, och en identifierare som stämmer medan en route target inte gör det ger en grupp som bildas och inte bär något. Jämför båda sidorna av dessa inställningar i samma genomgång.

Den bevisar inte heller peer-nåbarhet eller val av designated forwarder. Testa unicast och det nödvändiga broadcast- och multicast-beteendet i normalfallet och upprepa sedan med en gateway borttagen, så att den överlevande medlemmen bär gruppen själv.

Det är den andra körningen som bevisar att gruppen är verklig.

Bevara det observerade medlemskapet och tjänstekontexten tillsammans med testresultaten. En senare ändring av identifieraren kan då granskas som en multihoming-ändring, vilket den är, och inte som en kosmetisk redigering av en sträng. Resultaten är det enda beviset på att identifieraren gör det som ritningen säger.