Исти iESI унутар локације, јединствен између локација: Junos ушивање

Два пара мрежних пролаза опслужују два дата центра, и неко мора да одлучи колико interconnect ESI вредности је потребно пројекту. Одговор је једна по групи пролаза, не једна по fabric и не једна по пролазу. Погрешно поступање ствара fabric који изгледа конфигурисано и бира погрешан forwarder, или спаја две локације које је требало да остану одвојене. Правило и његови изузеци вреди записати поред списка пролаза.

Два опсега, два правила

Унутар локације, резервни interconnect пролази делују као једна multihomed крајња тачка, па деле један interconnect ESI. Њихови peer-ови морају да виде једног логичког члана, а не два независна. У томе је цео смисао заједничке вредности.

Између локација, свака група пролаза добија сопствену вредност. Два дата центра која деле идентификатор постају једна multihomed група у контролној равни, што обично није оно што пројекат ушивања преко WAN-а намерава. Две локације у једној групи такође наслеђују међусобне режиме отказа.

Унутар локације: један идентитет за групу

Дајте пару исту вредност на оба peer-а, у истом контексту услуге, и запишите је у инвентар идентификатора мреже, а не у разговор. Неподударање између два члана је режим отказа који даје групу од једног и без очигледног аларма. Упоредите оба члана пре него што поверујете радној сесији.

Подржани модел је all-active. Иста референца искључује single-active рад, аутоматски изведене LACP идентификаторе и source-bmac опције за овај идентитет ушивања, па пројекат који је претпоставио нешто од тога треба поново размотрити пре него што идентификатор уопште буде изабран. То ограничење је улаз за пројекат, а не фуснота.

Између локација: различите вредности или намерно спајање

Јединствена вредност по локацији држи две групе пролаза одвојеним. Ако је намера заиста да се једна multihomed група прошири између локација, то је друга архитектура са сопственим последицама по латенцију, отказе и прослеђивање, и о томе треба одлучити као о архитектури, а не као о избору идентификатора. Затражите ту одлуку писмено пре прозора за одржавање.

Запишите предвиђену разлику у план, да каснији инжењер који копира радни шаблон локације не увезе и његов идентификатор.

peer наредба је део идентитета

Сваки пролаз у групи наводи своје локалне peer-ове по loopback адреси, и та веза живи на глобалном нивоу EVPN, а не унутар појединачног MAC-VRF. Постављање у погрешну хијерархију је чест начин да се добије конфигурација која се commit-ује, али никада не формира групу. Прочитајте референтну хијерархију једном и потом је се држите.

И име наредбе се преместило. Juniper је преименовао наредбу interconnect peer-gateways у 24.2R1 и вратио interconnect-специфичан облик за interconnect дата центара у 24.4R1. Зато исечак узет из међуиздања може да користи име које распоређена верзија не прихвата, или обрнуто. Запишите издање из којег исечак потиче поред самог исечка.

Шта дељење iESI не чини

Оно не дефинише уместо вас route target, VNI или локалну EVPN инстанцу. Они остају одвојена конфигурација која мора да се сложи са обе стране, и идентификатор који се поклапа док се route target не поклапа ствара групу која се формира и ништа не носи. Упоредите обе стране тих поставки у истом пролазу.

Такође не доказује доступност peer-ова ни избор designated forwarder-а. Тестирајте unicast и потребно broadcast и multicast понашање у нормалном случају, затим поновите са уклоњеним једним пролазом да преостали члан носи групу сам.

Управо друго извршавање доказује да је група стварна.

Чувајте запажено чланство и контекст услуге уз резултате тестова. Каснија промена идентификатора тада може да се размотри као промена multihoming-а, што она и јесте, а не као козметичка исправка низа. Резултати су једини доказ да идентификатор ради оно што цртеж каже.