Network Admin

:: vs 0.0.0.0: почему IPv6-сокет иногда принимает IPv4 Запускаешь сервер на ::, смотришь ss и видишь IPv6-сокет:

ss -lntp
LISTEN 0 128 [::]:443

Но подключиться к нему можно и по IPv4. Почему? Потому что IPv6-сокет с адресом :: может принимать IPv4-соединения через IPv4-mapped IPv6 addresses. Например:

IPv6:  ::ffff:192.0.2.10
IPv4:  192.0.2.10

Поведение зависит от параметра IPV6_V6ONLY. Проверить системное значение в Linux:

cat /proc/sys/net/ipv6/bindv6only

Если значение 0, dual-stack обычно разрешён:

[::]:443
 ├─ IPv6
 └─ IPv4

Если 1, IPv6-сокет принимает только IPv6:

[::]:443 → IPv6
0.0.0.0:443 → IPv4

Это может неожиданно влиять на firewall и конфигурацию сервиса. Например, администратор разрешил порт только в IPv6-конфигурации, увидел [::]:443 и решил, что IPv4 там не слушается. А приложение фактически принимает оба стека. Проверить реальные сокеты:

ss -lntp
ss -lntp4
ss -lntp6

Формула: 0.0.0.0 → все IPv4-адреса. :: → все IPv6-адреса, а при IPV6_V6ONLY=0 ещё и IPv4 через mapped addresses. Поэтому :::443 не всегда означает «только IPv6». N.A.

DROP и REJECT делают одно и то же? Нет. Оба блокируют трафик, но клиент получает совершенно разный результат. ⏺DROP просто выбрасывает пакет:

iptables -A INPUT -p tcp --dport 22 -j DROP

Клиент отправляет SYN, но в ответ ничего не приходит:

client → SYN → server
client ← ... ← timeout

TCP будет повторять попытки, пока не истечёт timeout. ⏺REJECT блокирует соединение и отправляет ответ:

iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with tcp-reset

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

client → SYN → server
client ← RST ← server

Поэтому поведение приложения будет разным: DROP → «сервер молчит» REJECT → «сервер отказал» Это важно и для диагностики. Если всё дропать, ошибка часто выглядит как timeout, хотя проблема на самом деле в firewall.

Для ICMP-трафика REJECT может отправить ICMP unreachable вместо TCP RST.

И ещё момент: DROP не делает систему «более защищённой» автоматически. Он просто не сообщает отправителю, что пакет был отвергнут. N.A.

Как проверить, что BGP-маршрут анонсируется, но не используется Ситуация классическая: префикс в BGP есть, а трафик упорно идёт другим путём. Почти всегда причина - не в самом анонсе, а в выборе best path или в том, как маршрут попал (или не попал) в RIB/FIB. 1️⃣Проверяем, что маршрут вообще пришёл по BGP Сначала убеждаемся, что апстрим реально его отдал. Cisco: show ip bgp <prefix> Важно смотреть: • есть ли несколько путей • какой помечен как *> (best) Если маршрута нет, дальше можно не копать. 2️⃣Сравниваем BGP vs routing table Маршрут может быть в BGP, но не установлен в основную таблицу. show ip route <prefix> Если вместо BGP стоит: static, OSPF или connected, то BGP просто проиграл по административной дистанции. Смотрим атрибуты best path Часто маршрут есть, но проигрывает по атрибутам. show ip bgp <prefix> Обращаем внимание на: ⏺Local Preference (самая частая причина) ⏺AS_PATH (длиннее — хуже) ⏺MED ⏺Weight (Cisco) Даже разница в LocalPref 100 vs 200 полностью меняет путь. 4️⃣Проверяем policy: route-map / filter Маршрут может быть принят, но «искажён» политикой. show run | section route-map show ip bgp neighbors <IP> received-routes Иногда route-map не режет маршрут, но меняет LocalPref или MED. 5️⃣Проверяем CEF / FIB Бывает, BGP и RIB ок, а в forwarding таблице другое. show ip cef <prefix> Если next-hop не тот, что ожидается — проблема на этапе установки в FIB. N.A.

