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.

Почему стоит проверять качество кабельной разводки

Даже идеально настроенный коммутатор или роутер не спасёт сеть от проблем с плохими кабелями. 

Ошибки CRC, флапы линков, intermittent packet loss - чаще всего именно из-за физики.

Проверка кабельной разводки помогает заранее выявить:
⏺повреждённые или плохо обжатые коннекторы
⏺перекрещенные пары или неправильную разводку
⏺длинные сегменты без экранирования, которые влияют на скорость и стабильность

Примеры команд на Cisco:

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

show interfaces status
show interfaces counters errors

Диагностика физического уровня:

test cable-diagnostics tdr interface Gi0/1
show cable-diagnostics tdr interface Gi0/1

N.A.

TDR тест на коммутаторах

TDR (Time-Domain Reflectometer) проверяет физическое состояние кабелей на коммутаторах.

Он выявляет разрывы, плохие пары или неправильную разводку до того, как это станет причиной проблем в сети. Даже если интерфейс «зелёный», пакеты могут теряться из-за физики кабеля, а TDR это покажет.

Примеры команд на Cisco:

Проверка кабеля:

test cable-diagnostics tdr interface Gi0/1

Просмотр результатов:

show cable-diagnostics tdr interface Gi0/1

⏺Ну и немного советов по использованию:
• Делайте TDR-тесты после установки нового кабеля или замены оборудования.
• Сравнивайте результаты с предыдущими тестами, чтобы заметить ухудшение качества линка.
• Используйте вместе с проверкой счётчиков ошибок интерфейсов:

show interfaces counters errors
show interfaces status

Это помогает заранее найти проблемы и сэкономить время на поиск причин нестабильного трафика.

N.A.

DHCP Snooping + IP Source Guard

DHCP Snooping позволяет коммутатору понять, какие IP-адреса легитимны, а какие нет.
Без этого любой хост может поднять rogue DHCP или подменить IP и начать MITM внутри VLAN.
⏺Типичный симптом: сеть «работает», но клиенты периодически получают странные шлюзы, пропадает доступ или трафик уходит не туда.

DHCP Snooping строит binding-таблицу IP–MAC–VLAN–port и делает её источником правды для других механизмов защиты.

Включение DHCP Snooping глобально и для VLAN:
ip dhcp snooping
ip dhcp snooping vlan 10,20
Настройка trusted-портов (uplink к DHCP-серверу или L3):
interface Gi0/24
ip dhcp snooping trust
Ограничение скорости DHCP-запросов на access-портах:
interface Gi0/3
ip dhcp snooping limit rate 15
Проверка binding-таблицы:
show ip dhcp snooping binding
IP Source Guard использует эту таблицу и блокирует трафик с поддельным IP.

Включение на access-порте:
interface Gi0/3
ip verify source
Проверка статуса:
show ip verify source
Связка DHCP Snooping + IP Source Guard предотвращает IP spoofing и rogue DHCP на уровне L2, без участия firewall или L3-логики.

N.A.

Route leaking между VRF

VRF создают иллюзию жёсткой изоляции: разные таблицы маршрутизации, разные интерфейсы, всё аккуратно разложено.

Проблемы начинаются, когда маршруты из одного VRF внезапно появляются в другом - без явного intent.

Основная причина - import/export Route Target. RT это просто метка. Если один VRF экспортирует маршрут с RT, а другой его импортирует, маршрут появится, даже если сегменты логически не должны видеть друг друга.

Частый сценарий тут:
есть VRF PROD и MGMT. Для «временного доступа» или теста добавляют общий RT. Потом про него забывают. В итоге management-сеть внезапно получает маршруты в production или наоборот.

Пример некорректной конфигурации.

VRF PROD экспортирует маршруты:

vrf definition PROD
 rd 65000:10
 route-target export 65000:10
 route-target export 65000:99

VRF MGMT импортирует тот же RT:

vrf definition MGMT
 rd 65000:99
 route-target import 65000:99

Результат: все маршруты из PROD с RT 65000:99 появляются в MGMT. Никаких ACL, никаких предупреждений - маршруты валидны с точки зрения control plane.

Снаружи это выглядит странно: пакеты доходят до «чужих» подсетей, traceroute внезапно проходит, firewall «ничего не блокирует», потому что трафик уже оказался не там, где ожидали.

⏺Как это обычно обнаруживается:
— неожиданные маршруты в show ip route vrf
— асимметричный трафик между VRF
— утечки через shared-services VRF
— доступ туда, где его быть не должно, без явного L3-соединения

Проверка RT:

show vrf detail
show bgp vpnv4 unicast all
show ip route vrf PROD
show ip route vrf MGMT

Особенно опасны shared RT вроде 65000:100, которые используются «для удобства». Один лишний import — и изоляция превращается в условность.

N.A.

TTL Security / GTSM для BGP

TTL Security (или GTSM - Generalized TTL Security Mechanism) ограничивает BGP-сессии так, чтобы соседний роутер мог «достучаться» только с ожидаемого количества хопов.

Любой пакет с меньшим TTL считается подозрительным и отбрасывается. Это защищает control-plane от spoofed BGP-пакетов и DoS через подмену source IP.

⏺Часто понять отсутствие GTSM можно так: BGP-сессии рвутся при случайных ICMP или сканировании, или сосед получает пакеты с «чужим TTL», что создаёт flapping.

Настройка на Cisco:

router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 ttl-security hops 2

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

show bgp neighbors 10.0.0.2
show bgp summary

N.A.

Jumbo Frames и MTU mismatch

Jumbo Frames позволяют передавать большие пакеты (обычно до 9000 байт) и ускоряют трафик для storage, VM migration и high-throughput приложений.

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

Признаки проблемы:
⏺TCP-сессии медленно открываются или «висят» без packet loss по ping обычного размера
⏺VM migration или storage replication тормозят
⏺traceroute показывает неожиданное поведение или «packet too big» ICMP

Примеры команд на Cisco:

Настройка MTU на интерфейсе:

interface Gi0/1
 mtu 9216

Проверка MTU по пути:

ping 10.0.0.2 size 9000 df-bit
show interfaces Gi0/1

На Linux для проверки MTU и отправки jumbo-пакетов:

ip link set dev eth0 mtu 9000
ping -M do -s 8972 10.0.0.2

N.A.

ECMP pitfalls

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

На деле же для stateful трафика это как «разбросанные дорожки»: пакеты одного соединения идут разными путями, и соединение начинает вести себя странно. 

VPN рвётся, firewall теряет сессии, TCP-флоу скачут.

5 типичных проблем с ECMP:
1️⃣Stateful NAT или firewall - сессии рвутся из-за разных путей.
2️⃣Короткие TCP-флоу - хеш распределяет трафик неравномерно, часть линков простаивает.
3️⃣Асимметричный маршрут - входящие и исходящие пакеты идут по разным линкам.
4️⃣Динамическое добавление или удаление линков - внезапное перераспределение трафика вызывает jitter и packet loss.
5️⃣VPN-туннели - пакеты разбросаны, туннель становится нестабильным.

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

show ip route
show ip cef summary
ping 10.0.0.2 repeat 100
traceroute 10.0.0.2

N.A.

ARP / ND cache exhaustion

В больших сетях таблицы ARP (IPv4) и Neighbor Discovery (IPv6) могут переполняться. 

Это создаёт «невидимые» проблемы: линк вроде работает, а трафик теряется или идёт нестабильно, и обычные ping/traceroute иногда ничего не покажут.

Симптомы переполнения ARP/ND:
⏺Периодическая недоступность отдельных хостов даже при рабочем линке.
⏺Нестабильная маршрутизация L3: соседние коммутаторы видят один и тот же MAC на разных портах.
⏺Err-disable порты из-за excessive ARP/ND traffic (особенно на access-коммутаторах).
⏺CPU spike на коммутаторе при попытках обработать множество ARP/ND записей.
⏺Flapping sessions на stateful devices (firewall, NAT), когда таблица маршрутов перестаёт корректно обновляться.

Продвинутая диагностика:

show arp detail vrf MGMT
show ip arp | include incomplete
show ipv6 neighbors detail
show mac address-table dynamic | include <MAC>
show processes cpu sorted | include ARP
show platform tcam utilization
show logging | include ARP

Углублённая проверка паттернов:

debug arp
debug ipv6 nd
show interface Gi0/1 counters errors
show ip route vrf MGMT

И да, важно, что даже если линк физически up, проблемы ARP/ND могут разлагать L3-связь и stateful приложения. Это особенно критично для сегментов с VMs, IoT или high-density access.

N.A.

5 команд для продвинутой диагностики QoS на L3 интерфейсе

Интерфейс зелёный, линк up, а приложения всё равно жалуются на задержки или потерю пакетов? Скорее всего, виноват QoS.

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

1️⃣Какая политика висит на интерфейсе:

show policy-map interface GigabitEthernet1/0/1

Видно, какая политика output/input применена, какие классы трафика и сколько байт прошло через каждый.

2️⃣Статистика конкретного класса трафика:

show policy-map interface GigabitEthernet1/0/1 class CRITICAL

Сразу видно, сколько пакетов получили приоритет, сколько queued и сколько дропнуто.

3️⃣Очереди и шейпинг:

show queueing interface GigabitEthernet1/0/1

Глубина очередей, dropped packets, tail-drop и backlog - всё, что может создавать jitter и задержки.

4️⃣Состояние интерфейса и счётчики:

show interfaces GigabitEthernet1/0/1 counters

Ошибки, CRC, collisions, overruns - иногда именно они маскируются под проблемы QoS.

5️⃣Детальная статистика по всей политике:

show policy-map interface GigabitEthernet1/0/1 statistics

Смотрим dropped packets, conform/exceed rates по каждому классу - удобно для fine-tuning под high-load.

N.A.

Как проверить и исправить скорость и дуплекс на коммутаторах и серверах

Даже если линк выглядит «зелёным», многие проблемы с TCP, VoIP и storage на самом деле происходят из-за mismatch speed/duplex между коммутатором и сервером.

Правильная настройка ускоряет трафик и устраняет нестабильность.

⏺Симптомы бывает такие:

Если скорость или дуплекс не совпадают на двух сторонах линка, вы увидите случайные packet loss, CRC errors, TCP-сессии, которые тормозят или зависают, а голосовой и видео трафик начинает «скакать» с jitter.

Часто throughput ниже ожидаемого, особенно на storage или VM трафике, и все это может происходить при видимо «зелёном» интерфейсе.

⏺Как проверить на коммутаторе Cisco:

show interfaces Gi0/1 status
! Показывает статус, скорость и дуплекс порта
show interfaces Gi0/1
! Детальная информация: errors, duplex, speed, auto-negotiation
show interfaces counters errors
! Подсчёт CRC, collisions, overruns
show interfaces status | include Gi0/1
! Быстрая проверка состояния конкретного порта

⏺Как исправить mismatch:

1️⃣Вручную задать скорость и дуплекс на коммутаторе:

interface Gi0/1
speed 1000
duplex full
no shutdown

2️⃣На серверах - настроить NIC на фиксированную скорость и full duplex или включить auto-negotiation, если коммутатор тоже auto.

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

show interfaces Gi0/1 status
show interfaces Gi0/1
ping <сервер-IP> repeat 100

Если CRC и collisions исчезли, TCP стабилен, jitter пропал - линк настроен корректно.

N.A.

Как разделить management и пользовательский трафик

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

Отдельный management VLAN или VRF обеспечивает изоляцию и предсказуемость управления.

⏺Симптомы смешанного трафика: Когда management трафик идёт по тем же линкам, что и пользовательский, перегрузка, storm или широковещательные пакеты могут блокировать управление.

В такой ситуации коммутатор или сервер могут быть видны по IP, но команды не проходят, а ping и telnet/SSH зависают.

⏺Как настроить отдельный 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

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

show vlan brief
show ip route vrf MGMT
ping vrf MGMT 10.99.0.10

N.A.

Статические и динамические маршруты: проверка и исправление

Даже когда сеть работает «в целом», неправильные или нестабильные маршруты могут вызывать flapping, асимметрию путей и проблемы с ECMP.

Правильная проверка и настройка маршрутов помогает поддерживать стабильность и предсказуемость сети.

⏺Симптомы проблем с маршрутами: Static routes не обновляются при изменениях сети, что может приводить к недоступным сегментам.

Dynamic routes могут flapping’ать, вызывать асимметричные пути, повышенную нагрузку на CPU и нестабильность ECMP.

Проверка статических маршрутов:

show ip route static
show ip route <network>
ping <destination>
traceroute <destination>

Проверка динамических маршрутов (OSPF/BGP):

show ip route ospf
show ip route bgp
show ip bgp summary
show ip route

Диагностика проблем ECMP:

show ip cef summary
show ip cef <prefix> detail
traceroute <prefix>
ping <prefix> repeat 10

Исправление:

1️⃣Static routes: убедиться, что gateway корректный, добавить или изменить при необходимости:

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

2️⃣Dynamic routes: проверка соседей, фильтров и redistribute, исправление flapping:

router ospf 1
 network 10.0.0.0 0.0.0.255 area 0
router bgp 65001
 neighbor 192.168.1.2 remote-as 65002

N.A.