Кеңтаралымды дауылдың көзін кіріс трафик көрсетеді

Кеңтаралымды дауылды ең көп шулап тұрған коммутатордан емес, қалыптан тыс кадрлар ағыны оның порттарына қай бағыттан келіп жатқанын бақылау арқылы іздейді. Желінің ортасындағы коммутатор көбіне бәрінен нашар көрінеді, бірақ ол төменгі қабатта, қабырға розеткасының артында, арзан шағын коммутаторда немесе қате жалғанған екі розетка арасында туған трафикті ғана көбейтіп тұруы мүмкін.

Желі жұмысын тоқтатқан кезде іс-қимыл реті талдаудың тереңдігінен маңыздырақ. Алдымен бірнеше көрсеткішті сақтап алыңыз, одан кейін ілмекті мүмкіндігінше шағын учаскеде үзіңіз, байланысты қалпына келтіріңіз, тек содан соң конфигурацияны талдаңыз. Егер барлық аплинкті бірден өшірсеңіз, кеңсе желісі қалпына келуі мүмкін, бірақ ақауға апаратын ізді жоясыз және кабель қайта қосылғанда апат қайталанады.

Дауыл бірден үш деңгейден байқалады

Кеңтаралымды дауыл пайдаланушылар жұмысынан, порт көрсеткіштерінен және коммутатордың өз әрекетінен бір уақытта көрінеді. Бір белгіні басқа ақаумен шатастыру оңай, ал белгілердің қатар шығуы екінші деңгей ілмегі туралы негізді болжам жасауға мүмкіндік береді.

Пайдаланушылар шлюздің бірде жауап беріп, бірде жоғалып кететініне, DHCP мекенжайды ұзақ беретініне, телефония дыбысының үзіліп қалатынына және сол кеңседегі серверлерге қолжетімділік тұрақсыз екеніне шағымданады. Шлюзге дейінгі кідіріс секіреді, пакеттер жоғалады, бірақ порттардың физикалық индикаторлары жанып тұрады. Бір компьютерді қайта іске қосу ештеңені өзгертпейді, өйткені ақау бүкіл кеңтаралымды доменді, әдетте бір VLAN-ды немесе ортақ транкпен өтетін бірнеше VLAN-ды қамтиды.

Коммутаторларда бірнеше желінің жүктемесі өседі, ағынның басым бөлігі кеңтаралымды және жиі көпадресті кадрлардан тұрады. MAC мекенжайлары кестесінде бір мекенжай бір порттан екіншісіне жылдам ауысуы мүмкін. Журналда STP топологиясының жиі өзгеруі, кезектердің толуы, кадрлардың тасталуы немесе storm control іске қосылғаны жазылады. SSH арқылы басқару мен веб-интерфейс баяу жауап береді, себебі кадрларды жабдық деңгейінде жібергеннің өзінде басқару процессоры қызметтік оқиғаларды өңдеумен айналысады.

Жоғары жүктеменің бәрі дауыл емес. Сақтық көшірме жасау желіні бір адресті трафикпен толтырса да, көрші құрылғыларға кедергі келтірмеуі мүмкін. Электр қуаты қалпына келгеннен кейінгі жаппай ARP қысқа серпіліс жасап, өздігінен басылады. Дуплекс сәйкессіздігі CRC қателерін, late collisions және төмен пайдалы жылдамдықты туғызады, бірақ бір дұрыс кадрды шексіз айналдырмайды. Трафик құрамын, ақау аумағын және есептегіштердің өсу жылдамдығын бірге тексеріңіз.

