ECMP и hash buckets: почему трафик концентрируется на одном линке

Вроде несколько uplink и ECMP включён, но весь трафик «съезжает» на один порт.

Причина в том, как работает hashing: большинство платформ используют 5-tuple (src/dst IP, src/dst port, protocol) для распределения потоков по линкам. 

Если потоков мало или они одинаковы по этим полям, почти всё попадает в один bucket.

⏺На high-end роутерах есть ограничения ASIC - максимальное число hash-bucket’ов, которые реально могут распределять трафик. Даже при большом количестве линков маленькие TCP/UDP потоки часто концентрируются на одном порту.

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

show etherchannel load-balance
show interface <port-channel> counters
show interface <member-interface> statistics

На некоторых платформах можно посмотреть hash-бакеты напрямую:

show platform hardware forwarding hash <port-channel>

⏺Признак проблемы: линк full-duplex не загружен по среднему, но один порт получает почти весь трафик, а остальные почти пустые.

С небольшой коррекцией hash или увеличением числа параллельных потоков трафик начинает распределяться равномернее.

N.A.

5 команд, которые реально спасают на high-end сетях

Ситуация: маршруты есть, линк up, ping работает, но TCP/UDP падает, jitter/packet loss наблюдается. Эти команды быстро выявляют глубокие проблемы:

1️⃣RIB vs FIB divergence - маршрут есть в control-plane, но не запрограммирован в forwarding:

show ip route <prefix>
show platform hardware forwarding table drop

2️⃣ECMP hash distribution - почему traffic концентрируется на одном uplink:

show platform hardware forwarding hash <port-channel>
show etherchannel load-balance

3️⃣BFD session flaps - link вроде жив, но маршруты конвергируют мгновенно:

show bfd neighbors
show bfd sessions

4️⃣Overlay/VTEP sanity check - VXLAN/EVPN мультикаст и BUM-трафик:

show nve vni
show nve peers
show ip mroute

5️⃣CPU spikes под SNMP/NetFlow - microbursts silently дропят пакеты:

show processes cpu sorted
show platform hardware qfp active statistics drop

N.A.

VRF для полной изоляции management-трафика

На первый взгляд кажется, что смешивание management и user traffic - нормальное решение. 

Пока сеть лёгкая и нагрузка маленькая - работает. Но стоит появиться перегрузке, broadcast storm или spikes, и управление сетью превращается в кошмар: ping проходит, но SSH/Telnet/HTTPS могут не открываться, ACL и QoS накладывают неожиданные ограничения, и любое управление становится невозможным.

⏺VRF - это способ полностью изолировать management VLAN от основной сети. В нём свой routing table, отдельные ACL и QoS. Даже при критических нагрузках на user traffic, доступ к устройствам остаётся стабильным.

Пример на Cisco:

vrf definition MGMT
 rd 65000:99

interface Vlan99
 vrf forwarding MGMT
 ip address 10.99.0.10 255.255.255.0
 no shutdown

Теперь management VLAN живёт в своём «контейнере маршрутов». Трафик не смешивается с основной сетью, можно спокойно применять правила безопасности и приоритеты QoS без риска повлиять на user traffic.

Даже если в будущем нужно расширить управление или добавить мониторинг - всё остаётся чётко разделённым и предсказуемым.

N.A.

SNMP и NetFlow могут тайно ломать сеть

На первый взгляд кажется, что мониторинг - безопасное занятие. Но на high-end маршрутизаторах частый SNMP или NetFlow polling может создавать настоящие microbursts для CPU. В результате:

⏺Ping остаётся стабильным, но TCP/UDP падает.
⏺Пакеты silently drop, jitter растёт.
⏺Даже high-speed uplinks начинают вести себя странно.

Симптомы, которые сразу бросаются в глаза:

show processes cpu sorted
show platform hardware qfp active statistics drop
show interface <int> counters errors

N.A.

BFD flaps на стабильных линках

Линк выглядит стабильным: OSPF и BGP держат соседство, ping проходит, маршруты есть, но BFD внезапно сигнализирует «link down».

В результате мгновенно конвергируют маршруты, появляются кратковременные packet drops, а логи показывают тревожные сообщения, хотя физический линк не упал.

Часто причина кроется в jitter или небольших microbursts на линке. BFD очень чувствителен к задержкам: heartbeat и detect time могут «срабатывать» слишком быстро.

Проверка ситуации:

show bfd neighbors
show bfd sessions
ping <neighbor-ip> repeat 100

⏺Что помогает: увеличить тайминги BFD (detect interval, multiplier), проверить качество линка на jitter и drops, применить QoS для BFD-трафика, чтобы он не терялся при нагрузке.

N.A.

Как понять, что упираешься в single-flow limit

Канал вроде быстрый, интерфейс не забит, CPU в порядке - но скорость упирается в 200–300 Мбит/с и выше не растёт. При этом параллельные загрузки «вдруг» дают почти весь канал.

Это классический случай single-flow ограничения: один TCP-поток не может «раскачать» линк из-за latency и размеров окна. Чем выше RTT, тем сильнее эффект - поток просто не успевает нарастить объём данных в полёте.

Самая быстрая проверка - сравнить один поток и несколько:

iperf3 -c <server-ip> -P 1
iperf3 -c <server-ip> -P 10

Если при -P 1 скорость низкая, а при -P 10 резко растёт - это не проблема канала. Это ограничение одного TCP-потока.

Дальше можно посмотреть детали по соединению:

ss -ti

Обращаем внимание на cwnd, rtt, retrans. Маленькое окно или высокий RTT сразу объясняют, почему throughput не растёт.

Что обычно влияет:
⏺latency между узлами
⏺TCP window size и autotuning
⏺packet loss (даже небольшой сильно режет throughput)

⚡️В таких ситуациях «сеть медленная» - неправильный вывод. Канал свободен, просто один поток физически не может его загрузить.

N.A.

Апгрейд канала не всегда ускоряет приложение

Увеличили линк с 1 Гбит/с до 10 Гбит/с, а скорость приложения почти не изменилась. Такое часто встречается, когда речь про один TCP-поток.

Дело не в канале, а в том, сколько данных поток успевает держать «в полёте». 

RTT остался прежним, TCP window не вырос - поток просто не успевает заполнять новый bandwidth.

Реальный прирост появляется только если:
⏺добавить параллельные потоки
⏺оптимизировать TCP параметры

Проверка:

iperf3 -c <server-ip> -P 1    # один поток — потолок не выше старого
iperf3 -c <server-ip> -P 8    # несколько потоков — канал полностью загружен

N.A.

TCP retransmits в реальных сетях

Даже на пустом канале приложения могут тормозить. Packet loss или jitter заставляют TCP пересылать пакеты снова и снова, а один поток не успевает «накачать» канал.

⏺Признаки - медленный throughput, высокий RTT, заметные retransmits.

На Linux проверить легко

ss -ti | grep retrans
tcpdump -i eth0 tcp and host <peer-ip> -vv

Даже 0.1–0.5% потерь на WAN сильно сказываются на скорости одного потока. Параллельные соединения и настройка TCP window позволяют компенсировать этот эффект.

Особенно это важно для high-speed каналов между датацентрами, VoIP и стриминговых сервисов, где каждая миллисекунда задержки критична.

N.A.

QoS surprises в multi-tenant сетях

Даже когда вроде всё настроено, трафик может терять приоритет. CoS на L2 и DSCP на L3 не совпадают, и на trunk или overlay это особенно заметно: пакеты проходят, но VoIP, видео и контрольные протоколы начинают тормозить.

Чтобы понять, где «теряется приоритет», полезно смотреть, как устройство обрабатывает QoS. Например на Cisco:

# Как классифицируются пакеты на интерфейсе
show mls qos interface Gi1/0/1
show policy-map interface Gi1/0/1

# Какие очереди и сколько пакетов дропается
show queueing interface Gi1/0/1

# Какие class-map и DSCP сопоставления настроены
show class-map
show policy-map

# Проверка QoS на VLAN
show vlan brief
show mls qos vlan 10

⏺Практика: согласовывать trust boundary между L2 и L3, следить за очередями и задержками для критичных VLAN. Даже маленький mismatch может превратить приоритетный трафик в «тормозной», а эти команды помогут быстро увидеть проблему и исправить её.

N.A.