Dieselfde iESI binne ’n werf, uniek oor werwe: Junos-stikwerk
Een interconnect-ESI bind die gateways wat ’n werf bedien; ’n tweede werf het sy eie nodig. Die peer-stelling wat daardie identiteit dra, het tussen vrystellings verskuif.
Twee gateway-pare bedien twee datacentrums, en iemand moet besluit hoeveel interconnect-ESI-waardes die ontwerp nodig het. Die antwoord is een per gateway-groep, nie een per fabric en nie een per gateway nie. As dit verkeerd gedoen word, lewer dit ’n fabric wat geconfigureer lyk en die verkeerde forwarder kies, of dit voeg twee werwe saam wat bedoel was om apart te bly. Die reël en sy uitsonderings is die moeite werd om langs die gateway-lys neer te skryf.
Twee bestekke, twee reëls
Binne ’n werf tree die oortollige interconnect-gateways as een multihomed eindpunt op, so hulle deel ’n enkele interconnect-ESI. Hul peers moet een logiese lid sien eerder as twee onafhanklike lede. Dit is die hele punt van die gedeelde waarde.
Tussen werwe kry elke gateway-groep sy eie waarde. Twee datacentrums wat ’n identifikasie deel, word een multihomed groep in die beheervlak, wat nie is wat ’n stikontwerp oor ’n WAN gewoonlik bedoel nie. Twee werwe in een groep erf ook mekaar se foutmodusse.
Binne ’n werf: een identiteit vir die groep
Gee die paar dieselfde waarde op albei peers, in dieselfde dienskonteks, en teken dit in die netwerk se identifikasie-inventaris aan eerder as in ’n chat-draad. ’n Wanverhouding tussen die twee lede is die foutmodus wat ’n groep van een lewer en geen duidelike alarm nie. Vergelyk albei lede voordat jy ’n werkende sessie glo.
Die ondersteunde model is all-active. Dieselfde verwysing sluit single-active werking, outomaties afgeleide LACP-identifikasies en source-bmac-opsies vir hierdie stikidentiteit uit, so ’n ontwerp wat een van daardie aanvaar het, moet hersien word voordat die identifikasie selfs gekies word. Daardie beperking is ’n ontwerpinset, nie ’n voetnoot nie.
Oor werwe: verskillende waardes, of ’n doelbewuste samesmelting
’n Unieke waarde per werf hou die twee gateway-groepe apart. As die bedoeling werklik is om een multihomed groep oor werwe uit te brei, is dit ’n ander argitektuur met sy eie latensie-, fout- en aanstuurgevolge, en dit moet as ’n argitektuur besluit word eerder as as ’n identifikasiekeuse. Vra voor die onderhoudsvenster skriftelik om daardie besluit.
Skryf die beoogde onderskeid in die plan, sodat ’n latere ingenieur wat ’n werkende werf-sjabloon kopieer, nie sy identifikasie saam daarmee invoer nie.
Die peer-stelling is deel van die identiteit
Elke gateway in die groep lys sy plaaslike peers volgens loopback-adres, en daardie verhouding leef op die globale EVPN-vlak eerder as binne ’n individuele MAC-VRF. Om dit in die verkeerde hiërargie te plaas, is ’n algemene manier om ’n konfigurasie te lewer wat commit maar nooit die groep vorm nie. Lees die verwysingshiërargie een keer, en hou dan daarby.
Die stelling se naam het ook verskuif. Juniper het die interconnect peer-gateways-stelling in 24.2R1 hernoem en die interconnect-spesifieke vorm vir datacentrum-interconnect in 24.4R1 herstel. ’n Fragment uit die tussenliggende vrystelling kan dus ’n naam gebruik wat die ontplooide weergawe nie aanvaar nie, of omgekeerd. Teken die vrystelling waaruit die fragment kom, langs die fragment self aan.
Wat die deel van ’n iESI nie doen nie
Dit definieer nie route targets, VNI's of die plaaslike EVPN-instansie vir jou nie. Daardie bly aparte konfigurasie wat aan beide kante moet ooreenstem, en ’n identifikasie wat ooreenstem terwyl ’n route target dit nie doen nie, lewer ’n groep wat vorm en niks dra nie. Vergelyk beide kante van daardie instellings in dieselfde pas.
Dit bewys ook nie peer-bereikbaarheid of designated-forwarder-verkiesing nie. Toets unicast en die vereiste broadcast- en multicast-gedrag in die normale geval, en herhaal dan met een gateway verwyder sodat die oorblywende lid die groep alleen dra.
Daardie tweede loop is die een wat bewys die groep is werklik.
Hou die waargeneemde lidmaatskap en dienskonteks by die toetsresultate. ’n Latere identifikasieverandering kan dan as ’n multihoming-verandering hersien word, wat dit is, eerder as as ’n kosmetiese wysiging van ’n string. Die resultate is die enigste bewys dat die identifikasie doen wat die tekening sê.