Как проверить, что 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.

📂Как правильно документировать сеть, чтобы не потерять конфиги

Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.

1️⃣Сбор данных
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:

ip addr show          # список интерфейсов
ip route show         # таблица маршрутов
vtysh -c "show running-config"  # конфиги роутеров
show vlan brief       # VLAN на коммутаторах

2️⃣Структурирование: Систематизируем данные: топология, IP-план, протоколы, ACL/Firewall.
Пример таблицы IP:

Устройство | Интерфейс | IP           | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1         | eth0      | 10.0.1.1/24  | 10   | WAN
sw1        | vlan10    | 10.0.1.2/24  | 10   | серверная зона
sw2        | vlan20    | 10.0.2.1/24  | 20   | офисная зона
server1    | eth1      | 10.0.1.10/24 | 10   | база данных
server2    | eth1      | 10.0.1.11/24 | 10   | веб-сервер

3️⃣Version control: Сохраняем конфиги в Git. Каждый коммит с комментарием: что и зачем изменилось.

git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"

4️⃣Визуализация топологии: Diagram-as-code (Mermaid/Graphviz) или инструменты типа NetBox/Draw.io.
Пример Mermaid:

graph TD
    R1 --> SW1
    SW1 --> Server1
    SW1 --> Server2

5️⃣Автоматизация и backup: Скрипты для снятия конфигов и их сохранения в репозиторий или на NAS. Проверка актуальности backup. ✅

Полезные команды для контроля

git log --oneline --graph   # история изменений
diff old_config new_config  # что изменилось
ping 10.0.1.2              # проверить доступность после изменений

N.A.

ICMP: тестируем не только ping

На первый взгляд ping кажется простой командой, но ICMP - полноценный инструмент для диагностики сети и анализа маршрутов.

Что можно делать:
⏺Traceroute через ICMP помогает локализовать узкие места: задержки, потерю пакетов и переполненные маршрутизаторы.
⏺Даже если ping запрещён firewall, ICMP показывает, какие пакеты проходят, а какие блокируются.
⏺Анализ ICMP Time Exceeded и Destination Unreachable помогает понять поведение маршрутизаторов и Path MTU.

Как проверить:

# Traceroute через ICMP
traceroute -I 8.8.8.8

# Ping с разным TTL
ping -t 10 -c 5 8.8.8.8

# Проверка Path MTU
ping -M do -s 1472 8.8.8.8

Как можно сломать:
➖Firewall блокирует все ICMP → даже ping до localhost не покажет проблем маршрутизации.
➖MTU mismatches → пакеты теряются, но стандартный ping не всегда это показывает.
➖Неправильная маршрутизация → ICMP показывает только, что узел недоступен, но не где именно.

N.A.

BFD vs OAM: мониторинг линка

✅ BFD (Bidirectional Forwarding Detection) и OAM (Operations, Administration, Maintenance) выглядят похоже, оба следят за состоянием канала, но работают по разному и для разных целей.

BFD мгновенно реагирует на падение соседнего узла. 

Если OSPF или BGP видят потерю маршрута за миллисекунды, трафик сразу переключается на резерв. Это незаменимо, когда важна скорость реакции сети и минимальные простои.

⏺OAM проверяет качество канала глубже. Он измеряет задержки, jitter, потери пакетов и целостность цепочки, не вмешиваясь в маршрутизацию.

OAM полезен для Ethernet, MPLS и сервисных линков, когда важно понять, почему соединение работает медленно или нестабильно.

Примеры. BFD на FRR:

bfd
peer 10.0.0.2
  minimum-interval 300
  detection-multiplier 3

OAM на Ethernet:

ethtool -S eth0

Суть в том, что BFD следит за «живостью» маршрутов, мгновенно подсказывая, что линк упал, а OAM позволяет увидеть качество канала, измерить реальные параметры передачи и понять, где появляются задержки или потери.

N.A.

Да, я богат и я этого не скрываю 😎

N.A.

Почему сеть сложнее приложений?

Приложение можно уронить и поднять обратно. В худшем случае - откатить релиз или перезапустить контейнер. 

Обычно страдает один сервис, и то временно.

✋С сетью так не получается. Она общая для всех. Один неудачный маршрут, ACL или изменение MTU - и сразу начинают сыпаться десятки сервисов, которые между собой вообще никак не связаны.

⏺Вот обычный пример: добавили «временное» firewall-правило или поменяли порядок ACL. Вроде бы для одного сервиса. Через час перестаёт работать авторизация, потом отваливается мониторинг, а позже выясняется, что часть трафика пошла асимметрично и stateful firewall начал резать ответы.

⏺Или другой кейс - поменяли MTU на одном сегменте. Ping ходит, интерфейсы up, но крупные TCP-сессии рвутся, VPN начинает вести себя странно, а приложение выглядит «нестабильным», хотя с ним ничего не делали.

Поэтому сеть не любит эксперименты в продакшене. Здесь нельзя просто «задеплоить и посмотреть». 

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

N.A.

Когда L2-ошибка страшнее L3

