🧭 Как вычислить некорректную обработку ECN

Разберём типовую ситуацию: приложение «плавает» по скорости, задержки нормальные, потерь нет, а throughput падает.

Часто причина, что ECN по пути работает неправильно: биты стираются, игнорируются или не ставится CE при перегрузке.

ECN (Explicit Congestion Notification) - это механизм сигнализации о перегрузке без дропа.

Если одно устройство ломает поле DSCP/ECN, TCP начинает откатывать скорость так, будто сеть нестабильна.

Чтобы ECN работал корректно, нужно:

⏺Не перетирать DSCP/ECN политиками QoS
⏺Разрешить маркировку CE при перегрузке
⏺Исключить дроп пакетов с ECT0/ECT1 middlebox’ами
⏺Убедиться, что железо/ASIC поддерживает ECN

Если один элемент цепочки «портит» поле ToS — ECN фактически отключён.

Практика на Cisco:

1️⃣Проверяем, стирает ли QoS биты:

show policy-map interface Gi1/0/1

Если видим set dscp … → ECN скорее всего теряется.

2️⃣Проверяем статистику ECN/маркировки:

show policy-map interface Gi1/0/1 | i ECN|marked

CE-marking должен расти при нагрузке. Ноль - значит CE не ставится.

3️⃣Проверяем реальные пакеты:

monitor capture ... 
tcpdump ip[1] & 0x03 != 0

ECT0/ECT1/CE должны присутствовать. Если исчезают — кто-то чистит ToS.

4️⃣Проверяем аппаратную поддержку:

show platform hardware qfp active statistics drop | i ECN

Если есть дропы ECN - проблема внутри платформы или ASIC.

N.A.

Ловим «ломаный» QoS по DSCP

Бывает так: сеть чистая, задержки нормальные, потерь нет - а приложения вдруг притормаживают.

Часто проблема не в каналах, а в том, что DSCP меняется там, где никто не планировал.

В итоге QoS работает “криво”, а трафик оказывается в неверном классе.

QoS по DSCP держится на трёх вещах:

⏺Правильный trust на портах (где мы доверяем меткам)
⏺Классификация, соответствующая реальному трафику
⏺Политики, которые не перетирают DSCP по пути

Если одно звено даёт сбой - весь QoS превращается в best-effort.

Проверяем trust на интерфейсе:

show mls qos interface Gi1/0/1

Если trust отсутствует → DSCP переписывается на входе.

Смотрим, что делает политика QoS:

show policy-map interface Gi1/0/1

Нежелательный сигнал: set dscp default или любое фиксированное значение.

Проверяем, куда реально попадает трафик:

show policy-map interface Gi1/0/1 | i match|packets

Если приложение идёт в class-default → классификация сломана.

Сверяем DSCP на входе/выходе:

monitor capture ...

Если метка меняется по пути - виновник найден.

N.A.

Как найти порты с неправильными Storm Control-лимитами

Иногда Storm Control включён, но лимиты выставлены слишком жёстко - и коммутатор начинает резать обычный трафик как «шторм».

Типичный признак - порты рандомно падают в suppression, появляются жалобы на «плавающий» доступ, особенно в сетях с VoIP, камерой или IoT.

Важно понять две вещи:
⏺где включён Storm Control,
⏺и не слишком ли низкий порог стоит для конкретного трафика.

1️⃣Проверяем текущее состояние лимитов:

show storm-control

Если по порту suppression счётчик растёт — порог занижен.

2️⃣Смотрим конфигурацию интерфейса:

show running-config interface Gi1/0/10 | include storm

Обрати внимание на kbit/s или процент - именно они определяют, как быстро порт будет уходить в ограничение.

3️⃣Проверяем, были ли события suppression:

show storm-control interface Gi1/0/10

Если suppression last occurred недавно - лимит стоит пересматривать.

4️⃣Через SNMP можно вытянуть статистику по всем портам:

snmpwalk -v3 -u user -l authPriv -a SHA -A authpass -x AES -X privpass <switch> .1.3.6.1.4.1.9.9.187

OID Cisco Storm-Control вернёт counters broadcast/multicast/unicast для каждого порта, что удобно для массового анализа.

N.A.

🧭 Как вычислить сломанную политику QoS с Shaping и Token-Bucket

