Network Admin

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) решает эту проблему другим способом. Вместо того чтобы использовать полноценный 128-битный SID для каждого шага, несколько коротких инструкций помещаются внутрь одного IPv6-адреса:

IPv6 address
┌──────────────┬───────────────────────────────┐
│ locator      │ uSID │ uSID │ uSID │ uSID    │
└──────────────┴───────────────────────────────┘

Условно:

LOC:R1 | R5 | R8 | R12

Когда пакет проходит через очередной SRv6 node, текущий uSID обрабатывается, а следующий становится активным. В результате тот же логический путь:

R1 → R5 → R8 → R12

можно закодировать компактнее, чем последовательностью отдельных 128-битных SID. Зачем это вообще нужно? Потому что SRv6 использует IPv6-адреса для инструкций. Если построить длинный traffic-engineered path и записать каждый шаг отдельным SID, служебная часть пакета начинает заметно расти. uSID позволяет уплотнить несколько инструкций в один SID-контейнер, сохраняя модель SRv6. Условно: обычный SRv6:

[SID][SID][SID][SID][SID]

uSID:

[Locator | uSID | uSID | uSID | uSID]

То есть uSID - это не новый routing protocol и не «более быстрый IPv6». Это способ сделать SRv6-путь компактнее, когда количество инструкций становится большим. N.A.

TI-LFA: fast reroute без SPF Обычный IGP при отказе линка должен сначала понять, что топология изменилась, затем пересчитать SPF и установить новый маршрут. Это занимает время. TI-LFA работает иначе: резервный путь вычисляется заранее. Допустим, основной путь:

R1 ── R2 ── R4
       │
       X
       │
      R3 ── R4

R1 знает, что если линк R2-R4 пропадёт, трафик можно отправить через R3. При отказе R2 не ждёт полноценного SPF для восстановления forwarding. Он использует заранее рассчитанный backup path. В SR-сетях этот путь можно выразить через Segment List:

R1 → [SID R3] → R4

И пакет сразу получает альтернативный forwarding path. Получается:

обычный convergence:

link down
   ↓
LSA/LSP
   ↓
SPF
   ↓
новый маршрут
   ↓
FIB update
   ↓
forwarding


TI-LFA:

link down
   ↓
локальная защита
   ↓
backup path
   ↓
forwarding

Самая интересная часть здесь в том, что TI-LFA не пытается быстрее пересчитать всю сеть. Он старается сделать так, чтобы при отказе маршрутизатору вообще не пришлось ждать этого пересчёта для уже идущего трафика. Поэтому TI-LFA особенно полезен в сетях, где несколько десятков миллисекунд уже имеют значение: транспорт, датацентры, backbone и другие чувствительные к потере трафика сервисы. N.A.

show spanning-tree: почему STP блокирует порт В Cisco-подобных коммутаторах команда: show spanning-tree показывает не просто «какой порт заблокирован». Она позволяет понять, почему именно этот порт проиграл выбор пути. Например:

VLAN 10
Root ID    Priority    24586
           Address     0011.2233.4455

Interface        Role Sts Cost
Gi1/0/1          Root FWD 4
Gi1/0/2          Altn BLK 4

На первый взгляд кажется: Gi1/0/2 - резервный линк, всё нормально. Но STP выбирает не «основной и резервный кабель». Каждый switch сравнивает BPDU и стоимость пути до Root Bridge. Если два пути имеют одинаковый cost, в дело идут дополнительные tie-breaker:

Root Bridge
    ↓
Root Path Cost
    ↓
Sender Bridge ID
    ↓
Sender Port ID

Поэтому после замены коммутатора или изменения priority один и тот же физический линк вполне может внезапно стать BLK. Особенно полезно смотреть:

show spanning-tree vlan 10 detail

Там можно увидеть изменения topology и понять, почему STP пересчитал дерево, а не просто констатировать, что порт заблокирован. N.A.