Ақау шекарасы алғашқы коммутаторға кірмей тұрып VLAN-ды анықтауға көмектеседі. Бір бөлімнің сымды желі пайдаланушылары байланыстан айырылып, қонақтарға арналған Wi-Fi мен телефондар жұмыс істесе, олардың VLAN-дары мен шлюздерін салыстырыңыз. Бірнеше VLAN қатар жоғалса, ортақ транкті, қате жиналған арналар агрегациясын немесе осы VLAN-дардың бәрін өткізетін құрылғыдағы ілмекті іздеңіз. Бір VLAN-дағы дауыл физикалық коммутатордың әр портын жүктемеуі мүмкін, алайда ол құрылғыны басқаруды қолжетімсіз етіп, бүкіл желі істен шыққандай әсер қалдырады.

Басқару процессорының жүктемесін де бақылаңыз, бірақ оны негізгі өлшем етпеңіз. Кейбір модельдер дауылды жабдық деңгейінде өткізіп, CPU жүктемесін орташа күйде сақтайды. Басқа модельдер ARP, белгісіз хаттамалар немесе қызметтік кадрларды процессорға жіберіп, басқару мүмкіндігін тез жоғалтады. Қалыпты CPU порттардағы қалыптан тыс көрсеткіштерді жоққа шығармайды, ал жоғары CPU трафикті талдамай тұрып ілмекті дәлелдемейді.

RFC 919 кеңтаралымның тиімсіз жағын түсіндіреді: мұндай пакетті естіген әр түйін оған өз ресурсын жұмсайды. Дұрыс желіде бұл шығын бір доменмен және көшірмелердің шектеулі санымен бітеді. Ethernet кадрының екінші деңгейде IP TTL сияқты шектеуі жоқ, сондықтан ілмектегі коммутаторлар оны STP, қорғаныс механизмі немесе инженер ілмекті үзгенше көшіре береді.

Ілмек пен шулы түйінге әртүрлі шешім керек

Екінші деңгей ілмегі бар кадрларды қайта көбейтеді, ал шулы түйін жаңа кадрларды шамадан тыс шығарады. Екі жағдайда да broadcast есептегіші өседі, бірақ іздеу тәсілі мен түпкілікті жөндеу әртүрлі.

Ілмек болғанда өзара байланысқан бірнеше порттың кіріс және шығыс жылдамдығы жоғарылайды. Бір бастапқы MAC мекенжайы порттар арасында ауысып тұрады, өйткені оның кадрлары басқа жолмен қайтып келеді. Трафик түсірілімінде бірдей ARP сұраулары немесе басқа қайталанатын кадрлар жиі кездеседі. Сақинаның бір қабырғасын өшіру бүкіл домендегі ағынды бірден дерлік азайтады.

Шулы түйін болғанда негізгі кіріс жылдамдығы бір access-портта шоғырланады. Бастапқы MAC мекенжайлары тұрақты қалады, STP рөлдері өзгермейді, ал түсірілімдегі пакеттер бір-бірінен өзгеше болады немесе реттік мәні өзгеріп отырған бір жіберушіден келеді. Сол портты өшіру де апатты тоқтатады, бірақ себеп кабель сақинасында емес, желілік картада, драйверде, қолданбада немесе қате бапталған құрылғыда болады.

Үшінші жағдай да бар: IGMP snooping өшірілгенде немесе дұрыс істемегенде көпадресті ағын кеңтаралымды трафик сияқты жайылады. Ілмек болмаса да, ол access-порттарды толтыра алады. Broadcast және multicast есептегіштерін бөлек, MAC кестесін және кадрлардың қайталануын қараңыз. «Барлық шам жыпылықтап тұр» деген белгі бұл ақауларды ажыратпайды.

Іс жүзіндегі айырмашылық қарапайым: ілмек кезінде тұйық жолды, ал генератор кезінде бір көзді іздейсіз. Storm control нақты порттағы екі құбылыстың да әсерін шектей алады, бірақ трафиктің неге пайда болғанын түсіндірмейді және кабель сызбасын жөндемейді.

Өшірер алдындағы түсірілім кейін бірнеше сағат үнемдейді

