Большой RX ring не всегда делает сеть быстрее

У сетевой карты есть очереди, куда складываются входящие пакеты, пока драйвер не успел их обработать.

При burst-трафике большой ring действительно может помочь пережить кратковременный всплеск:

NIC → RX ring → driver → kernel

Но бесконечной очереди не бывает.

Если CPU стабильно обрабатывает, например, 500 тыс. пакетов/с, а приходит 700 тыс.:

500k → 700k → 900k → ...

ring постепенно заполняется, после чего начинаются drops.

Увеличение ring позволяет накопить больше пакетов:

ethtool -g eth0
ethtool -G eth0 rx 4096

Но если скорость обработки не изменилась, это только отодвинет момент переполнения.
Более того, слишком глубокая очередь может увеличить latency: пакет уже не теряется, но дольше ждёт своей очереди на обработку.

Поэтому при проблемах с сетью важно различать:

packet loss
и
packet queueing

Первое означает, что пакет исчез. Второе, что пакет всё ещё жив, но уже слишком долго ждёт обработки.

N.A.

Как локальный трафик может вообще не попадать на физический интерфейс

Если приложение обращается к IP, который Linux считает своим локальным адресом, пакет не отправляется на физический интерфейс.

Например, на сервере:

eth0 → 10.0.0.10/24

Приложение выполняет:

curl http://10.0.0.10:8080

Интуитивно кажется, что будет:

application
    ↓
eth0
    ↓
switch
    ↓
eth0
    ↓
server

Но Linux сначала проверяет destination и видит, что 10.0.0.10 принадлежит самому хосту.

Маршрут будет иметь тип local:

ip route get 10.0.0.10

Например:

local 10.0.0.10 dev lo src 10.0.0.10

Поэтому физический eth0 в этом обмене вообще не участвует:

application
    ↓
local routing
    ↓
lo
    ↓
local socket

Это важно при диагностике.


Можно поставить:

tcpdump -ni eth0 port 8080

и не увидеть вообще ничего, хотя curl успешно устанавливает соединение.

А вот:

tcpdump -ni lo port 8080

покажет этот трафик.

Причём это не означает, что lo - какой-то физический интерфейс. Это отдельный путь local delivery внутри сетевого стека Linux.

Поэтому проверка «пакет дошёл до сервера через его сетевую карту?» иногда вообще поставлена неправильно: если источник и destination находятся на одном хосте, пакет мог никогда не попасть на wire.

N.A.

Почему BGP может выбрать более длинный путь

В BGP легко представить выбор маршрута как простое правило: меньше AS в пути - лучше.

Но AS-path length - только один из атрибутов, которые участвуют в best-path selection.

Например, маршрутизатор получил:

10.10.10.0/24

peer A:  AS_PATH 64501 64502
peer B:  AS_PATH 64503 64504 64505

На первый взгляд BGP должен выбрать A.
Но если у маршрута от B выше LOCAL_PREF, он может стать предпочтительным ещё до того, как длина AS_PATH вообще сыграет роль.

Условно:

A → LOCAL_PREF 100 → AS_PATH 2

B → LOCAL_PREF 200 → AS_PATH 3
BGP выберет B.

Это важный момент: BGP ищет не «самый короткий маршрут», а лучший маршрут по последовательности атрибутов.

На выбор могут влиять:

LOCAL_PREF
      ↓
AS_PATH
      ↓
ORIGIN
      ↓
MED
      ↓
eBGP / iBGP
      ↓
IGP metric
      ↓
router ID / другие tie-breaker

Поэтому добавление ещё одного AS в путь не обязательно заставит трафик пойти через другого провайдера.

Посмотреть, почему конкретный маршрут победил:

show bgp ipv4 unicast 10.10.10.0/24

А в FRRouting удобно смотреть ещё и выбранный best path:

vtysh -c "show bgp ipv4 unicast 10.10.10.0/24"

Именно поэтому при разборе BGP-проблемы вопрос «у какого peer меньше AS_PATH?» часто оказывается слишком ранним.

Сначала нужно понять, какой атрибут сделал маршрут предпочтительнее.

N.A.

Почему нельзя смешивать management и user traffic «потом разделим»

Пока всё спокойно, смешанный трафик кажется нормальным решением.

Как только сеть ловит перегрузку или шторм, management-трафик оказывается в той же очереди, что и пользовательский.

В момент инцидента устройство может быть доступно по IP, но управлять им невозможно.

Самый простой вариант - отдельный management 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

N.A.

Что происходит с DHCP lease, когда сервер получает тот же IP после перезагрузки

DHCP - это не просто «сервер выдал IP и забыл».

Когда клиент получает адрес, например:

192.168.1.50

он получает ещё и lease time:

lease: 8 hours

При обычной работе клиент не ждёт окончания lease. Он пытается продлить его заранее.

Упрощённо:

0% ───────── 50% ───────── 87.5% ───── 100%
              │              │
           renew          rebind       expire