RD и RT - почему это не одно и то же В MPLS L3VPN есть две сущности, которые часто смешивают: RD (Route Distinguisher) и RT (Route Target). Обе выглядят как что-то вроде:

65000:100

Но делают они совершенно разные вещи. Представим двух клиентов:

Customer A
10.10.10.0/24

Customer B
10.10.10.0/24

Для обычного BGP это один и тот же IPv4-префикс. RD добавляет к нему уникальность:

RD 65000:100 + 10.10.10.0/24
        ↓
65000:100:10.10.10.0/24

У второго клиента:

65000:200:10.10.10.0/24

Теперь PE-маршрутизатор может хранить оба маршрута, несмотря на одинаковый IPv4 prefix. Но RD не решает, кому этот маршрут можно импортировать. Для этого используется RT. Например:

VRF-A
 export RT 65000:100
 import RT 65000:200

А у другой VRF:

VRF-B
 export RT 65000:200
 import RT 65000:100

Получается:

VRF-A
  │
  │ export RT 65000:100
  ↓
MP-BGP
  ↓
  │ import RT 65000:100
  ↓
VRF-B

То есть логика примерно такая:

RD → «Как сделать этот маршрут уникальным?»

RT → «В какие VRF этот маршрут можно импортировать?»

И здесь есть важный момент. Одинаковый RD не означает, что VRF должны видеть маршруты друг друга. И наоборот: одинаковый RT не означает, что маршруты имеют одинаковый RD. Их можно даже специально сделать разными:

VRF-A
RD: 65000:101
RT export: 65000:100

VRF-B
RD: 65000:202
RT import: 65000:100

Маршруты будут различаться в VPN control plane благодаря RD, а политика распространения между VRF будет определяться RT. Поэтому RD и RT лучше запомнить не как «две похожие цифры», а как две разные функции: RD - идентичность VPN-маршрута. RT - политика его распространения. N.A.

bpftool prog profile: кто съедает CPU внутри BPF BPF-программы могут работать в сетевом пути тысячи и миллионы раз в секунду. Поэтому проблема иногда выглядит странно:

CPU → 100%
приложение → почти не грузит
network traffic → высокий

Смотреть только на процессы в top здесь недостаточно. У bpftool есть режим профилирования конкретной BPF-программы:

bpftool prog show

Находим нужную программу и получаем её ID:

123: xdp  name firewall

После этого:

bpftool prog profile id 123

Можно получить статистику выполнения программы и понять, сколько процессорного времени она реально потребляет. Почему это полезно? Допустим, на сервере стоит XDP-фильтр. Он должен быстро отбрасывать мусорный трафик, но внутри программы появилась сложная логика: несколько map lookup, дополнительные проверки и работа с большим количеством пакетов. При небольшом трафике это незаметно. А при 5 млн PPS:

5 000 000 packets/sec
        ×
несколько дополнительных операций
        ↓
существенная нагрузка CPU

И в итоге администратор видит просто высокий softirq/CPU usage, хотя источник нагрузки находится внутри BPF-программы. Это особенно интересно тем, что BPF выполняется не как отдельный процесс, который можно найти в top. То есть искать:

top
ps aux

в этом случае недостаточно. Логика диагностики получается другой:

CPU ↑
 ↓
network/softirq ↑
 ↓
BPF подозрителен
 ↓
bpftool prog show
 ↓
bpftool prog profile

И это уже позволяет искать не «какой процесс грузит CPU», а какая программа внутри kernel datapath тратит процессорное время. N.A.

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?

После ответа запись снова станет, например:

10.10.10.1 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Но есть важный нюанс. flush не чинит ARP-проблему. Если шлюз не отвечает на ARP, после очистки вы просто получите INCOMPLETE и потерю связи. Поэтому команда полезна именно как диагностический приём:

ip neigh show dev eth0
ip neigh flush dev eth0
ip neigh show dev eth0

Если после flush сосед снова быстро появляется с правильным MAC - проблема могла быть в устаревшем состоянии neighbor table. Если остаётся:

INCOMPLETE

ищите уже ниже:

tcpdump -ni eth0 arp

N.A.

Как Linux выбирает, через какой интерфейс отправить пакет На сервере два интерфейса:

eth0 → 10.0.1.10/24
eth1 → 10.0.2.10/24

И оба имеют доступ к внешней сети. Когда приложение обращается к:

8.8.8.8

Linux не выбирает интерфейс по принципу «первый доступный». Сначала он делает routing lookup:

ip route get 8.8.8.8

Например:

8.8.8.8 via 10.0.1.1 dev eth0 src 10.0.1.10

Здесь kernel уже определил:

destination → 8.8.8.8
gateway     → 10.0.1.1
interface   → eth0
source IP   → 10.0.1.10

Но интереснее становится, когда появляются ip rule.

ip rule

Например:

0:      from all lookup local
100:    from 10.0.2.0/24 lookup isp2
200:    from all lookup main

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

source 10.0.1.10 → eth0
source 10.0.2.10 → eth1

При этом обычный:

ip route

может вообще не объяснить, почему второй пакет пошёл через eth1. Для конкретного источника можно проверить:

ip route get 8.8.8.8 from 10.0.2.10

И получить уже другой результат. Поэтому на multi-homed сервере вопрос «какой default route стоит?» часто недостаточен. Нужно смотреть какой routing policy применяется именно к этому пакету. N.A.

Что происходит с DHCP lease, когда сервер получает тот же IP после перезагрузки DHCP - это не просто «сервер выдал IP и забыл». Когда клиент получает адрес, например:

192.168.1.50

он получает ещё и lease time:

lease: 8 hours

При обычной работе клиент не ждёт окончания lease. Он пытается продлить его заранее. Упрощённо:

0% ───────── 50% ───────── 87.5% ───── 100%
              │              │
           renew          rebind       expire

На этапе T1 клиент обращается к DHCP-серверу, который выдал lease. Если тот недоступен, позже начинается T2 - клиент уже пытается продлить аренду через broadcast, чтобы найти любой доступный DHCP-сервер. Посмотреть lease на Linux можно, например, через:

networkctl status eth0

или:

cat /var/lib/dhcp/dhclient.leases

При перезагрузке клиент может попытаться вернуть себе прежний адрес. Но DHCP-сервер не обязан его сохранить: он проверяет актуальность lease и состояние пула. Поэтому ситуация:

сервер был → 192.168.1.50
перезагрузился
сервер снова появился → 192.168.1.73

не обязательно означает ошибку DHCP. Между клиентом и сервером существует отдельное состояние аренды, и IP-адрес - только одна его часть. Именно поэтому при проблемах с DHCP полезно смотреть не только ip addr, а кто выдал lease, когда он истекает и на каком этапе продления находится клиент. N.A.

Почему нельзя смешивать management и user traffic «потом разделим» Пока всё спокойно, смешанный трафик кажется нормальным решением. Как только сеть ловит перегрузку или шторм, management-трафик оказывается в той же очереди, что и пользовательский. В момент инцидента устройство может быть доступно по IP, но управлять им невозможно. Самый простой вариант - отдельный management VLAN. Пример на Cisco: vlan 99 name MANAGEMENT interface Vlan99 ip address 10.99.0.10 255.255.255.0 no shutdown Access-порты для управления: interface GigabitEthernet1/0/1 switchport mode access switchport access vlan 99 Транки - только с нужными VLAN: interface GigabitEthernet1/0/24 switchport mode trunk switchport trunk allowed vlan 10,20,99 Если нужно жёстко отделить управление — VRF: vrf definition MGMT rd 65000:99 interface Vlan99 vrf forwarding MGMT ip address 10.99.0.10 255.255.255.0 N.A.

5 команд для поиска проблем с ARP после замены сервера Заменили сервер, оставили тот же IP, интерфейс поднялся, gateway пингуется - но часть устройств всё ещё пытается отправлять трафик на старый MAC. Проверяем по порядку. 1️⃣Смотрим текущий neighbor state

