Главная› Инженер СПД› Жизненные ситуации

🎧 Жизненные ситуации: разборы реальных заявок

Здесь нет новой теории — здесь смены как они есть. Каждый кейс — реальный звонок клиента и полный разбор: куда заходим сначала, какую команду даём, почему именно её, а не другую, что означает каждый из двух возможных ответов и куда он нас ведёт. Прочитай кейсы один раз вдумчиво — и на первой смене ты будешь действовать по знакомой колее, а не паниковать.

Универсальный порядок, который работает всегда

Почти каждый разбор ниже идёт по одной лесенке — снизу вверх по слоям:

физика порта → MAC (видим ли клиента на L2) → ARP (связался ли L3 с L2) → маршруты → протоколы (BGP) → сквозной пинг.

Почему снизу: каждый следующий слой не может работать без предыдущего. Если MAC клиента не виден на коммутаторе — бессмысленно смотреть BGP: кадры до нас просто не доезжают. Первый найденный «нет» = слой, где живёт проблема. Так ты экономишь время и никогда не чинишь не то.

Кейс 1. «У нас вообще ничего не работает!»

«Здравствуйте! Офис на Ленина, 10 — интернет пропал полностью, ничего не открывается, телефония лежит. Ничего не трогали, вчера всё работало!» — бухгалтер клиента, голос на панике.

Полная потеря сервиса — самый частый и, парадоксально, самый простой тип заявки: раз не работает всё, проблема почти наверняка низко — физика или L2. Открываем в системе документацию клиента: подключён к коммутатору доступа SW-LEN10, порт Gi0/5, VLAN 105, выше — маршрутизатор PE-LEN, услуга IP access, VRF ROMASHKA.

1

Заходим на коммутатор доступа: жив ли порт клиента

SW-LEN10# show interfaces Gi0/5 status Port Name Status Vlan Duplex Speed Gi0/5 CUST:ROMASHKA notconnect 105 auto auto
порт — это «дверь» клиента в нашу сеть, и его состояние проверяется одной командой за секунду. Начинать с BGP или маршрутов, пока не знаешь, что порт вообще поднят, — значит строить дом с крыши.
notconnect
линка нет физически. Смотрим дальше по физике: кабель, кросс, конвертер, питание роутера клиента (шаг 2).
connected
физика есть — тогда сразу к шагу 3 (MAC): проверяем, доезжают ли до нас кадры клиента.
2

Порт down: разделяем «наша сторона / сторона клиента»

Прежде чем гонять монтажника, спрашиваем клиента по телефону (вежливо, без «а вы пробовали»): «Посмотрите, пожалуйста, на ваш роутер — горят ли на нём лампочки? А на разъёме, куда приходит наш кабель, есть ли огонёк?»

пять минут разговора экономят выезд. Нет питания на роутере клиента (уборщица выключила, электрик обесточил) — четверть всех «всё лежит». Лампочка линка не горит с обеих сторон — проблема в кабеле/кроссе между нами.
роутер мёртв
проблема на стороне клиента (питание/железка) — сопровождаем словами, заявка не наша, но остаёмся на связи до восстановления.
всё горит
а у нас notconnect → битая физика между нами: заявка монтажникам на прозвон линии, параллельно проверяем наш SFP/порт (show interfaces Gi0/5 transceiver — есть ли сигнал по оптике).
3

Порт up: смотрим MAC-адреса — «в обе стороны»

SW-LEN10# show mac address-table interface Gi0/5 Vlan Mac Address Type Ports 105 a45e.601f.220b DYNAMIC Gi0/5 ← MAC роутера клиента — он «дышит» SW-LEN10# show mac address-table vlan 105 105 a45e.601f.220b DYNAMIC Gi0/5 ← клиент 105 0023.04ee.be01 DYNAMIC Po1 ← MAC нашего PE, виден через аплинк — путь наверх жив
MAC-таблица — это «журнал посещений» L2: запись появляется, только если от устройства реально пришёл кадр. Смотрим в обе стороны: (а) MAC клиента на его порту = кадры клиента до нас доезжают; (б) MAC нашего шлюза (PE) через аплинк = путь от коммутатора наверх тоже жив. Две записи — и весь L2-участок доказанно работает, никакие догадки не нужны.
нет MAC клиента
порт up, но кадров нет: роутер клиента завис (попросить перезагрузить), не тот VLAN на порту (сверь с документацией: show run int Gi0/5), или порт в err-disabled (show interfaces status err-disabled).
нет MAC шлюза
проблема выше коммутатора: аплинк, VLAN не прописан на транке (show interfaces trunk — есть ли 105 в allowed?), авария на агрегации.
оба есть
L2 полностью жив → поднимаемся на маршрутизатор (шаг 4).
4

