Հանգիստ 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 նկարագրում է վստահված սերվերի դինամիկ ուսուցումը և անհայտ ARP և ND հարցումների լռելյայն flooding-ը։ Այդ flooding-ի ամբողջական ճնշումը սահմանափակվում է այն տեղակայումներով, որոնց ուսուցման կամ մատակարարման ենթադրությունները դարձնում են այն անվտանգ, ինչը ավելի նեղ պայման է, քան ենթադրում են կարգավորման ուղեցույցների մեծ մասը։

Նոր հայտնաբերված վերջնակետեր սպասող fabric-ին անհրաժեշտ է աշխատող ուղի այդ հարցումների համար։ Եթե ինչ-որ մեկը անջատել է անհայտ հարցումների flooding-ը BUM երթևեկությունը նվազեցնելու համար, հանգիստ հոսթերն են այն բնակչությունը, որը դրա համար վճարում է, և ախտանիշը գալիս է շաբաթներ անց՝ որպես ընդհատվող հասանելիության բողոք։

Կարդացեք ճնշման կարգավորումը որպես հայտարարություն այն մասին, թե ինչ է խոստանում իմանալ fabric-ը։ Եթե ոչինչ չի մատակարարում կապերը, խոստումը ճիշտ չէ հազվադեպ ուղարկողների համար։ Համեմատեք կարգավորված ճնշումը մատակարարման համակարգի հետ, որը պետք է սնուցի այն։ Երբ այդ երկուսը չեն համընկնում, fabric-ը վարվում է հենց այնպես, ինչպես կարգավորված է, և սպասելիքն է այն, ինչ պետք է ուղղել։

Թարմացում, հնացում և ստատիկ այլընտրանք

Ստանդարտը նկարագրում է աջակցվող թարմացման փորձարկումները մինչև դինամիկ գրառումների հնանալը։ Պատասխանները թարմացնում են համապատասխան bridge և վստահված սերվերի վիճակը։ պատասխանների բացակայությունը կարող է օրինականորեն հանգեցնել հեռացման և երթուղու հետկանչի։ Սա վրիպակ չէ, որը պետք է ճնշվի յուրաքանչյուր ժամաչափ ձգելով։

Հնացման ժամաչափերի անորոշ երկարացումը տեսանելի ձախողումը փոխանակում է հնացածի հետ։ fabric-ը շարունակում է գովազդել մի տեղակայում, որը հոսթը լքել է։ Օգտագործեք իրականացման փաստաթղթավորված կառավարիչները և ընտրեք կյանքի տևողություն, որը համապատասխանում է այն հաճախականությանը, որով ողջամտորեն կարելի է սպասել, որ վերջնակետը կխոսի։

Հայտնի, կառավարվող վերջնակետերի համար ստատիկ կամ վերահսկիչի կողմից մատակարարված կապը օրինական երկրորդ մոդել է։ Դա պահանջում է սեփականատեր, որը զբաղվում է փոխարինմամբ և տեղափոխմամբ, որովհետև մատակարարված գրառումը ինքն իրեն չի թարմացնում, երբ հոսթը տեղափոխվում է այլ պորտ։

Ինչ գրանցել հաջորդ տոմսից առաջ

Պահեք կապի աղբյուրը, վերջին թարմացման ժամանակը, ընթացիկ տեղակայումը և ցանկացած հետկանչի իրադարձություն MAC երթուղու կողքին։ Այդ գրառումը պատասխանում է այն հարցին, որը տոմսը իրականում տալիս է։ արդյոք հավելվածը սպասում է հայտնաբերմանը, հենվում է հնացած վիճակի վրա, թե ձախողվում է փոխանցել հաջող լուծումից հետո։

Այնուհետև որոշեք, թե երեքից որը դուք պատրաստ եք շահագործել։ Flooding-ով հայտնաբերումը, իրատեսական կյանքի տևողությամբ թարմացումը կամ սեփականատիրոջով մատակարարումը բոլորն էլ պաշտպանելի են։ Այն fabric-ը, որը կարգավորված է մեկի համար և սպասվում է, որ կվարվի ինչպես մյուսը, այն տեղն է, որտեղ հանգիստ հոսթերը անհետանում են։