ip neigh show

Например:

10.0.0.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff STALE

Важно не только наличие MAC, но и состояние записи: REACHABLE, STALE, DELAY, PROBE, FAILED. 2️⃣Проверяем ARP непосредственно до gateway

arping -I eth0 10.0.0.1

Если ответы приходят с неожиданного MAC, проблема уже не в маршрутизации. 3️⃣Смотрим ARP на интерфейсе

tcpdump -ni eth0 arp

Можно увидеть, кто спрашивает:

Who-has 10.0.0.10?

и кто отвечает:

10.0.0.10 is-at 11:22:33:44:55:66

Если разные устройства получают разные MAC для одного IP - это уже серьёзный признак конфликта или некорректного failover. 4️⃣Наблюдаем изменения neighbor table в реальном времени

ip monitor neigh

Полезно, когда проблема появляется не постоянно: можно увидеть, как запись меняется между состояниями или удаляется. 5️⃣Проверяем доступность после обновления ARP

ping -c 5 10.0.0.1

Но ping здесь - только финальная проверка. Успешный ICMP сам по себе не говорит, что ARP работает корректно. Типичный сценарий после замены:

старый сервер
10.0.0.10 → AA:AA:AA:AA:AA:AA

        ↓ замена

новый сервер
10.0.0.10 → BB:BB:BB:BB:BB:BB

Если где-то ещё осталась старая ARP-запись, трафик может продолжать уходить на AA:AA:AA:AA:AA:AA. Поэтому после замены сервера полезно проверять не только:

ip addr
ip route

но и связку: IP → ARP/neighbor → MAC → реальный интерфейс Именно она часто объясняет ситуацию, когда сервер уже заменили, а сеть ещё живёт по старой записи. N.A.

Почему BGP может выбрать более длинный путь В BGP легко представить выбор маршрута как простое правило: меньше AS в пути - лучше. Но AS-path length - только один из атрибутов, которые участвуют в best-path selection. Например, маршрутизатор получил:

10.10.10.0/24

peer 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

B → LOCAL_PREF 200 → AS_PATH 3
BGP выберет B.

Это важный момент: BGP ищет не «самый короткий маршрут», а лучший маршрут по последовательности атрибутов. На выбор могут влиять:

LOCAL_PREF
      ↓
AS_PATH
      ↓
ORIGIN
      ↓
MED
      ↓
eBGP / iBGP
      ↓
IGP metric
      ↓
router ID / другие tie-breaker

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

show bgp ipv4 unicast 10.10.10.0/24

А в FRRouting удобно смотреть ещё и выбранный best path:

vtysh -c "show bgp ipv4 unicast 10.10.10.0/24"

Именно поэтому при разборе BGP-проблемы вопрос «у какого peer меньше AS_PATH?» часто оказывается слишком ранним. Сначала нужно понять, какой атрибут сделал маршрут предпочтительнее. N.A.

Как локальный трафик может вообще не попадать на физический интерфейс Если приложение обращается к IP, который Linux считает своим локальным адресом, пакет не отправляется на физический интерфейс. Например, на сервере:

eth0 → 10.0.0.10/24

Приложение выполняет:

curl http://10.0.0.10:8080

Интуитивно кажется, что будет:

application
    ↓
eth0
    ↓
switch
    ↓
eth0
    ↓
server

Но Linux сначала проверяет destination и видит, что 10.0.0.10 принадлежит самому хосту. Маршрут будет иметь тип local:

ip route get 10.0.0.10

Например:

local 10.0.0.10 dev lo src 10.0.0.10

Поэтому физический eth0 в этом обмене вообще не участвует:

application
    ↓
local routing
    ↓
lo
    ↓
local socket

Это важно при диагностике. Можно поставить:

tcpdump -ni eth0 port 8080

и не увидеть вообще ничего, хотя curl успешно устанавливает соединение. А вот:

tcpdump -ni lo port 8080

покажет этот трафик. Причём это не означает, что lo - какой-то физический интерфейс. Это отдельный путь local delivery внутри сетевого стека Linux. Поэтому проверка «пакет дошёл до сервера через его сетевую карту?» иногда вообще поставлена неправильно: если источник и destination находятся на одном хосте, пакет мог никогда не попасть на wire. N.A.

📂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

Новое устройство отправляет объявление:

10.0.0.10 is-at bb:bb:bb:bb:bb:bb

Соседи получают его и обновляют ARP-кэш. В результате трафик начинает идти на новый MAC практически сразу - без того, чтобы каждый клиент самостоятельно выполнял ARP lookup. Посмотреть такие объявления:

tcpdump -ni eth0 arp

А текущую таблицу соседей:

ip neigh show

Это особенно важно при: ⏺failover виртуального IP ⏺миграции виртуальной машины ⏺переключении кластера на резервный узел Поэтому после переноса сервиса между хостами может измениться не DNS, не маршрут и не IP-адрес - меняется только MAC, связанный с уже известным IP, и сеть быстро узнаёт об этом через gratuitous ARP. N.A.

Большой 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

Но если скорость обработки не изменилась, это только отодвинет момент переполнения. Более того, слишком глубокая очередь может увеличить latency: пакет уже не теряется, но дольше ждёт своей очереди на обработку. Поэтому при проблемах с сетью важно различать:

packet loss
и
packet queueing

Первое означает, что пакет исчез. Второе, что пакет всё ещё жив, но уже слишком долго ждёт обработки. N.A.

Сетевой пакет может потеряться ещё внутри NIC В tcpdump нет пакета - легко сделать вывод, что он не пришёл на сервер. Но между физическим портом и tcpdump находится сама сетевой карта. У NIC есть собственные RX ring buffers. Драйвер забирает из них дескрипторы и передаёт полученные данные ядру. При перегрузке очередь может не успеть обработать входящие пакеты:

NIC
 ↓
RX ring
 ↓
driver
 ↓
kernel
 ↓
tcpdump

Если проблема возникает на уровне NIC/driver, пакет может исчезнуть до того, как станет виден обычному packet capture. Поэтому при странных потерях полезно смотреть не только:

ip -s link show eth0

но и аппаратную статистику:

ethtool -S eth0

А размеры RX/TX ring:

ethtool -g eth0

Можно увидеть отдельные counters вроде rx_missed_errors, rx_no_buffer или специфичные для конкретного драйвера drops. Это важный момент при диагностике: если пакет не попал в tcpdump, это ещё не доказывает, что его не получила сетевая карта. N.A.

📂 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 постепенно исчезает:

bridge fdb show br br0

Особенно интересно это проявляется при миграции VM. Было:

VM → eth0

После миграции:

VM → eth1

MAC тот же, но source frames начинают приходить с другого интерфейса. Bridge переучивает запись:

old MAC → eth0
        ↓
new MAC → eth1

Если MAC начинает постоянно перемещаться между портами, можно получить MAC flapping - и тогда проблема уже не в IP-маршрутизации. Linux bridge в таком режиме фактически выполняет ту же базовую функцию, что и физический L2-коммутатор: строит таблицу MAC → порт на основании уже увиденного трафика. N.A.

Пока все работает, о хорошей инженерной работе обычно не говорят Заметят обычно обратное: когда система легла, когда бизнес встал, когда инфраструктура не выдержала. И вот тогда все резко вспоминают, что где-то есть инженер, от которого это все зависело. Именно поэтому в рамках конференции IT Elements 2026 пройдет первая профессиональная премия «Инженерное искусство». Она посвящена людям, которые каждый день создают, защищают и развивают корпоративное ИТ. Шесть номинаций – и в каждой свой герой: 🔹Архитектор системы 🔹Инженер инноваций 🔹Инженер восстановления 🔹Инженер инфраструктуры 🔹Инженер безопасности 🔹Лидер инженерной команды Если вам есть чем гордиться – или вы знаете проект, который заслужил, чтобы о нем узнали, – расскажите об этом профессиональному сообществу. Заявки принимаются до 31 августа по ссылке.

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