На маршрутизаторе: ARP — встретились ли L3 и L2

PE-LEN# show ip arp vrf ROMASHKA Protocol Address Age (min) Hardware Addr Type Interface Internet 10.77.1.1 - 0023.04ee.be01 ARPA Gi0/1.105 ← мы сами Internet 10.77.1.2 12 a45e.601f.220b ARPA Gi0/1.105 ← клиент! MAC совпадает с тем, что видели на свитче
ARP-запись — доказательство, что роутер и клиент обменялись пакетами на L3 (ARP — это вопрос-ответ, запись не появится в одну сторону). Обрати внимание: мы сверяем MAC из ARP с MAC из таблицы коммутатора — они должны совпадать. Не совпали — в сети два устройства с одним IP, совсем другая история (кейс 5).
Incomplete / нет
роутер спрашивает — клиент не отвечает: у клиента сбился IP на порту, файрвол клиента режет ARP, или мы смотрим не тот сабинтерфейс. Проверить конфиг: show run interface Gi0/1.105 — VLAN и адрес по документации?
запись есть
ping vrf ROMASHKA 10.77.1.2 для контроля — и дальше к маршрутам/BGP (шаг 5).
5

Маршруты и BGP: получает ли клиент «весь мир»

PE-LEN# show ip bgp vpnv4 vrf ROMASHKA summary | begin Neighbor Neighbor V AS MsgRcvd MsgSent Up/Down State/PfxRcd 10.77.1.2 4 65001 8841 8850 3d02h 4 ← Established, клиент анонсирует 4 сети PE-LEN# show ip route vrf ROMASHKA | include 0.0.0.0 B* 0.0.0.0/0 [200/0] via 10.255.0.1 ← default в VRF есть — интернет клиенту отдаём
если сессия BGP жива и default-маршрут в VRF присутствует — со стороны оператора услуга работает полностью, и мы можем это доказать. В колонке State/PfxRcd должно быть число (= Established); слово Active/Idle — сессия лежит, идём в плейбуки BGP.
«Мы проверили ваш стык от порта до маршрутизации: физический линк в норме, ваше оборудование видно в сети, маршрутный обмен работает, сквозная связность до вашего роутера есть. Проблема локализована внутри вашей сети — рекомендуем проверить настройки вашего роутера и внутренний коммутатор» — с фактами, а не «у нас всё нормально».

Кейс 2. «Интернет есть, но всё жутко тормозит»

«Скорость упала раз в десять! Файлы качаются еле-еле, видеосвязь рассыпается. Так со вчерашнего вечера» — админ клиента, канал 100 Мбит/с.

«Тормозит» — заявка-обманка: сервис работает, значит физика/маршруты в целом живы. Здесь ищем деградацию: ошибки на порту, перегруз канала или потери на линии. Порядок другой, чем в кейсе 1 — начинаем со счётчиков ошибок, а не со статуса.

1

Ошибки на порту клиента — CRC главный подозреваемый

SW-LEN10# show interfaces Gi0/5 | include error|CRC|duplex Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX 3941 input errors, 3941 CRC, 0 frame, 0 overrun ← кадры приходят битыми!
CRC-ошибки = кадры доезжают повреждёнными: биты по пути искажаются. TCP такие кадры пересылает заново — снаружи это выглядит ровно как «жутко тормозит», при этом пинг может даже ходить. Это самая частая причина деградации, и она находится одной командой — поэтому она первая.
CRC растут
сбрось счётчики (clear counters Gi0/5), подожди 2–3 минуты, посмотри снова. Растут → битая среда передачи: патч-корд, кросс, «зажатая дверью витуха», для оптики — грязный коннектор или деградировавший SFP (шаг 2). Замена патч-корда чинит половину таких заявок.
чисто
среда в порядке → смотри загрузку канала (шаг 3).
Проверь и duplex: если в выводе Half-duplex или скорость 100Mb/s на гигабитном порту — авто-согласование сломалось (частая беда после замены оборудования клиента). Half-duplex в 2026 году = всегда ошибка: коллизии съедят канал. Лечится фиксацией скорости/duplex с обеих сторон или починкой кабеля (гигабит требует все 8 жил!).
2

Если оптика: уровни сигнала (DDM)

