Почему MTU 1500 в реальности никогда не 1500?

MTU 1500 это максимальный размер payload в Ethernet-фрейме. Цифра знакомая, но в реальной сети между твоим приложением и получателем почти всегда есть что-то, что откусывает от этого значения.

Иногда немного, иногда достаточно чтобы сломать крупные передачи.

Туннели

Любой туннель оборачивает оригинальный пакет в новый и добавляет свои заголовки. GRE забирает 24 байта, IPsec в tunnel mode от 50 до 70 байт в зависимости от алгоритмов шифрования, WireGuard 60 байт, VXLAN 50 байт.

Если на пути несколько туннелей, байты суммируются. Итоговый MTU внутри может оказаться 1400 и ниже, при этом интерфейс снаружи честно показывает 1500.

PPPoE

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

Если роутер не учитывает это и анонсирует клиентам MSS под 1500, крупные TCP-сегменты начинают фрагментироваться или молча дропаться на пути.

Делаем вторую часть с более подробным разбором на практике?

N.A.

Как работает TCAM и почему правила ACL влияют на производительность железа

Обычная RAM ищет данные по адресу: дай адрес, получи значение. TCAM работает наоборот: дай значение, получи результат за один такт. Content Addressable Memory, и T означает Ternary: каждый бит может быть 0, 1 или X (don’t care). Именно X позволяет матчить префиксы и маски.

Благодаря этому коммутатор находит совпадение для любого пакета за одну операцию, независимо от размера таблицы. Именно поэтому железо форвардит трафик на линейной скорости.

Почему TCAM дорогой и ограниченный

TCAM потребляет в 5-10 раз больше энергии и площади чристалла чем обычная SRAM. Поэтому его мало: на типичном enterprise-коммутаторе несколько десятков тысяч записей, и они делятся между маршрутами, ACL, QoS и MAC-таблицей.

Посмотреть сколько TCAM осталось на Cisco:

show platform tcam utilization
show sdm prefer

Как ACL влияют на TCAM

Каждая строка ACL это одна или несколько записей в TCAM. Правило с диапазоном портов разбивается на несколько записей потому что TCAM не умеет в диапазоны нативно.

Правило permit tcp any any gt 1024 может развернуться в десятки записей. На больших ACL это незаметно, но на коммутаторах с маленьким TCAM таблица заканчивается и новые правила просто не применяются.

show ip access-lists
show platform hardware capacity

Что делать при нехватке

Меняем SDM profile чтобы перераспределить TCAM между функциями. Например отдать больше под ACL за счёт MAC-таблицы:

sdm prefer acl
reload

N.A.

Почему MTU 1500 в реальности никогда не 1500. Часть 2

Почему фрагментация не всегда спасает: Когда пакет не влезает в MTU промежуточного узла, тот должен отправить отправителю ICMP Fragmentation Needed.

Отправитель получает сообщение, уменьшает размер сегмента и пробует снова. Это называется Path MTU Discovery и работает хорошо в теории.

На практике многие сети и файерволы блокируют ICMP полностью. Сообщение Fragmentation Needed не доходит, отправитель продолжает слать большие пакеты, они дропаются без каких-либо уведомлений.

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

Проверяем реальный Path MTU до хоста и тестируем конкретный размер пакета:

tracepath 8.8.8.8
ping -M do -s 1400 8.8.8.8

Если ping с -M do (don’t fragment) падает на определённом размере, MTU на пути именно там.

Как фиксить

Выставляем MTU вручную на туннельном интерфейсе:

ip link set dev tun0 mtu 1420

Для PPPoE на Cisco MSS clamp ограничивает размер TCP-сегментов на уровне роутера, не давая клиентам использовать значения выше допустимого:

interface Dialer0
 ip tcp adjust-mss 1452

N.A.

Что такое IX и как трафик идёт внутри него

IX (Internet Exchange) это физическая точка где провайдеры, CDN и крупные сети подключаются друг к другу напрямую. Вместо того чтобы гонять трафик через транзитного провайдера и платить за каждый гигабит, участники обмениваются трафиком напрямую и бесплатно между собой.