Порттардың күйін өзгертпей тұрып, коммутаторлар әлі жауап берсе, деректердің қысқа түсірілімін сақтаңыз. Оған екі минуттай уақыт кетеді, ал сақталған мәлімет байланыс қалпына келгеннен кейін іздеу бағытын көрсетеді.

Уақытты, ақау шыққан VLAN-дарды, шлюздің қолжетімділігін және әлі басқарылатын коммутаторларды жазып алыңыз. STP күйін, интерфейс жылдамдығын, broadcast және multicast есептегіштерін, журналды, LLDP немесе CDP көршілерін және MAC мекенжайларының ауысуын сақтаңыз. Бастапқы мәндерді сақтамай тұрып есептегіштерді тазаламаңыз.

Cisco IOS XE үшін ең аз командалар жиыны мынадай болуы мүмкін:

show clock
show spanning-tree vlan 120
show interfaces counters
show interfaces | include is up|input rate|output rate
show mac address-table notification mac-move
show logging
show lldp neighbors

Команда атаулары өндіруші мен нұсқаға байланысты. Басқа коммутаторларда interface statistics, Ethernet switching table, spanning tree status, log buffer және LLDP neighbors баламаларын іздеңіз. Қалай жұмыс істейтінін тексермей, төтенше консольге бейтаныс тазалау немесе қайта іске қосу командасын енгізбеңіз.

Коммутаторлар стегінде портпен бірге қатысушы нөмірін де жазыңыз. Gi1/0/24 және Gi3/0/24 соңғы сандары бірдей болғанымен, әртүрлі физикалық шкафты білдіреді. Ішкі stack-link күйін тексеріңіз: оның толуы немесе үзілуі трафик жолын өзгертеді және сыртқы есептегіштерді күтпеген түрде көрсетуі мүмкін. Виртуалды шассиде де слот пен интерфейс иесін белгілеңіз.

Арасына 10-20 секунд салып, екі түсірілім жасаңыз. Бір жыл бойы жиналған абсолютті есептегіштің пайдасы шамалы. Екі мәннің айырмасы жылдамдықты көрсетеді. Егер порттағы broadcast 15 секундта 18 240 100-ден 18 690 100-ге дейін өссе, бұл секундына 30 000 кадр:

(18 690 100 - 18 240 100) / 15 = 30 000 pps

Бір санаттағы порттарды салыстырыңыз. Қабат аплинкі принтер портына қарағанда көбірек трафик тасымалдауы қалыпты. Күдік тудыратын белгі жай ғана үлкен есептегіш емес, қалыпты жүктемеге және сол рөлдегі көрші желілерге қарағанда күрт өсу.

Cisco компаниясының Catalyst 9000 коммутаторларындағы екінші деңгей ілмектерін анықтау нұсқаулығы алдымен кіріс жылдамдығына, broadcast пен multicast үлесіне және пакеттің орташа өлшеміне қарауды ұсынады. Бұл STP топологиясы өзгергені туралы ретсіз хабарламаларды қуалаудан пайдалырақ. Жүктемесі жоғары коммутаторлар мұндай хабарламаларды өздері көп шығарады, сондықтан оқиға ілмек көзін емес, зардап шеккен орынды көрсетуі мүмкін.

Кіріс есептегіштерімен ағынға қарсы жүріңіз

Көзді ядродан ең үлкен қалыптан тыс кіріс ағынын жіберген көршіге қарай біртіндеп өту арқылы табады. Әр қадамда күдікті порттардың кіріс жылдамдығын және көршілер картасын тексеріңіз. Транк access-портқа айналғанша немесе екі жол қайта тұйықталғанша осы әрекетті жалғастырыңыз.