SW-LEN10# show interfaces Gi0/5 transceiver Temperature Voltage Current Tx Power Rx Power Gi0/5 36.1 3.29 18.4 -5.5 -26.7 ← принимаемый сигнал у самого дна
у каждого SFP есть «слух» (чувствительность, обычно до −24…−28 dBm). Rx Power у границы = сигнал доходит еле-еле: любые изгибы/грязь добивают его до ошибок. Нормальный уровень для короткой линии: −3…−15 dBm. Это объективное число — по нему сразу видно, деградировала ли линия, без выездов и гаданий.
Rx на дне
чистка коннекторов, проверка муфт/изгибов, замер рефлектометром — заявка линейщикам с конкретным числом в комментарии.
Rx в норме
оптика не виновата → шаг 3.
3

Загрузка канала: может, он просто занят?

SW-LEN10# show interfaces Gi0/5 | include rate 30 second input rate 98452000 bits/sec, 8123 packets/sec ← ~98 Мбит/с из 100 — канал забит В нас 30 second output rate 2100000 bits/sec, 1911 packets/sec
канал 100 Мбит/с, утилизация 98% — «тормозит» не сеть, а полка тарифа: кто-то у клиента качает бэкап/торрент или (хуже) наружу льётся мусор. Смотрим направление: input (от клиента) забит — источник у них; output (к клиенту) — их заливают снаружи, возможен DDoS.
полка
сообщаем клиенту с числами: «ваш канал утилизирован на 98% входящим трафиком с вашей стороны — проверьте, кто передаёт». При подозрении на DDoS к клиенту — эскалация по анти-DDoS процедуре (RTBH из урока BGP).
канал пустой
ошибок нет, канал свободен, а тормозит → проблема дальше нашей зоны: потери на магистрали (mtr от клиента), перегруз у самого клиента (их файрвол/прокси). Даём клиенту список фактов.
«На вашем порту фиксировались ошибки CRC — заменили патч-корд на кроссе, счётчики чистые уже 30 минут, скорость по замеру 94 Мбит/с. Понаблюдайте, пожалуйста, до конца дня».

Кейс 3. «Головной офис не видит филиал» (IPVPN)

«У нас IPVPN на 12 точек. Из центрального офиса перестала открываться 1С филиала в Твери. Остальные филиалы работают» — ИТ-директор сети магазинов.

Ключевой факт в самой заявке: остальные филиалы работают. Значит, центр и общая услуга живы — проблема локализована вокруг одной точки (Тверь). Всегда вылавливай такие факты из слов клиента: они срезают половину дерева диагностики ещё до первой команды.

1

На PE Твери: жив ли стык с CE филиала

PE-TVER# ping vrf MAGNIT 10.77.9.2 !!!!! Success rate is 100 percent PE-TVER# show ip bgp vpnv4 vrf MAGNIT summary | include 10.77.9.2 10.77.9.2 4 65021 9911 9902 4w2d 0 ← сессия жива... но префиксов НОЛЬ!
начинаем с ближней к проблеме точки — PE филиала: если бы лежал сам стык, кейс свёлся бы к кейсу 1. Здесь интереснее: сессия Established (4 недели аптайма!), но филиал перестал анонсировать свои сети — PfxRcd 0. Число принятых префиксов — самая информативная колонка summary, всегда смотри на неё, а не только на State.
PfxRcd = 0
CE филиала «замолчал»: у клиента слетел конфиг BGP (network/redistribute), перезагрузился в старый конфиг, или их админ что-то «улучшил». Наша сеть тут ни при чём — но докажем это до конца (шаг 2).
префиксы есть
тогда смотрим доехали ли они до центра — шаг 3.
2

Что именно пропало: сравниваем с центром

PE-TVER# show ip route vrf MAGNIT | include 10.9. ← сети филиала 10.9.x.x в VRF нет вообще PE-MSK# show ip route vrf MAGNIT 10.9.1.0 % Network not in table ← и в центре её, конечно, тоже нет
проверяем одно и то же с двух концов — «в обе стороны». Маршрута нет уже на PE самого филиала → он не мог доехать и до центра: источник иссяк. Если бы на PE-TVER маршрут был, а в Москве нет — искали бы потерю по пути (RT, route reflector). Направление, где маршрут пропадает впервые, — и есть место проблемы.
3

Если префиксы на PE есть, а в центре нет: проверка RT