L3 ломается громко и понятно. Нет маршрута - трафик не идёт. traceroute обрывается, логика очевидна: ищем, где потерялся next hop.

L2 ведёт себя иначе. Ошибка может существовать долго и выглядеть как «плавающая» проблема. 

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

⏺Классический пример - L2-петля. Один лишний кабель или неправильно настроенный trunk, STP не сработал или был выключен «временно». В результате бродкаст и unknown unicast начинают размножаться, CPU на коммутаторах улетает в 100%, ARP-таблицы постоянно меняются. Сервисы вроде бы живы, но соединения рвутся, задержки скачут, пользователи жалуются на «рандом».

⏺Другой кейс - MAC-flapping. Один и тот же MAC адрес прыгает между портами. Для L3 всё выглядит нормально, IP есть, маршруты на месте. А на самом деле кадры ходят туда-сюда, сессии TCP рвутся, а причина скрыта глубоко на втором уровне.

Ещё хуже, когда проблема затрагивает control-plane. STP пересчитывается слишком часто, порты то блокируются, то открываются, и сеть сама себя дестабилизирует. Это выглядит как деградация приложений, хотя корень проблемы — обычный L2.

🔥Поэтому L2-ошибки опасны не масштабом, а коварством. Они не выключают сеть сразу, а превращают её в нестабильную среду, где всё вроде бы работает, но ничего не работает надёжно.

N.A.

Зачем ограничивать MAC-адреса на порту, если есть VLAN

VLAN изолирует трафик, но никак не ограничивает количество устройств за портом.

Для коммутатора access-порт по умолчанию готов принять десятки MAC-адресов, если они в одном VLAN.

⏺Типовой сценарий - под столом появляется неуправляемый свитч. Всё продолжает «работать», но на один порт внезапно приходит много MAC-адресов. CAM-таблица начинает активно обновляться, часть трафика уходит в unknown unicast, появляются задержки и странные обрывы сессий.

Port security нужен, чтобы зафиксировать ожидания от порта: здесь должно быть одно устройство или, максимум, телефон + ПК. Всё остальное — не штатная ситуация.

Как это выглядит в конфигурации (Cisco-подобный синтаксис):

interface GigabitEthernet1/0/10
 switchport mode access
 switchport access vlan 20
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky

Здесь порт примет максимум два MAC-адреса и запомнит их автоматически. При появлении третьего - трафик будет резаться и логироваться, без мгновенного падения порта.

Если нужен жёсткий вариант:

switchport port-security violation shutdown

Порт уйдёт в err-disable при нарушении. Полезно там, где точно не должно быть никаких сюрпризов.

Проверка состояния:

show port-security interface Gi1/0/10
show mac address-table interface Gi1/0/10

N.A.

Почему ACL лучше писать длиннее, но понятнее

Короткий ACL выглядит красиво и экономит строки, но на практике это почти всегда ловушка. 

Одно правило с кучей wildcard вроде «разрешить всё, кроме…» потом трудно проверить. Часто думаешь, что всё нормально, а в реальности блокируются нужные сервисы или остаются дыры.

⏺Длинный ACL читается как карта: каждое правило понятно, есть комментарий, сразу видно, кто и что может. Менять его проще, отлаживать проще, а шанс случайно сломать сеть падает к нулю.

Пример на Cisco:

! Короткое ACL — вроде работает, но что именно разрешено?
access-list 101 permit tcp any any eq 80
access-list 101 permit tcp any any eq 443
access-list 101 permit udp any any range 5000 6000

! Длинное ACL — сразу понятно, для чего каждая строка
! Веб-трафик
access-list 101 permit tcp any any eq 80 comment Web HTTP
access-list 101 permit tcp any any eq 443 comment Web HTTPS
! UDP для приложений
access-list 101 permit udp any any range 5000 6000 comment App UDP

Теперь ACL сам объясняет, что делает. Добавлять новые сервисы или проверять старые проще, а коллега через месяц сразу поймёт, что и зачем разрешено.

N.A.

Почему лучше явно задавать STP root, а не оставлять «по умолчанию»

Когда STP root не задан, сеть выбирает его сама - по наименьшему BID. Пока топология не меняется, всё выглядит стабильно и «работает». Проблемы начинаются в момент изменений.

Типичная ситуация: заменили коммутатор, обновили прошивку или просто перезагрузили часть сети.

⏺У нового устройства оказался ниже BID - и root bridge тихо переехал. STP пересчитался, часть портов ушла в blocking, а трафик пошёл по менее удачному пути.

Снаружи это выглядит как деградация сервисов. Увеличились задержки, появились таймауты, где-то просел throughput. Маршруты есть, линков хватает, но сеть стала «чуть медленнее», и искать начинают в приложениях.

Явно заданный root фиксирует логику сети. Вы заранее решаете, где должна сходиться L2-топология и через какие устройства идти основной трафик. Любые изменения в сети тогда либо не влияют на STP, либо сразу заметны.

Пример на Cisco:

spanning-tree vlan 10,20 priority 4096

Или проще:

spanning-tree vlan 10,20 root primary

Проверка:

show spanning-tree vlan 10

N.A.

