Същият iESI в рамките на сайта, уникален между сайтовете: свързване Junos
Един interconnect ESI свързва шлюзовете, обслужващи сайт; вторият сайт се нуждае от свой. Изявлението peer, носещо тази идентичност, се премести между версиите.
Две двойки шлюзове обслужват два центъра за данни и някой трябва да реши колко стойности 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 форма за свързване на центрове за данни в 24.4R1. Затова откъс, взет от междинната версия, може да използва име, което разгърнатата версия не приема, или обратното. Запишете версията, от която идва откъсът, до самия откъс.
Какво не прави споделянето на iESI
То не дефинира вместо вас route target, VNI или локалния EVPN екземпляр. Те остават отделна конфигурация, която трябва да съвпада от двете страни, и идентификатор, който съвпада, докато route target не съвпада, създава група, която се образува и не носи нищо. Сравнете двете страни на тези настройки в един и същ проход.
То също не доказва достижимост на peer-ите или избор на designated forwarder. Тествайте unicast и нужното broadcast и multicast поведение при нормалния случай, после повторете с премахнат един шлюз, за да носи останалият член групата сам.
Именно второто пускане доказва, че групата е реална.
Пазете наблюдаваното членство и контекста на услугата с резултатите от тестовете. Тогава по-късна промяна на идентификатора може да се преглежда като промяна на multihoming, каквато е, а не като козметична редакция на низ. Резултатите са единственото доказателство, че идентификаторът прави това, което казва схемата.