PE-TVER# show vrf detail MAGNIT | include RD|Export RD 65000:210; default RD Export VPN route-target communities: RT:65000:201 ← а у всех остальных точек 65000:210!
маршруты между PE переносит BGP, а «пускать или не пускать в VRF» решает совпадение RT (урок VRF). Опечатка в одной цифре RT — и точка выпадает из «клуба», хотя все сессии зелёные. Так проявляются вчерашние работы: «мы ничего не трогали» почти всегда означает «трогали, но не мы».
«Стык с вашим оборудованием в Твери работает (пинг 100%, BGP-сессия активна), но ваш маршрутизатор перестал анонсировать сети филиала — принято 0 префиксов, до сбоя было 3. Проверьте конфигурацию BGP на вашем CE — вероятно, изменения вчера вечером» (и приложи вывод summary — фактура решает споры).

Кейс 4. «Связь пропадает на пару минут несколько раз в день»

«Неуловимая ерунда: три-четыре раза в день всё замирает минуты на две, потом само восстанавливается. Поймать не можем» — админ клиента.

Плавающие проблемы руками не ловятся — их ловят логи и счётчики. Прелесть в том, что железо всё помнит: наша задача — просто спросить.

1

Логи коммутатора: что происходило в моменты замирания

SW-LEN10# show logging | include Gi0/5 10:12:33: %LINK-3-UPDOWN: Interface Gi0/5, changed state to down 10:14:01: %LINK-3-UPDOWN: Interface Gi0/5, changed state to up 13:47:12: %LINK-3-UPDOWN: Interface Gi0/5, changed state to down 13:49:20: %LINK-3-UPDOWN: Interface Gi0/5, changed state to up ← порт «моргает» — flapping!
сверь времена в логе с жалобами клиента («в 10:10 и около 14:00» — совпало!). Порт физически падает и встаёт — это объясняет и «само восстанавливается»: линк поднялся, MAC/ARP переучились, поехало. Ищем, почему падает: плохой контакт (окисление, полуживой SFP), пережатый кабель, или оборудование клиента перезагружается (посмотри аптайм их роутера при следующем звонке).
2

Если порт стабилен, а связь всё равно замирает: ищем петлю

SW-LEN10# show logging | include MACFLAP %SW_MATM-4-MACFLAP_NOTIF: Host a45e.601f.220b in vlan 105 is flapping between port Gi0/5 and port Gi0/12
MAC «скачет» между двумя портами = один и тот же кадр приходит с двух сторон — классический симптом петли (кто-то соединил два порта патч-кордом или у клиента закольцевались свитчи). Петля устраивает шторм broadcast: сеть «замирает», пока STP или перегрузка не притушат. Замирания «волнами» + MACFLAP в логах = ищи петлю, а не кабель.
MACFLAP есть
смотри оба порта из сообщения: что за них воткнуто (show run int, LLDP), гаси лишний (shutdown) и объясняй клиенту, что нашлось. Включи на клиентских портах защиту: bpduguard + storm-control.
чисто
смотри выше: логи агрегации и PE (флапы аплинка? флап BGP? show ip bgp vpnv4 vrf X summary — колонка Up/Down маленькая = сессия недавно перезапускалась → «Last reset, due to…» скажет причину).
«Порт вашего подключения падал 4 раза за сутки — время совпадает с вашими замираниями. Заменили SFP-модуль и обжали кабель на кроссе; за последние 6 часов падений нет. Наблюдаем ещё сутки, заявку пока не закрываем» — плавающие заявки закрывай только после периода наблюдения!

Кейс 5. «После ваших работ у нас всё сломалось!»

«Ночью у вас были работы — с утра наш терминал оплаты не подключается к банку! Верните всё как было!» — злой директор магазина. Ночью действительно меняли коммутатор доступа.

Заявки «после работ» разбирают в первую очередь — тут репутация. Хорошая новость: круг подозреваемых узкий, всё, что менялось, известно. Типовые последствия замены железа: не перенесённый конфиг порта и застрявшие таблицы у соседей.

1

Сверяем конфиг порта с эталоном (до работ)

SW-LEN10-NEW# show run interface Gi0/5 interface GigabitEthernet0/5 switchport access vlan 1 ← а по документации должен быть VLAN 105! switchport mode access
после замены железа первым делом сверяют конфиг с бэкапом/документацией: «потерянная строчка» — типовой итог ночного переноса. Порт в неверном VLAN = клиент оказался «в чужом дворе»: линк up, лампочки горят, а трафик уходит в пустоту. Это объясняет картину «физика есть, сервиса нет» без всякой мистики.
2

Конфиг верный, а не работает: застрявший ARP на соседях