Почему старые соединения идут по старому маршруту После изменения маршрута можно увидеть странную ситуацию: ip route уже показывает новый путь, но существующее TCP-соединение продолжает работать через старый. Это нормально. ⏺Маршрут не пересчитывается как отдельное решение для каждого TCP-сеанса Когда приложение открывает соединение, ядро выбирает маршрут для этого потока. Дальше пакеты существующего соединения обрабатываются с учётом уже созданного состояния. Поэтому изменение:

ip route replace default via 192.168.1.1

не означает, что все уже установленные TCP-соединения мгновенно начнут использовать новый gateway. ⏺Особенно заметен conntrack На firewall или NAT устройство хранит состояние соединения: conntrack -L Там может находиться запись ESTABLISHED, по которой последующие пакеты распознаются как часть уже существующего потока. Это особенно важно при NAT: кроме маршрута существует ещё состояние трансляции адресов и портов. ⏺Новые соединения уже могут пойти иначе После изменения маршрута:

ip route get 8.8.8.8

может показать новый интерфейс или gateway. Поэтому одновременно возможна ситуация, когда новые подключения используют новый путь, а старые продолжают работать по прежнему состоянию. ⏺Почему это важно при переключении каналов При аварийном переключении WAN недостаточно просто заменить default route. Старые TCP-сессии могут продолжать использовать прежнее состояние, а NAT/Firewall может дополнительно удерживать их до таймаута. Из-за этого после failover часто наблюдается:

новые подключения → работают
старые подключения → timeout

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

ip route get <destination>
sudo conntrack -L
ss -nt

N.A.

TCP-флаги, которые нельзя блокировать бездумно Фильтровать TCP-флаги кажется удобным способом усилить firewall: разрешить только «нормальные» пакеты и всё остальное отбросить. Но некоторые флаги участвуют не только в установлении соединения, и их бездумная блокировка может ломать уже работающие TCP-сессии. ⏺SYN - установка соединения Без SYN новый TCP-сеанс просто не начнётся:

Client → SYN → Server
Client ← SYN/ACK ← Server
Client → ACK → Server

Если firewall отбрасывает входящие SYN, сервер не сможет принимать новые TCP-соединения. ⏺ACK - подтверждение данных ACK встречается практически во всём нормальном TCP-трафике после установки соединения. Например:

Client → PSH, ACK
Server → ACK

Правило вида:

iptables -A INPUT -p tcp ! --tcp-flags ACK ACK -j DROP

может выглядеть логично, но нельзя просто считать отсутствие ACK признаком атаки: SYN-пакет нового соединения как раз приходит без ACK. Поэтому обычно проверяют состояние соединения через conntrack, а не только наличие флага. ⏺RST - аварийное закрытие RST сообщает другой стороне, что TCP-соединение больше не существует. Например, приложение не слушает порт:

Client → SYN → Server
Client ← RST ← Server

Если firewall блокирует RST без понимания контекста, клиент может вместо быстрого отказа получить долгий timeout. RST также используется для завершения некоторых некорректных или уже несуществующих соединений. ⏺FIN - нормальное закрытие FIN означает: «я больше не буду отправлять данные».

Client → FIN, ACK
Server → ACK
Server → FIN, ACK
Client → ACK

Блокировка FIN может превращать нормальное закрытие соединения в зависание до срабатывания timeout. ⏺Что делать вместо фильтрации отдельных флагов Для stateful firewall обычно правильнее разрешать уже установленные соединения:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

А новые подключения контролировать отдельно:

iptables -A INPUT -p tcp --dport 22 \
    -m conntrack --ctstate NEW -j ACCEPT

То есть проверять не просто «какие TCP-флаги приехали», а в каком состоянии находится соединение. Особенно опасны универсальные правила вроде:

-p tcp --tcp-flags ALL NONE -j DROP
-p tcp --tcp-flags ALL ALL -j DROP

Они действительно могут отсеивать часть мусорного трафика, но сами по себе не являются полноценной защитой TCP. N.A.

