Sayt daxilində eyni iESI, saytlar arasında unikal: Junos birləşdirməsi

İki şlüz cütü iki data mərkəzinə xidmət edir və kimsə dizaynın neçə interconnect ESI dəyərinə ehtiyacı olduğuna qərar verməlidir. Cavab hər şlüz qrupu üçün birdir, hər fabric üçün bir deyil və hər şlüz üçün bir deyil. Bunu səhv etmək, konfiqurasiya olunmuş görünən və yanlış forwarder seçən bir fabric yaradır, ya da ayrı qalması nəzərdə tutulan iki saytı birləşdirir. Qayda və onun istisnaları şlüz siyahısının yanında yazılmağa dəyər.

İki əhatə, iki qayda

Sayt daxilində ehtiyat interconnect şlüzləri vahid multihomed son nöqtə kimi çıxış edir, buna görə də vahid interconnect ESI paylaşırlar. Onların peer-ləri iki müstəqil üzv deyil, bir məntiqi üzv görməlidir. Paylaşılan dəyərin bütün mənası budur.

Saytlar arasında hər şlüz qrupu öz dəyərini alır. Eyni identifikatoru paylaşan iki data mərkəzi idarəetmə müstəvisində bir multihomed qrupa çevrilir, bu da WAN üzərindən birləşdirmə dizaynının adətən nəzərdə tutduğu şey deyil. Bir qrupdakı iki sayt həm də bir-birinin nasazlıq rejimlərini miras alır.

Sayt daxilində: qrup üçün vahid kimlik

Cütə hər iki peer-də eyni dəyəri, eyni xidmət kontekstində verin və onu söhbət lentində deyil, şəbəkənin identifikator inventarında qeyd edin. İki üzv arasındakı uyğunsuzluq bir nəfərdən ibarət qrup və aşkar siqnal olmayan nasazlıq rejimidir. İşləyən sessiyaya inanmazdan əvvəl hər iki üzvü müqayisə edin.

Dəstəklənən model all-active-dir. Eyni istinad bu birləşdirmə kimliyi üçün single-active işləməsini, avtomatik çıxarılan LACP identifikatorlarını və source-bmac seçimlərini istisna edir, buna görə də bunlardan birini fərz edən dizayn identifikator seçilməzdən əvvəl yenidən nəzərdən keçirilməlidir. Bu məhdudiyyət dizayn girişidir, haşiyə deyil.

Saytlar arasında: fərqli dəyərlər və ya qəsdən birləşmə

Hər sayt üçün unikal dəyər iki şlüz qrupunu ayrı saxlayır. Əgər məqsəd həqiqətən bir multihomed qrupu saytlar arasında genişləndirməkdirsə, bu, öz gecikmə, nasazlıq və yönləndirmə nəticələri olan fərqli arxitekturadır və identifikator seçimi kimi deyil, arxitektura kimi qərarlaşdırılmalıdır. Bu qərarı texniki xidmət pəncərəsindən əvvəl yazılı şəkildə tələb edin.

Nəzərdə tutulan fərqi plana yazın ki, sonradan işləyən sayt şablonunu köçürən mühəndis onun identifikatorunu da özü ilə gətirməsin.

Peer bəyanatı kimliyin bir hissəsidir

Qrupdakı hər şlüz yerli peer-lərini loopback ünvanı ilə sadalayır və bu əlaqə ayrı MAC-VRF daxilində deyil, qlobal EVPN səviyyəsində yaşayır. Onu yanlış iyerarxiyaya yerləşdirmək, commit olunan amma qrupu heç vaxt formalaşdırmayan konfiqurasiya yaratmağın adi yoludur. İstinad iyerarxiyasını bir dəfə oxuyun, sonra ona sadiq qalın.

Bəyanatın adı da dəyişdi. Juniper 24.2R1-də interconnect peer-gateways bəyanatının adını dəyişdi və 24.4R1-də data mərkəzi interconnect üçün interconnect-xüsusi formanı bərpa etdi. Buna görə aralıq buraxılışdan götürülmüş fraqment yerləşdirilmiş versiyanın qəbul etmədiyi addan istifadə edə bilər, ya da əksinə. Fraqmentin hansı buraxılışdan gəldiyini fraqmentin özünün yanında qeyd edin.

iESI paylaşmağın etmədiyi şeylər

O, sizin üçün route target-ləri, VNI-ləri və ya yerli EVPN instansiyasını təyin etmir. Bunlar hər iki tərəfdə uyğun olmalı ayrı konfiqurasiya olaraq qalır və uyğun gələn, lakin route target-ı uyğun gəlməyən identifikator formalaşan və heç nə daşımayan qrup yaradır. Bu parametrlərin hər iki tərəfini eyni keçiddə müqayisə edin.

O, həm də peer əlçatanlığını və ya designated forwarder seçimini sübut etmir. Normal halda unicast və tələb olunan broadcast və multicast davranışını yoxlayın, sonra sağ qalan üzv qrupu tək daşıması üçün bir şlüzü çıxararaq təkrarlayın.

Məhz ikinci icra qrupun həqiqi olduğunu sübut edir.

Müşahidə olunan üzvlüyü və xidmət kontekstini test nəticələri ilə birlikdə saxlayın. Sonrakı identifikator dəyişikliyi sonra sətirdə kosmetik düzəliş kimi deyil, multihoming dəyişikliyi kimi, olduğu kimi nəzərdən keçirilə bilər. Nəticələr identifikatorun rəsmdə deyiləni etdiyinin yeganə sübutudur.