დუპლექსის შეუსაბამობა VPN-კარიბჭის პორტზე: წაიკითხეთ ორივე ბოლო

ფაილის კოპირება გვირაბში ერთი წამით ჩერდება, გრძელდება და 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 უკეთ იგრძნობა» იმად, რაზეც შემდეგ ინჟინერს შეუძლია აშენება.