Иногда трафик вроде классифицирован правильно, но на пиках появляются задержки или пакеты «теряются» без видимых drop’ов.

Причина часто в неправильно настроенном shaping или drift token-bucket - hardware ограничивает throughput неравномерно, либо буфер переполняется.

Важно понимать, что QoS работает только если shaping и token-bucket настроены согласованно по всей цепочке.

1️⃣Проверяем статистику очередей:

show policy-map interface Gi1/0/1

Ищем drops, match, transmitted packets и rate-limits.

2️⃣Смотрим token-bucket counters:

show queueing interface Gi1/0/1

Если токены расходуются быстрее, чем refill → пиковый трафик режется.

3️⃣Сравниваем с hardware counters:

show platform hardware qfp active statistics drop

Если есть drop на ASIC — shaping реально ограничивает throughput, возможно, неправильно выставлен burst.

4️⃣Анализируем traffic flow:

monitor capture ...

Сравниваем пиковый traffic с лимитами QoS. Если падает на microburst — лимит слишком жёсткий или token-bucket «дрейфует».

N.A.

Как найти «утекающий» DHCP‑трафик

Когда клиенты жалуются, что «IP не выдаётся», причина часто не в сервере, а в том, что DHCP broadcast где‑то теряется по пути. Это трудно заметить, потому что обычный трафик при этом работает.

Вот короткая схема проверки:

1️⃣Проверяем Snooping
Если включён DHCP Snooping, он может блокировать сервер или relay на недоверенном порту.

show ip dhcp snooping
show ip dhcp snooping binding

Если сервер сидит на untrusted‑порту - DISCOVER не проходит.

2️⃣Ищем зону, где режется broadcast
Storm Control, ACL или неправильные VLAN могут «убивать» DHCP‑кадры.

show storm-control
show vlan brief
show access-lists

Если на порту агрессивный storm‑control или ACL с deny udp 67/68 - пакеты не доходят.

3️⃣Проверяем Relay (IP Helper): Если используется relay, проверяем, что он настроен на правильный сервер.

show running-config interface <uplink>

Если ip helper указывает на старый/неправильный адрес - OFFER/ACK «теряются».

4️⃣Смотрим счётчики на интерфейсах: На некоторых портах могут быть drops именно по L2 broadcast.

show interface Gi1/0/15 counters

Если broadcast-drops растут - DHCP Discover там «тонет».

5️⃣Тестируем вручную
На Linux:

tcpdump -ni eth0 port 67 or port 68

Если DISCOVER уходит, а OFFER не приходит - проблема выше по цепочке.

N.A.

Как вычислить «молчаливый» ARP-флуд в сети

Даже если обычный трафик нормальный, сеть может испытывать проблемы из-за частого повторного ARP-запроса, который почти не виден в интерфейсных counters, но забивает CPU коммутатора или broadcast-домен.

Особенно важно для IoT, камер и массовых DHCP-сетей.

Проверим 👇

1️⃣Счётчики ARP на коммутаторе

show ip arp summary
show interfaces Gi1/0/10 counters

Если количество ARP-запросов растёт неравномерно - возможен флуд.

2️⃣Логи и события ARP

show logging | include ARP

Ищем «arp request rate» или warnings от CPU.

3️⃣Сетевой capture
На Linux или коммутаторе с capture:

tcpdump -nn -i eth0 arp

Смотрим частоту ARP-запросов. Если сотни/тысячи в секунду - это перегрузка.

4️⃣Проверяем защиту
На Cisco можно включить ARP Inspection/Snooping, чтобы ограничить flood:

show ip arp inspection



N.A.

Ping внешнего IP: что происходит с ICMP-пакетом

На первый взгляд ping 8.8.8.8 прост, но под капотом - целый путь через стек и сеть.

Шаги прохождения пакета:
1️⃣Формирование пакета
Ping создаёт ICMP Echo Request через RAW-сокет. Источник - твой IP, цель - 8.8.8.8.

2️⃣Локальный стек
Пакет проходит через iptables/netfilter. Если политика DROP - даже локально он не уйдёт.

3️⃣Маршрутизация
Ядро выбирает интерфейс и next-hop для внешнего IP. NAT может поменять исходный адрес.

