Последние посты
Network Admin
22 сент., 10:05
Loop Guard vs Root Guard: в чем разницаОба механизма относятся к STP, но защищают от совершенно разных аварий.Loop Guard нужен, когда порт перестал получать BPDU, хотя раньше получал их.Например, между двумя коммутаторами есть STP-линк:SW1 ───────── SW2 BPDU →SW2 должен получать BPDU и держать порт в blocking/discarding. Если BPDU внезапно перестали доходить из-за односторонней проблемы линка, SW2 может решить, что путь свободен, и перевести порт в forwarding.Получается L2-петля. Loop Guard обнаруживает потерю ожидаемых BPDU и не дает порту перейти в forwarding:BPDU пропали ↓ Loop Guard ↓
Network Admin
21 сент., 09:33
MAB: когда MAC заменяет 802.1X802.1X предполагает, что устройство умеет пройти аутентификацию через EAP.Но что делать с устройством вроде принтера, IP-телефона или камеры, где полноценного 802.1X может не быть?Для этого используют MAB - MAC Authentication Bypass.Схема выглядит примерно так:Устройство │ │ MAC ↓ Access Switch │ │ RADIUS ↓ AAA
Network Admin
18 сент., 09:04
RIB vs FIB divergence в high-end роутерахВ routing table (RIB) маршрут отображается корректно: next-hop есть, метрики нормальные, протокол сходится.Но data-plane не использует этот маршрут - пакеты не уходят, и кажется, что сеть «работает частично».Причины чаще всего связаны с ограничениями ASIC, рекурсивным разрешением next-hop или проблемами с adjacency.Для диагностики сначала проверяем, как маршрут запрограммирован в FIB/CEF:show ip cef <prefix> detailЕсли next-hop не разрешается через adjacency, пакеты не будут пересылаться:show adjacency detail show ip arp <next-hop>На high-end платформах полезно проверить hardware table и возможные дропы:show platform hardware qfp active feature cef drop
Network Admin
17 сент., 09:02
gNMI vs SNMP pollingПредставим сеть из сотни коммутаторов. Нужно следить за загрузкой интерфейсов.Классический вариант - SNMP polling:NMS ──→ switch "дай counters"NMS ──→ switch "дай counters"NMS ──→ switch "дай counters"Сервер сам регулярно опрашивает устройства.Например, раз в 60 секунд.Проблема появляется, когда нужны более частые данные.
Network Admin
16 сент., 09:00
SRv6 uSID: зачем нужны короткие SIDВ обычном SRv6 маршрут можно описать последовательностью Segment ID:R1 → R5 → R8 → R12Каждый SID занимает IPv6-адрес, поэтому длинный путь быстро раздувает SRH.Например:SID 1 SID 2 SID 3 SID 4 SID 5 ...Чем больше сегментов, тем больше служебных данных приходится тащить вместе с пакетом. uSID (micro-SID) решает эту проблему другим способом.
Network Admin
15 сент., 11:53
TI-LFA: fast reroute без SPFОбычный IGP при отказе линка должен сначала понять, что топология изменилась, затем пересчитать SPF и установить новый маршрут.Это занимает время. TI-LFA работает иначе: резервный путь вычисляется заранее.Допустим, основной путь:R1 ── R2 ── R4 │ X │ R3 ── R4R1 знает, что если линк R2-R4 пропадёт, трафик можно отправить через R3.При отказе R2 не ждёт полноценного SPF для восстановления forwarding. Он использует заранее рассчитанный backup path. В SR-сетях этот путь можно выразить через Segment List:
Network Admin
14 сент., 13:28
show spanning-tree: почему STP блокирует портВ Cisco-подобных коммутаторах команда: show spanning-tree показывает не просто «какой порт заблокирован». Она позволяет понять, почему именно этот порт проиграл выбор пути.Например:VLAN 10 Root ID Priority 24586 Address 0011.2233.4455Interface Role Sts Cost Gi1/0/1 Root FWD 4 Gi1/0/2 Altn BLK 4На первый взгляд кажется: Gi1/0/2 - резервный линк, всё нормально.Но STP выбирает не «основной и резервный кабель». Каждый switch сравнивает BPDU и стоимость пути до Root Bridge.
Network Admin
11 сент., 09:10
RD и RT - почему это не одно и то жеВ MPLS L3VPN есть две сущности, которые часто смешивают:RD (Route Distinguisher) и RT (Route Target).Обе выглядят как что-то вроде:65000:100Но делают они совершенно разные вещи. Представим двух клиентов:Customer A 10.10.10.0/24Customer B 10.10.10.0/24Для обычного BGP это один и тот же IPv4-префикс.
Network Admin
10 сент., 09:05
bpftool prog profile: кто съедает CPU внутри BPFBPF-программы могут работать в сетевом пути тысячи и миллионы раз в секунду.Поэтому проблема иногда выглядит странно:CPU → 100% приложение → почти не грузит network traffic → высокийСмотреть только на процессы в top здесь недостаточно.У bpftool есть режим профилирования конкретной BPF-программы:bpftool prog showНаходим нужную программу и получаем её ID:123: xdp name firewall
Network Admin
9 сент., 09:05
ip neigh flush: команда, которая может мгновенно изменить поведение сетиИногда сервер продолжает отправлять трафик на старый MAC-адрес, хотя ARP уже должен был обновиться.Вместо перезапуска интерфейса можно заставить Linux заново разрешить соседей:ip neigh flush dev eth0После этого:ip neigh show dev eth0может показать:10.10.10.1 INCOMPLETEЯдро ещё не знает MAC шлюза и отправит ARP-запрос:Who has 10.10.10.1?
Network Admin
8 сент., 09:45
Как Linux выбирает, через какой интерфейс отправить пакетНа сервере два интерфейса:eth0 → 10.0.1.10/24 eth1 → 10.0.2.10/24И оба имеют доступ к внешней сети.Когда приложение обращается к:8.8.8.8Linux не выбирает интерфейс по принципу «первый доступный».Сначала он делает routing lookup:ip route get 8.8.8.8Например:
Network Admin
7 сент., 09:05
Что происходит с DHCP lease, когда сервер получает тот же IP после перезагрузкиDHCP - это не просто «сервер выдал IP и забыл».Когда клиент получает адрес, например:192.168.1.50он получает ещё и lease time:lease: 8 hoursПри обычной работе клиент не ждёт окончания lease. Он пытается продлить его заранее.Упрощённо:0% ───────── 50% ───────── 87.5% ───── 100% │ │ renew rebind expire
Network Admin
4 сент., 09:35
Почему нельзя смешивать management и user traffic «потом разделим»Пока всё спокойно, смешанный трафик кажется нормальным решением.Как только сеть ловит перегрузку или шторм, management-трафик оказывается в той же очереди, что и пользовательский.В момент инцидента устройство может быть доступно по IP, но управлять им невозможно.Самый простой вариант - отдельный management VLAN.Пример на Cisco:vlan 99 name MANAGEMENTinterface Vlan99 ip address 10.99.0.10 255.255.255.0 no shutdownAccess-порты для управления:
Network Admin
3 сент., 09:35
5 команд для поиска проблем с ARP после замены сервераЗаменили сервер, оставили тот же IP, интерфейс поднялся, gateway пингуется - но часть устройств всё ещё пытается отправлять трафик на старый MAC. Проверяем по порядку.1️⃣Смотрим текущий neighbor stateip neigh showНапример:10.0.0.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff STALEВажно не только наличие MAC, но и состояние записи: REACHABLE, STALE, DELAY, PROBE, FAILED.2️⃣Проверяем ARP непосредственно до gatewayarping -I eth0 10.0.0.1Если ответы приходят с неожиданного MAC, проблема уже не в маршрутизации.
Network Admin
2 сент., 09:25
Почему BGP может выбрать более длинный путьВ BGP легко представить выбор маршрута как простое правило: меньше AS в пути - лучше.Но AS-path length - только один из атрибутов, которые участвуют в best-path selection.Например, маршрутизатор получил:10.10.10.0/24peer A: AS_PATH 64501 64502 peer B: AS_PATH 64503 64504 64505На первый взгляд BGP должен выбрать A. Но если у маршрута от B выше LOCAL_PREF, он может стать предпочтительным ещё до того, как длина AS_PATH вообще сыграет роль.Условно:A → LOCAL_PREF 100 → AS_PATH 2
Network Admin
1 сент., 09:15
Как локальный трафик может вообще не попадать на физический интерфейсЕсли приложение обращается к IP, который Linux считает своим локальным адресом, пакет не отправляется на физический интерфейс.Например, на сервере:eth0 → 10.0.0.10/24Приложение выполняет:curl http://10.0.0.10:8080Интуитивно кажется, что будет:application ↓ eth0 ↓ switch ↓
Network Admin
31 авг., 14:47
📂Gratuitous ARP меняет ARP-кэш без единого ARP-запросаОбычно ARP работает так:Host A → Who has 10.0.0.10? Host B → 10.0.0.10 is aa:bb:cc:dd:ee:ffНо устройство может само отправить ARP-пакет, не дожидаясь никакого запроса.Это и есть Gratuitous ARP. Например, виртуальный IP переезжает:до:10.0.0.10 → aa:aa:aa:aa:aa:aaпосле:10.0.0.10 → bb:bb:bb:bb:bb:bb
Network Admin
28 авг., 09:32
Большой RX ring не всегда делает сеть быстрееУ сетевой карты есть очереди, куда складываются входящие пакеты, пока драйвер не успел их обработать.При burst-трафике большой ring действительно может помочь пережить кратковременный всплеск:NIC → RX ring → driver → kernelНо бесконечной очереди не бывает.Если CPU стабильно обрабатывает, например, 500 тыс. пакетов/с, а приходит 700 тыс.:500k → 700k → 900k → ...ring постепенно заполняется, после чего начинаются drops.Увеличение ring позволяет накопить больше пакетов:ethtool -g eth0 ethtool -G eth0 rx 4096
Network Admin
27 авг., 09:31
Сетевой пакет может потеряться ещё внутри NICВ tcpdump нет пакета - легко сделать вывод, что он не пришёл на сервер. Но между физическим портом и tcpdump находится сама сетевой карта.У NIC есть собственные RX ring buffers. Драйвер забирает из них дескрипторы и передаёт полученные данные ядру.При перегрузке очередь может не успеть обработать входящие пакеты:NIC ↓ RX ring ↓ driver ↓ kernel ↓ tcpdumpЕсли проблема возникает на уровне NIC/driver, пакет может исчезнуть до того, как станет виден обычному packet capture.
Network Admin
26 авг., 11:10
📂 Linux bridge учит MAC-адреса почти как обычный коммутаторКогда Linux работает как bridge, он не просто механически пересылает Ethernet-кадры между интерфейсами.У него есть собственная forwarding database - FDB.Когда кадр приходит на bridge, ядро смотрит на его source MAC и запоминает, откуда он пришёл:aa:bb:cc:dd:ee:01 → eth0 aa:bb:cc:dd:ee:02 → eth1Посмотреть таблицу можно:bridge fdb showПосле этого кадр для aa:bb:cc:dd:ee:02 уже не нужно отправлять на все порты - bridge знает, что destination находится за eth1.Если destination MAC неизвестен, кадр будет flood’иться по подходящим портам. После получения ответа bridge снова обновит FDB.У записей есть timeout, поэтому старый MAC постепенно исчезает:
