Network Admin

Open in Telegram

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

Network:Белый хакер Russia53 135 Technologies & Applications10 184...

📈 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 462 subscribers, ranking 10 184 in the Technologies & Applications category and 53 135 in the Russia region.

📊 Audience metrics and dynamics

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

According to the latest data from 10 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -34 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 15.96%. Within the first 24 hours after publication, content typically collects 7.98% reactions from the total number of subscribers.
Post reach: On average, each post receives 1 989 views. Within the first day, a publication typically gains 994 views.
Reactions and interaction: The audience actively supports content: the average number of reactions per post is 9.
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 11 June, 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 462

Subscribers

-124 hours

-47 days

-3430 days

1 989

Post views

~ 99424 hours

~ 1 16748 hours

15.96%

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

June '26

+31

in 4 channels

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
11 June	+2
10 June	+3
09 June	+1
08 June	+3
07 June	0
06 June	+1
05 June	+3
04 June	+1
03 June	+1
02 June	+3
01 June	+13

Channel Posts

Почему 10G линк работает на 1G и как это поймать Линк поднялся, всё зелёное, но скорость как на старом железе. Первая мысль: проблема в приложении или сети. На деле часто линк просто не договорился о скорости. Смотрим на какой скорости реально работает интерфейс:

ethtool eth0 | grep -E "Speed|Duplex|Auto"
ip -s link show eth0

Если Speed: 1000Mb/s на 10G интерфейсе, autonegotiation не договорился или принудительно выставлена неверная скорость. Проверяем ошибки на интерфейсе:

ethtool -S eth0 | grep -E "error|drop|miss|fail"

Много ошибок на физическом уровне говорят о проблеме с кабелем или SFP. Смотрим что видит интерфейс с другой стороны через LLDP:

lldpctl eth0

Покажет что анонсирует сосед: скорость, duplex, модель устройства. Принудительно выставляем скорость если autonegotiation не работает:

ethtool -s eth0 speed 10000 duplex full autoneg off

Проверяем SFP модуль: температуру, мощность сигнала, vendor:

ethtool -m eth0

Если rx_power или tx_power сильно ниже нормы для данного типа модуля, проблема в оптике или трансивере. ⚡️ DAC-кабели (прямое медное подключение) иногда не работают с чужими SFP-модулями даже если физически подходят. Вендор-лок на уровне прошивки коммутатора: Cisco по умолчанию не принимает non-Cisco трансиверы без service unsupported-transceiver. N.A.

2	Почему autonegotiation ломается и когда его лучше отключить Autonegotiation это протокол согласования скорости и duplex между двумя портами. Работает через обмен FLP (Fast Link Pulse) сигналами до установки линка. Когда всё работает, трогать не надо. Когда ломается, диагностировать неочевидно. Чаще всего ломается на стыке старого и нового оборудования: одна сторона анонсирует одно, другая понимает иначе. Классический результат: линк поднимается на 100Мбит half-duplex вместо гигабита. Формально работает, по факту коллизии и потери на любой нагрузке. Смотрим что согласовалось: ethtool eth0 \| grep -E "Speed\|Duplex\|Link" Проверяем ошибки которые говорят о duplex mismatch: ethtool -S eth0 \| grep -E "collision\|late_collision\|deferred" Много коллизий при нормальном линке, почти всегда duplex mismatch. Когда отключать autonegotiation: на линках к старому оборудованию которое плохо его реализует, на trunk-портах где важна предсказуемость, на линках где наблюдается периодическая смена скорости. Выставляем принудительно на обоих концах: ethtool -s eth0 speed 1000 duplex full autoneg off На Cisco: interface Gi0/1 speed 1000 duplex full no negotiation auto ⚡️ Принудительная скорость на одном конце при включённом autonegotiation на другом хуже чем оба в auto. Один конец не получает FLP и падает в half-duplex по умолчанию. Если отключаешь autoneg, отключай на обоих концах. N.A.	1 022
3	Почему роутер не всегда выбирает маршрут с наименьшей метрикой Метрика это не единственный критерий выбора маршрута. Сначала роутер смотрит на длину префикса: более специфичный маршрут всегда побеждает независимо от метрики. Маршрут 192.168.1.0/24 с метрикой 100 выиграет у 192.168.0.0/16 с метрикой 1. Longest prefix match, основа IP-маршрутизации. Второй критерий: administrative distance. Если маршрут до одной сети пришёл от OSPF и от статики одновременно, роутер выбирает по AD, а не метрике. Статика имеет AD 1, OSPF 110, eBGP 20, iBGP 200. Маршрут с меньшим AD побеждает даже если метрика хуже. На Cisco смотрим что реально в таблице и почему: show ip route 10.0.0.0 show ip route 10.0.0.0 255.255.255.0 longer-prefixes В выводе видно AD и метрику в формате [AD/metric]: O 10.0.0.0/24 [110/20] via 192.168.1.1 Если маршрут которого ожидаешь не появляется, проверяем все источники: show ip route summary show ip bgp 10.0.0.0 show ip ospf database ⚡️ BGP это отдельная история: внутри BGP выбор лучшего маршрута идёт по своему алгоритму из 13 шагов, метрика там только один из критериев и далеко не первый. Weight, Local Preference, AS-path length всё это важнее. N.A.	1 216
4	Как работает TCP window scaling и почему его отключение убивает скорость TCP window это сколько данных можно отправить не дожидаясь подтверждения. Без window scaling максимум 65535 байт, это ограничение 16-битного поля в заголовке. На канале с большой задержкой этого катастрофически мало. ⏺Считается просто: пропускная способность = window size / RTT. Канал 1 Гбит, RTT 100мс, без scaling максимум 65535 / 0.1 = 655 Кбит/с. Гигабитный канал работает как мегабитный. Window scaling добавляет множитель до 1073741824 байт. Согласовывается при TCP handshake через опцию WS. Проверяем включён ли: sysctl net.ipv4.tcp_window_scaling ss -tin dst <IP> \| grep wscale Смотрим реальные размеры окна в Wireshark: фильтр tcp.window_size, если значения не растут выше 65535, scaling не работает. Включаем если выключен: sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216" sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216" ⚡️ Некоторые файерволы и middlebox-ы обрезают TCP-опции при handshake. Window scaling согласовывается один раз и если файервол дропнул опцию WS, весь поток работает без scaling. Симптом: скорость нормальная на коротких дистанциях и падает на каналах с высоким RTT. N.A.	1 371
5	Почему mmap быстрее read() для больших файлов и когда это не так read() работает так: ядро копирует данные из page cache в буфер в user space. Два адресных пространства, одна лишняя копия на каждый вызов. При больших файлах это накапливается. mmap отображает файл прямо в виртуальное адресное пространство процесса. Никакой копии, процесс читает данные напрямую из page cache через указатель. Первое обращение к странице вызывает page fault, ядро подгружает её с диска, дальше доступ как к обычной памяти. На больших файлах с последовательным чтением разница заметна: меньше syscall-ов, меньше копирований, меньше переключений контекста. Именно поэтому базы данных, поисковые движки и компиляторы используют mmap для работы с большими структурами данных. Когда mmap медленнее При случайном доступе к очень большому файлу mmap генерирует много мелких page fault-ов. Каждый fault это обращение к ядру, TLB miss, возможно диск. read() с большим буфером читает последовательно и prefetch работает лучше. На NUMA-системах mmap может давать неожиданные результаты: страницы аллоцируются на одном узле, процесс работает на другом, латентность растёт. ⏺При записи mmap требует явного msync() чтобы гарантировать сброс на диск. Легко забыть, данные теряются при падении процесса. Смотрим page fault-ы конкретного процесса: /usr/bin/time -v ./myprogram 2>&1 \| grep "Page faults" perf stat -e page-faults ./myprogram N.A.	1 828
6	Настройка VLAN на Linux через systemd-networkd systemd-networkd это не только для серверов без GUI, на практике удобнее nmcli для воспроизводимых конфигураций: файлы в /etc/systemd/network/, всё декларативно, легко версионировать в git. Типичный сценарий: сервер подключён к trunk-порту коммутатора, нужно поднять несколько VLAN-интерфейсов с разными адресами. Создаём VLAN-интерфейсы Для каждого VLAN нужно два файла: .netdev описывает интерфейс, .network настраивает его. VLAN 10: # /etc/systemd/network/vlan10.netdev [NetDev] Name=eth0.10 Kind=vlan [VLAN] Id=10 # /etc/systemd/network/vlan10.network [Match] Name=eth0.10 [Network] Address=192.168.10.1/24 Gateway=192.168.10.254 VLAN 20 аналогично, меняем Id и адреса. Привязываем физический интерфейс Физический интерфейс должен знать что он trunk и какие VLAN на нём живут: # /etc/systemd/network/eth0.network [Match] Name=eth0 [Network] VLAN=eth0.10 VLAN=eth0.20 Применяем: systemctl restart systemd-networkd Проверка ip -d link show eth0.10 ip addr show eth0.10 networkctl status eth0.10 networkctl status покажет состояние интерфейса, привязанные адреса и есть ли carrier. N.A.	1 655
7	На Stepik запустили мощный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем» В программе только важные аспекты: — troubleshooting Docker и образов — диагностика сетевых проблем — настройка readiness/liveness probes — отладка pod’ов, деплоев и ingress — анализ логов контейнеров и кластера — разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам 48 часов доступен со скидкой 25% ↗️ Пройти курс на Stepik	1 222
8	Почему ICMP redirect считается дырой в безопасности ICMP redirect это сообщение которое роутер отправляет хосту: “для этого назначения есть путь лучше, используй вот этот шлюз”. Хост получает сообщение и обновляет свою таблицу маршрутизации на лету, без какого-либо подтверждения. Проблема в том что никакой аутентификации нет. Любой хост в сегменте может отправить ICMP redirect от имени шлюза и перенаправить трафик жертвы через себя. Классический MITM без особых усилий: жертва продолжает думать что общается напрямую, трафик идёт через атакующего. ⏺Проверяем включены ли redirects на Linux: sysctl net.ipv4.conf.all.accept_redirects sysctl net.ipv4.conf.all.send_redirects 1 означает включено. Отключаем: sysctl -w net.ipv4.conf.all.accept_redirects=0 sysctl -w net.ipv4.conf.all.send_redirects=0 echo "net.ipv4.conf.all.accept_redirects=0" >> /etc/sysctl.conf echo "net.ipv4.conf.all.send_redirects=0" >> /etc/sysctl.conf На Cisco роутер по умолчанию отправляет redirects. Отключаем на интерфейсе: interface Gi0/0 no ip redirects ⏺Отдельная история с secure_redirects: Linux по умолчанию принимает redirects только от шлюзов из своей таблицы маршрутизации. Это частичная защита, но не полная: если атакующий находится на том же сегменте что и шлюз, ограничение не помогает. sysctl net.ipv4.conf.all.secure_redirects N.A.	1 650
9	Настройка WireGuard: сервер, клиент, роутинг WireGuard проще IPsec и OpenVPN по конфигурации, быстрее поднимается и меньше точек где можно ошибиться. Вот минимальная рабочая конфигурация. Сервер Генерируем ключи: wg genkey \| tee /etc/wireguard/server_private.key \| wg pubkey > /etc/wireguard/server_public.key Конфиг сервера /etc/wireguard/wg0.conf: [Interface] PrivateKey = <server_private_key> Address = 10.0.0.1/24 ListenPort = 51820 PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [Peer] PublicKey = <client_public_key> AllowedIPs = 10.0.0.2/32 Включаем форвардинг и поднимаем интерфейс: sysctl -w net.ipv4.ip_forward=1 echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf wg-quick up wg0 systemctl enable wg-quick@wg0 Клиент wg genkey \| tee /etc/wireguard/client_private.key \| wg pubkey > /etc/wireguard/client_public.key Конфиг клиента: [Interface] PrivateKey = <client_private_key> Address = 10.0.0.2/24 DNS = 1.1.1.1 [Peer] PublicKey = <server_public_key> Endpoint = <server_ip>:51820 AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 25 wg-quick up wg0 Проверка wg show ping 10.0.0.1 curl ifconfig.me wg show покажет активные peer-ы, последнее рукопожатие и переданный трафик. Если handshake давно не было, туннель не установлен. N.A.	1 493
10	🔈 Новый VPS/VDS-сервис от упоротых инфраструктурщиков Давно дружим с CORTEL, это ребята про enterprise решения для крупняка. Сейчас они запустили отдельный бренд для аренды VPS/VDS — Serverum. Это сервис, где можно выбрать VPS, оплатить и сразу начать пользоваться. Подойдёт для dev/stage-сред, тестовых стендов, ботов, pet-проектов, небольших сервисов и других задач, где нужен сервер без лишней возни. Внутри: — собственная проприетарная платформа — отечественные решения — защищённая инфраструктура — низкие цены — живая поддержка от инженерной команды Сейчас ребята запускают первых пользователей и собирают честную обратную связь от тех, кто реально работает с инфраструктурой. Можно зайти, потыкать, взять VPS под задачу и написать фидбек. 👉 Serverum.ru	1 255
11	Почему traceroute показывает асимметричный путь и когда это нормально Запускаешь traceroute до хоста и видишь что хопы идут через один город, а ответы приходят явно другим путём. Или часть хопов показывает латентность выше чем финальный хост. Выглядит как проблема, но чаще всего это просто нормальная работа интернета. ⏺IP-маршрутизация не гарантирует симметрию. Пакет от тебя до хоста и пакет обратно идут независимо, каждый по своей таблице маршрутизации на каждом хопе. BGP на разных AS выбирает пути по своим политикам, и нет никакого механизма который бы согласовывал прямой и обратный путь. Латентность растёт а потом падает к финальному хопу, это тоже не аномалия. Промежуточные роутеры отвечают на TTL exceeded с низким приоритетом, часто через менее оптимальный интерфейс. Финальный хост отвечает нормально. Цифры на хопах показывают не задержку пути а задержку до конкретного роутера с его стороны. Смотрим путь в обе стороны: traceroute 8.8.8.8 mtr --report 8.8.8.8 mtr показывает потери и латентность в реальном времени по каждому хопу, намного информативнее одного traceroute. Когда асимметрия это реальная проблема: stateful firewall или NAT на пути видит только половину сессии. Пакеты в одну сторону проходят, в другую дропаются потому что состояние соединения не было установлено через этот узел. mtr --report --report-cycles 20 <IP> Если конкретный хоп показывает стабильные потери только в одну сторону, вот где проблема. N.A.	1 753
12	Что происходит когда OSPF area 0 теряет связность Area 0 это backbone. Все остальные area обязаны быть физически или логически подключены к ней. Если area 0 разваливается на части, OSPF не пересчитывает маршруты в обход, он просто перестаёт видеть часть сети. Два роутера в area 0 потеряли связь между собой. Каждый считает что его кусок backbone и есть вся сеть. Area которые висят за каждым из них становятся недостижимы с другой стороны. Никаких fallback, никакого альтернативного пути если он не был настроен заранее. Смотрим что происходит с соседями и LSA: show ip ospf neighbor show ip ospf database show ip ospf database summary Если в базе данных пропали LSA от роутеров на другой стороне разрыва, связность потеряна. Маршруты до их сетей исчезнут из таблицы маршрутизации. show ip route ospf Временное решение пока чинится физика: virtual-link через транзитную area. Натягиваем логический туннель между двумя ABR через area которая ещё жива: router ospf 1 area 1 virtual-link <router-id соседнего ABR> На обоих ABR с обеих сторон разрыва. Virtual-link восстанавливает связность area 0 поверх transit area. N.A.	2 336
13	Вебинар MPLS в маршрутизаторах ESR. Часть 1. L2VPN! Мы обещали вернуться с подробностями, и мы это делаем. Пришло время окончательно разобраться, почему MPLS называют «слоем 2.5» и как заставить его работать на благо вашей сети. 📌 1 июня 2026 (понедельник) 🕐 14:00 (по МСК) Начинаем серию вебинаров по технологии, которая не теряет актуальности и остается базой для современных сетей. 📚 Что разберем на первой встрече: ➖Вспомним теорию — зачем вообще нужен MPLS и почему его называют «L2.5» ➖L2VPN Martini mode ➖L2VPN Kompella mode 🎙 Спикер: Алексей Листаров — инженер с многолетним опытом работы в крупном операторе связи. Сертифицированный преподаватель нашего авторизованного учебного центра Академии Eltex. 🔗 Регистрация Готовьте свои вопросы по конфигурации, будем разбираться вместе! #eltex #eltexcm #webinar #вебинар #esr #mpls #kompella #martini #mode @eltexcm #реклама О рекламодателе	1 021
14	Почему после замены коммутатора половина сети перестала работать Заменили коммутатор, всё подключили, часть хостов работает, часть нет. Физически всё поднято, линки горят. Начинается час диагностики. Обычно проблема в одном из трёх Новый коммутатор пришёл с дефолтной конфигурацией. Все порты в VLAN 1, транки не настроены. Хосты которые работают находятся в VLAN 1 и просто повезло. Остальные VLANы не существуют на новом железе. show vlan brief show interfaces trunk Если VLANы не созданы или транк не поднят, вот оно. STP выбрал новый коммутатор Root Bridge потому что у него меньший MAC или приоритет не был выставлен. Топология пересчиталась, часть портов ушла в blocking. Хосты за этими портами недоступны. show spanning-tree show spanning-tree detail \| include root Смотрим кто стал Root и почему. Если новый коммутатор, выставляем приоритет обратно на нужное железо: spanning-tree vlan 1 priority 4096 Старый коммутатор работал с negotiated duplex или speed, новый договорился иначе. Часть портов поднялась в half-duplex, отсюда коллизии и потери. show interfaces Gi0/1 \| include duplex Если видим half-duplex там где не должно быть, фиксим явно: interface Gi0/1 duplex full speed 1000 N.A.	2 241
15	У FirstVDS проходит акция «Битва Гиков» Прямо сейчас можно заказать новый VDS со скидкой до 30%, подключить спецтариф с фиксированной ценой на всё время использования сервера, а заодно поучаствовать в онлайн‑игре и розыгрыше призов. Среди призов — PS5 Pro 2 ТБ, Steam Deck OLED 512 ГБ, и сертификаты на баланс. За призами! 🎮 #реклама О рекламодателе	1 282
16	Как ведёт себя сеть при split-brain в HSRP Два роутера в HSRP обмениваются hello-пакетами каждые 3 секунды. Если связь между ними пропадает, каждый решает что сосед умер и становится Active. Оба держат один виртуальный IP, оба отвечают на ARP-запросы своим MAC. Клиенты в этот момент делятся на два лагеря в зависимости от того чей ARP-ответ пришёл последним. Половина трафика идёт через один роутер, половина через другой. Если маршруты на них разные, часть сессий рвётся, часть работает. Отлаживать это неприятно потому что проблема плавающая и воспроизводится через раз. Смотрим состояние HSRP и кто сейчас Active: show standby brief show standby Если оба показывают Active, split-brain в действии. Проверяем доступность между роутерами: ping <IP соседнего роутера> source <интерфейс HSRP> Чаще всего причина не в роутерах а в коммутаторе между ними: упал транк, слетел VLAN, сработал STP. Hello-пакеты не проходят, оба уходят в Active. show interfaces trunk show spanning-tree vlan <ID> N.A.	2 072
17	Что происходит когда два DHCP-сервера отвечают на один запрос Подключил кто-то в офисе домашний роутер к корпоративной сети, или подняли новый DHCP и старый не выключили. Оба слышат broadcast, оба отвечают. Клиент берёт первый пришедший offer. Не правильный, а именно первый. Если левый сервер ответил быстрее, клиент получает адрес из чужого пула, чужой шлюз, чужой DNS. Настроен, но в сеть не ходит или ходит куда не надо. Хуже когда пулы пересекаются: два клиента получают одинаковый IP и оба теряют связь. Без каких-либо ошибок на их стороне. Смотрим кто вообще отвечает на DHCP в сегменте: sudo tcpdump -i eth0 port 67 or port 68 -n nmap --script broadcast-dhcp-discover Если в выводе несколько Server Identifier, проблема подтверждена. Лечится DHCP Snooping на коммутаторе: офферы разрешены только с доверенных портов, со всех остальных дропаются: ip dhcp snooping ip dhcp snooping vlan 10 interface Gi0/1 ip dhcp snooping trust interface range Gi0/2 - 24 no ip dhcp snooping trust N.A.	2 076
18	Ethernet OAM (802.1ag) с Linux и FRRouting Ethernet OAM (Operations, Administration and Maintenance) по стандарту 802.1ag позволяет контролировать доступность и состояние линков на уровне L2. На Linux можно использовать утилиты eth-oam для генерации OAM-сообщений (Continuity Check Messages, Loopback, Link Trace). Пример проверки линка: # Проверка доступности линка между хостами через CFM Continuity Check eth-oam-ccm -i eth0 -m 1 -t 10 Где -i — интерфейс, -m — Maintenance Association ID, -t — интервал в секундах. Для интеграции с FRRouting можно настроить уведомления о недоступности линка и динамически изменять маршруты. Например, при падении линка BGP-сессия будет разорвана и маршруты уйдут на резервный путь. Дополнительно можно использовать Loopback и Link Trace для диагностики проблем: # Loopback запрос к соседнему устройству eth-oam-lb -i eth0 -m 1 # Trace путь до узла через L2 eth-oam-lt -i eth0 -m 1 -d <MAC-адрес-соседа> N.A.	2 094
19	Что такое IX и как трафик идёт внутри него IX (Internet Exchange) это физическая точка где провайдеры, CDN и крупные сети подключаются друг к другу напрямую. Вместо того чтобы гонять трафик через транзитного провайдера и платить за каждый гигабит, участники обмениваются трафиком напрямую и бесплатно между собой. Крупнейшие точки обмена: DE-CIX во Франкфурте, AMS-IX в Амстердаме, MSK-IX в Москве. Через DE-CIX проходит больше 10 Тбит/с в пике. Как устроено внутри Физически IX это один большой коммутатор (или несколько связанных), к которому все участники подключают свои роутеры. Эта общая среда называется IXP fabric. Каждый участник получает порт и IP-адрес в общей подсети IX. Дальше всё через BGP. Каждый участник поднимает BGP-сессии с теми с кем хочет обмениваться трафиком, анонсирует свои префиксы и получает чужие. Никакой автоматики, только явные пиринговые договорённости. Route Server Чтобы не поднимать сотни BGP-сессий с каждым участником отдельно, большинство IX предоставляют Route Server. Подключаешься к одному RS, получаешь маршруты от всех участников кто тоже подключён к RS. Можно фильтровать что принимать и что анонсировать. router bgp 65001 neighbor 193.178.185.1 remote-as 65000 neighbor 193.178.185.1 description MSK-IX Route Server Как трафик идёт внутри Пакет от пользователя провайдера А до сервера в сети провайдера Б: роутер А смотрит BGP-таблицу, видит что префикс Б получен через IX, отправляет пакет напрямую на роутер Б через IXP fabric. Транзитный провайдер не участвует, задержка меньше, стоимость ниже. N.A.	2 663
20	Почему MTU 1500 в реальности никогда не 1500. Часть 2 Почему фрагментация не всегда спасает: Когда пакет не влезает в MTU промежуточного узла, тот должен отправить отправителю ICMP Fragmentation Needed. Отправитель получает сообщение, уменьшает размер сегмента и пробует снова. Это называется Path MTU Discovery и работает хорошо в теории. На практике многие сети и файерволы блокируют ICMP полностью. Сообщение Fragmentation Needed не доходит, отправитель продолжает слать большие пакеты, они дропаются без каких-либо уведомлений. Симптом характерный: мелкие запросы проходят нормально, крупные зависают или обрываются. Проверяем реальный Path MTU до хоста и тестируем конкретный размер пакета: tracepath 8.8.8.8 ping -M do -s 1400 8.8.8.8 Если ping с -M do (don’t fragment) падает на определённом размере, MTU на пути именно там. Как фиксить Выставляем MTU вручную на туннельном интерфейсе: ip link set dev tun0 mtu 1420 Для PPPoE на Cisco MSS clamp ограничивает размер TCP-сегментов на уровне роутера, не давая клиентам использовать значения выше допустимого: interface Dialer0 ip tcp adjust-mss 1452 N.A.	2 774

View all posts