Niyə QFX MAC ünvanı EVPN-də görünür, lakin yönləndirmə cədvəlində görünmür

EVPN verilənlər bazasında MAC ünvanı tapmaq onun marşrut kimi elan edildiyini və ya qəbul edildiyini sübut edir, bundan başqa heç nəyi yox. Yönləndirmə cədvəli sonradan proqramlaşdırılan fərqli bir strukturdur, ona görə də eyni MAC ünvanı birində görünə, digərində isə olmaya bilər, halbuki hər protokol düzgün işləyir. Bu iki çıxışı bir-birinin surəti kimi qəbul etmək mühəndisləri BGP nasazlığının arxasınca göndərir, halbuki əsl boşluq idxal siyasəti və ya həll olunmamış növbəti hopdur. Verməyə dəyər sual fabricin MAC ünvanını bilməsi deyil, hansı mərhələdə onu ötürmənin dayandığıdır.

Fərqli suallara cavab verən iki cədvəl

Junos EVPN-də verilənlər bazası hər instansiya üzrə MAC ünvanlarını və hər birinin necə gəldiyini sadalayır: giriş portundan öyrənilib, Type 2 marşrutunda qəbul edilib və ya çoxsaylı hostinq qrupunun bir hissəsi kimi işarələnib. Juniper-in show evpn database arayışı baxışı oxunaqlı edən hər MAC və hər instansiya üzrə filtrləri əhatə edir. Bu, instansiya və MAC üzrə açarlanmış idarəetmə müstəvisi xülasəsidir, aparatın kadrları kommutasiya etdiyi cədvəl deyil.

Kommutasiya cədvəli həmin yönləndirmə vəziyyətidir. Hər iki çıxış MAC ünvanlarını VLAN və ya VNI konteksti ilə yanaşı sadalayır; məhz buna görə onlar sətir-sətir müqayisə olunur və məhz buna görə müqayisə yanıldıcıdır. Verilənlər bazasındakı qeyd marşrutun mövcud olduğunu və instansiyaya qəbul edildiyini bildirir; platformanın onu yönləndirmə üçün quraşdırdığı barədə heç nə demir.

Type 2 marşrutu MAC ünvanını, istəyə bağlı IP ünvanını, etiketi və ya VNI-ni, marşrut fərqləndiricisini və uzaq VTEP-i adlandıran növbəti hopu daşıyır. Kabel ilə həmin marşrut arasında dörd şey qırıla bilər: host heç vaxt öyrənilmir, marşrut heç vaxt elan edilmir, idxalda rədd edilir və ya onun növbəti hopu həll olunmur. Hər nasazlıq fərqli cədvəl dəsti dolu saxlayır, buna görə ardıcıllığı ümumiyyətlə diaqnostika etmək mümkündür.

Lokal öyrənmə hələ də birinci gəlir

Ümumi fərziyyə budur ki, EVPN MAC öyrənməsini öz üzərinə götürür, ona görə boş verilənlər bazası overlay problemi demək olmalıdır. Lokal öyrənmə giriş tərəfində hələ də işləyir, VXLAN yaranmazdan əvvəl olduğu kimi: kommutator icazə verilmiş kadrın mənbə MAC ünvanını düzgün VLAN və xidmətdə öyrənir və yalnız bundan sonra onun üçün Type 2 yaradır. Uyğun kadr göndərməmiş hostun elan edəcək heç nəyi yoxdur. Kadrları VLAN üzvlüyü, filtr və ya aqreqatın işləməyən üzvü tərəfindən atılan host overlay baxımından eyni görünür.

Birləşmə nöqtəsindən başlayın və yalnız oxuma üçün olan əmrlərlə irəliləyin. Məqsəd hostdan gələn kadrın nəzərdə tutulan xidmətdə keçdiyini sübut etməkdir, çünki heç vaxt çatmayan kadrı aşağı axında heç nə kompensasiya etmir.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Seçilmiş LACP üzvləri dəstənin işlək olmasından daha vacibdir, çünki aqreqat bir üzvdə işlək ola bilər, halbuki hostun trafiki aşağı və ya bloklanmış keçidə heşlənir. İnterfeys sayğacları səssiz hostu atan hostdan ayırır, çünki heç vaxt ötürməyən host ilə kadrları təsnifatla atılan host eyni boş cədvəli qoyub gedir.