4️⃣Физический путь
Пакет выходит на интерфейс, проходит коммутаторы и маршрутизаторы. TTL уменьшается на каждом hop.

5️⃣Удалённый узел
Echo Reply создаётся на хосте и идёт обратно по пути, определённому его routing table.

6️⃣Возврат и RTT
Пакет возвращается, ping фиксирует RTT и выводит результат.

Что может сломать ping:

Пинг может не работать, если на локальной машине или по пути к цели блокируют ICMP пакеты (firewall/ACL), отсутствует маршрут к внешнему IP, некорректно настроен NAT, или TTL пакета слишком мал, чтобы достичь удалённого узла.

Полезные команды:

traceroute 8.8.8.8
tcpdump -i eth0 icmp
iptables -L -v -n
ip route get 8.8.8.8

N.A.

Как проверить, что BGP-маршрут анонсируется, но не используется

Ситуация классическая: префикс в BGP есть, а трафик упорно идёт другим путём.

Почти всегда причина - не в самом анонсе, а в выборе best path или в том, как маршрут попал (или не попал) в RIB/FIB.

1️⃣Проверяем, что маршрут вообще пришёл по BGP

Сначала убеждаемся, что апстрим реально его отдал.

Cisco:

show ip bgp <prefix>

Важно смотреть:
• есть ли несколько путей
• какой помечен как *> (best)

Если маршрута нет, дальше можно не копать.

2️⃣Сравниваем BGP vs routing table

Маршрут может быть в BGP, но не установлен в основную таблицу.

show ip route <prefix>

Если вместо BGP стоит: static, OSPF или connected, то BGP просто проиграл по административной дистанции.

Смотрим атрибуты best path

Часто маршрут есть, но проигрывает по атрибутам.

show ip bgp <prefix>

Обращаем внимание на:
⏺Local Preference (самая частая причина)
⏺AS_PATH (длиннее — хуже)
⏺MED
⏺Weight (Cisco)

Даже разница в LocalPref 100 vs 200 полностью меняет путь.

4️⃣Проверяем policy: route-map / filter

Маршрут может быть принят, но «искажён» политикой.

show run | section route-map
show ip bgp neighbors <IP> received-routes

Иногда route-map не режет маршрут, но меняет LocalPref или MED.

5️⃣Проверяем CEF / FIB

Бывает, BGP и RIB ок, а в forwarding таблице другое.

show ip cef <prefix>

Если next-hop не тот, что ожидается — проблема на этапе установки в FIB.

N.A.

📂Как правильно документировать сеть, чтобы не потерять конфиги

Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.

1️⃣Сбор данных
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:

ip addr show          # список интерфейсов
ip route show         # таблица маршрутов
vtysh -c "show running-config"  # конфиги роутеров
show vlan brief       # VLAN на коммутаторах

2️⃣Структурирование: Систематизируем данные: топология, IP-план, протоколы, ACL/Firewall.
Пример таблицы IP:

Устройство | Интерфейс | IP           | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1         | eth0      | 10.0.1.1/24  | 10   | WAN
sw1        | vlan10    | 10.0.1.2/24  | 10   | серверная зона
sw2        | vlan20    | 10.0.2.1/24  | 20   | офисная зона
server1    | eth1      | 10.0.1.10/24 | 10   | база данных
server2    | eth1      | 10.0.1.11/24 | 10   | веб-сервер

3️⃣Version control: Сохраняем конфиги в Git. Каждый коммит с комментарием: что и зачем изменилось.

git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"

4️⃣Визуализация топологии: Diagram-as-code (Mermaid/Graphviz) или инструменты типа NetBox/Draw.io.
Пример Mermaid:

graph TD
    R1 --> SW1
    SW1 --> Server1
    SW1 --> Server2

5️⃣Автоматизация и backup: Скрипты для снятия конфигов и их сохранения в репозиторий или на NAS. Проверка актуальности backup. ✅

Полезные команды для контроля

git log --oneline --graph   # история изменений
diff old_config new_config  # что изменилось
ping 10.0.1.2              # проверить доступность после изменений

N.A.

ICMP: тестируем не только ping

На первый взгляд ping кажется простой командой, но ICMP - полноценный инструмент для диагностики сети и анализа маршрутов.