NIC → driver → skb → network stack → socket → application

Но skb создаётся не в самом начале. XDP может выполнить программу прямо на раннем этапе обработки пакета, когда драйвер уже получил его из NIC, но обычный sk_buff ещё не создан. Поэтому решение можно принять буквально на входе:

NIC
 ↓
driver
 ↓
XDP
 ├── DROP
 ├── PASS → обычный network stack
 ├── TX
 └── REDIRECT

Например, простой XDP-программе достаточно проверить destination IP и сразу отбросить пакет:

SEC("xdp")
int drop_packet(struct xdp_md *ctx)
{
    return XDP_DROP;
}

При XDP_DROP пакет вообще не доходит до обычного kernel networking stack. Это важно под большой нагрузкой: если отбросить ненужный трафик после создания skb, часть работы ядро уже успело выполнить. XDP позволяет перенести фильтрацию значительно раньше. Проверить, загружена ли XDP-программа:

ip -details link show dev eth0

И посмотреть статистику:

ip -s link show dev eth0

Поэтому «firewall на сервере» - не всегда означает, что пакет сначала проходит весь сетевой стек, а потом его фильтруют. В Linux точка принятия решения может находиться практически сразу после получения кадра сетевой картой. N.A.

Почему ss показывает тысячи соединений, а netstat - другую картину На одном сервере можно запустить:

ss -ant

и получить тысячи TCP-соединений, а затем: netstat -ant и увидеть совсем другое количество. Это не обязательно означает, что один из инструментов врёт. ss работает через современный интерфейс ядра Linux - NETLINK_INET_DIAG.

Ядро отдаёт ему информацию о сокетах напрямую, поэтому ss может получать состояние соединений без перебора /proc и без старого механизма netstat.

netstat из пакета net-tools - устаревший инструмент. Его возможности и способ получения данных отличаются, а часть информации может отображаться иначе. Особенно заметна разница на серверах с большим количеством ephemeral connections и быстро меняющимся состоянием TCP. Для диагностики лучше смотреть не просто количество строк:

ss -s

а разбивку состояний:

ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c

Например:

ESTAB      18420
TIME-WAIT   7312
SYN-RECV    428

И отдельно проверить конкретный listener: ss -lntp Важный момент: TIME-WAIT, SYN-RECV, ESTAB и listening sockets - это разные состояния kernel socket state. Поэтому простое сравнение «сколько строк показывает утилита» может давать совершенно разные выводы. ss сегодня является основным инструментом для анализа TCP/UDP-сокетов в Linux, а netstat в новых системах обычно оставляют только ради совместимости со старыми привычками и скриптами. N.A.

Один VLAN может проходить через несколько коммутаторов без единого L3-интерфейса VLAN не привязан к конкретному коммутатору. Если между устройствами настроен trunk, один и тот же broadcast domain может растянуться через несколько физических узлов. Например:

PC ── SW1 ══ SW2 ══ SW3 ── Server
      VLAN 30   VLAN 30   VLAN 30

На trunk-портах кадр VLAN 30 идёт с тегом 802.1Q. Проверка на Linux:

ip -d link show eth0.30

На Cisco:

show interfaces trunk
show vlan id 30

При этом шлюз VLAN может находиться вообще на другом устройстве:

PC → SW1 → SW2 → SW3 → Router
                         VLAN 30

Коммутаторы между ними работают только на L2 и не принимают решение о маршрутизации. Но есть важный нюанс: чем дальше растянут L2-домен, тем больше устройств получают его broadcast и unknown-unicast traffic. Поэтому проблема иногда выглядит как «сеть внезапно стала шумной», хотя IP-маршрутизация при этом вообще не менялась. N.A.