PE-LEN# show ip arp vrf ROMASHKA 10.77.1.2 Internet 10.77.1.2 187 0011.22aa.01ff ARPA Gi0/1.105 ← MAC СТАРОЙ железки (умерла 3 часа назад)! PE-LEN# clear ip arp vrf ROMASHKA 10.77.1.2 ← сбрасываем — роутер переспросит PE-LEN# show ip arp vrf ROMASHKA 10.77.1.2 Internet 10.77.1.2 0 a45e.601f.220b ARPA Gi0/1.105 ← новый MAC, связь ожила
роутер Cisco помнит ARP-записи до 4 часов (урок ARP). Если при работах менялось что-то с новым MAC на старом IP — соседи будут слать кадры «в прошлое», пока запись не протухнет. Отсюда мистика «само заработало к обеду». Инженер не ждёт обеда: clear ip arp — и проверка. То же касается MAC-таблиц промежуточных свитчей после переключения портов: clear mac address-table dynamic vlan 105.
Урок на будущее: в чек-лист любых работ включай пункт «сбросить ARP/MAC на смежных устройствах и дождаться первого клиентского трафика». Тогда таких звонков утром просто не будет.
«Да, причина была на нашей стороне: при ночной замене оборудования порт получил неверную настройку сети (и на маршрутизаторе оставалась устаревшая запись о старом устройстве). Исправили в 09:40, терминал работает — проверьте, пожалуйста. Приносим извинения за неудобства». Признавать свою ошибку с фактами и временем исправления — признак сильной поддержки.

Кейс 6. «Не работает только один сервис» — а виновата MTU

«Странная штука: почта ходит, сайты открываются, а корпоративный портал через ваш VPN висит на больших страницах. Маленькие открываются!»

«Маленькое проходит, большое висит» — почти дословный диагноз: проблема MTU в туннеле. Это любимая ловушка услуг с инкапсуляцией (IPVPN, L2VPN, GRE): заголовки туннеля съедают байты, и «толстые» пакеты перестают пролезать.

1

Подтверждаем гипотезу пингом с запретом фрагментации

PE-LEN# ping vrf ROMASHKA 10.9.1.5 size 1500 df-bit ..... Success rate is 0 percent ← 1500 с DF не пролезает! PE-LEN# ping vrf ROMASHKA 10.9.1.5 size 1400 df-bit !!!!! Success rate is 100 percent ← 1400 проходит → где-то по пути MTU < 1500
обычный пинг (маленький) ходит, поэтому связность «есть». Пинг размером 1500 с флагом DF (don't fragment — «не резать») повторяет судьбу больших пакетов данных. Подбором размера (1500 → 1400 → 1450…) находим реальный «просвет» пути — это объективное число для дальнейшего разбора: где-то в транспорте не подняли MTU под заголовки MPLS/туннеля.
1500 не лезет
ищем звено с малым MTU: show interfaces | include MTU по пути, поднимаем MTU на транспортных линках (магистраль оператора обычно живёт с MTU 9000+ именно поэтому). Временный обходной для клиента — TCP MSS clamping на стыке: ip tcp adjust-mss 1360.
1500 лезет
MTU ни при чём — копай сам сервис (порт, TLS, сервер), алгоритм №2 из шпаргалки по сетям.
«Нашли: на одном из участков после переключения не был увеличен размер кадра под туннель. Исправили, большие страницы портала открываются — проверьте со своей стороны».

Что общего во всех кейсах — запомни это

  1. 🪜
    Всегда лесенка снизу вверх: порт → MAC → ARP → маршруты → BGP → сквозной тест. Первый «нет» = слой проблемы.
  2. ↔️
    Проверяй «в обе стороны»: MAC клиента и MAC шлюза; маршрут на ближнем PE и на дальнем; пинг туда и оттуда. Направление, где картина ломается, показывает место аварии.
  3. 🔢
    Счётчики и логи вместо ощущений: CRC, PfxRcd, UPDOWN, MACFLAP, Rx Power — железо всё помнит, спроси его.
  4. 🗣️
    Слова клиента — тоже диагностика: «остальные филиалы работают», «маленькие страницы открываются», «после ваших работ» — каждый такой факт срезает полдерева.
  5. 📋
    Ответ клиенту — факты: что проверили, что увидели (числа!), что сделали, что просим проверить его. Никогда «у нас всё нормально».
Как тренироваться

Перечитай кейсы через неделю, закрывая разборы: смотри только на «звонок» и проговаривай вслух свои шаги — какая команда, почему, какие два исхода. Затем прогони тесты по сетям и плейбуки в уроках (ARP, VRF, BGP) — они дополняют эти кейсы деталями каждого слоя. Команды под рукой — шпаргалка Cisco/Juniper/Huawei.