CORE-1 ядролық коммутаторы, FLOOR-2 және FLOOR-3 қабат коммутаторлары және VLAN 120 бар желіні елестетейік. CORE-1-дегі екі аплинктің шығыс жылдамдығы желі шегіне жақын, бірақ FLOOR-2 бағытына баратын порттың кіріс broadcast көрсеткіші әлдеқайда жоғары. FLOOR-2-ге өтеміз. Онда үлкен кіріс ағыны Gi1/0/47 портына келеді, LLDP оны келіссөз бөлмесіндегі шағын коммутатормен байланыстырады. Сол құрылғының екі порты бір уақытта ағын көрсетеді, ал MAC мекенжайлары олардың арасында ауысып тұрады. Физикалық тексеру шағын коммутаторды бір VLAN-дағы екі розеткамен жалғаған екі патч-кордты табады.

Бұл бағыт маңызды. Үлкен шығыс жылдамдығы көбіне көзден келесі зардап шеккен құрылғыға қарай апарады. Үлкен кіріс жылдамдығы коммутатордың көшірмелерді қайдан алып жатқанын көрсетеді. Асимметриялық топологияда, агрегатталған арналарда және есептегіштердің жабдықтық ерекшеліктерінде өзгеше жағдайлар болады, сондықтан желінің екі жағындағы көрсеткіштерді салыстырыңыз.

Мына бес әрекетті ретімен орындаңыз:

1. Апат салдары көрінетін коммутаторды тауып, дауыл жүрген VLAN-ды анықтаңыз.
2. Белсенді порттардағы кіріс broadcast және multicast өсімін салыстырыңыз.
3. Қалыптан тыс порттың көршісін LLDP, CDP, порт сипаттамасы немесе сызба арқылы анықтаңыз.
4. Сол көршіге өтіп, дәл сондай уақыт аралығымен өлшеуді қайталаңыз.
5. Желі шетінде MAC мекенжайын патч-панельмен, розеткамен және нақты құрылғымен сәйкестендіріңіз.

Порт сипаттамасын жалғыз дәлел деп қабылдамаңыз. Кеңсе көшкеннен кейін «бухгалтерия принтері» деген жазу үстел астындағы басқарылмайтын коммутаторға апаруы жиі кездеседі. Жоғары жүктеме кезінде LLDP ақпараты да жоғалуы мүмкін. Кемінде екі белгіні сәйкестендіріңіз: есептегіш пен көршіні немесе есептегіш пен физикалық кабель жолын.

Айна порты арқылы трафик түсіре алсаңыз, бірдей кадрлардың қайталануын тексеріңіз. Бастапқы және мақсатты мекенжайлардың, EtherType мәнінің, ARP мазмұнының сәйкестігі және олардың жақын уақытта келуі ілмек туралы қорытындыны күшейтеді. Түсірілім апатты тоқтатуды кешіктірмеуі керек. Бүкіл кеңсе байланыссыз қалғанда, есептегіштер мен күдікті қабырғаны мұқият өшіру көбіне тезірек жауап береді.

Unknown unicast трафигін бөлек тексеріңіз. Мақсатты MAC мекенжайы белгісіз кадрды коммутатор VLAN бойымен broadcast сияқты таратады. MAC кестесі тұрақсыз болған кезде бұл трафик өсіп, broadcast есептегіші толық жағдайды көрсетпесе де, жүктемені арттырады. Жалпы кіріс жылдамдығы жоғары, ал broadcast орташа болса, unknown unicast, MAC жазбаларының жасын және үйрену жылдамдығын салыстырыңыз.

Іздеу порт атауымен емес, бөлмедегі нақты затпен аяқталады. Коммутация кестесіндегі жазба патч-панель нөміріне, розеткаға және кабельге апаруы керек. Бірдеңені өшірмей тұрып, сол жердегі қызметкерден қосылымның екі ұшын суретке түсіруді сұраңыз. Осындай қарапайым белгілеу логикалық сызбадан көрінбейтін екі қабырға розеткасы арасындағы ілмекті жиі табады.

STP қорғаныстың ілмекті неге тоқтатпағанын көрсетеді