Uzaq MAC ünvanının itirildiyi yer

Uzaq MAC ünvanı əks istiqamətdə və səssizcə sıradan çıxır. Type 2 marşrutu gəlir, lakin o, yalnız marşrut hədəfi və VNI yerli konfiqurasiyaya uyğun olduqda instansiyaya daxil olur və yalnız növbəti hop əlçatan VTEP-ə həll olduqda istifadəyə yararlı olur. Marşrut hədəfinin uyğunsuzluğu BGP cədvəlində heç bir instansiyanın istəmədiyi etibarlı marşrut qoyur.

Üç baxışı sıra ilə oxuyun: marşrutun mövcudluğu, verilənlər bazası qeydi, yönləndirmə qeydi. Aşağıdakı əmrlər hər mərhələdə eyni MAC ünvanını sorğulayır və nümunə ünvan çıxışları müqayisə edilə bilən saxlayır.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Bu çıxışlar üç ayrı suala cavab verir. bgp.evpn.0 daxilində verilənlər bazası qeydi olmayan marşrut idxal siyasətinə, marşrut hədəfinə və ya instansiya konfiqurasiyasına işarə edir. Yönləndirmə qeydi olmayan verilənlər bazası qeydi platformanın proqramlaşdırılmasına işarə edir və bu, başqa eskalasiya yoluna aiddir. Növbəti hopu həll olunmayan aktiv marşrut nəqliyyat və ya etiket problemidir və onu heç bir MAC sazlama düzəltmir.

Onu düzəldən yenidən başlatma çox az şey sübut edir

Yenidən başlatma simptonu yox etdikdə, cazibədar nəticə konfiqurasiyanın sağlam olmalı olduğudur. Yenidən başlatma hər cədvəli sıfırdan proqramlaşdırır, buna görə köhnə qeydin siyasət səhvini kölgələdiyi halı da gizlədir; nasazlıq adətən növbəti dəyişiklikdə, keçid tərpənməsində və ya marşrutun geri çəkilməsində qayıdır.

İstənilən texniki xidmət pəncərəsindən əvvəl yenidən başlatmanın siləcəyini qeydə alın. Bu üç əmr əvvəl və sonranı müqayisə etmək üçün kifayətdir və cihazda heç nəyi dəyişmir.

show evpn database instance blue
show route table bgp.evpn.0
show version

Həmin çıxışları tarix və proqram təminatı buraxılışı ilə birlikdə arxivləşdirin. Sonrakı hesabatda eyni yenidən başlatmanın əvvəllər işlədiyi deyilirsə, bu sübut deyil, ipucudur və fərq yalnız kimsə əvvəlki çıxışı saxladıqda görünür.

Halların çoxunu həll edən dörd müşahidə

Dörd müşahidə demək olar ki, hər halı əhatə edir: birləşmə və onun xidməti, nümunə dəyər kimi MAC, marşrutun və verilənlər bazasının vəziyyəti və istifadədə olan buraxılış. Açıq şəkildə nümunə olan MAC seçin ki, heç kim onu istehsal ünvanı ilə səhv salmasın: birinci oktet 02 yerli idarə olunan unicast ünvanını göstərir, qalan oktetlər sərbəstdir və buna görə 02:00:00:00:00:5c təhlükəsiz yer tutucudur.

Sonra qoy cavablar uğursuz olan mərhələni göstərsin. Birləşmədə öyrənmə yoxdursa, giriş tərəfi; verilənlər bazası qeydi olmayan marşrut idxal; yönləndirmə vəziyyəti olmayan verilənlər bazası qeydi proqramlaşdırma deməkdir. Nə olursa olsun, toplanmış çıxışları host, interfeys, xidmət və buraxılışla birlikdə təhvil verin ki, növbəti mühəndis sorğunu təkrarlamaq əvəzinə yolu təkrar yarada bilsin.