На этапе T1 клиент обращается к DHCP-серверу, который выдал lease.

Если тот недоступен, позже начинается T2 - клиент уже пытается продлить аренду через broadcast, чтобы найти любой доступный DHCP-сервер.

Посмотреть lease на Linux можно, например, через:

networkctl status eth0

или:

cat /var/lib/dhcp/dhclient.leases

При перезагрузке клиент может попытаться вернуть себе прежний адрес. Но DHCP-сервер не обязан его сохранить: он проверяет актуальность lease и состояние пула.

Поэтому ситуация:

сервер был → 192.168.1.50
перезагрузился
сервер снова появился → 192.168.1.73

не обязательно означает ошибку DHCP.

Между клиентом и сервером существует отдельное состояние аренды, и IP-адрес - только одна его часть.

Именно поэтому при проблемах с DHCP полезно смотреть не только ip addr, а кто выдал lease, когда он истекает и на каком этапе продления находится клиент.

N.A.

Как Linux выбирает, через какой интерфейс отправить пакет

На сервере два интерфейса:

eth0 → 10.0.1.10/24
eth1 → 10.0.2.10/24

И оба имеют доступ к внешней сети.

Когда приложение обращается к:

8.8.8.8

Linux не выбирает интерфейс по принципу «первый доступный».

Сначала он делает routing lookup:

ip route get 8.8.8.8

Например:

8.8.8.8 via 10.0.1.1 dev eth0 src 10.0.1.10

Здесь kernel уже определил:

destination → 8.8.8.8
gateway     → 10.0.1.1
interface   → eth0
source IP   → 10.0.1.10

Но интереснее становится, когда появляются ip rule.

ip rule

Например:

0:      from all lookup local
100:    from 10.0.2.0/24 lookup isp2
200:    from all lookup main

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

source 10.0.1.10 → eth0
source 10.0.2.10 → eth1

При этом обычный:

ip route

может вообще не объяснить, почему второй пакет пошёл через eth1.

Для конкретного источника можно проверить:

ip route get 8.8.8.8 from 10.0.2.10

И получить уже другой результат.

Поэтому на multi-homed сервере вопрос «какой default route стоит?» часто недостаточен.

Нужно смотреть какой routing policy применяется именно к этому пакету.

N.A.

ip neigh flush: команда, которая может мгновенно изменить поведение сети

Иногда сервер продолжает отправлять трафик на старый MAC-адрес, хотя ARP уже должен был обновиться.

Вместо перезапуска интерфейса можно заставить Linux заново разрешить соседей:

ip neigh flush dev eth0

После этого:

ip neigh show dev eth0

может показать:

10.10.10.1 INCOMPLETE

Ядро ещё не знает MAC шлюза и отправит ARP-запрос:

Who has 10.10.10.1?

После ответа запись снова станет, например:

10.10.10.1 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Но есть важный нюанс.
flush не чинит ARP-проблему. Если шлюз не отвечает на ARP, после очистки вы просто получите INCOMPLETE и потерю связи.

Поэтому команда полезна именно как диагностический приём:

ip neigh show dev eth0
ip neigh flush dev eth0
ip neigh show dev eth0

Если после flush сосед снова быстро появляется с правильным MAC - проблема могла быть в устаревшем состоянии neighbor table.

Если остаётся:

INCOMPLETE

ищите уже ниже:

tcpdump -ni eth0 arp

N.A.

bpftool prog profile: кто съедает CPU внутри BPF

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

Поэтому проблема иногда выглядит странно:

CPU → 100%
приложение → почти не грузит
network traffic → высокий

Смотреть только на процессы в top здесь недостаточно.

У bpftool есть режим профилирования конкретной BPF-программы:

bpftool prog show

Находим нужную программу и получаем её ID:

123: xdp  name firewall

После этого:

bpftool prog profile id 123

Можно получить статистику выполнения программы и понять, сколько процессорного времени она реально потребляет.

Почему это полезно?

Допустим, на сервере стоит XDP-фильтр. Он должен быстро отбрасывать мусорный трафик, но внутри программы появилась сложная логика: несколько map lookup, дополнительные проверки и работа с большим количеством пакетов.

При небольшом трафике это незаметно.

А при 5 млн PPS:

5 000 000 packets/sec
        ×
несколько дополнительных операций
        ↓
существенная нагрузка CPU

И в итоге администратор видит просто высокий softirq/CPU usage, хотя источник нагрузки находится внутри BPF-программы.

Это особенно интересно тем, что BPF выполняется не как отдельный процесс, который можно найти в top.

То есть искать:

top
ps aux

в этом случае недостаточно.

Логика диагностики получается другой:

CPU ↑
 ↓
network/softirq ↑
 ↓
BPF подозрителен
 ↓
bpftool prog show
 ↓
bpftool prog profile

И это уже позволяет искать не «какой процесс грузит CPU», а какая программа внутри kernel datapath тратит процессорное время.

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.

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.

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.