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.

Понимание и использование протокола DNSSEC

DNS — основа Интернета, но он подвержен атакам, таким как Man-in-the-Middle и Cache Poisoning, где злоумышленники могут подменить DNS-ответы.

DNSSEC (Domain Name System Security Extensions) решает эту проблему, обеспечивая защиту целостности и подлинности DNS-запросов с помощью криптографических методов.

Как работает DNSSEC?
⏺Цифровая подпись: Ответы DNS подписываются приватным ключом, а получатель может проверить их подлинность с помощью публичного ключа.
⏺Цепочка доверия: Публичные ключи проверяются через цепочку доверия, начиная с корневого DNS-сервера.

Почему это важно:

DNSSEC предотвращает:
• Man-in-the-Middle атаки — защита от подделки DNS-ответов.
• Cache Poisoning — защита от подмены данных в кэше DNS-сервера.
• Подделку ответов — гарантия, что данные не были изменены.

Как настроить DNSSEC?
1️⃣Генерация ключей: Создайте пару ключей (приватный и публичный) для домена.
2️⃣Подпись записей: Подпишите DNS-записи приватным ключом.
3️⃣Добавление записей на сервер: Обновите DNS-записи, добавив RRSIG и DNSKEY.
4️⃣Проверка: Убедитесь, что все записи правильно подписаны и работают.

N.A.

Диагностика VLAN leakage

VLAN leakage - ситуация, когда трафик из одного VLAN неожиданно появляется в другом. Обычно это не «баг», а следствие ошибок в trunk-настройках, native VLAN или некорректного tagging’а.

⏺Основные источники VLAN leakage

Чаще всего проблема возникает из-за несовпадения native VLAN на транке, когда untagged трафик интерпретируется по-разному на соседних устройствах.

Второй частый сценарий - trunk mismatch: VLAN разрешён с одной стороны, но не с другой. Третья причина - устройства или гипервизоры, которые отправляют трафик без тегов там, где ожидается tagged frame.

⏺Проверка trunk-интерфейсов

show interfaces trunk

Можно увидеть:
• какие интерфейсы реально работают в trunk
• native VLAN
• список allowed VLAN

show running-config interface Gi0/24

Проверка, явно ли задан switchport trunk native vlan и allowed vlan.

⏺Проверка native VLAN consistency

show interfaces Gi0/24 switchport

Отображает operational native VLAN. Именно она важна, а не только конфигурация.

show spanning-tree vlan <VLAN_ID>

Иногда leakage проявляется через неожиданные STP-события в «чужом» VLAN.

⏺Поиск VLAN mismatch и неожиданных MAC

show mac address-table vlan <VLAN_ID>

Если в VLAN появляются MAC-адреса, которые физически должны быть в другом сегменте — это прямой индикатор leakage.

show mac address-table interface Gi0/24

Помогает понять, какие VLAN реально приходят по конкретному транку.

⏺Проверка tagging ошибок и untagged трафика

show interfaces Gi0/24 counters errors

Ошибки encapsulation и drops иногда указывают на некорректный tagging.

show vlan brief

Позволяет проверить, не используется ли native VLAN как рабочий пользовательский VLAN, что сильно повышает риск leakage.

N.A.

Что происходит при конфликте IP-адресов

IP-конфликт - это ситуация, когда два устройства в одной подсети считают один и тот же адрес «своим».

На бумаге всё выглядит корректно: маска правильная, gateway задан, линк зелёный. Но на уровне ARP начинается борьба за право отвечать на запросы.

Когда кто-то в сети спрашивает: «Кто владелец IP 192.168.1.10?», отвечают оба устройства. В ARP-кэше сохраняется MAC того, кто ответил последним. Через некоторое время ответит второй, и запись перепишется. Трафик начнёт уходить уже к нему.

⏺Именно поэтому поведение нестабильное:
пинг проходит через раз, веб-интерфейс то открывается, то нет, SSH обрывается, пользователи говорят «само чинится и снова ломается».

Что в этот момент происходит в сети

ARP-таблицы на разных устройствах начинают «мигать»: один и тот же IP связан с разными MAC-адресами.

На коммутаторе можно увидеть, что трафик для этого IP приходит то с одного порта, то с другого.

Если конфликт затрагивает gateway или сервер - последствия становятся заметными сразу: сессии рвутся, NAT ломается, сервисы становятся непредсказуемыми.

Почему это выглядит случайно

Потому что всё зависит от того, чья ARP-ответная гонка победила в конкретный момент. Пока в кэше «правильный» MAC - всё работает. Как только запись обновилась, трафик уходит к другому устройству.

N.A.

Почему трафик концентрируется на одном линке в агрегированных каналах

Даже когда в сети настроено несколько линков через LACP / Port-Channel или ECMP, трафик иногда упорно идёт по одному физическому каналу. Интерфейсы подняты, агрегирование активно, но один линк перегружен, а остальные почти пустые.

Такое поведение часто вводит в заблуждение - кажется, что резервные линки «не работают», хотя на самом деле алгоритм распределения трафика делает именно так.

↗️Как работает распределение трафика

Балансировка в LACP и ECMP обычно основана на hash-функции, которая использует параметры пакета для выбора линка:
• Source / Destination MAC
• Source / Destination IP
• Source / Destination TCP/UDP порты

Коммутатор или маршрутизатор вычисляет «хэш» и назначает конкретный линк для этой сессии.

Если большинство сессий используют одинаковые параметры (например, много трафика к одному серверу или одному сервису), хэш-функция распределяет их на один линк. 

Остальные остаются почти пустыми - это и называется hash polarization.

На практике это проявляется так:
⏺Один линк работает на 90–100% пропускной способности, другие - почти пустые.
⏺Сессии к одному серверу всегда идут через один и тот же линк.
⏺Мониторинг агрегированного канала показывает нормальную пропускную способность, но дисбаланс по отдельным линкам очевиден.

Как проверить на Cisco

show etherchannel summary

Статус всех Port-Channel, активные интерфейсы и режим LACP.

show interfaces port-channel 1

Ошибки, drops, скорость и загрузка агрегированного интерфейса.

show interfaces Gi0/1 etherchannel

Как конкретный физический интерфейс участвует в Port-Channel.

show etherchannel load-balance

Схема распределения трафика: по MAC, IP или портам.

show platform hardware port-channel statistics

Аппаратные счётчики по линкам, чтобы увидеть дисбаланс на уровне ASIC.

N.A.