XDP/eBPF для QoS: приоритизация UDP-трафика в Linux В реальном времени аудио и видео сильно чувствительны к задержкам и джиттеру. Даже небольшие перегрузки сети могут испортить VoIP или RTP-поток. XDP — это точка входа пакета в Linux, прямо в драйвере NIC. eBPF-программа, загруженная в XDP, может: ➖маркировать пакеты (skb->mark) для последующей обработки tc/qdisc ➖отбрасывать или редиректить трафик ➖собирать статистику по IP, портам или протоколам В связке с tc или iptables можно реализовать приоритизацию UDP-трафика для VoIP/RTP без изменения приложений. ⏺Например: приоритизация UDP-порта 5004 (RTP) и сбор статистики Создаём простую eBPF карту для подсчёта пакетов по IP/портам: struct bpf_map_def SEC("maps") packet_count = { .type = BPF_MAP_TYPE_HASH, .key_size = sizeof(struct flow_key), .value_size = sizeof(__u64), .max_entries = 1024, }; В XDP-программе проверяем порт и увеличиваем счётчик: if (udp->dest == bpf_htons(5004)) { __u64 *cnt, zero = 0; cnt = bpf_map_lookup_elem(&packet_count, &key); if (!cnt) bpf_map_update_elem(&packet_count, &key, &zero, BPF_NOEXIST); else __sync_fetch_and_add(cnt, 1); skb->mark = 46; // DSCP EF для QoS } Загружаем XDP на интерфейс: ip link set dev eth0 xdp obj rtp_qos.o sec xdp Проверяем статистику через bpftool: bpftool map dump id <map_id> Теперь все RTP-пакеты маркируются для максимального приоритета, а количество пакетов можно отслеживать в реальном времени. N.A.

Что крупные заказчики проверяют на пилоте NGFW Чем крупнее сеть, тем выше требования к NGFW. Выдержит ли он пиковую нагрузку при активных IPS и инспекции зашифрованного трафика? Сохранятся ли соединения при отказе узла? Как отработает переключение между каналами при росте задержек и потере пакетов? Обнаружит ли обращения к ИИ-сервисам в обход ИБ? За год Novum прошёл проверку в реальной эксплуатации у крупных заказчиков. 📅 1 октября, 11:00 (мск) «Ideco NGFW Novum год спустя: новые возможности для крупных инфраструктур» Расскажем: ▪️ что нового в масштабировании, отказоустойчивости и управлении; ▪️ что проверяли заказчики на пилотах и с какими результатами; ▪️ SD-WAN и QoS на нагруженных каналах; ▪️ Shadow AI Discovery: 84 AI-сервиса, распознавание без расшифровки TLS; ▪️ независимые оценки и планы развития. Онлайн с записью, участие бесплатное. Зарегистрироваться ➡️

Почему SSL/TLS соединения падают при смене времени Даже когда сертификаты вроде валидны и сервер доступен, HTTPS-сессии могут обрываться или выдавать ошибки handshake. Основная причина в том, что TLS строго проверяет время: если системные часы сервера или клиента сильно отстают или опережают реальное время, сертификаты могут считаться просроченными или ещё не действительными. ⏺Ещё одна частая причина - неправильно настроенный NTP. Без синхронизации часы расходятся, и handshake с клиентом завершается с ошибкой. Иногда сбои связаны с expired сертификатами, которые дополнительно усугубляют проблему, особенно на новых соединениях. Как проверить

show ntp status

Проверка синхронизации времени на сетевых устройствах.

date

Смотрим системное время на сервере.

openssl s_client -connect <host>:443

Анализ TLS handshake и проверки сертификатов.

timedatectl

Проверка часового пояса и синхронизации на Linux.

show logging | include NTP

N.A.

Основные причины ошибки «No route to host» Когда приложение не может подключиться к серверу, No route to host часто ошибочно воспринимают как проблему самого сервера. На деле причина может находиться на любом участке маршрута. 1️⃣На хосте нет маршрута Linux должен понимать, через какой интерфейс и gateway отправлять пакет. Проверить конкретный маршрут можно:

ip route get 10.10.20.15

Если подходящего маршрута нет, пакет не будет отправлен. 2️⃣ Неправильная маска или gateway Например, сервер считает адрес назначения локальным из-за неправильной маски и пытается найти его через ARP вместо отправки на маршрутизатор. Проверить:

ip addr
ip route

3️⃣ Проблема с ARP Маршрут может существовать, но следующий hop не отвечает на ARP-запросы:

ip neigh

Если рядом с адресом появляется:

FAILED
INCOMPLETE

хост не смог разрешить IP в MAC. 4️⃣ Firewall возвращает ICMP unreachable No route to host не всегда означает, что маршрута действительно нет. Firewall может отправить ICMP Destination Host Unreachable, после чего приложение получит именно такую ошибку. Проверить правила:

sudo nft list ruleset

5️⃣ Маршрутизатор не знает путь дальше Ваш сервер может иметь правильный default route, но следующий маршрутизатор не обязан знать, где находится сеть назначения. Проверить путь:

traceroute -n 10.10.20.15

6️⃣ Обратный маршрут сломан Пакет может успешно дойти до сервера, но ответ пойдет через другой маршрут или вообще не найдет пути обратно. На сервере полезно проверить:

ip route get <IP-клиента>

Особенно часто это проявляется при нескольких интерфейсах, VRF или policy routing. 7️⃣ Маршрут есть, но интерфейс фактически не работает Например, в таблице:

10.10.20.0/24 dev eth1

но сам eth1 находится в DOWN или физический линк не поднят. Проверить:

ip link show eth1

Поэтому No route to host лучше читать не как «сервер недоступен», а как «на этом этапе сеть не смогла доставить пакет дальше». Сначала смотрим маршрут, затем next-hop, ARP и уже после этого разбираемся с firewall и удалённым хостом. N.A.

DSCP remarking: где пакет может потерять свой приоритет DSCP хранится прямо в IP-заголовке и используется устройствами сети для выбора очереди и политики обработки. Например, приложение отправило пакет с:

DSCP = EF (46)

На первом маршрутизаторе он попал в priority queue. Но дальше значение может измениться:

Host
 ↓
Router 1      DSCP 46
 ↓
Router 2      DSCP 8
 ↓
Router 3      DSCP 8
 ↓
Server

Это называется DSCP remarking - устройство переписывает значение DSCP. Причин может быть несколько. Например, на границе сети оператор разрешает клиенту использовать только определённые классы:

DSCP 46 → DSCP 10
DSCP 34 → DSCP 8
остальные → DSCP 0

Или коммутатор доверяет DSCP только на uplink, а на access-портах переписывает его:

PC → Switch
     DSCP 46
       ↓
   policy-map
       ↓
     DSCP 0

Ещё вариант - политика QoS на WAN. Перед отправкой трафика в другой сегмент сеть может изменить маркировку, чтобы она соответствовала локальной QoS-модели. Важно: изменение DSCP не меняет сам пакет или приложение. Меняется только поле, по которому следующие устройства принимают решения о QoS. Поэтому при проблемах с приоритетным трафиком недостаточно посмотреть DSCP на сервере:

tcpdump → DSCP 0

Это ещё не означает, что приложение отправляло DSCP 0. Он мог быть изменён где-то по пути:

Host
 ↓
Access switch
 ↓
Distribution
 ↓
WAN router
 ↓
Provider
 ↓
Server

Если QoS внезапно перестал работать, полезно проверять DSCP на разных участках пути и искать место, где:

46 → 46 → 46 → 0
             ↑
          remarking

Именно там находится политика, которая изменила классификацию пакета. N.A.

MPLS PHP: зачем предпоследний LSR снимает label В MPLS пакет обычно идет через несколько LSR:

PE1 → P1 → P2 → PE2

PE1 добавляет label:

IP → [Label 100] → P1 → P2 → PE2

На P1 и P2 не нужно заглядывать в IP-заголовок. Они работают по label: смотрят в LFIB, меняют label и отправляют пакет дальше. Но возникает вопрос: зачем заставлять последний P-router делать ещё одну операцию? Для этого используется PHP - Penultimate Hop Popping. P2, то есть предпоследний LSR, заранее знает, что следующий hop — PE2. Вместо обычного swap:

[Label 100]
    ↓
[Label 200]

он снимает label полностью:

[Label 100]
    ↓
IP packet
    ↓
PE2

PE2 получает уже обычный IP-пакет и не тратит ресурсы на удаление последнего MPLS label перед дальнейшей обработкой. Обычно для этого используется специальный Implicit Null label. Он фактически означает: «на следующем hop label уже не нужен». Получается такая цепочка:

PE1          P1          P2          PE2
 │            │           │           │
 │ Label 100  │ Label 200 │           │
 ├───────────►├──────────►├───────────►│
 │            │           │   IP       │
 │            │           │  без label │

Почему именно предпоследний, а не последний? Потому что если последний PE всё равно должен обработать пакет дальше как IP, нет особого смысла сначала передавать ему MPLS label, чтобы он тут же его снял. PHP переносит эту работу на предыдущий LSR и оставляет PE уже готовый к обычной обработке пакета. В итоге путь выглядит так:

Ingress PE → Label switching → PHP → Egress PE

Именно поэтому в MPLS часто можно увидеть: на предпоследнем LSR label уже исчез, хотя пакет ещё не дошёл до конечного PE. N.A.

9 октября в Москве пройдет СисАдмин 2026 — большая конференция для системных администраторов, ИТ-менеджеров, инженеров и специалистов по поддержке инфраструктуры. 📍 Москва, кластер «Ломоносов» 📅 9 октября 2026 🗣 Офлайн-формат, один день Участие бесплатное, нужно только зарегистрироваться на https://tglink.io/bf34972f25c2f4?erid=2W5zFHae1UD. О чем конференция ✔️ Управление рабочими местами на Windows, Linux, macOS; ✔️ MDM/UEM/EMM; ✔️ Администрирование техники Apple; ✔️ Управление ИТ-инфраструктурой и мониторинг; ✔️ Информационная безопасность для системных администраторов; ✔️ Миграция на Linux; ✔️ Организация работы ИТ-отдела и поддержки и многое другое. 📌 СисАдмин 2026 — это более 700 участников, ИТ-выставка, насыщенная программа, неформальное общение и квиз с призами. Вы можете не только прийти как гость, но и бесплатно выступить с докладом. Для этого оставьте заявку на сайте. До встречи на СисАдмин 🙌 #реклама О рекламодателе

Loop Guard vs Root Guard: в чем разница Оба механизма относятся к STP, но защищают от совершенно разных аварий. Loop Guard нужен, когда порт перестал получать BPDU, хотя раньше получал их. Например, между двумя коммутаторами есть STP-линк:

SW1 ───────── SW2
     BPDU →

SW2 должен получать BPDU и держать порт в blocking/discarding. Если BPDU внезапно перестали доходить из-за односторонней проблемы линка, SW2 может решить, что путь свободен, и перевести порт в forwarding. Получается L2-петля. Loop Guard обнаруживает потерю ожидаемых BPDU и не дает порту перейти в forwarding:

BPDU пропали
     ↓
Loop Guard
     ↓
порт остаётся в loop-inconsistent

Root Guard решает другую проблему. Допустим, ваш коммутатор уже является Root Bridge:

        ROOT
       SW1
      /   \
    SW2   SW3

Кто-то подключает новый коммутатор с более низким Bridge ID:

SW1 ─── SW2 ─── SW4
              ↑
       новый Root претендент

SW4 начинает отправлять superior BPDU. Без защиты STP может перестроить дерево и выбрать SW4 корневым. Root Guard на порту SW2 не позволяет этому случиться. При получении superior BPDU порт уходит в root-inconsistent и не становится путем к новому Root Bridge. То есть запомнить можно так:

Loop Guard
→ BPDU неожиданно исчезли
→ защищает от L2-петли

Root Guard
→ пришёл superior BPDU
→ защищает позицию Root Bridge

И ещё важный момент: BPDU Guard - это третий сценарий. Он обычно ставится на access/edge-портах. Если туда вообще приходит BPDU, порт блокируется, потому что за ним не должен находиться STP-коммутатор. Получается:

BPDU пришёл туда, где его быть не должно
→ BPDU Guard

BPDU перестал приходить туда, где он должен быть
→ Loop Guard

Пришёл superior BPDU и пытается изменить Root
→ Root Guard

Разница не в том, что один «сильнее» другого. Они реагируют на три разные аномалии STP. N.A.

MAB: когда MAC заменяет 802.1X 802.1X предполагает, что устройство умеет пройти аутентификацию через EAP. Но что делать с устройством вроде принтера, IP-телефона или камеры, где полноценного 802.1X может не быть? Для этого используют MAB - MAC Authentication Bypass. Схема выглядит примерно так:

Устройство
    │
    │ MAC
    ↓
Access Switch
    │
    │ RADIUS
    ↓
   AAA

Switch узнаёт MAC устройства и отправляет его на RADIUS как идентификатор:

Calling-Station-Id = AA:BB:CC:DD:EE:FF

RADIUS проверяет MAC по своей базе и может вернуть, например, VLAN:

Access-Accept
    ↓
VLAN 30

После этого порт получает доступ в соответствующий VLAN. Но MAB - это не полноценная замена 802.1X по уровню безопасности. MAC-адрес не является секретом. Его можно узнать и подменить. Поэтому типичная политика выглядит так:

802.1X
  ↓
если устройство умеет → нормальная аутентификация

нет ответа 802.1X
  ↓
MAB
  ↓
проверка MAC

Например:

Ноутбук
   ↓
802.1X → пользователь/сертификат → VLAN 20

IP-телефон
   ↓
802.1X не поддерживает
   ↓
MAB → MAC известен RADIUS → VLAN 30

Неизвестное устройство
   ↓
MAB → Access-Reject

Поэтому MAB обычно используют как fallback для устройств, которые физически не могут пройти 802.1X, а не как более простой способ аутентификации всех клиентов. 🔥И важный момент: MAB не означает, что switch «доверяет MAC». Он лишь использует MAC как идентификатор, который передаётся AAA-системе для принятия решения о доступе. N.A.

RIB vs FIB divergence в high-end роутерах В routing table (RIB) маршрут отображается корректно: next-hop есть, метрики нормальные, протокол сходится. Но data-plane не использует этот маршрут - пакеты не уходят, и кажется, что сеть «работает частично». Причины чаще всего связаны с ограничениями ASIC, рекурсивным разрешением next-hop или проблемами с adjacency. Для диагностики сначала проверяем, как маршрут запрограммирован в FIB/CEF:

show ip cef <prefix> detail

Если next-hop не разрешается через adjacency, пакеты не будут пересылаться:

show adjacency detail
show ip arp <next-hop>

На high-end платформах полезно проверить hardware table и возможные дропы:

show platform hardware qfp active feature cef drop

Решение обычно включает корректировку рекурсивного next-hop, перераспределение нагрузки по ASIC, а иногда - оптимизацию L3 adjacency и проверку максимального количества маршрутов/entry в FIB для high-end маршрутизаторов. N.A.

gNMI vs SNMP polling Представим сеть из сотни коммутаторов. Нужно следить за загрузкой интерфейсов. Классический вариант - SNMP polling:

NMS ──→ switch
       "дай counters"

NMS ──→ switch
       "дай counters"

NMS ──→ switch
       "дай counters"

Сервер сам регулярно опрашивает устройства. Например, раз в 60 секунд. Проблема появляется, когда нужны более частые данные. При интервале 60 секунд вы можете не увидеть короткий всплеск:

60 sec ──────────────────────────
        ↑
      burst

Через минуту SNMP получит уже совершенно нормальное значение. gNMI может работать иначе - через streaming telemetry. Устройство устанавливает долгоживущую сессию с collector’ом и само отправляет изменения или значения с заданным интервалом:

switch
  │
  ├── update
  ├── update
  ├── update
  └── update
        ↓
     collector

Например, можно подписаться на конкретный путь:

/interfaces/interface[name=Ethernet1]/state/counters

И получать обновления без постоянного GET со стороны collector. Главное отличие:

SNMP polling
NMS → GET → device
NMS → GET → device
NMS → GET → device


gNMI telemetry
device ─────────→ collector
device ─────────→ collector
device ─────────→ collector

Но gNMI не означает автоматически «данные всегда быстрее и лучше». Если настроить telemetry слишком агрессивно, сотни устройств начнут постоянно отправлять большое количество данных. Collector, сеть и сами устройства тоже получают нагрузку. Поэтому инженерная задача здесь не просто заменить SNMP на gNMI, а выбрать правильную модель:

редкие counters
    ↓
polling может быть достаточен

частые изменения состояния
    ↓
streaming telemetry

критические события
    ↓
ON_CHANGE / event-driven

SNMP отлично подходит для классического мониторинга и огромного количества уже существующей инфраструктуры. gNMI интереснее там, где нужно получать более детальное состояние сети практически в реальном времени, особенно при автоматизации и работе с YANG-моделями. N.A.

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.