OSPF հարեւանները VPN-ի միջով չե՞ն ձեւավորվում. ստուգեք սրանք հերթով

Թունելը աշխատում է, ինտերֆեյսները նույն ենթացանցում են, եւ OSPF-ը դեռ ոչինչ չի ցուցադրում։ Մեծ մասամբ թունելը կարգին է, եւ OSPF-ի մեկ պահանջ չի բավարարվում։ Կատարեք ստորեւ նշված հինգ ստուգումները հերթով եւ կանգ առեք առաջին ձախողվածի վրա։

Յուրաքանչյուր ստուգում ունի իր ախտանիշը, այդ պատճառով հերթականությունը ցանկից կարեւոր է։

Ստուգում 1. արդյոք կապի մոդելը ճիշտ է

Կետ-կետ ինտերֆեյսը եւ ընդհանուր բազմահասանելի ցանցը տարբեր OSPF միջավայրեր են։ Broadcast-LAN կարգաբերումը թունելի վրա պատճենելը այստեղ ամենատարածված սխալն է։ Սահմանեք ցանցի տեսակը, որն աջակցում է VPN-ի իրականացումը, սովորաբար կետ-կետ՝ երթուղավորված թունելի համար։ Ապա հաստատեք, որ հարթակը համաձայն է, քանի որ որոշ իրականացումներ անտեսում կամ վերագրում են կարգավորումը։

Եթե կապի մոդելը սխալ է, ցանկի մնացած ոչինչ չի օգնի։

Ստուգում 2. արդյոք փաթեթներն անցնում են

OSPFv2-ը IP 89 արձանագրություն է, ոչ TCP կամ UDP պորտ, ուստի պորտերի համար գրված firewall կանոնը լուռ գցում է այն։ Hello-ները նաեւ գնում են multicast հասցեներ, որոնք քաղաքականությունը կարող է չթույլատրել։ Թույլատրեք 89 արձանագրությունը թունելի ծայրերի միջեւ, ապա ստուգեք՝ արդյոք հարթակին պետք են հստակ հարեւանի հայտարարություններ։

Թունելը, որն անցկացնում է միայն ping, քաղաքականության խնդիր է, ոչ երթուղավորման։

Ստուգում 3. արդյոք հարեւանի պարամետրերը համընկնում են

Տարածքի ID-ն, hello- եւ dead- ինտերվալները, նույնականացումը եւ stub դրոշները բոլորը պետք է համընկնեն։ Անհամապատասխանությունը սովորաբար հարեւանին թողնում է տեսանելի վիճակում՝ լուռ ձախողվելու փոխարեն, ինչը օգտակար է։ Համեմատեք աշխատող կարգաբերումը երկու ծայրերում, ոչ թե նախատեսվածը։

MTU-ի անհամապատասխանությունը նուրբն է։ Այն արգելափակում է տվյալների բազայի փոխանակումը ExStart-ում, ուստի հարեւանը երբեք չի հասնում Full-ի։

Ստուգում 4. ինչ է ասում վիճակը

Վիճակը անվանում է ձախողումը։ Init-ը նշանակում է, որ hello-ները գալիս են, բայց այս երթուղիչը դրանցում նշված չէ, ինչը ցույց է տալիս միակողմանի ուղի կամ multicast խնդիր։ Two-Way-ը նորմալ է broadcast սեգմենտում ոչ DR հարեւանի հետ եւ աննորմալ կետ-կետ կապում։ ExStart-ի կամ Exchange-ի կախվածությունը նշանակում է MTU կամ տվյալների բազայի նկարագրության խնդիր։ Loading-ը նշանակում է, որ կապի վիճակի հարցումներին չեն պատասխանում։

Կարդացեք վիճակը նախքան որեւէ բան փոխելը, որովհետեւ այն բացառում է ցանկի մեծ մասը։

show ip ospf neighbor տպում է վիճակը, հարեւանի հասցեն եւ dead ժամաչափը։ Համեմատեք այդ ժամաչափը երկու կողմերի hello ինտերվալի հետ։ hello-ից չորս անգամ մեծ dead ինտերվալը նորմալ է, մնացած ամեն ինչ անհամապատասխանություն է։ Վիճակի սյունակը ամբողջ էջի ամենաարագ ընթերցումն է։

Ստուգում 5. ինչ է իրականում հայտարարվում

Ամբողջական հարեւանությունը երթուղի չէ։ Ստուգեք, թե որ ցանցերն են ստեղծվում, որոնք են սովորում եւ որոնք են տեղադրվում երթուղավորման աղյուսակում։ Բացակայող ցանցի հայտարարությունը կամ կայքի նախածանցը բացառող վերաբաշխման քաղաքականությունը տալիս է առողջ հարեւան եւ դատարկ աղյուսակ։

Ապա փորձարկեք հոսթ մակարդակի հավելվածը եւ վերադարձի ուղին, որովհետեւ երթուղավորման արձանագրությունը firewall չի բացում։

IPv6-ի համար OSPFv3-ն ունի իր պահանջները եւ հասցեների ընտանիքի անջատիչ չէ յուրաքանչյուր OSPFv2 կարգավորման վրա։ Օգտագործեք համապատասխան արձանագրությունը եւ հարթակի փաստաթղթերը։ Իսկ եթե կապը մեկ ֆիքսված կապուղի է, համեմատեք ստատիկ երթուղիները նախքան ղեկավարման հարթություն ավելացնելը, որը ստիպված կլինեք շահագործել։