Spanning Tree Protocol бір жолды белсенді қалдырып, артық жолды бөгеуі керек, бірақ конфигурацияда STP болуы оның нақты ілмекті көріп тұрғанын білдірмейді. Порт рөлдерін, түбірлік көпірді, BPDU қабылдануын және әр VLAN шекарасын тексеріңіз.

Алдымен нақты root bridge мәнін жобадағы мәнмен салыстырыңыз. Күтпеген түбір көбіне басымдығы тиімдірек болып тұрған қосымша коммутаторды көрсетеді. Одан кейін forwarding және discarding немесе blocking күйіндегі порттарды табыңыз. Егер екі қатар жол бір VLAN-ды өткізіп, ешқайсысы бөгелмесе, екі жақ BPDU алып тұрғанын және транктердегі VLAN конфигурациясы сәйкес екенін анықтаңыз.

Кеңседегі жиі себеп edge немесе PortFast баптауының артында жасырынады. Бұл баптау соңғы құрылғы портына орынды, өйткені STP-дің әдеттегі ауысуын күттірмейді. Бірақ портты қауіпсіз етпейді. Қызметкер шағын коммутаторды екі edge-портқа қосса, жобалаушы жоспарламаған жол пайда болады. BPDU Guard BPDU алған кезде осындай access-портты өшіруі керек, бірақ механизм қосылған жерде және жалғанған құрылғы BPDU шынымен өткізген жағдайда ғана жұмыс істейді.

Төрт қорғаныс механизмін тексеріп, олардың қызметін шатастырмаңыз:

• BPDU Guard edge-портта BPDU пайда болса, оны жабады және қолжетімділік шекарасын қорғайды.
• Root Guard порттағы бөгде коммутатордың түбір рөліне өтуіне жол бермейді.
• Loop Guard күтілген BPDU жоғалғанда түбірлік емес портты forwarding күйіне өткізбейді.
• Storm control шек бойынша broadcast, multicast немесе unknown unicast трафигін шектеп, залалды азайтады.

Storm control STP орнын баспайды. Тым жоғары шек ілмектің желіні жүктеуіне мүмкіндік береді, ал тым төмен шек заңды ARP, DHCP немесе құрылғыларды анықтау серпілісін тоқтатады. Әр порт түрінің өлшенген қалыпты жүктемесіне сүйеніп шек таңдаңыз және әрекетті алдын ала белгілеңіз: тастау, хабарлау немесе өшіру. Іске қосылғаннан кейін инженер портты, трафик түрін, шекті және уақытты көруі керек. Әйтпесе қорғаныс жалпы апатты түсініксіз жергілікті үзіліске ғана айналдырады.

Агрегатталған арналарды бөлек тексеріңіз. Бір жақ екі желіні бір LAG деп санап, екінші жақ оларды тәуелсіз порт ретінде көрсе, STP мен коммутация кестесі бір-біріне қайшы ақпарат алады. Port-channel құрамын, келісу хаттамасын, VLAN-дарды және әр қатысушының күйін екі жақтан салыстырыңыз.

Біржақты желі тағы бір қауіпті жағдай туғызады. Бір жақ BPDU қабылдап, екінші жақ таратқыштың, оптиканың немесе сүзгінің ақауына байланысты оны көрмей қалады. Бұрын бөгелген порт түбірге жол жоғалды деп шешіп, кадр өткізе бастауы мүмкін. Екі жақтағы BPDU қабылдануын, LLDP көршісін және кіріс жылдамдығын салыстырыңыз. Әр жақ өзін designated деп санап, көрші тек бір жақтан көрінсе, физикалық желі мен Loop Guard жұмысын тексеру қажет.

Желі тоқтаса, ең шағын қабырғаны үзіңіз

Байланыс толық жоғалғанда алдымен оны қалпына келтіру керек, бірақ ілмектің дәлелденген немесе ең ықтимал бір қабырғасын ғана өшірген дұрыс. Есептегіштер шеткі сегментті көрсетсе, сол жерден бастаңыз және барлық магистраль желісін қатар өшірмеңіз.

