Dupleksa neatbilstība VPN vārtejas portā: nolasiet abus galus

Faila kopēšana caur tuneli uz sekundi apstājas, turpinās, un VPN žurnāli neko nerāda. Lietojumprogramma vaino tīklu, tīkls vaino lietojumprogrammu, un komutatora ports ir ieslēgts jau vienpadsmit mēnešus. Šī rokasgrāmata sākas ar apstāšanos un virzās uz āru līdz fiziskajam savienojumam: ko ports patiešām dara, ko dara tālais gals un ko darīja skaitītāji, kamēr jūs vērojāt. To ir vērts izdarīt pirms kāds aizskar dupleksa iestatījumu.

Sāciet ar apstāšanos, nevis ar portu

Aprakstiet simptomu tā, lai to varētu pārbaudīt. Apstāšanās apmēram uz sekundi lielapjoma pārsūtīšanas laikā ir cita problēma nekā savienojums, kas atiestatās, un pauze reizi stundā atšķiras no tās, kas notiek ik pēc dažām sekundēm. Pierakstiet slodzi, virzienu un aptuveno intervālu.

Pēc tam atkārtojiet to, vērojot saskarni. Fiziska problēma izpaužas kā skaitītāju kustība attiecīgās slodzes laikā, un problēma, kas vispār nekustina skaitītājus, visticamāk, atrodas virs saites slāņa. Vērojiet minūti, nevis sekundi, jo šiem defektiem bieži vajag pastāvīgu satiksmi, pirms tie parādās. Tukšgaitas uzraudzība neko nepierāda par saiti, kas slikti uzvedas tikai slodzes laikā.

Tas ir svarīgi, jo dupleksa neatbilstībai ir paraksts: kļūdas, kas parādās tikai slodzes laikā, satiksmes virzienā, kamēr mazi ping un interaktīvas sesijas paliek nevainojamas. Ja arī tukšgaitas satiksme neizdodas, vispirms meklējiet citur.

Nolasiet darbības režīmu abos galos

Saglabātā konfigurācija nav darbības stāvoklis. Ports var būt konfigurēts automātiskajām sarunām un nonākt pusdupleksā, vai būt konfigurēts fiksētam ātrumam, kam otrs gals nekad nav piekritis. Nolasiet, ko saite pašlaik dara abās pusēs.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Pierakstiet ātrumu, dupleksu un to, vai automātiskās sarunas ir ieslēgtas, pēc tam iegūstiet tos pašus trīs faktus no blakus esošā komutatora vai pakalpojumu sniedzēja porta. Viens gals pats par sevi neko nepasaka, jo neatbilstība ir attiecības, nevis iestatījums. Ielieciet abas rindas blakus pieteikumā, ar laiku, kad tās nolasījāt. Puse no šī vingrinājuma vērtības ir abiem nolasījumiem vienā vietā.

Ja nevarat nolasīt tālo galu, jūs to nevarat diagnosticēt. Palūdziet īpašniekam darbības režīmu un skaitītājus vai noorganizējiet piekļuvi, pirms sākat mainīt savu pusi.

Kā izskatās 10/100 pusdupleksa gadījums

10/100 vara saitēs automātiski sarunājošs gals var noteikt piespiedu partnera ātrumu, neuzzinot tā dupleksa iestatījumu. Paralēlā noteikšana nosaka ātrumu no signāla, un duplekss tiek pieņemts, nevis sarunāts, tāpēc viena puse var palikt pusdupleksā, kamēr otra darbojas pilnajā.

Cisco automātisko sarunu vadlīnijas izskaidro tieši šo gadījumu. Tas nav arguments izslēgt sarunas visur, un tas neko noderīgu nepasaka par gigabitu varu, kur duplekss ir fiksēts un automātiskās sarunas ir vajadzīgas, lai saite vispār paceltos.

Novērojamie pierādījumi ir kļūdu sajaukums, kas pastāv tikai vienā virzienā: FCS vai CRC kļūdas pilnā dupleksa pusē, sadursmes vai vēlas sadursmes pusdupleksa pusē, un caurlaidspēja, kas slodzes laikā sabrūk, kamēr aizture tukšgaitā paliek normāla. Šī asimetrija ir paraksts. Vienkārši pārslogota saite degradējas abos virzienos un visu laiku.

Mainiet abus galus kopā, ar ceļu atpakaļ

Dupleksa labojums ir saskaņota izmaiņa, nevis vietēja. Savas puses piespiešana bez tālā gala piekrišanas ir veids, kā strādājoša saite kļūst salauzta, un tas, ka CLI pieņem komandu, pierāda tikai to, ka sintakse bija derīga.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Pirms kaut ko tādu palaižat, pārliecinieties, ka platforma atbalsta šo kombināciju un ka tālais gals tiks mainīts tajā pašā laika logā. Saglabājiet neatkarīgu veidu, kā administrēt ierīci, jo ports, kuru gatavojaties mainīt, var būt tieši tas, kas pārvadā jūsu pārvaldības sesiju.

Daudzās mūsdienu saitēs pareizā atbilde ir atstāt automātiskās sarunas ieslēgtas abos galos, nevis kaut ko piespiest. Piespiešana ir konkrētas tehnoloģijas konkrētas neatbilstības zāles, nevis vispārējs uzlabojums. Jo īpaši gigabitu varam ir vajadzīgas automātiskās sarunas, lai saite vispār paceltos, tāpēc 10/100 padoms uz to neattiecas.

Pārliecinieties, ka skaitītāji ir pavirzījušies uz labo pusi

Pēc izmaiņām vēlreiz nolasiet darbības stāvokli abos galos un pārliecinieties, ka tie sakrīt. Pēc tam palaidiet to pašu slodzi, kas izraisīja apstāšanos, un salīdziniet skaitītāju starpības, nevis dzīves laika kopsummas, jo kopsumma, kas krājas gadu, nevar pateikt, kas notika pēdējās desmit minūtēs.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Saite bez jaunām kļūdām pie tās pašas slodzes ir pierādījums, kura jums trūka. Saite, kas joprojām kļūdās, vai tāda, kur skaitītāji vispār nekustējās, jūs sūta uz nākamo robežu, nevis dziļāk dupleksa strīdā. Abi iznākumi ir progress, un tas ir vairāk, nekā konfigurācijas fails var dot. Nepalaidiet garām otro nolasījumu tāpēc, ka pirmais izskatījās pareizs.

Ierakstiet skaitļus pirms un pēc pieteikumā ar laika zīmogiem. Tieši šis ieraksts pārvērš «VPN jūtas labāk» kaut kā tādā, uz ko nākamais inženieris var balstīties.