Network Admin

Open in Telegram

Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C

Network:Белый хакер Russia51 817 Technologies & Applications9 781...

📈 Analytical overview of Telegram channel Network Admin

Channel Network Admin (@networkadm) in the Russian language segment is an active participant. Currently, the community unites 12 399 subscribers, ranking 9 781 in the Technologies & Applications category and 51 817 in the Russia region.

📊 Audience metrics and dynamics

Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 12 399 subscribers.

According to the latest data from 15 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -12 over the last 30 days and by 1 over the last 24 hours, overall reach remains high.

Verification status: Not verified
Engagement rate (ER): The average audience engagement rate is 13.68%. Within the first 24 hours after publication, content typically collects 5.90% reactions from the total number of subscribers.
Post reach: On average, each post receives 1 696 views. Within the first day, a publication typically gains 731 views.
Reactions and interaction: The audience actively supports content: the average number of reactions per post is 4.
Thematic interests: Content is focused on key topics such as vlan, arp, интерфейс, ping, dhcp.

📝 Description and content policy

The author describes the resource as a platform for expressing subjective opinions:
“Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C”

Thanks to the high frequency of updates (latest data received on 16 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.

12 399

Subscribers

+124 hours

-117 days

-1230 days

1 696

Post views

~ 73124 hours

~ 89548 hours

13.68%

Engagement rate

No data

Posts per day

Ads index

beta

Data loading in progress...

Similar Channels

Системный администратор

More channels

Tags Cloud

Incoming and Outgoing Mentions

---

Attracting Subscribers

September '26

+27

in 0 channels

August '26

+69

in 10 channels

Get PRO

July '26

+57

in 1 channels

Get PRO

June '26

+64

in 5 channels

Get PRO

May '26

+43

in 0 channels

Get PRO

April '26

+50

in 0 channels

Get PRO

March '26

+33

in 0 channels

Get PRO

February '26

+50

in 0 channels

Get PRO

January '26

+102

in 5 channels

Get PRO

December '25

+176

in 12 channels

Get PRO

November '25

+125

in 2 channels

Get PRO

October '25

+168

in 7 channels

Get PRO

September '25

+238

in 15 channels

Get PRO

August '25

+12

in 0 channels

Get PRO

July '25

+97

in 11 channels

Get PRO

June '25

+76

in 4 channels

Get PRO

May '25

+57

in 1 channels

Get PRO

April '25

+751

in 23 channels

Get PRO

March '25

+135

in 6 channels

Get PRO

February '25

+258

in 8 channels

Get PRO

January '25

+470

in 19 channels

Get PRO

December '24

+133

in 4 channels

Get PRO

November '24

+93

in 0 channels

Get PRO

October '24

+333

in 6 channels

Get PRO

September '24

+131

in 0 channels

Get PRO

August '24

+656

in 8 channels

Get PRO

July '24

+79

in 0 channels

Get PRO

June '24

+335

in 5 channels

Get PRO

May '24

+121

in 0 channels

Get PRO

April '24

+194

in 3 channels

Get PRO

March '24

+137

in 1 channels

Get PRO

February '24

+140

in 2 channels

Get PRO

January '24

+162

in 6 channels

Get PRO

December '23

+120

in 0 channels

Get PRO

November '23

+538

in 7 channels

Get PRO

October '23

+53

in 2 channels

Get PRO

September '23

+836

in 0 channels

Get PRO

August '23

+432

in 0 channels

Get PRO

July '23

+641

in 0 channels

Get PRO

June '23

+453

in 0 channels

Get PRO

May '23

+968

in 0 channels

Get PRO

April '23

+2 725

in 0 channels

Get PRO

March '23

+2 642

in 0 channels

Get PRO

February '23

+2 465

in 0 channels

Get PRO

January '23

+1 848

in 0 channels

Get PRO

December '22

+1 541

in 0 channels

Date	Subscriber Growth	Mentions	Channels
16 September	0
15 September	+3
14 September	+3
13 September	0
12 September	0
11 September	0
10 September	+4
09 September	+1
08 September	0
07 September	+5
06 September	+3
05 September	+2
04 September	0
03 September	+4
02 September	+2
01 September	0

Channel Posts

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

View all posts