Network Admin
前往频道在 Telegram
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
显示更多
网络:📈 Telegram 频道 Network Admin 的分析概览
频道 Network Admin (@networkadm) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 12 399 名订阅者，在 技术与应用 类别中位列第 9 781，并在 俄罗斯 地区排名第 51 817 位。
📊 受众指标与增长动态
自 невідомо 创建以来，项目保持高速增长，吸引了 12 399 名订阅者。
根据 15 九月, 2026 的最新数据，频道保持稳定运转。过去 30 天订阅人数变化为 -12，过去 24 小时变化为 1，整体触达仍然可观。
- 认证状态： 未认证
- 互动率 (ER)： 平均受众互动率为 13.68%。内容发布后 24 小时内通常能获得 5.90% 的反应，占订阅者总量。
- 帖子覆盖： 每篇帖子平均可获得 1 696 次浏览，首日通常累积 731 次浏览。
- 互动与反馈： 受众积极参与，单帖平均反应数为 4。
- 主题关注点： 内容集中在 vlan, arp, интерфейс, ping, dhcp 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台：
“Обучающий канал по сетевому и системному администрированию.
Сотрудничество: @dad_admin
Биржа: https://telega.in/c/networkadm
РКН: https://bit.ly/4ioc61C”
凭借高频更新（最新数据采集于 16 九月, 2026），频道始终保持新鲜度与高覆盖。分析显示受众积极互动，使其成为 技术与应用 类别中的关键影响点。
12 399
订阅者
+124 小时
-117 天
-1230 天
数据加载中...
吸引订阅者
九月 '26
九月 '26
+27
在0个频道中
八月 '26
+69
在10个频道中
Get PRO
七月 '26
+57
在1个频道中
Get PRO
六月 '26
+64
在5个频道中
Get PRO
五月 '26
+43
在0个频道中
Get PRO
四月 '26
+50
在0个频道中
Get PRO
三月 '26
+33
在0个频道中
Get PRO
二月 '26
+50
在0个频道中
Get PRO
一月 '26
+102
在5个频道中
Get PRO
十二月 '25
+176
在12个频道中
Get PRO
十一月 '25
+125
在2个频道中
Get PRO
十月 '25
+168
在7个频道中
Get PRO
九月 '25
+238
在15个频道中
Get PRO
八月 '25
+12
在0个频道中
Get PRO
七月 '25
+97
在11个频道中
Get PRO
六月 '25
+76
在4个频道中
Get PRO
五月 '25
+57
在1个频道中
Get PRO
四月 '25
+751
在23个频道中
Get PRO
三月 '25
+135
在6个频道中
Get PRO
二月 '25
+258
在8个频道中
Get PRO
一月 '25
+470
在19个频道中
Get PRO
十二月 '24
+133
在4个频道中
Get PRO
十一月 '24
+93
在0个频道中
Get PRO
十月 '24
+333
在6个频道中
Get PRO
九月 '24
+131
在0个频道中
Get PRO
八月 '24
+656
在8个频道中
Get PRO
七月 '24
+79
在0个频道中
Get PRO
六月 '24
+335
在5个频道中
Get PRO
五月 '24
+121
在0个频道中
Get PRO
四月 '24
+194
在3个频道中
Get PRO
三月 '24
+137
在1个频道中
Get PRO
二月 '24
+140
在2个频道中
Get PRO
一月 '24
+162
在6个频道中
Get PRO
十二月 '23
+120
在0个频道中
Get PRO
十一月 '23
+538
在7个频道中
Get PRO
十月 '23
+53
在2个频道中
Get PRO
九月 '23
+836
在0个频道中
Get PRO
八月 '23
+432
在0个频道中
Get PRO
七月 '23
+641
在0个频道中
Get PRO
六月 '23
+453
在0个频道中
Get PRO
五月 '23
+968
在0个频道中
Get PRO
四月 '23
+2 725
在0个频道中
Get PRO
三月 '23
+2 642
在0个频道中
Get PRO
二月 '23
+2 465
在0个频道中
Get PRO
一月 '23
+1 848
在0个频道中
Get PRO
十二月 '22
+1 541
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 16 九月 | 0 | |||
| 15 九月 | +3 | |||
| 14 九月 | +3 | |||
| 13 九月 | 0 | |||
| 12 九月 | 0 | |||
| 11 九月 | 0 | |||
| 10 九月 | +4 | |||
| 09 九月 | +1 | |||
| 08 九月 | 0 | |||
| 07 九月 | +5 | |||
| 06 九月 | +3 | |||
| 05 九月 | +2 | |||
| 04 九月 | 0 | |||
| 03 九月 | +4 | |||
| 02 九月 | +2 | |||
| 01 九月 | 0 |
频道帖子
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.
| 2 |  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. | 729 |
| 3 |  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. | 977 |
| 4 |  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. | 1 249 |
| 5 |  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. | 1 211 |
| 6 |  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. | 1 196 |
| 7 |  Как 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. | 1 295 |
| 8 |  Что происходит с 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. | 1 457 |
| 9 |  Почему нельзя смешивать 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. | 1 925 |
| 10 |  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. | 1 681 |
| 11 |  Почему 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. | 1 519 |
| 12 |  Как локальный трафик может вообще не попадать на физический интерфейс
Если приложение обращается к 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. | 1 326 |
| 13 |  📂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. | 1 524 |
| 14 |  Большой 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. | 2 212 |
| 15 |  Сетевой пакет может потеряться ещё внутри 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. | 2 180 |
| 16 |  📂 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. | 2 036 |
| 17 |  Пока все работает, о хорошей инженерной работе обычно не говорят
Заметят обычно обратное: когда система легла, когда бизнес встал, когда инфраструктура не выдержала. И вот тогда все резко вспоминают, что где-то есть инженер, от которого это все зависело.
Именно поэтому в рамках конференции IT Elements 2026 пройдет первая профессиональная премия «Инженерное искусство». Она посвящена людям, которые каждый день создают, защищают и развивают корпоративное ИТ.
Шесть номинаций – и в каждой свой герой:
🔹Архитектор системы
🔹Инженер инноваций
🔹Инженер восстановления
🔹Инженер инфраструктуры
🔹Инженер безопасности
🔹Лидер инженерной команды
Если вам есть чем гордиться – или вы знаете проект, который заслужил, чтобы о нем узнали, – расскажите об этом профессиональному сообществу.
Заявки принимаются до 31 августа по ссылке. | 1 118 |
| 18 |  Пакет можно отбросить до создания 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. | 1 859 |
| 19 |  Почему 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. | 1 922 |
| 20 |  Один 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. | 2 491 |
