Тивкиот EVPN домаќин никогаш не се решава: следете го ARP до врзувањето

Крајната точка е поврзана, нејзиниот порт е активен, а надзорниот домаќин се уште не може да ја достигне. Некој извршува ping од другата страна и тоа почнува да работи, што прави проблемот да изгледа повремен, а fabric да изгледа невин. Овој образец е потпис на тивок домаќин: тој ретко пренесува, па однесувањето на fabric при откривање и освежување е поважно од состојбата на неговото поврзување. Започнете со една целна IP, MAC и bridge domain и следете ја следната размена на решавање.

Следете ја следната ARP или ND размена

За IPv4, набљудувајте ја ARP размената на домаќинот што бара; за IPv6, следете ги Neighbor Solicitation и Advertisement. Потврдете дека барањето влегува во целниот локален сегмент и целниот VNI, бидејќи барање што никогаш не стигнува до правилниот bridge domain не може да биде одговорено од ниту едно прокси.

Потоа погледнете што знае fabric за целта. Рута само со MAC може да идентификува Layer 2 одредиште, додека проксито се уште нема врзување IP-to-MAC за неа. Тоа се одделни записи, и проверката на едниот не кажува ништо за другиот.

Ако постои валидно врзување, проксито може да одговори согласно својата политика, но MAC-от во тоа врзување се уште бара активна патека за препраќање. Ако врзувањето недостасува, барањето мора да стигне до поврзувањето на крајната точка преку патеката за flooding или репликација пред нешто да може да научи од одговорот.

Два записи што мора да се совпаднат

MAC рутата одговара каде живее Ethernet адресата. Табелата на проксито одговара кој IP се мапира на кој MAC. Домаќин што не зборувал неодамна може да има сосема добра MAC рута и никаков употреблив запис во проксито, и тоа е точно состојбата што создава неуспех при решавање на здраво поврзување.

На оддалеченото поврзување, проверете дали крајната точка навистина ја прима размената и одговара на неа. Нејзиниот одговор го освежува локалното учење и соодветното EVPN огласување, поради што рачниот ping изгледа како да ги поправа работите: вие го создадовте сообраќајот што fabric го чекаше. Тоа објаснува и зошто поправката не трае: штом освежениот запис остари, крајната точка повторно замолчува. Закажаниот ping го лекува симптомот и ја крие празнината во дизајнот.

По одговорот, следете ја избраната рута и инсталираната состојба за препраќање назад кон барателот. Успехот на решавањето и успехот на препраќањето се два одделни настани, а тикетот што ги меша ве праќа на погрешен слој.

Што всушност претпоставува стандардот

RFC 9161 го опишува динамичкото учење на проксито и стандардното flooding на непознати ARP и ND барања. Целосното потиснување на тоа flooding е ограничено на распоредувања чии претпоставки за учење или обезбедување го прават безбедно, што е потесен услов отколку што сугерираат повеќето конфигурациски водичи.

Fabric што очекува новооткриени крајни точки има потреба од работна патека за тие барања. Ако некој го исклучил flooding на непознати барања за да го намали BUM сообраќајот, тивките домаќини се популацијата што плаќа за тоа, а симптомот доаѓа недели подоцна како жалба за повремена достапност.

Читајте го поставувањето за потиснување како изјава за тоа што fabric ветува дека знае. Ако ништо не ги обезбедува врзувањата, ветувањето не е точно за ретките испраќачи. Споредете го конфигурираното потиснување со системот за обезбедување што треба да го храни. Кога тие две не се согласуваат, fabric се однесува точно како што е конфигуриран, и очекувањето е тоа што треба да се поправи.

Освежување, стареење и статичната алтернатива

Стандардот ги опишува поддржаните сонди за освежување пред динамичките записи да остарат. Одговорите го освежуваат соодветниот bridge и состојбата на проксито; отсуството на одговори може законски да доведе до отстранување и повлекување на рутата. Тоа не е дефект што треба да се потисне со растегнување на секој тајмер.

Неограниченото продолжување на тајмерите за стареење разменува видлив неуспех за застарен: fabric продолжува да рекламира локација што домаќинот ја напуштил. Користете ги документираните контроли на имплементацијата и изберете животен век што одговара на тоа колку често разумно може да се очекува крајната точка да зборува.

За познати, управувани крајни точки, статично или од контролерот обезбедено врзување е легитимен втор модел. Му треба сопственик што се занимава со замена и преместување, бидејќи обезбедениот запис не се ажурира сам кога домаќинот преминува на друг порт.

Што да се запише пред следниот тикет

Чувајте го изворот на врзувањето, времето на последното освежување, тековната локација и секој настан на повлекување до MAC рутата. Тој запис одговара на прашањето што тикетот всушност го поставува: дали апликацијата чека откривање, се потпира на застарена состојба или не успева да препрати по успешно решавање?

Потоа одлучете кој од трите сте подготвени да го управувате. Откривање со flooding, освежување со реалистичен животен век или обезбедување со сопственик — сите се одбраниви. Fabric конфигуриран за едно, а од кој се очекува да се однесува како друго, е местото каде што тивките домаќини исчезнуваат.