Что можно делать:
⏺Traceroute через ICMP помогает локализовать узкие места: задержки, потерю пакетов и переполненные маршрутизаторы.
⏺Даже если ping запрещён firewall, ICMP показывает, какие пакеты проходят, а какие блокируются.
⏺Анализ ICMP Time Exceeded и Destination Unreachable помогает понять поведение маршрутизаторов и Path MTU.

Как проверить:

# Traceroute через ICMP
traceroute -I 8.8.8.8

# Ping с разным TTL
ping -t 10 -c 5 8.8.8.8

# Проверка Path MTU
ping -M do -s 1472 8.8.8.8

Как можно сломать:
➖Firewall блокирует все ICMP → даже ping до localhost не покажет проблем маршрутизации.
➖MTU mismatches → пакеты теряются, но стандартный ping не всегда это показывает.
➖Неправильная маршрутизация → ICMP показывает только, что узел недоступен, но не где именно.

N.A.

BFD vs OAM: мониторинг линка

✅ BFD (Bidirectional Forwarding Detection) и OAM (Operations, Administration, Maintenance) выглядят похоже, оба следят за состоянием канала, но работают по разному и для разных целей.

BFD мгновенно реагирует на падение соседнего узла. 

Если OSPF или BGP видят потерю маршрута за миллисекунды, трафик сразу переключается на резерв. Это незаменимо, когда важна скорость реакции сети и минимальные простои.

⏺OAM проверяет качество канала глубже. Он измеряет задержки, jitter, потери пакетов и целостность цепочки, не вмешиваясь в маршрутизацию.

OAM полезен для Ethernet, MPLS и сервисных линков, когда важно понять, почему соединение работает медленно или нестабильно.

Примеры. BFD на FRR:

bfd
peer 10.0.0.2
  minimum-interval 300
  detection-multiplier 3

OAM на Ethernet:

ethtool -S eth0

Суть в том, что BFD следит за «живостью» маршрутов, мгновенно подсказывая, что линк упал, а OAM позволяет увидеть качество канала, измерить реальные параметры передачи и понять, где появляются задержки или потери.

N.A.

Да, я богат и я этого не скрываю 😎

N.A.

Почему сеть сложнее приложений?

Приложение можно уронить и поднять обратно. В худшем случае - откатить релиз или перезапустить контейнер. 

Обычно страдает один сервис, и то временно.

✋С сетью так не получается. Она общая для всех. Один неудачный маршрут, ACL или изменение MTU - и сразу начинают сыпаться десятки сервисов, которые между собой вообще никак не связаны.

⏺Вот обычный пример: добавили «временное» firewall-правило или поменяли порядок ACL. Вроде бы для одного сервиса. Через час перестаёт работать авторизация, потом отваливается мониторинг, а позже выясняется, что часть трафика пошла асимметрично и stateful firewall начал резать ответы.

⏺Или другой кейс - поменяли MTU на одном сегменте. Ping ходит, интерфейсы up, но крупные TCP-сессии рвутся, VPN начинает вести себя странно, а приложение выглядит «нестабильным», хотя с ним ничего не делали.

Поэтому сеть не любит эксперименты в продакшене. Здесь нельзя просто «задеплоить и посмотреть». 

Любое изменение требует понимания, куда реально пойдёт трафик, кто от этого зависит и как быстро вернуть всё назад, если что-то пошло не так.

N.A.

Когда L2-ошибка страшнее L3

L3 ломается громко и понятно. Нет маршрута - трафик не идёт. traceroute обрывается, логика очевидна: ищем, где потерялся next hop.

L2 ведёт себя иначе. Ошибка может существовать долго и выглядеть как «плавающая» проблема. 

Петля в сети, флапающий порт или неправильный STP priority не отключают сервис сразу, а медленно разрушают всё вокруг.

⏺Классический пример - L2-петля. Один лишний кабель или неправильно настроенный trunk, STP не сработал или был выключен «временно». В результате бродкаст и unknown unicast начинают размножаться, CPU на коммутаторах улетает в 100%, ARP-таблицы постоянно меняются. Сервисы вроде бы живы, но соединения рвутся, задержки скачут, пользователи жалуются на «рандом».

⏺Другой кейс - MAC-flapping. Один и тот же MAC адрес прыгает между портами. Для L3 всё выглядит нормально, IP есть, маршруты на месте. А на самом деле кадры ходят туда-сюда, сессии TCP рвутся, а причина скрыта глубоко на втором уровне.

Ещё хуже, когда проблема затрагивает control-plane. STP пересчитывается слишком часто, порты то блокируются, то открываются, и сеть сама себя дестабилизирует. Это выглядит как деградация приложений, хотя корень проблемы — обычный L2.

🔥Поэтому L2-ошибки опасны не масштабом, а коварством. Они не выключают сеть сразу, а превращают её в нестабильную среду, где всё вроде бы работает, но ничего не работает надёжно.

N.A.

Зачем ограничивать MAC-адреса на порту, если есть VLAN

VLAN изолирует трафик, но никак не ограничивает количество устройств за портом.

Для коммутатора access-порт по умолчанию готов принять десятки MAC-адресов, если они в одном VLAN.

⏺Типовой сценарий - под столом появляется неуправляемый свитч. Всё продолжает «работать», но на один порт внезапно приходит много MAC-адресов. CAM-таблица начинает активно обновляться, часть трафика уходит в unknown unicast, появляются задержки и странные обрывы сессий.

Port security нужен, чтобы зафиксировать ожидания от порта: здесь должно быть одно устройство или, максимум, телефон + ПК. Всё остальное — не штатная ситуация.

Как это выглядит в конфигурации (Cisco-подобный синтаксис):

interface GigabitEthernet1/0/10
 switchport mode access
 switchport access vlan 20
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky

Здесь порт примет максимум два MAC-адреса и запомнит их автоматически. При появлении третьего - трафик будет резаться и логироваться, без мгновенного падения порта.

Если нужен жёсткий вариант:

switchport port-security violation shutdown

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

Проверка состояния:

show port-security interface Gi1/0/10
show mac address-table interface Gi1/0/10

N.A.

Почему ACL лучше писать длиннее, но понятнее

Короткий ACL выглядит красиво и экономит строки, но на практике это почти всегда ловушка. 

Одно правило с кучей wildcard вроде «разрешить всё, кроме…» потом трудно проверить. Часто думаешь, что всё нормально, а в реальности блокируются нужные сервисы или остаются дыры.

⏺Длинный ACL читается как карта: каждое правило понятно, есть комментарий, сразу видно, кто и что может. Менять его проще, отлаживать проще, а шанс случайно сломать сеть падает к нулю.

Пример на Cisco:

! Короткое ACL — вроде работает, но что именно разрешено?
access-list 101 permit tcp any any eq 80
access-list 101 permit tcp any any eq 443
access-list 101 permit udp any any range 5000 6000

! Длинное ACL — сразу понятно, для чего каждая строка
! Веб-трафик
access-list 101 permit tcp any any eq 80 comment Web HTTP
access-list 101 permit tcp any any eq 443 comment Web HTTPS
! UDP для приложений
access-list 101 permit udp any any range 5000 6000 comment App UDP

Теперь ACL сам объясняет, что делает. Добавлять новые сервисы или проверять старые проще, а коллега через месяц сразу поймёт, что и зачем разрешено.

N.A.

Почему лучше явно задавать STP root, а не оставлять «по умолчанию»

Когда STP root не задан, сеть выбирает его сама - по наименьшему BID. Пока топология не меняется, всё выглядит стабильно и «работает». Проблемы начинаются в момент изменений.

Типичная ситуация: заменили коммутатор, обновили прошивку или просто перезагрузили часть сети.

⏺У нового устройства оказался ниже BID - и root bridge тихо переехал. STP пересчитался, часть портов ушла в blocking, а трафик пошёл по менее удачному пути.

Снаружи это выглядит как деградация сервисов. Увеличились задержки, появились таймауты, где-то просел throughput. Маршруты есть, линков хватает, но сеть стала «чуть медленнее», и искать начинают в приложениях.

Явно заданный root фиксирует логику сети. Вы заранее решаете, где должна сходиться L2-топология и через какие устройства идти основной трафик. Любые изменения в сети тогда либо не влияют на STP, либо сразу заметны.

Пример на Cisco:

spanning-tree vlan 10,20 priority 4096

Или проще:

spanning-tree vlan 10,20 root primary

Проверка:

show spanning-tree vlan 10

N.A.