Դուպլեքսի անհամապատասխանություն VPN-շլյուզի պորտում. կարդացեք երկու ծայրերը
10/100 պորտը, որը համաձայնեցնում է արագությունը, բայց ոչ դուպլեքսը, ծանրաբեռնվածության տակ սխալներ է առաջացնում: Կարդացեք աշխատանքային ռեժիմը երկու ծայրերում, ապա համեմատեք ժամանակային հաշվիչները:
Ֆայլի պատճենումը թունելով մեկ վայրկյան կանգ է առնում, շարունակվում, և VPN-ի մատյանները ոչինչ չեն ցույց տալիս: Հավելվածը մեղադրում է ցանցին, ցանցը՝ հավելվածին, իսկ կոմուտատորի պորտը միացված է արդեն տասնմեկ ամիս: Այս ուղեցույցը սկսվում է դադարից և շարժվում դեպի ֆիզիկական կապը՝ ինչ է իրականում անում պորտը, ինչ է անում հեռավոր ծայրը և ինչ արեցին հաշվիչները, մինչ դուք դիտում էիք: Արժե անել սա նախքան որևէ մեկը կդիպչի դուպլեքսի կարգավորմանը:
Սկսեք դադարից, ոչ թե պորտից
Նկարագրեք ախտանիշն այնպես, որ հնարավոր լինի ստուգել: Զանգվածային փոխանցման ժամանակ մոտ մեկ վայրկյան տևող կանգը այլ խնդիր է, քան վերականգնվող կապը, և ժամը մեկ անգամ տեղի ունեցող դադարը տարբերվում է ամեն մի քանի վայրկյանը մեկ տեղի ունեցողից: Գրեք ծանրաբեռնվածությունը, ուղղությունը և մոտավոր ինտերվալը:
Այնուհետև վերարտադրեք այն՝ դիտելով ինտերֆեյսը: Ֆիզիկական խնդիրը դրսևորվում է որպես հաշվիչների շարժում տվյալ ծանրաբեռնվածության ընթացքում, իսկ այն խնդիրը, որը ընդհանրապես հաշվիչների շարժում չի առաջացնում, հավանաբար գտնվում է կապի շերտից վեր: Դիտեք մեկ րոպե, ոչ թե մեկ վայրկյան, քանի որ այս թերությունները հաճախ պահանջում են շարունակական թրաֆիկ նախքան ի հայտ գալը: Պարապ վիճակում մոնիտորինգը ոչինչ չի ապացուցում այն կապի մասին, որը վատ է վարվում միայն ծանրաբեռնվածության տակ:
Սա կարևոր է, որովհետև դուպլեքսի անհամապատասխանությունն ունի ստորագրություն՝ սխալներ, որոնք հայտնվում են միայն ծանրաբեռնվածության տակ, թրաֆիկի ուղղությամբ, մինչ փոքր ping-երը և ինտերակտիվ սեանսները մնում են անթերի: Եթե պարապ թրաֆիկը նույնպես ձախողվում է, ապա նախ այլ տեղ փնտրեք:
Կարդացեք աշխատանքային ռեժիմը երկու ծայրերում
Պահված կոնֆիգուրացիան աշխատանքային վիճակը չէ: Պորտը կարող է կարգավորված լինել ավտոմատ բանակցության համար և հայտնվել կիսադուպլեքսում, կամ կարգավորված լինել ֆիքսված արագության, որին մյուս ծայրը երբեք չի համաձայնել: Կարդացեք, թե կապը հիմա ինչ է անում երկու կողմերում:
ethtool eth0 ethtool -S eth0 | grep -iE 'error|drop|collision|fcs' ip -s link show eth0
Գրանցեք արագությունը, դուպլեքսը և արդյոք ավտոմատ բանակցությունը միացված է, ապա ստացեք նույն երեք փաստերը հարևան կոմուտատորից կամ մատակարարի պորտից: Մեկ ծայրը ինքնին ոչինչ չի ասում, որովհետև անհամապատասխանությունը հարաբերություն է, ոչ թե կարգավորում: Տեղադրեք երկու տողերը կողք-կողքի տոմսում՝ այն ժամով, երբ կարդացիք դրանք: Վարժության արժեքի կեսն այն է, որ երկու ընթերցումները մեկ տեղում լինեն:
Եթե չեք կարող կարդալ հեռավոր ծայրը, չեք կարող ախտորոշել սա: Խնդրեք սեփականատիրոջից աշխատանքային ռեժիմը և հաշվիչները, կամ կազմակերպեք մուտքը նախքան ձեր կողմը փոխելը:
Ինչպիսին է 10/100 կիսադուպլեքս դեպքը
10/100 պղնձե կապերում ավտոմատ բանակցող ծայրը կարող է հայտնաբերել հարկադրված գործընկերոջ արագությունը՝ չսովորելով նրա դուպլեքսի կարգավորումը: Զուգահեռ հայտնաբերումը որոշում է արագությունը ազդանշանից, և դուպլեքսը ենթադրվում է բանակցելու փոխարեն, այնպես որ մի կողմը կարող է մնալ կիսադուպլեքսում, մինչ մյուսը աշխատում է լրիվ դուպլեքսում:
Cisco-ի ավտոմատ բանակցության ուղեցույցը բացատրում է հենց այդ դեպքը: Սա փաստարկ չէ բանակցությունը ամենուր անջատելու համար, և այն ոչինչ օգտակար չի ասում գիգաբիթ պղնձի մասին, որտեղ դուպլեքսը ֆիքսված է, և ավտոմատ բանակցությունը պարտադիր է, որպեսզի կապը ընդհանրապես բարձրանա:
Դիտելի ապացույցը սխալների խառնուրդ է, որոնք գոյություն ունեն միայն մեկ ուղղությամբ՝ FCS կամ CRC սխալներ լրիվ դուպլեքսի կողմում, բախումներ կամ ուշ բախումներ կիսադուպլեքսի կողմում, և թողունակություն, որը փլուզվում է ծանրաբեռնվածության տակ, մինչ ուշացումը պարապ վիճակում նորմալ է մնում: Այդ ասիմետրիան է ստորագրությունը: Պարզապես գերբեռնված կապը վատանում է երկու ուղղությամբ և բոլոր ժամանակներում:
Փոխեք երկու ծայրերը միասին՝ վերադարձի ճանապարհով
Դուպլեքսի ուղղումը համակարգված փոփոխություն է, ոչ տեղային: Ձեր կողմը հարկադրելը առանց հեռավոր ծայրի համաձայնության այն ձևն է, որով աշխատող կապը դառնում է կոտրված, և CLI-ի կողմից հրահանգի ընդունումը միայն ապացուցում է, որ շարահյուսությունը վավեր էր:
sudo ethtool -s eth0 speed 100 duplex full autoneg off ethtool eth0
Նախքան նման բան գործարկելը, հաստատեք, որ հարթակը աջակցում է այդ համակցությանը և որ հեռավոր ծայրը կփոխվի նույն պատուհանում: Պահպանեք սարքը կառավարելու անկախ եղանակ, որովհետև այն պորտը, որը պատրաստվում եք փոխել, կարող է հենց այն լինել, որը կրում է ձեր կառավարման սեանսը:
Շատ ժամանակակից կապերում ճիշտ պատասխանն այն է՝ թողնել ավտոմատ բանակցությունը միացված երկու ծայրերում՝ ինչ-որ բան հարկադրելու փոխարեն: Հարկադրումը կոնկրետ տեխնոլոգիայի կոնկրետ անհամապատասխանության դեղն է, ոչ թե ընդհանուր բարելավում: Մասնավորապես գիգաբիթ պղինձը ավտոմատ բանակցության կարիք ունի, որպեսզի կապը բարձրանա, ուստի 10/100-ի խորհուրդը չի տարածվում:
Հաստատեք, որ հաշվիչները շարժվել են դեպի լավը
Փոփոխությունից հետո նորից կարդացեք աշխատանքային վիճակը երկու ծայրերում և հաստատեք, որ դրանք համընկնում են: Ապա գործարկեք նույն ծանրաբեռնվածությունը, որը առաջացրեց դադարը, և համեմատեք հաշվիչների տարբերությունները, ոչ թե կյանքի ընթացքի գումարները, որովհետև մեկ տարի կուտակվող գումարը չի կարող ասել, թե ինչ է տեղի ունեցել վերջին տասը րոպեում:
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs' ip -s link show eth0 ping -f -c 200 10.90.0.1
Կապը, որը նույն ծանրաբեռնվածության տակ նոր սխալներ չի տալիս, այն ապացույցն է, որ պակասում էր: Կապը, որը դեռ սխալվում է, կամ այն, որտեղ հաշվիչները սկզբում ընդհանրապես չշարժվեցին, ձեզ ուղարկում է հաջորդ սահմանը՝ դուպլեքսի վեճի մեջ ավելի խորանալու փոխարեն: Երկու ելքերն էլ առաջընթաց են, ինչը ավելին է, քան կոնֆիգուրացիայի ֆայլը կարող է տալ: Չշրջանցեք երկրորդ ընթերցումը, որովհետև առաջինը ճիշտ էր թվում:
Գրեք առաջ և հետո թվերը տոմսում՝ ժամանակի նիշերով: Հենց այդ գրառումն է «VPN-ը ավելի լավ է զգացվում» արտահայտությունը դարձնում մի բան, որի վրա հաջորդ ինժեները կարող է կառուցել: