Network Admin

Зачем на транках отключать DTP, даже если соседи свои DTP хорош, пока сеть маленькая и все помнят, что где включено. В реальной жизни это редкость. Достаточно один раз перепутать порт или скопировать конфиг - и access внезапно начинает вести себя как trunk. Обычно это выглядит так: линк up, VLAN’ы «вроде» работают, но где-то появляется лишний трафик, а потом выясняется, что порт сам договорился не о том режиме. Формально никто ничего не ломал. Проще сразу зафиксировать поведение порта и не надеяться на автодоговорённости. interface GigabitEthernet1/0/24 switchport mode trunk switchport trunk allowed vlan 10,20,30 switchport nonegotiate Здесь порт всегда trunk и только с нужными VLAN. Никаких сюрпризов от соседнего устройства. Для access-портов логика та же: interface GigabitEthernet1/0/10 switchport mode access switchport access vlan 20 switchport nonegotiate Даже если на другом конце кто-то случайно включит trunk, порт не «переобуется» сам. Проверка простая: show interfaces Gi1/0/24 switchport Меньше автоматики - меньше неочевидных проблем. В сетях это почти всегда плюс. N.A.

Как hardware offload ломает диагностику в tcpdump tcpdump показывает пакеты какими их видит ядро, а не какими они уходят в провод. Когда включён hardware offload, часть работы по формированию пакетов перекладывается на сетевую карту, и ядро никогда не видит финальные пакеты целиком. Самый частый случай: TSO (TCP Segmentation Offload). Ядро передаёт NIC один большой кусок данных, до 64KB, а карта сама нарезает его на пакеты по MSS перед отправкой. tcpdump перехватывает трафик до NIC и видит один гигантский пакет которого в реальности никогда не существовало в сети. Смотрим какие offload включены: ethtool -k eth0 | grep -E "tcp-segmentation|generic-segmentation|large-receive" Типичный вывод: tcp-segmentation-offload: on generic-segmentation-offload: on large-receive-offload: on Где это создаёт проблемы Видим в tcpdump пакеты по 30-40KB и думаем что MTU на линке огромный или что-то сломано с фрагментацией. На деле это GSO/TSO артефакты, в провод уходят нормальные пакеты по 1500 байт. LRO (Large Receive Offload) работает в обратную сторону: NIC склеивает входящие пакеты в один большой до передачи в ядро. tcpdump на входящем трафике снова видит гигантские пакеты которых не было в сети. Если диагностируешь проблему с MTU или фрагментацией, offload полностью искажает картину. Отключаем для честной диагностики: ethtool -K eth0 tso off gso off lro off gro off После диагностики включаем обратно: ethtool -K eth0 tso on gso on gro on Альтернатива: снимать трафик не с хостового интерфейса а с зеркального порта на коммутаторе, там пакеты уже после NIC и выглядят как в реальной сети. N.A.

Что такое GRE keepalive и почему туннель может считать себя живым, когда он мёртвый GRE туннель по умолчанию stateless: поднял интерфейс, настроил peer, и с точки зрения роутера туннель живой всегда, даже если на другом конце давно ничего нет. Маршруты через туннель стоят в таблице, трафик уходит в никуда, роутер об этом не знает. GRE keepalive решает это: один конец периодически шлёт пакеты через туннель, инкапсулированные так что другой конец возвращает их обратно как обычный IP-трафик. Если ответов нет N раз подряд, интерфейс туннеля уходит в down. Настройка на Cisco: interface Tunnel0 tunnel source Gi0/0 tunnel destination 203.0.113.1 keepalive 10 3 10 секунд интервал, 3 пропущенных пакета до down. Итого 30 секунд до детекции падения. Проверяем состояние: show interface Tunnel0 | include keepalive|line protocol debug tunnel keepalive Почему туннель считает себя живым когда мёртвый Keepalive работает асимметрично: настраивается и проверяется независимо на каждом конце. Если keepalive включён только на одной стороне, эта сторона детектирует падение, вторая нет. Хуже: keepalive пакет инкапсулируется в GRE и отправляется на destination. Там роутер декапсулирует его и видит пакет с destination равным своему tunnel source, то есть самому себе. Он отвечает через обычную таблицу маршрутизации, не через туннель обратно. Если на другом конце туннель упал но физический линк жив, keepalive пакет дойдёт до peer, тот ответит через физику, и отправитель решит что туннель живой. Хотя туннель как таковой не работает. Проверяем реальное состояние туннеля отдельно от keepalive: ping 10.0.0.2 source Tunnel0 traceroute 10.0.0.2 source Tunnel0 Если пинг через tunnel source проходит, туннель реально работает. Если нет, keepalive врёт. N.A.

Что такое RPF check и почему он дропает валидный трафик RPF (Reverse Path Forwarding) check это механизм защиты от spoofed-источников в multicast и unicast uRPF. Роутер получает пакет и проверяет: если бы я отправлял пакет обратно к источнику, ушёл бы он через тот же интерфейс на котором пришёл? Если нет, пакет дропается. Логика простая: легитимный трафик приходит с той стороны откуда роутер знает маршрут до источника. Если пакет пришёл с “неправильного” интерфейса, скорее всего адрес подделан. Где ломается на валидном трафике Асимметричный роутинг. Пакет от источника 10.0.0.1 пришёл на интерфейс eth1, но маршрут до 10.0.0.1 в таблице указывает через eth0. RPF check проваливается, пакет дропается, хотя трафик абсолютно легитимный. Это классическая ситуация при ECMP, нескольких аплинках или когда входящий и исходящий трафик идут разными путями. Проверяем включён ли uRPF на интерфейсе: show ip interface Gi0/0 | include verify Смотрим счётчики дропов от RPF: show ip traffic | include unicast RPF show cef interface Gi0/0 | include RPF На Linux: cat /proc/net/stat/rt_cache | grep rpf Два режима uRPF ⏺Strict mode: маршрут до источника должен указывать именно на интерфейс где пришёл пакет. Ломается при асимметричном роутинге. ⏺Loose mode: маршрут до источника должен просто существовать в таблице, через любой интерфейс. Защищает от пакетов с несуществующими источниками, но пропускает асимметричный трафик. На Cisco переключаем в loose: interface Gi0/0 ip verify unicast source reachable-via any Strict mode: interface Gi0/0 ip verify unicast source reachable-via rx На Linux: sysctl -w net.ipv4.conf.eth0.rp_filter=1 1 это strict, 2 это loose, 0 отключён. N.A.

Проверка VLAN-тегов в сети Когда трафик не проходит через свичи или маршрутизаторы, одна из частых причин — ошибка в настройке VLAN. Пакеты могут теряться, если: ⏺порт настроен как access, а мы отправляем трафик с тегами; ⏺тег VLAN не совпадает с конфигурацией на другом конце; ⏺свич отбрасывает кадры из «неразрешённого» VLAN. Смотрим теги через tcpdump sudo tcpdump -i eth0 -nn -e vlan • -e — выводит Ethernet-заголовок; • vlan — фильтрует кадры с тегами 802.1Q. Пример: 12:30:45.123456 ethertype 802.1Q (0x8100), VLAN 100, IP 192.168.10.2 > 192.168.10.1: ICMP echo request Здесь видно, что кадр принадлежит VLAN 100. Проверка конкретного VLAN sudo tcpdump -i eth0 vlan 200 Покажет только кадры из VLAN 200. Полезно, чтобы убедиться, что нужный VLAN действительно идёт по линку. Тест с arping Можно проверить связность внутри VLAN: sudo arping -I eth0.100 192.168.100.1 Здесь eth0.100 — подинтерфейс, созданный для VLAN 100. Если ответ есть, значит VLAN на этом пути работает. Создание VLAN-интерфейса в Linux sudo ip link add link eth0 name eth0.100 type vlan id 100 sudo ip addr add 192.168.100.10/24 dev eth0.100 sudo ip link set eth0.100 up Теперь можно тестировать трафик напрямую по этому VLAN. N.A.

Как IGMP snooping решает проблему multicast-флуда и где ломается Без IGMP snooping коммутатор не знает кто хочет получать multicast-трафик. Multicast MAC не изучается через обычный ARP, поэтому коммутатор обращается с ним как с broadcast: флудит на все порты. В сети с видеостримингом или IPTV это убивает полосу на портах где этот трафик никому не нужен. IGMP snooping решает это пассивно: коммутатор подслушивает IGMP-сообщения между хостами и роутером и строит таблицу кто на какую группу подписан. Multicast уходит только на порты где есть реальные получатели. Смотрим таблицу IGMP snooping на Cisco: show ip igmp snooping groups show ip igmp snooping Где ломается ⏺Первая проблема: querier. IGMP snooping требует чтобы кто-то периодически спрашивал хосты “вы ещё в группе?”. Обычно это роутер. Если роутера нет в сегменте или он не шлёт IGMP queries, коммутатор не получает ответов, записи в таблице устаревают и трафик снова начинает флудить. Включаем IGMP querier на коммутаторе если роутера нет: ip igmp snooping querier ip igmp snooping querier address 192.168.1.1 ⏺Вторая проблема: неизвестный multicast. Если группа не в таблице snooping, коммутатор флудит её на все порты по умолчанию. На коммутаторах где это поведение нежелательно: no ip igmp snooping flood-unknown-multicast ⏺Третья проблема: статические записи против динамических. Если хост не шлёт IGMP join (некоторые приложения не умеют), запись в таблице не появится и трафик не дойдёт. Добавляем вручную: ip igmp snooping vlan 10 static 239.1.1.1 interface Gi0/5 N.A.

Как устроен транзитный BGP и чем отличается от пиринга Два способа получить связность в интернете: купить транзит или договориться о пиринге. Внешне похоже, технически и финансово принципиально разные вещи. Транзит Платишь провайдеру за то что он несёт твой трафик куда угодно в интернете. Провайдер анонсирует тебе full routing table, десятки тысяч префиксов, ты через него достигаешь любой AS. Он в свою очередь анонсирует твои префиксы своим апстримам и пирам. Отношение клиент-провайдер в BGP community обозначается как customer cone. Провайдер принимает маршруты от тебя и распространяет их дальше, ты платишь за каждый мегабит. router bgp 65001 neighbor 198.51.100.1 remote-as 1299 neighbor 198.51.100.1 description Telia-Transit neighbor 198.51.100.1 route-map TRANSIT-IN in neighbor 198.51.100.1 route-map TRANSIT-OUT out Пиринг Два оператора договариваются обмениваться трафиком бесплатно, но только своим собственным трафиком и трафиком своих клиентов. Ты не несёшь через пира трафик третьих AS, он не несёт через тебя. Пиринг имеет смысл когда между двумя сетями достаточно взаимного трафика чтобы окупить договорённость. Крупные CDN и контент-провайдеры пирятся агрессивно именно поэтому: им выгодно отдавать трафик напрямую, минуя транзит. neighbor 203.0.113.1 route-map PEER-IN in neighbor 203.0.113.1 route-map PEER-OUT out route-map PEER-OUT permit 10 match ip address prefix-list OWN-PREFIXES PEER-OUT анонсирует только собственные префиксы, не транзитные маршруты клиентов или других пиров. Технически чем отличается У транзитного провайдера LOCAL_PREF на маршруты от клиентов обычно выше чем от пиров, выше чем от апстримов. Это стандартная политика: клиентский трафик приоритетнее всего, потому что клиент платит. Маршруты полученные от пира не анонсируются другим пирам или апстримам, только клиентам вниз. Это и есть техническая граница пиринга. route-map TRANSIT-IN permit 10 set local-preference 100 route-map PEER-IN permit 10 set local-preference 150 route-map CUSTOMER-IN permit 10 set local-preference 200 ⚡️ Пиринг не всегда бесплатный. Paid peering это когда один из участников платит другому за обмен трафиком, обычно когда трафик сильно асимметричный. Netflix платит за пиринг с крупными ISP именно потому что трафик идёт почти только в одну сторону. N.A.

TCP Nagle algorithm: когда включён мешает и когда отключение ломает Nagle придумали в 1984 чтобы не засорять сеть мелкими пакетами. Алгоритм простой: не отправляй новый пакет пока предыдущий не подтверждён, если данных меньше чем MSS. Мелкие записи буферизуются и отправляются одним куском. На медленных линках 80-х это спасало. На современных сетях чаще мешает. ⏺Где Nagle создаёт проблемы Интерактивные протоколы где важна задержка каждого пакета. SSH, Telnet, remote desktop, любой протокол запрос-ответ где клиент шлёт маленький запрос и ждёт ответа. Nagle держит пакет в буфере ожидая подтверждения предыдущего, задержка растёт. Классический симптом: команды в SSH ощутимо залипают особенно на каналах с высоким RTT. Проверяем включён ли Nagle на сокете через ss: ss -tin dst <IP> | grep -i nagle Отключается через TCP_NODELAY на уровне приложения: int flag = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag)); Или глобально через sysctl хотя это грубо: sysctl -w net.ipv4.tcp_low_latency=1 ⏺Когда отключение ломает Высокопроизводительные системы где приложение шлёт много мелких write(). Без Nagle каждый write() становится отдельным пакетом, количество пакетов растёт в разы, нагрузка на сеть и CPU увеличивается. Базы данных и файловые серверы обычно держат Nagle включённым именно поэтому. ⏺Взаимодействие с delayed ACK Самая неприятная комбинация: Nagle на отправителе плюс delayed ACK на получателе. Отправитель ждёт ACK перед отправкой следующего пакета, получатель откладывает ACK до 200мс надеясь что будет что пигибэкнуть. Оба ждут друг друга, задержка 200мс гарантирована. tcpdump -i eth0 -nn host <IP> | grep -E "ACK|PSH" Если видишь паузы ровно 200мс между пакетами, это оно. ⚡️ Правильное решение не отключать Nagle глобально, а делать это точечно на конкретных сокетах где важна латентность. Глобальное отключение на сервере с mixed workload ухудшит производительность для одних приложений пока улучшает для других. N.A.

Коммутатор начал флапать порты: где искать Флап это когда порт циклически уходит в down и возвращается в up. Для STP каждый флап это topology change, пересчёт, временная потеря связности. На загруженной сети даже один флапающий порт создаёт заметные проблемы. Смотрим счётчики переходов состояния на всех портах: show interfaces | include line protocol|changes show interfaces counters errors Порт с аномально высоким Link-state change count это он. На Linux если коммутатор не Cisco: ip monitor link journalctl -k | grep "NIC Link" ip monitor link показывает события в реальном времени, journalctl покажет историю флапов с таймстампами. Физические причины Самые частые: плохой кабель, разболтанный коннектор, неисправный SFP. Проверяем уровень сигнала на оптике: show interfaces Gi0/1 transceiver ethtool -m eth0 Смотрим на rx_power, если значение плавает или ниже допустимого порога для данного типа модуля, проблема в оптике или трансивере. Программные причины Если физика чистая, смотрим на STP и BPDU: show spanning-tree detail | include changes debug spanning-tree events Частые topology change от конкретного порта могут быть вызваны устройством которое периодически уходит в сон, например IP-телефон или ноутбук. Проверяем autonegotiation, несогласованный duplex тоже вызывает флапы: show interfaces Gi0/1 | include duplex,speed ⚡️Если флап идёт строго по расписанию, например каждые несколько часов, смотри на spanning-tree hello timer и max-age. Иногда это не физика, а STP решает что сосед умер из-за потери BPDU на перегруженном канале. N.A.

Как найти петлю в L2 без доступа к коммутаторам Петля в L2 без STP это широковещательный шторм: broadcast-фреймы начинают множиться, загружают все порты, сеть деградирует до полной недоступности за секунды. Диагностировать нужно быстро, и часто без доступа к коммутаторам. Первый признак: резкий рост broadcast-трафика на интерфейсе. Смотрим счётчики прямо сейчас: watch -n 1 'ip -s link show eth0 | grep -A2 RX' Если счётчик пакетов растёт на тысячи в секунду при минимальной нагрузке, петля активна. Ловим broadcast-шторм живым трафиком: tcpdump -i eth0 -n broadcast Если один и тот же фрейм появляется несколько раз подряд с одинаковым содержимым, это он. Петля гоняет один фрейм по кругу, tcpdump видит каждый проход. Смотрим источник шторма по MAC: tcpdump -i eth0 -n -e broadcast | awk '{print $2}' | sort | uniq -c | sort -rn | head -10 MAC который встречается аномально часто, скорее всего источник или точка где петля замыкается. Ищем дублирующиеся фреймы по содержимому: tcpdump -i eth0 -w /tmp/capture.pcap tcpdump -r /tmp/capture.pcap -n | awk '{print $NF}' | sort | uniq -c | sort -rn | head Локализация физически Если есть возможность ходить по офису, отключаем патч-корды по одному и смотрим когда шторм прекратится. Момент когда счётчики перестали расти, последний отключённый кабель и есть замыкание. watch -n 1 'ip -s link show eth0 | grep -A1 RX' ⚡️Если STP включён но петля всё равно есть, скорее всего где-то BPDU Guard сработал и порт ушёл в err-disabled, но петля успела образоваться через другой путь. Проверяй err-disabled порты если есть хоть какой-то доступ к одному коммутатору: show interfaces status err-disabled. N.A.