Shutdown командасын бермей тұрып портты, уақытты, ағымдағы есептегіштерді және оны таңдаудың себебін тіркеңіз. Бұл желі маңызды сегменттің, телефон станциясының, қолжетімділікті бақылау жүйесінің немесе медициналық жабдықтың жалғыз аплинкі емес екенін тексеріңіз. Тәуекел қолайлы болса, портты өшіріп, жоғары тұрған коммутатордың кіріс жылдамдығын бірден бақылаңыз.

Дұрыс қабырғаны өшіргенде broadcast күрт әрі тұрақты төмендейді, басқару қайта ашылады және шлюзге дейінгі кідіріс қалыпқа келеді. Кемінде екі өлшеу аралығын күтіңіз, себебі кезектер босап, STP қайта құрылуы керек. Көрсеткіш өзгермесе, портты бұрынғы күйіне қайтарыңыз, нәтижені жазыңыз және келесі үміткерге өтіңіз. Кездейсоқ өшірілген порттар тобын қалдырмаңыз.

Басқару толық жоғалса, кабельді физикалық ажыратуға болады, бірақ орнындағы топ екі ұшын атап, әр әрекетті хабарлауы керек. Сызбамен сәйкес келсе, жақында өзгерген учаскелерден және шеткі қосарлы қосылымдардан бастаңыз. Ядро кабельдерін түсіне немесе индикатордың жыпылықтау жиілігіне қарап суырмаңыз.

Төтенше әрекет ретін қысқа нұсқаулықта сақтаңыз:

1. Инцидентті жариялап, келісілмеген кабель және конфигурация өзгерістерін тоқтатыңыз.
2. Қолжетімді есептегіштерді, STP күйін, журналды және уақытты сақтаңыз.
3. Кіріс ағыны мен көршілер картасы бойынша бір қабырғаны таңдаңыз.
4. Оны өшіріп, ағынның төмендеуін және бақылау түйіндерінің қолжетімділігін тексеріңіз.
5. Уақытша сызбаны тіркеп, себеп анықталғанша портты қоспаңыз.

Қалпына келгеннен кейін ping-пен шектелмеңіз. Клиенттер DHCP арқылы мекенжай алуы, DNS сұрауларын шешуі, шлюзді және негізгі ішкі қызметтерді көруі керек. Дауыстық VLAN, Wi-Fi және қонақ желісі жұмыс станцияларынан өзгеше қалпына келуі мүмкін. Шлюздің бір сәтті жауабы кеңсе штаттық режимге оралғанын дәлелдемейді.

Бір адамды ауыстырып қосуды басқаруға, екіншісін журнал жүргізуге тағайындаңыз. Үш әкімші әртүрлі портты қатар өшірсе, есептегіш төмендеуін нақты әрекетпен байланыстыру мүмкін болмайды. Журналда дәл уақыт, құрылғы, интерфейс, өзгеріске дейінгі және кейінгі күй, орындаушының аты және бақылау нәтижесі болуы керек. Мұндай тәртіп баяу көрінуі мүмкін, бірақ топ жоққа шығарылған болжамдарды қайталамайтындықтан, әдетте үзіліс уақытын қысқартады.

MAC ауысуы мен STP өзгерістері бағыт береді, үкім шығармайды

MAC мекенжайының порттар арасында жиі ауысуы ілмек шекарасын көрсетуі мүмкін, бірақ жеке өзі оны дәлелдемейді. Сымсыз клиент access point құрылғылары арасында заңды түрде ауысады, кластер ортақ виртуалды MAC қолдануы мүмкін, ал гипервизор виртуалды машинаны хосттар арасында көшіреді.

Ілмек кезінде көрініс әдетте жаппай болады: көптеген MAC мекенжайы бір жұп интерфейс немесе бір сақинадағы бірнеше желі арасында тез ауысады. Бұл оқиғалардың уақытын broadcast өсуімен салыстырыңыз. Дауылсыз ауысқан бір мекенжай бүкіл қабатты өшіруді емес, нақты құрылғыны тексеруді қажет етеді.

Topology Change Notification да көзді тікелей көрсетпейді. RSTP-де түпкі емес порт forwarding күйіне өткенде өзгеріс пайда болады. Дауыл кезінде басқару процессоры BPDU өңдеуін кешіктіруі мүмкін, порттар күйін өзгертеді, журнал екінші кезектегі оқиғалармен толады. Cisco TCN хабарламаларын қуу ілмек басталған жерге емес, зардап шеккен коммутаторларға апаруы мүмкін екенін бөлек ескертеді.

Уақыт желісін құру пайдалырақ: қай порт бірінші болып күрт кіріс ағынын көрсетті, MAC moves қайда басталды, қай интерфейс STP рөлін өзгертті және қандай әрекет өсуді тоқтатты. Коммутаторлардың сағаты синхрондалуы керек. Синхрондау болмаса, «бұл оқиға ертерек болды» деген жазба болжамға айналады.

Журналды соңғы рұқсат етілген өзгерістермен салыстырыңыз, бірақ ең соңғы өзгерісті автоматты түрде себеп деп жарияламаңыз. Жаңа access point іске қосылған уақыт тазалық кезінде қозғалған ескі кабель туғызған ілмекпен сәйкес келуі мүмкін. Өзгерістің VLAN-ы, порты және уақыты кіріс ағынының бағытымен сәйкес келгенде ғана ол негізді күдікке айналады. Мұндай сүзгі қолайлы, бірақ жалған оқиғадан қорғайды.

CRC қателері, drops және no buffer есептегіштері қосымша мәлімет береді. CRC көбіне физикалық желіні немесе дуплекс сәйкессіздігін көрсетеді, ал drops пен no buffer жүктеме кезінде пайда болады. Олар дауылмен қатар жүруі мүмкін, бірақ екінші жол белсенді тұрса, нашар патч-кордты ауыстыру логикалық ілмекті үзбейді.

Байланыс қалпына келген соң түпкі себепті дәлелдеңіз

Топ сызба бойынша ілмек жолын қайта құрып, оны қай бақылау тоқтатуы тиіс болғанын түсіндірмейінше, инцидент жабылмайды. «Коммутаторды қайта іске қостық, көмектесті» деген сөз себепті емес, әрекетті сипаттайды.

Зақымдалған порттардың конфигурациясын, журналды, өшіруге дейінгі және кейінгі есептегіштерді, MAC кестесін және кабель қосылымының суреттерін сақтаңыз. Әр кабельдің екі ұшын да тексеріңіз. Шағын басқарылмайтын коммутатор табылса, оның барлық портын қараңыз: ілмек екі розетка, өтпелі порты бар IP-телефон немесе док-станция арқылы өтуі мүмкін.

Төрт сұраққа жауап беріңіз:

• Қай физикалық немесе логикалық жол тұйықталды?
• STP неге жолдардың бірін бөгеуге тиіс еді, бірақ бөге алмады?
• BPDU Guard, Loop Guard немесе storm control оқиғаны неге шектемеді?
• Қай өзгеріс жаңа бір істен шығу нүктесін жасамай, қайталануға жол бермейді?

Жөндеу жауапқа сәйкес болуы керек. Артық кабельді алып, пайдаланылмайтын розетканы жабыңыз. Edge күйін тек пайдаланушы порттарына беріп, өндіруші саясатына сай BPDU Guard қосыңыз. Екі жақтағы allowed VLAN және LAG келісуін түзетіңіз. Storm control шектерін нақты өлшемдер бойынша баптаңыз. Келесі инженер ескірген жазуды қумас үшін порт сипаттамаларын қосып, сызбаны жаңартыңыз.

Инцидент есебі басталған оқиғаны, қорғаныс кемшілігін және салдарды ажыратуы керек. Мысалы, оқиғаны келіссөз бөлмесі мен қабат коммутаторы арасындағы екі кабель бастады. Қорғаныс кемшілігі пайдаланушы порттарында BPDU Guard болмауы еді. Салдары кезектердің толуы мен VLAN 120 қолжетімділігінің жоғалуы болды. Осының бәрін «кеңтаралымды дауыл» деген бір тіркеске жинасаңыз, топ қай бақылауды өзгерту керегін түсінбейді.

Жұмыс уақытында есептегіштерді бақыламай және өшіру командасын дайындамай, апат портын «тексеру үшін» қоспаңыз. Сызбаны оқшауланған сегментте қайталау немесе кабельдерді бір-бірден қосып, әр қосқан сайын STP мен broadcast өсімін тексеру қауіпсіздеу.

Коммутация желісі серверлік және пайдаланушы инфрақұрылымымен байланысқан ұйымдарға GSE.kz тәулік бойы техникалық қолдау көрсететін және Қазақстан бойынша сервис желісі бар жүйелік интегратор ретінде шешімді жобалап, сүйемелдей алады. Бұл ішкі сызба, бастапқы метрикалар және топтың консольге қолжетімділігі қажеттігін жоймайды. Сыртқы инженер де ілмекті нақты деректер арқылы іздейді.

Қорғаныс істен шығу сынағынан кейін ғана сенімді болады

Алдын алу нақты шекарадан басталады: пайдаланушы порттары транкке айналмауы, бөгде түбір рөлін қабылдамауы және жоспарланбаған сақина құрмауы керек. Access-коммутаторлардағы біркелкі конфигурация үлгісі ешкім есінде ұстамайтын ерекшеліктер санын азайтады.

Бүкіл доменде RSTP немесе MSTP хаттамасын біркелкі қосып, түбірлік және резервтік көпірлерді саналы түрде тағайындаңыз, транктердегі рұқсат етілген VLAN-дарды шектеңіз. Edge-порттарда BPDU Guard қолданыңыз, қолайлы резерв жолдарында Loop Guard мүмкіндігін қарастырыңыз, ал шекарада тексерілген storm control шектерін қойыңыз. Бір пайызды барлық интерфейске көшірмеңіз: телефон, access point, аплинк және принтердің қалыпты трафик сипаты әртүрлі.

Мониторинг кіріс broadcast және multicast жылдамдығын, порт жүктемесін, MAC ауысуын, STP өзгерістерін және қорғаныстың іске қосылуын сақтауы керек. Тәулік уақыты бойынша қалыпты деңгейді белгілеңіз. Әйтпесе «жоғары трафик» дабылы апат кезінде үндемейді немесе қызметкерлер таңертең компьютерлерін қосқан сайын кезекші инженерді оятады.

Зертханада немесе оқшауланған VLAN-да басқарылатын сынақ өткізіңіз. Сынақ коммутаторын қорғалған edge-портқа қосып, BPDU Guard күтілген күйге өтетінін және журналда түсінікті жазба қалдыратынын тексеріңіз. Трафик генераторымен шектеулі broadcast ағынын беріп, жұмыс желісіне әсер етпей storm control шегін сынаңыз. Қалпына келтіру командаларын жазып қойыңыз, өйткені түсінікті рәсімсіз автоматты өшіру апатты ұзартып жіберуі мүмкін.

Соңында екі есептегіш түсірілімі арқылы іздеу тәсілін жаттықтырыңыз. Кезекші инженер дәлелдерді тазаламай және желінің жартысын өшірмей, ядродан access-портқа бірнеше қадамда жете алуы керек. Нақты дауыл кезінде күрделі мониторинг панельдері желімен бірге қатып қалуы мүмкін, ал консоль, LLDP картасы және есептегіштер айырмасы жұмыс істейтін құрал болып қалады.