Крупнейшие точки обмена: DE-CIX во Франкфурте, AMS-IX в Амстердаме, MSK-IX в Москве. Через DE-CIX проходит больше 10 Тбит/с в пике.

Как устроено внутри

Физически IX это один большой коммутатор (или несколько связанных), к которому все участники подключают свои роутеры. Эта общая среда называется IXP fabric. Каждый участник получает порт и IP-адрес в общей подсети IX.

Дальше всё через BGP. Каждый участник поднимает BGP-сессии с теми с кем хочет обмениваться трафиком, анонсирует свои префиксы и получает чужие. Никакой автоматики, только явные пиринговые договорённости.

Route Server

Чтобы не поднимать сотни BGP-сессий с каждым участником отдельно, большинство IX предоставляют Route Server.

Подключаешься к одному RS, получаешь маршруты от всех участников кто тоже подключён к RS. Можно фильтровать что принимать и что анонсировать.

router bgp 65001
 neighbor 193.178.185.1 remote-as 65000
 neighbor 193.178.185.1 description MSK-IX Route Server

Как трафик идёт внутри

Пакет от пользователя провайдера А до сервера в сети провайдера Б: роутер А смотрит BGP-таблицу, видит что префикс Б получен через IX, отправляет пакет напрямую на роутер Б через IXP fabric. Транзитный провайдер не участвует, задержка меньше, стоимость ниже.

N.A.

Ethernet OAM (802.1ag) с Linux и FRRouting

Ethernet OAM (Operations, Administration and Maintenance) по стандарту 802.1ag позволяет контролировать доступность и состояние линков на уровне L2.

На Linux можно использовать утилиты eth-oam для генерации OAM-сообщений (Continuity Check Messages, Loopback, Link Trace).

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

# Проверка доступности линка между хостами через CFM Continuity Check
eth-oam-ccm -i eth0 -m 1 -t 10

Где -i — интерфейс, -m — Maintenance Association ID, -t — интервал в секундах.

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

Например, при падении линка BGP-сессия будет разорвана и маршруты уйдут на резервный путь.

Дополнительно можно использовать Loopback и Link Trace для диагностики проблем:

# Loopback запрос к соседнему устройству
eth-oam-lb -i eth0 -m 1

# Trace путь до узла через L2
eth-oam-lt -i eth0 -m 1 -d <MAC-адрес-соседа>

N.A.

Что происходит когда два DHCP-сервера отвечают на один запрос

Подключил кто-то в офисе домашний роутер к корпоративной сети, или подняли новый DHCP и старый не выключили. Оба слышат broadcast, оба отвечают.

Клиент берёт первый пришедший offer. Не правильный, а именно первый. Если левый сервер ответил быстрее, клиент получает адрес из чужого пула, чужой шлюз, чужой DNS. Настроен, но в сеть не ходит или ходит куда не надо.

Хуже когда пулы пересекаются: два клиента получают одинаковый IP и оба теряют связь. Без каких-либо ошибок на их стороне.

Смотрим кто вообще отвечает на DHCP в сегменте:

sudo tcpdump -i eth0 port 67 or port 68 -n
nmap --script broadcast-dhcp-discover

Если в выводе несколько Server Identifier, проблема подтверждена.

Лечится DHCP Snooping на коммутаторе: офферы разрешены только с доверенных портов, со всех остальных дропаются:

ip dhcp snooping
ip dhcp snooping vlan 10

interface Gi0/1
 ip dhcp snooping trust

interface range Gi0/2 - 24
 no ip dhcp snooping trust

N.A.

Как ведёт себя сеть при split-brain в HSRP

Два роутера в HSRP обмениваются hello-пакетами каждые 3 секунды. Если связь между ними пропадает, каждый решает что сосед умер и становится Active.

Оба держат один виртуальный IP, оба отвечают на ARP-запросы своим MAC.

Клиенты в этот момент делятся на два лагеря в зависимости от того чей ARP-ответ пришёл последним.

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

Отлаживать это неприятно потому что проблема плавающая и воспроизводится через раз.

Смотрим состояние HSRP и кто сейчас Active:

show standby brief
show standby

Если оба показывают Active, split-brain в действии. Проверяем доступность между роутерами:

ping <IP соседнего роутера> source <интерфейс HSRP>

Чаще всего причина не в роутерах а в коммутаторе между ними: упал транк, слетел VLAN, сработал STP. Hello-пакеты не проходят, оба уходят в Active.

show interfaces trunk
show spanning-tree vlan <ID>

N.A.

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

Заменили коммутатор, всё подключили, часть хостов работает, часть нет. Физически всё поднято, линки горят. Начинается час диагностики.

Обычно проблема в одном из трёх

Новый коммутатор пришёл с дефолтной конфигурацией. Все порты в VLAN 1, транки не настроены. Хосты которые работают находятся в VLAN 1 и просто повезло. Остальные VLANы не существуют на новом железе.

show vlan brief
show interfaces trunk

Если VLANы не созданы или транк не поднят, вот оно.

STP выбрал новый коммутатор Root Bridge потому что у него меньший MAC или приоритет не был выставлен. Топология пересчиталась, часть портов ушла в blocking. Хосты за этими портами недоступны.

show spanning-tree
show spanning-tree detail | include root

Смотрим кто стал Root и почему. Если новый коммутатор, выставляем приоритет обратно на нужное железо:

spanning-tree vlan 1 priority 4096

Старый коммутатор работал с negotiated duplex или speed, новый договорился иначе. Часть портов поднялась в half-duplex, отсюда коллизии и потери.

show interfaces Gi0/1 | include duplex

Если видим half-duplex там где не должно быть, фиксим явно:

interface Gi0/1
 duplex full
 speed 1000

N.A.

Что происходит когда OSPF area 0 теряет связность

Area 0 это backbone. Все остальные area обязаны быть физически или логически подключены к ней.

Если area 0 разваливается на части, OSPF не пересчитывает маршруты в обход, он просто перестаёт видеть часть сети.

Два роутера в area 0 потеряли связь между собой. Каждый считает что его кусок backbone и есть вся сеть. Area которые висят за каждым из них становятся недостижимы с другой стороны. Никаких fallback, никакого альтернативного пути если он не был настроен заранее.

Смотрим что происходит с соседями и LSA:

show ip ospf neighbor
show ip ospf database
show ip ospf database summary

Если в базе данных пропали LSA от роутеров на другой стороне разрыва, связность потеряна. Маршруты до их сетей исчезнут из таблицы маршрутизации.

show ip route ospf

Временное решение пока чинится физика: virtual-link через транзитную area. Натягиваем логический туннель между двумя ABR через area которая ещё жива:

router ospf 1
 area 1 virtual-link <router-id соседнего ABR>

На обоих ABR с обеих сторон разрыва. Virtual-link восстанавливает связность area 0 поверх transit area.

N.A.

Настройка WireGuard: сервер, клиент, роутинг

WireGuard проще IPsec и OpenVPN по конфигурации, быстрее поднимается и меньше точек где можно ошибиться. Вот минимальная рабочая конфигурация.

Сервер

Генерируем ключи:

wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key

Конфиг сервера /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server_private_key>
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.0.0.2/32

Включаем форвардинг и поднимаем интерфейс:

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
wg-quick up wg0
systemctl enable wg-quick@wg0

Клиент

wg genkey | tee /etc/wireguard/client_private.key | wg pubkey > /etc/wireguard/client_public.key

Конфиг клиента:

[Interface]
PrivateKey = <client_private_key>
Address = 10.0.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <server_public_key>
Endpoint = <server_ip>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

wg-quick up wg0

Проверка

wg show
ping 10.0.0.1
curl ifconfig.me

wg show покажет активные peer-ы, последнее рукопожатие и переданный трафик. Если handshake давно не было, туннель не установлен.

N.A.