Разное поведение DNS у разных клиентов
Снаружи всё выглядит одинаково, но поведение разъезжается по группам клиентов.
Первое, что обычно всплывает — не сами ответы DNS, а то, как они кешируются и переиспользуются в системе.
Дальше полезно посмотреть не “что резолвится”, а как именно система выбирает адреса и в каком порядке.
Следующий слой - системные кеши и библиотечный резолвинг, который вообще не виден через обычные проверки.
N.A.
Сервис у части пользователей работает нормально, у части периодически “проваливается” или уходит в странные задержки.
Снаружи всё выглядит одинаково, но поведение разъезжается по группам клиентов.
Первое, что обычно всплывает — не сами ответы DNS, а то, как они кешируются и переиспользуются в системе.
resolvectl query <domain>
Дальше полезно посмотреть не “что резолвится”, а как именно система выбирает адреса и в каком порядке.
getent ahostsv4 <domain>
Следующий слой - системные кеши и библиотечный резолвинг, который вообще не виден через обычные проверки.
strace -e trace=network -f curl -s <url>
N.A.
👍9
Service работает через IP, не через DNS
Сервис открывается по IP нормально, но по доменному имени начинает вести себя странно: таймауты, разные ответы, иногда вообще “не тот” backend.
Часто это, когда клиент и DNS живут разной жизнью: IP уже поменялся, а часть систем продолжает ходить по старым записям.
Дальше полезно посмотреть, что реально возвращается не “в теории”, а в контексте системы.
N.A.
Сервис открывается по IP нормально, но по доменному имени начинает вести себя странно: таймауты, разные ответы, иногда вообще “не тот” backend.
Часто это, когда клиент и DNS живут разной жизнью: IP уже поменялся, а часть систем продолжает ходить по старым записям.
resolvectl status
Дальше полезно посмотреть, что реально возвращается не “в теории”, а в контексте системы.
getent hosts <domain>
ip route get <ip>
curl -v --resolve <domain>:443:<ip> https://<domain>
N.A.
👍8
Неравномерное распределение трафика LB
⏺ Снаружи всё выглядит нормально: LB живой, backend’ы подняты, трафик есть, но один инстанс стабильно перегружен, а остальные почти пустые.
Распределение часто ломается не на уровне новых подключений, а на уровне уже установленных сессий и того, как они “прилипают” к backend’ам.
⏺ По общей картине видно, что соединения есть, но это ничего не говорит о том, как они распределены между нодами и как долго живут.
Если разложить соединения глубже, становится заметно, что часть клиентов держит длинные сессии и фактически закрепляется за конкретным backend’ом.
⏺ И именно эти долгоживущие соединения начинают создавать перекос: новые запросы уже не успевают “выровнять” баланс.
Иногда эффект усиливается просто из-за того, что клиенты создают разное количество соединений и неравномерно их переиспользуют.
⏺ При повторных запросах можно заметить, что ответы стабильно приходят с одних и тех же backend’ов, даже если ожидается равномерное распределение.
N.A.
Распределение часто ломается не на уровне новых подключений, а на уровне уже установленных сессий и того, как они “прилипают” к backend’ам.
ss -s
Если разложить соединения глубже, становится заметно, что часть клиентов держит длинные сессии и фактически закрепляется за конкретным backend’ом.
ss -tn sport = :80
Иногда эффект усиливается просто из-за того, что клиенты создают разное количество соединений и неравномерно их переиспользуют.
curl -I <url>
ipvsadm -Ln
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
5 команд, которые реально помогают ловить “невидимые” сетевые проблемы
1️⃣ TCP-состояние и скрытые retransmit’ы
Когда сервис “живой”, но всё тормозит - обычные проверки ничего не показывают. Тут полезно смотреть, что происходит прямо в TCP-очередях.
2️⃣ Реальное поведение маршрута ядра (а не “как должно быть”)
Иногда проблема не в сети, а в том, куда система на самом деле отправляет трафик.
3️⃣ Где именно ломается соединение (DNS / connect / TLS / HTTP)
Когда всё “медленно”, важно понять, на каком этапе зависает запрос.
4️⃣ Потери, которые не видно через ping
ICMP может быть чистым, а TCP уже страдает. Нужен более честный взгляд на поток.
5️⃣ Реальная картина очередей и backpressure
Когда система “не падает, но не отвечает” - это почти всегда очереди.
N.A.
Когда сервис “живой”, но всё тормозит - обычные проверки ничего не показывают. Тут полезно смотреть, что происходит прямо в TCP-очередях.
ss -ti state all
Иногда проблема не в сети, а в том, куда система на самом деле отправляет трафик.
ip route get <ip>
Когда всё “медленно”, важно понять, на каком этапе зависает запрос.
curl -w "@-" -o /dev/null -s <url>
ICMP может быть чистым, а TCP уже страдает. Нужен более честный взгляд на поток.
mtr -T -P 443 <host>
Когда система “не падает, но не отвечает” - это почти всегда очереди.
ss -ltnp
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍6
Traceroute не совпадает с реальным путём
Сервис ведёт себя так, будто трафик идёт по одному маршруту, но traceroute показывает совсем другую картину.
При этом ping может быть стабильным, а задержки появляться “внезапно” и без логики.
⏺ Дело в том, что traceroute показывает не путь пакета, а поведение промежуточных узлов, которые могут по-разному отвечать на TTL-expired. В реальности трафик часто идёт через ECMP или policy routing, которые в traceroute просто не видны.
Иногда расхождение усиливается из-за балансировки на уровне ядра или оборудования, когда разные потоки уходят по разным линкам, а traceroute показывает только один из возможных путей.
N.A.
Сервис ведёт себя так, будто трафик идёт по одному маршруту, но traceroute показывает совсем другую картину.
При этом ping может быть стабильным, а задержки появляться “внезапно” и без логики.
traceroute <ip>
ip route get <ip>
Иногда расхождение усиливается из-за балансировки на уровне ядра или оборудования, когда разные потоки уходят по разным линкам, а traceroute показывает только один из возможных путей.
mtr -T <ip>
tracepath <ip>
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
VTP - почему его лучше отключить и как безопасно мигрировать без него
VTP (VLAN Trunking Protocol) автоматически синхронизирует VLAN-базу между коммутаторами. Звучит удобно, но по факту это бомба замедленного действия.
Главная проблема, что любой коммутатор с более высоким revision number перезапишет VLAN-базу на всех остальных. Подключил старый свич из кладовки, и все VLAN на продакшене слетели.
Почему отключают:
⏺ Один неверный свич уничтожает всю VLAN-конфигурацию сети
⏺ Сложно контролировать изменения - нет нормального аудита
⏺ VTP v1/v2 не поддерживает extended VLAN (
⏺ В современных сетях проще и безопаснее управлять VLAN вручную или через автоматизацию
Как безопасно мигрировать
1️⃣ Сначала зафиксируй текущую VLAN-базу на VTP Server
Сохрани список всех активных VLAN - это твой эталон.
2️⃣ Переводи коммутаторы в VTP Transparent по одному, начиная с краёв сети
Transparent не синхронизирует VLAN с другими, но передаёт VTP-объявления дальше - сеть не ломается сразу.
3️⃣ Убеждаешься, что VLAN-база на каждом свиче совпадает с эталоном
4️⃣ Когда все переведены в Transparent - можно отключить VTP полностью (VTP v3)
В v1/v2 режима off нет, Transparent - финальная точка.
5️⃣ Дальше VLAN управляются вручную на каждом свиче или через Ansible/Netmiko.
⚡️ Revision number обнуляется при смене VTP domain или переключении в Transparent. Если срочно нужно обезвредить «опасный» свич перед подключением - меняй domain name на любой другой.
N.A.
VTP (VLAN Trunking Protocol) автоматически синхронизирует VLAN-базу между коммутаторами. Звучит удобно, но по факту это бомба замедленного действия.
Главная проблема, что любой коммутатор с более высоким revision number перезапишет VLAN-базу на всех остальных. Подключил старый свич из кладовки, и все VLAN на продакшене слетели.
Почему отключают:
1006–4094)Как безопасно мигрировать
show vlan brief
show vtp status
Сохрани список всех активных VLAN - это твой эталон.
vtp mode transparent
Transparent не синхронизирует VLAN с другими, но передаёт VTP-объявления дальше - сеть не ломается сразу.
show vlan brief
vtp mode off
В v1/v2 режима off нет, Transparent - финальная точка.
⚡️ Revision number обнуляется при смене VTP domain или переключении в Transparent. Если срочно нужно обезвредить «опасный» свич перед подключением - меняй domain name на любой другой.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍2🔥2
OSPF: сосед завис в EXSTART/EXCHANGE
EXSTART/EXCHANGE - это этап, где два OSPF-соседа договариваются об обмене LSA. Если сосед завис здесь, база топологии не синхронизируется и маршруты не появятся.
⏺ Три главные причины: MTU mismatch (самая частая, DD-пакеты не проходят если MTU разный), дублирующийся Router ID (два роутера с одинаковым RID не могут завершить negotiation), проблемы аутентификации (пакеты уходят, но отклоняются на другой стороне).
Диагностика
Смотрим состояние соседа:
Если сосед висит в EXSTART/EXCHANGE больше нескольких секунд, уже проблема.
1️⃣ Проверяем MTU
На обоих роутерах значение должно совпадать. Либо выравниваем MTU, либо отключаем проверку:
2️⃣ Проверяем дублирующийся Router ID
RID должен быть уникальным в домене. Меняем вручную и перезапускаем процесс:
3️⃣ Проверяем аутентификацию
Тип аутентификации и ключ должны совпадать на обоих концах. Если используется MD5:
N.A.
EXSTART/EXCHANGE - это этап, где два OSPF-соседа договариваются об обмене LSA. Если сосед завис здесь, база топологии не синхронизируется и маршруты не появятся.
Диагностика
Смотрим состояние соседа:
show ip ospf neighbor
Если сосед висит в EXSTART/EXCHANGE больше нескольких секунд, уже проблема.
show interfaces Gi0/0 | include MTU
На обоих роутерах значение должно совпадать. Либо выравниваем MTU, либо отключаем проверку:
interface Gi0/0
ip ospf mtu-ignore
show ip ospf | include Router ID
RID должен быть уникальным в домене. Меняем вручную и перезапускаем процесс:
router ospf 1
router-id 1.1.1.1
clear ip ospf process
show ip ospf interface Gi0/0
Тип аутентификации и ключ должны совпадать на обоих концах. Если используется MD5:
interface Gi0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 <key>
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
Wireshark фильтры для диагностики VLAN-трафика
Быстрая шпаргалка для тех, кто разбирает проблемы на trunk-портах или отлавливает трафик конкретного VLAN.
Базовые фильтры
Показать все 802.1Q фреймы, сузить до конкретного VLAN ID или до трафика одного хоста внутри него. Отправная точка для любой диагностики:
ARP, DHCP, STP
ARP помогает отловить конфликты IP и посмотреть кто отвечает на запросы. DHCP покажет, доходят ли Discover-пакеты до сервера. STP нужен когда подозреваешь петлю или нестабильную топологию:
Трафик между двумя хостами и очистка от служебного
Первый фильтр изолирует сессию между конкретными хостами. Второй убирает CDP, LLDP и STP, когда нужно смотреть только на пользовательский трафик без шума:
Double-tag и QoS
Первый фильтр ловит QinQ-фреймы или признаки VLAN hopping, когда внутри тегированного фрейма есть ещё один тег. Второй фильтрует по значению CoS, полезно при диагностике приоритизации трафика:
N.A.
Быстрая шпаргалка для тех, кто разбирает проблемы на trunk-портах или отлавливает трафик конкретного VLAN.
Базовые фильтры
Показать все 802.1Q фреймы, сузить до конкретного VLAN ID или до трафика одного хоста внутри него. Отправная точка для любой диагностики:
vlan
vlan.id == 10
vlan.id == 10 && ip.addr == 192.168.10.5
ARP, DHCP, STP
ARP помогает отловить конфликты IP и посмотреть кто отвечает на запросы. DHCP покажет, доходят ли Discover-пакеты до сервера. STP нужен когда подозреваешь петлю или нестабильную топологию:
vlan.id == 10 && arp
vlan.id == 10 && bootp
vlan.id == 10 && stp
Трафик между двумя хостами и очистка от служебного
Первый фильтр изолирует сессию между конкретными хостами. Второй убирает CDP, LLDP и STP, когда нужно смотреть только на пользовательский трафик без шума:
vlan.id == 20 && ip.addr == 192.168.20.1 && ip.addr == 192.168.20.2
vlan.id == 10 && !stp && !cdp && !lldp
Double-tag и QoS
Первый фильтр ловит QinQ-фреймы или признаки VLAN hopping, когда внутри тегированного фрейма есть ещё один тег. Второй фильтрует по значению CoS, полезно при диагностике приоритизации трафика:
vlan.id == 100 && vlan
vlan.priority == 5
N.A.
👍8❤1
LACP vs Static LAG: когда что использовать
LAG (Link Aggregation Group) объединяет несколько физических линков в один логический. Два способа это сделать: статически или через LACP. Разница принципиальная.
⏺ Static LAG просто объединяет порты без какого-либо согласования. Коммутатор не знает, что происходит на другой стороне, линк считается активным даже если там ничего нет. Быстро настраивается, но слепо.
⏺ LACP (802.3ad) согласовывает агрегат через обмен LACPDU-пакетами. Оба конца знают о состоянии линков, при падении одного порта трафик перераспределяется автоматически. Чуть сложнее в настройке, но надёжнее.
Статику используют когда другая сторона не поддерживает LACP, например старое оборудование или некоторые гипервизоры. В остальных случаях лучше LACP.
Настройка на Cisco
Static LAG:
LACP (active инициирует согласование, passive ждёт):
Проверка агрегата
Смотрим статус Port-Channel и какие порты в него входят:
В выводе show etherchannel summary флаги говорят всё: P - порт в бандле, D - порт упал, S - suspended. Если видишь I (individual) вместо P, порт не попал в агрегат, скорее всего несовпадение настроек speed/duplex или native VLAN.
N.A.
LAG (Link Aggregation Group) объединяет несколько физических линков в один логический. Два способа это сделать: статически или через LACP. Разница принципиальная.
Статику используют когда другая сторона не поддерживает LACP, например старое оборудование или некоторые гипервизоры. В остальных случаях лучше LACP.
Настройка на Cisco
Static LAG:
interface range Gi0/1 - 2
channel-group 1 mode on
LACP (active инициирует согласование, passive ждёт):
interface range Gi0/1 - 2
channel-group 1 mode active
Проверка агрегата
Смотрим статус Port-Channel и какие порты в него входят:
show etherchannel summary
show lacp neighbor
В выводе show etherchannel summary флаги говорят всё: P - порт в бандле, D - порт упал, S - suspended. Если видишь I (individual) вместо P, порт не попал в агрегат, скорее всего несовпадение настроек speed/duplex или native VLAN.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2
Bonding на Linux: mode 802.3ad и проверка активных линков
Bonding в Linux это аналог LAG на уровне ОС. Mode 802.3ad (LACP) объединяет интерфейсы в агрегат с динамическим согласованием, как на Cisco mode active.
Для работы нужен пакет ifenslave и загруженный модуль bonding:
Настройка через systemd-networkd
Создаём bond-интерфейс:
Привязываем физические интерфейсы к бонду:
Назначаем IP на bond0:
Проверка
Статус агрегата и активных линков:
Покажет режим, активные интерфейсы, состояние LACP и MII каждого слейва. Если слейв показывает MII Status: down, физический линк не поднят или коммутатор не согласовал LACP.
Быстрая проверка через ip:
N.A.
Bonding в Linux это аналог LAG на уровне ОС. Mode 802.3ad (LACP) объединяет интерфейсы в агрегат с динамическим согласованием, как на Cisco mode active.
Для работы нужен пакет ifenslave и загруженный модуль bonding:
modprobe bonding
apt install ifenslave
Настройка через systemd-networkd
Создаём bond-интерфейс:
# /etc/systemd/network/bond0.netdev
[NetDev]
Name=bond0
Kind=bond
[Bond]
Mode=802.3ad
LACPTransmitRate=fast
MIIMonitorSec=100ms
Привязываем физические интерфейсы к бонду:
# /etc/systemd/network/bond-slave.network
[Match]
Name=eth0 eth1
[Network]
Bond=bond0
Назначаем IP на bond0:
# /etc/systemd/network/bond0.network
[Match]
Name=bond0
[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
Проверка
Статус агрегата и активных линков:
cat /proc/net/bonding/bond0
Покажет режим, активные интерфейсы, состояние LACP и MII каждого слейва. Если слейв показывает MII Status: down, физический линк не поднят или коммутатор не согласовал LACP.
Быстрая проверка через ip:
ip link show bond0
ip -d link show bond0
N.A.
👍6
Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:
ip addr show # список интерфейсов
ip route show # таблица маршрутов
vtysh -c "show running-config" # конфиги роутеров
show vlan brief # VLAN на коммутаторах
2️⃣Структурирование: Систематизируем данные: топология, IP-план, протоколы, ACL/Firewall.
Пример таблицы IP:
Устройство | Интерфейс | IP | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1 | eth0 | 10.0.1.1/24 | 10 | WAN
sw1 | vlan10 | 10.0.1.2/24 | 10 | серверная зона
sw2 | vlan20 | 10.0.2.1/24 | 20 | офисная зона
server1 | eth1 | 10.0.1.10/24 | 10 | база данных
server2 | eth1 | 10.0.1.11/24 | 10 | веб-сервер
git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"
Пример Mermaid:
graph TD
R1 --> SW1
SW1 --> Server1
SW1 --> Server2
Полезные команды для контроля
git log --oneline --graph # история изменений
diff old_config new_config # что изменилось
ping 10.0.1.2 # проверить доступность после изменений
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14
STP Port States: почему порт долго висит в Listening/Learning
STP переводит порт через несколько состояний перед тем как начать передавать трафик. Blocking, Listening, Learning, Forwarding. В норме переход занимает 30 секунд (15 сек Listening + 15 сек Learning). Если порт завис и не переходит в Forwarding, сеть на этом сегменте не работает.
⏺ Чаще всего дело в одном из трёх: некорректно выбран Root Bridge и порт пересчитывает топологию, на порту включён TCN (Topology Change Notification) и STP постоянно переинициализируется, или PortFast не включён там где должен быть.
⏺ Диагностика
Смотрим состояние портов и кто Root Bridge:
Проверяем TCN, частые topology change говорят о нестабильном линке или петле:
⏺ Что делать?
Если порт ведёт к конечному устройству (PC, сервер, принтер), включаем PortFast. Порт сразу переходит в Forwarding, минуя Listening/Learning:
Если TCN генерирует конкретный порт, включаем BPDU Guard. При получении BPDU порт уходит в err-disabled вместо того чтобы ломать топологию:
Глобально для всех PortFast-портов:
N.A.
STP переводит порт через несколько состояний перед тем как начать передавать трафик. Blocking, Listening, Learning, Forwarding. В норме переход занимает 30 секунд (15 сек Listening + 15 сек Learning). Если порт завис и не переходит в Forwarding, сеть на этом сегменте не работает.
Смотрим состояние портов и кто Root Bridge:
show spanning-tree
show spanning-tree detail
Проверяем TCN, частые topology change говорят о нестабильном линке или петле:
show spanning-tree detail | include topology change
Если порт ведёт к конечному устройству (PC, сервер, принтер), включаем PortFast. Порт сразу переходит в Forwarding, минуя Listening/Learning:
interface Gi0/1
spanning-tree portfast
Если TCN генерирует конкретный порт, включаем BPDU Guard. При получении BPDU порт уходит в err-disabled вместо того чтобы ломать топологию:
interface Gi0/1
spanning-tree bpduguard enable
Глобально для всех PortFast-портов:
spanning-tree portfast default
spanning-tree portfast bpduguard default
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4👌1
BGP Blackholing: как быстро дропать DDoS-трафик на уровне сети
Когда на сервер идёт DDoS, стандартный ответ: заблокировать на фаерволе.
Сложность в том, что трафик всё равно доходит до твоего канала и забивает его. Blackholing решает это на уровень выше, трафик дропается ещё у провайдера или на границе сети.
Идея простая: анонсируешь BGP-соседу маршрут до атакуемого IP с community-тегом, который говорит “дропай этот трафик”. Провайдер получает анонс и перенаправляет трафик в null на своей стороне до того как он дошёл до тебя.
Как это выглядит на практике
Создаём статический маршрут в null и анонсируем его через BGP с нужным community (значение уточняется у провайдера, обычно это RTBH community):
Проверяем что маршрут анонсируется соседу:
Убираем blackhole когда атака закончилась
N.A.
Когда на сервер идёт DDoS, стандартный ответ: заблокировать на фаерволе.
Сложность в том, что трафик всё равно доходит до твоего канала и забивает его. Blackholing решает это на уровень выше, трафик дропается ещё у провайдера или на границе сети.
Идея простая: анонсируешь BGP-соседу маршрут до атакуемого IP с community-тегом, который говорит “дропай этот трафик”. Провайдер получает анонс и перенаправляет трафик в null на своей стороне до того как он дошёл до тебя.
Как это выглядит на практике
Создаём статический маршрут в null и анонсируем его через BGP с нужным community (значение уточняется у провайдера, обычно это RTBH community):
ip route 203.0.113.5 255.255.255.255 Null0
route-map BLACKHOLE permit 10
set community 65535:666 additive
set local-preference 200
router bgp 65001
neighbor 198.51.100.1 route-map BLACKHOLE out
network 203.0.113.5 mask 255.255.255.255
Проверяем что маршрут анонсируется соседу:
show bgp ipv4 unicast 203.0.113.5
show bgp neighbors 198.51.100.1 advertised-routes
Убираем blackhole когда атака закончилась
no ip route 203.0.113.5 255.255.255.255 Null0
clear ip bgp 198.51.100.1 soft out
N.A.
🔥9✍4👍1
Anycast: как это работает за пределами DNS
Anycast это когда один и тот же IP-адрес анонсируется из нескольких точек одновременно. Клиент отправляет пакет, сеть сама выбирает ближайший узел по метрикам BGP.
Большинство знает anycast по DNS: 8.8.8.8 это не один сервер, а сотни точек по всему миру. Но этим применение не ограничивается.
CDN используют anycast чтобы отдавать статику с ближайшего к пользователю POP-а. Cloudflare, Fastly, Akamai, все работают так. Пользователь в Берлине получает контент из Франкфурта, а не из Нью-Йорка, хотя обращается к одному IP.
NTP-серверы пула
Как анонсируется anycast-префикс
Каждая точка присутствия поднимает BGP-сессию с апстримом и анонсирует один и тот же префикс:
Маршрут в Null0 нужен чтобы BGP принял префикс для анонса, реальный трафик обрабатывается локально.
N.A.
Anycast это когда один и тот же IP-адрес анонсируется из нескольких точек одновременно. Клиент отправляет пакет, сеть сама выбирает ближайший узел по метрикам BGP.
Никакого DNS, никакого балансировщика между клиентом и сервером.
Большинство знает anycast по DNS: 8.8.8.8 это не один сервер, а сотни точек по всему миру. Но этим применение не ограничивается.
CDN используют anycast чтобы отдавать статику с ближайшего к пользователю POP-а. Cloudflare, Fastly, Akamai, все работают так. Пользователь в Берлине получает контент из Франкфурта, а не из Нью-Йорка, хотя обращается к одному IP.
DDoS-mitigation строится на том же принципе. Атака распределяется между всеми точками присутствия, ни одна не получает весь объём трафика.
NTP-серверы пула
pool.ntp.org тоже anycast, клиент всегда попадает на географически близкий узел без какой-либо логики на своей стороне.Как анонсируется anycast-префикс
Каждая точка присутствия поднимает BGP-сессию с апстримом и анонсирует один и тот же префикс:
router bgp 65001
network 192.0.2.0 mask 255.255.255.0
ip route 192.0.2.0 255.255.255.0 Null0
Маршрут в Null0 нужен чтобы BGP принял префикс для анонса, реальный трафик обрабатывается локально.
N.A.
👍8
Proxy ARP: когда роутер отвечает на чужие ARP-запросы
Обычно на ARP-запрос “кто такой
Где это реально используется сейчас
В облаках и гипервизорах Proxy ARP используется постоянно. Когда виртуальная машина получает IP из одной подсети, а физически находится на хосте в другой, гипервизор отвечает на ARP-запросы за неё. VMware, KVM с определёнными сетевыми конфигурациями, AWS при определённых настройках VPC, всё это Proxy ARP под капотом.
Когда это ломает сеть
Если Proxy ARP включён на роутере по умолчанию (на Cisco он включён), а в сети несколько роутеров, начинается хаос.
Несколько устройств отвечают на один ARP-запрос разными MAC-адресами, трафик уходит не туда, сессии рвутся.
Вторая проблема: хосты кешируют ARP-ответы. Если роутер ответил за чужой IP, хост будет слать трафик через него даже когда прямой маршрут появился.
Проверяем на Cisco:
Отключаем если не нужен:
На Linux:
N.A.
Обычно на ARP-запрос “кто такой
192.168.1.50?” отвечает сам хост с этим IP. Proxy ARP меняет это поведение: роутер перехватывает запрос и отвечает своим MAC-адресом, как будто этот IP находится на нём. Хост отправляет трафик на роутер, роутер форвардит дальше.Изначально это придумали для соединения подсетей без настройки маршрутов на конечных устройствах. Актуально было в эпоху когда маски подсетей на хостах не совпадали с реальной топологией.
Где это реально используется сейчас
В облаках и гипервизорах Proxy ARP используется постоянно. Когда виртуальная машина получает IP из одной подсети, а физически находится на хосте в другой, гипервизор отвечает на ARP-запросы за неё. VMware, KVM с определёнными сетевыми конфигурациями, AWS при определённых настройках VPC, всё это Proxy ARP под капотом.
Когда это ломает сеть
Если Proxy ARP включён на роутере по умолчанию (на Cisco он включён), а в сети несколько роутеров, начинается хаос.
Несколько устройств отвечают на один ARP-запрос разными MAC-адресами, трафик уходит не туда, сессии рвутся.
Вторая проблема: хосты кешируют ARP-ответы. Если роутер ответил за чужой IP, хост будет слать трафик через него даже когда прямой маршрут появился.
Проверяем на Cisco:
show ip interface Gi0/0 | include proxy
Отключаем если не нужен:
interface Gi0/0
no ip proxy-arp
На Linux:
cat /proc/sys/net/ipv4/conf/eth0/proxy_arp
echo 0 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
N.A.
👍7
Как коммутатор строит CAM-таблицу и что происходит при переполнении
CAM-таблица это то, за счёт чего коммутатор работает как коммутатор, а не как хаб. Без неё каждый фрейм уходил бы на все порты.
Как строится таблица
Коммутатор учится пассивно: когда фрейм приходит на порт, смотрит на source MAC и записывает на каком порту он находится.
Когда нужно отправить фрейм, ищет destination MAC. Нашёл, отправил на конкретный порт. Не нашёл, flooding на все порты кроме входящего. Записи живут 300 секунд по умолчанию, потом удаляются.
Что происходит при переполнении
CAM хранится в аппаратной памяти фиксированного размера. Когда таблица полна, новые записи не добавляются и любой фрейм с неизвестным MAC уходит флудом. Коммутатор деградирует до хаба.
На этом построена атака MAC flooding: генерируются фреймы с тысячами случайных source MAC, таблица забивается, и весь трафик начинает идти на порт атакующего тоже.
Защита
Port Security ограничивает количество MAC на порту:
N.A.
CAM-таблица это то, за счёт чего коммутатор работает как коммутатор, а не как хаб. Без неё каждый фрейм уходил бы на все порты.
Как строится таблица
Коммутатор учится пассивно: когда фрейм приходит на порт, смотрит на source MAC и записывает на каком порту он находится.
Когда нужно отправить фрейм, ищет destination MAC. Нашёл, отправил на конкретный порт. Не нашёл, flooding на все порты кроме входящего. Записи живут 300 секунд по умолчанию, потом удаляются.
show mac address-table
show mac address-table aging-time
Что происходит при переполнении
CAM хранится в аппаратной памяти фиксированного размера. Когда таблица полна, новые записи не добавляются и любой фрейм с неизвестным MAC уходит флудом. Коммутатор деградирует до хаба.
На этом построена атака MAC flooding: генерируются фреймы с тысячами случайных source MAC, таблица забивается, и весь трафик начинает идти на порт атакующего тоже.
Защита
Port Security ограничивает количество MAC на порту:
interface Gi0/1
switchport port-security
switchport port-security maximum 2
switchport port-security violation restrict
show port-security interface Gi0/1
N.A.
👍6
Почему MTU 1500 в реальности никогда не 1500?
MTU 1500 это максимальный размер payload в Ethernet-фрейме. Цифра знакомая, но в реальной сети между твоим приложением и получателем почти всегда есть что-то, что откусывает от этого значения.
Туннели
Любой туннель оборачивает оригинальный пакет в новый и добавляет свои заголовки. GRE забирает 24 байта, IPsec в tunnel mode от 50 до 70 байт в зависимости от алгоритмов шифрования, WireGuard 60 байт, VXLAN 50 байт.
Если на пути несколько туннелей, байты суммируются. Итоговый MTU внутри может оказаться 1400 и ниже, при этом интерфейс снаружи честно показывает 1500.
PPPoE
Если роутер не учитывает это и анонсирует клиентам MSS под 1500, крупные TCP-сегменты начинают фрагментироваться или молча дропаться на пути.
Делаем вторую часть с более подробным разбором на практике?
N.A.
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.
1👍45
Как работает 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:
Как ACL влияют на TCAM
Каждая строка ACL это одна или несколько записей в TCAM. Правило с диапазоном портов разбивается на несколько записей потому что TCAM не умеет в диапазоны нативно.
Правило permit tcp any any gt 1024 может развернуться в десятки записей. На больших ACL это незаметно, но на коммутаторах с маленьким TCAM таблица заканчивается и новые правила просто не применяются.
Что делать при нехватке
Меняем SDM profile чтобы перераспределить TCAM между функциями. Например отдать больше под ACL за счёт MAC-таблицы:
N.A.
Обычная 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.
👍4🤯1
Почему MTU 1500 в реальности никогда не 1500. Часть 2
Почему фрагментация не всегда спасает: Когда пакет не влезает в MTU промежуточного узла, тот должен отправить отправителю ICMP Fragmentation Needed.
На практике многие сети и файерволы блокируют ICMP полностью. Сообщение Fragmentation Needed не доходит, отправитель продолжает слать большие пакеты, они дропаются без каких-либо уведомлений.
Симптом характерный: мелкие запросы проходят нормально, крупные зависают или обрываются.
Проверяем реальный Path MTU до хоста и тестируем конкретный размер пакета:
Если ping с -M do (don’t fragment) падает на определённом размере, MTU на пути именно там.
Как фиксить
Выставляем MTU вручную на туннельном интерфейсе:
Для PPPoE на Cisco MSS clamp ограничивает размер TCP-сегментов на уровне роутера, не давая клиентам использовать значения выше допустимого:
N.A.
Почему фрагментация не всегда спасает: Когда пакет не влезает в 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.
👍6❤2🔥1
Что такое IX и как трафик идёт внутри него
IX (Internet Exchange) это физическая точка где провайдеры, CDN и крупные сети подключаются друг к другу напрямую. Вместо того чтобы гонять трафик через транзитного провайдера и платить за каждый гигабит, участники обмениваются трафиком напрямую и бесплатно между собой.
Как устроено внутри
Физически IX это один большой коммутатор (или несколько связанных), к которому все участники подключают свои роутеры. Эта общая среда называется IXP fabric. Каждый участник получает порт и IP-адрес в общей подсети IX.
Дальше всё через BGP. Каждый участник поднимает BGP-сессии с теми с кем хочет обмениваться трафиком, анонсирует свои префиксы и получает чужие. Никакой автоматики, только явные пиринговые договорённости.
Route Server
Чтобы не поднимать сотни BGP-сессий с каждым участником отдельно, большинство IX предоставляют Route Server.
Подключаешься к одному RS, получаешь маршруты от всех участников кто тоже подключён к RS. Можно фильтровать что принимать и что анонсировать.
Как трафик идёт внутри
Пакет от пользователя провайдера А до сервера в сети провайдера Б: роутер А смотрит BGP-таблицу, видит что префикс Б получен через IX, отправляет пакет напрямую на роутер Б через IXP fabric. Транзитный провайдер не участвует, задержка меньше, стоимость ниже.
N.A.
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.
👍9