Дедлайн Новый год стучится в дверь! 😊

Я думаю, что все устали и всем пора отдыхать, набираться сил. Все дедлайны позади, а о будущих думать пока не стоит! 😊

Я пожелаю Вам хороших каникул, счастья, здоровья, поменьше выгорания и успехов в новом году! 😊

С наступающим, 2026! 😊

Когда стоит настраивать ECMP, а когда он только мешает

ECMP выглядит как очевидное улучшение: несколько равных путей, больше пропускная способность, меньше перегрузок.

Для stateless-трафика и большого количества потоков это действительно работает хорошо.

⏺Проблемы начинаются там, где появляются stateful-сессии. ECMP распределяет трафик по хешу. Если хеш считается только по IP, разные TCP-сессии могут пойти по разным путям. А если по пути стоит stateful firewall, NAT или load balancer, ответы начинают возвращаться не тем маршрутом, где была создана сессия.

Типичный симптом: часть соединений работает, часть рвётся. Повторные попытки иногда проходят, иногда нет. Ping и traceroute выглядят нормально, а приложение ведёт себя нестабильно.

ECMP хорошо подходит для spine-leaf, DC-трафика, east-west потоков, где много коротких сессий и нет жёсткой привязки состояния к одному пути. Там он действительно даёт масштабирование.

А вот на edge, перед firewall или VPN, ECMP часто создаёт больше проблем, чем пользы. В таких местах один предсказуемый маршрут надёжнее двух «умных», которые могут внезапно поменять путь для части трафика.

⚡️Перед включением ECMP важно понимать, по каким полям считается хеш и кто дальше по цепочке хранит состояние.

N.A.

Почему стоит проверять резервные пути и failover

Redundant link сам по себе не гарантирует стабильность сети.

Даже если линк поднят и маршруты выглядят корректно, приложения могут страдать: маршрутизация не пересчиталась, firewall блокирует новый путь, ECMP разбил сессии неправильно.

Пример практики на Cisco:

show ip route
show ip cef
ping 10.0.0.2 source 10.0.0.1

⏺Лучше заранее имитировать отказ: поднять резервный линк, отключить основной и проверить, что трафик корректно уходит по backup. Так вы увидите реальные слабые места, которые не проявляются при просто «up» интерфейсе.

Failover стоит проверять регулярно - после изменений в конфигурации, апгрейда прошивки или добавления новых VLAN. Это снижает риск, что в момент инцидента резерв не сработает.

N.A.

5 случаев, когда ECMP мешает больше, чем помогает

ECMP (Equal-Cost Multi-Path) выглядит как очевидная оптимизация: несколько равных маршрутов - больше пропускная способность, меньше перегрузок.

Для некоторых сценариев это действительно работает, но есть ситуации, когда ECMP создаёт больше проблем, чем пользы.

1️⃣Stateful firewall или NAT: ECMP распределяет пакеты по хешу. Если дальше стоит stateful устройство, оно «ждёт» пакеты на одном пути. Когда часть пакетов идёт по другому, сессии рвутся, и соединения начинают ломаться.

2️⃣VPN-туннели: Хеширование ECMP может «разделять» пакеты одной сессии между линками. VPN-туннель теряет целостность, туннель падает или трафик идёт только в одну сторону.

3️⃣VoIP и real-time трафик: Голос и видео требуют последовательности пакетов. Если ECMP отправляет часть пакетов по другому пути, появляются дерганья, потеря качества и jitter.

4️⃣Мониторинг и логирование: Когда трафик идёт по разным линкам, становится сложно понять, где возникла проблема. Инструменты вроде NetFlow, sFlow или SNMP видят разрозненные потоки, а алерты путаются.

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

⏺В итоге ECMP отлично подходит для DC-трафика, spine-leaf или крупных east-west потоков, где много коротких сессий. На edge, перед stateful устройствами или для критичных приложений лучше использовать один предсказуемый маршрут - меньше «умной» логики, меньше плавающих проблем.

Пример на Linux:

ip route add 10.0.0.0/24 nexthop via 192.168.1.1 nexthop via 192.168.2.1

N.A.

Static route vs Dynamic route

Выбор между static и dynamic напрямую влияет на стабильность и управляемость сети.

⏺Static route - предсказуемая, простая и ломается редко. Отлично подходит для небольших сегментов или point-to-point линков, где топология почти не меняется. Минус - при изменениях сети маршруты нужно менять вручную. Static маршруты полезны как backup для критичных сегментов, потому что они всегда доступны и не зависят от состояния соседних устройств.

⏺Dynamic route - гибкая, адаптируется к изменениям топологии. Подходит для больших сетей с frequent changes, когда ручное управление стало бы слишком сложным. Минус - может флапать и создавать нестабильность при ошибках конфигурации, фильтрах или нестабильных соседях. Dynamic маршруты удобны для основного трафика, где нужно быстро подстраиваться под изменения.

Примеры на Cisco:

Static route:

ip route 10.0.0.0 255.255.255.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 192.168.1.254

Dynamic route (OSPF):

router ospf 1
 network 10.0.0.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0

N.A.