Как Ethernet временно останавливает передачу
Представим, что сервер принимает трафик быстрее, чем успевает его обрабатывать. Буферы сетевой карты заполняются, и скоро начнутся потери пакетов.
Но Ethernet умеет не только отбрасывать кадры. В некоторых сетях он может попросить соседнее устройство временно прекратить передачу.
⏺ Как это работает?
В стандарте IEEE 802.3x предусмотрены специальные PAUSE-кадры. Если включён Flow Control, перегруженный приёмник может отправить такой кадр соседу.
Получив кадр, сосед временно приостанавливает обычную передачу данных по линку.
При этом PAUSE действует на весь линк, а не на отдельное TCP-соединение.
⏺ Как проверить в Linux?
Посмотрим настройки сетевой карты:
В выводе интересуют
Статистику можно поискать через:
Названия счётчиков и их доступность зависят от драйвера.
⏺ В чём подвох?
PAUSE помогает избежать переполнения буферов, но создаёт другую проблему: один перегруженный получатель способен затормозить весь трафик на физическом соединении.
Из-за этого Flow Control не всегда улучшает производительность. Иногда он просто переносит перегрузку на соседнее устройство.
N.A.
Представим, что сервер принимает трафик быстрее, чем успевает его обрабатывать. Буферы сетевой карты заполняются, и скоро начнутся потери пакетов.
Но Ethernet умеет не только отбрасывать кадры. В некоторых сетях он может попросить соседнее устройство временно прекратить передачу.
В стандарте IEEE 802.3x предусмотрены специальные PAUSE-кадры. Если включён Flow Control, перегруженный приёмник может отправить такой кадр соседу.
Внутри указывается время паузы в единицах по 512 битовых интервалов.
Получив кадр, сосед временно приостанавливает обычную передачу данных по линку.
При этом PAUSE действует на весь линк, а не на отдельное TCP-соединение.
Посмотрим настройки сетевой карты:
ethtool -a eth0
В выводе интересуют
RX и TX: разрешён ли приём PAUSE-кадров и может ли интерфейс отправлять их сам.Статистику можно поискать через:
ethtool -S eth0 | grep -i pause
Названия счётчиков и их доступность зависят от драйвера.
PAUSE помогает избежать переполнения буферов, но создаёт другую проблему: один перегруженный получатель способен затормозить весь трафик на физическом соединении.
Из-за этого Flow Control не всегда улучшает производительность. Иногда он просто переносит перегрузку на соседнее устройство.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Почему два коммутатора могут одновременно считать себя главным шлюзом
В сети используется MLAG: два физических коммутатора объединены в логическую пару, а серверы подключены сразу к обоим через LACP.
Всё работает нормально, пока между коммутаторами не пропадает служебное соединение — peer-link.
⏺ Что происходит при разрыве?
Через peer-link устройства обмениваются служебной информацией и синхронизируют часть состояния.
Если связь между ними потеряна, каждый коммутатор может перестать получать актуальные данные о соседе.
Тогда возникает риск split-brain: оба коммутатора считают, что могут самостоятельно обслуживать общие подключения.
⏺ Чем это грозит?
В зависимости от реализации MLAG возможны дублирование кадров, MAC flapping, нарушения пересылки и потери трафика.
При этом физические интерфейсы могут оставаться UP, поэтому обычная проверка состояния портов не всегда обнаружит проблему.
⏺ Как защищаются от split-brain?
Кроме того, многие реализации MLAG при потере peer-link автоматически отключают определённые порты на вторичном коммутаторе, чтобы не допустить одновременной независимой работы пары.
Конкретное поведение зависит от производителя и настроек.
N.A.
В сети используется MLAG: два физических коммутатора объединены в логическую пару, а серверы подключены сразу к обоим через LACP.
Всё работает нормально, пока между коммутаторами не пропадает служебное соединение — peer-link.
Через peer-link устройства обмениваются служебной информацией и синхронизируют часть состояния.
Если связь между ними потеряна, каждый коммутатор может перестать получать актуальные данные о соседе.
Особенно опасна ситуация, когда одновременно нарушается и дополнительный канал проверки доступности — keepalive.
Тогда возникает риск split-brain: оба коммутатора считают, что могут самостоятельно обслуживать общие подключения.
В зависимости от реализации MLAG возможны дублирование кадров, MAC flapping, нарушения пересылки и потери трафика.
При этом физические интерфейсы могут оставаться UP, поэтому обычная проверка состояния портов не всегда обнаружит проблему.
Обычно используют отдельный peer-keepalive, который проходит независимо от peer-link.
Кроме того, многие реализации MLAG при потере peer-link автоматически отключают определённые порты на вторичном коммутаторе, чтобы не допустить одновременной независимой работы пары.
Конкретное поведение зависит от производителя и настроек.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Проверка DNSSEC валидации через dig +dnssec, а не просто наличия настройки
DNSSEC включён в конфиге резолвера, но это не значит что валидация реально работает.
Резолвер может принимать неподписанные ответы, игнорировать сломанные подписи или вообще не проверять цепочку доверия. Проверяем поведение, а не настройку.
Базовая проверка: резолвер возвращает AD флаг
AD (Authentic Data) в ответе означает что резолвер проверил подписи и доверяет ответу:
Смотрим на флаги в строке flags: qr rd ra ad. Если ad есть, валидация работает для этого домена.
Проверка что резолвер отклоняет сломанные подписи
Существуют специальные тестовые домены с намеренно сломанным DNSSEC:
Если резолвер валидирует правильно, ответ должен быть SERVFAIL а не реальный IP. Если вернулся IP, резолвер принимает сломанные подписи.
Тот же тест, другой домен. SERVFAIL это ожидаемый правильный ответ.
Скрипт массовой проверки нескольких резолверов
В cron раз в час:
N.A.
DNSSEC включён в конфиге резолвера, но это не значит что валидация реально работает.
Резолвер может принимать неподписанные ответы, игнорировать сломанные подписи или вообще не проверять цепочку доверия. Проверяем поведение, а не настройку.
Базовая проверка: резолвер возвращает AD флаг
AD (Authentic Data) в ответе означает что резолвер проверил подписи и доверяет ответу:
dig +dnssec sigok.verteiltesysteme.net @127.0.0.1
Смотрим на флаги в строке flags: qr rd ra ad. Если ad есть, валидация работает для этого домена.
Проверка что резолвер отклоняет сломанные подписи
Существуют специальные тестовые домены с намеренно сломанным DNSSEC:
dig sigfail.verteiltesysteme.net @127.0.0.1
Если резолвер валидирует правильно, ответ должен быть SERVFAIL а не реальный IP. Если вернулся IP, резолвер принимает сломанные подписи.
dig dnssec-failed.org @127.0.0.1
Тот же тест, другой домен. SERVFAIL это ожидаемый правильный ответ.
Скрипт массовой проверки нескольких резолверов
#!/bin/bash
RESOLVERS=(«127.0.0.1» «1.1.1.1» «8.8.8.8» «9.9.9.9»)
VALID_DOMAIN=«sigok.verteiltesysteme.net»
BROKEN_DOMAIN=«sigfail.verteiltesysteme.net»
LOG=«/var/log/dnssec_check.log»
echo «=== DNSSEC check $(date) ===« >> «$LOG»
for resolver in «${RESOLVERS[@]}»; do
valid_ad=$(dig +dnssec +time=3 «$VALID_DOMAIN» @«$resolver» 2>/dev/null \
| grep «flags:» | grep -c « ad «)
broken_status=$(dig +time=3 «$BROKEN_DOMAIN» @«$resolver» 2>/dev/null \
| grep «status:» | awk -F’[,:]’ ‘{print $2}’ | tr -d ‘ ‘)
if [ «$valid_ad» -eq 1 ] && [ «$broken_status» = «SERVFAIL» ]; then
result=«OK»
elif [ «$valid_ad» -eq 0 ]; then
result=«FAIL: не возвращает AD флаг»
else
result=«FAIL: принимает сломанные подписи ($broken_status)»
fi
echo «$resolver: $result» | tee -a «$LOG»
done
В cron раз в час:
0 * * * * /usr/local/bin/check_dnssec.sh
N.A.
👍4
VLAN Translation: когда VLAN 100 превращается в VLAN 200
Представим, что две компании подключаются через сеть оператора. У первой используется VLAN 100, а у второй - VLAN 200.
Нужно объединить их в один L2-сегмент, но менять VLAN на оборудовании клиентов никто не хочет.
Для этого существует VLAN Translation - механизм переписывания VLAN-тегов прямо на коммутаторе.
⏺ Как это работает?
Коммутатор получает Ethernet-кадр с тегом VLAN 100, заменяет VLAN ID на 200 и отправляет дальше.
При этом IP-адреса, MAC-адреса и содержимое полезной нагрузки не меняются. Переписывается именно VLAN ID в заголовке 802.1Q.
⏺ Как это настраивается?
На некоторых платформах Cisco с поддержкой VLAN mapping используется такой синтаксис:
Конкретные команды и ограничения зависят от модели и версии ПО.
Проверить настройки на поддерживаемых платформах можно командой:
⏺ Где применяется?
Чаще всего VLAN Translation встречается в операторских сетях, при объединении инфраструктур и подключении клиентов с пересекающимися VLAN ID.
Но важно учитывать: трансляция не создаёт изоляцию сама по себе. Если несколько клиентских VLAN отображаются в один общий VLAN, их трафик может оказаться в одном широковещательном домене.
⚡️ VLAN Translation позволяет соединять L2-сети с разной нумерацией VLAN без изменения конфигурации конечных устройств. Главное - правильно определить, где именно переписываются теги и какие сегменты после этого объединяются.
N.A.
Представим, что две компании подключаются через сеть оператора. У первой используется VLAN 100, а у второй - VLAN 200.
Нужно объединить их в один L2-сегмент, но менять VLAN на оборудовании клиентов никто не хочет.
Для этого существует VLAN Translation - механизм переписывания VLAN-тегов прямо на коммутаторе.
Коммутатор получает Ethernet-кадр с тегом VLAN 100, заменяет VLAN ID на 200 и отправляет дальше.
При обратной передаче происходит обратная замена: VLAN 200 превращается в VLAN 100.
При этом IP-адреса, MAC-адреса и содержимое полезной нагрузки не меняются. Переписывается именно VLAN ID в заголовке 802.1Q.
На некоторых платформах Cisco с поддержкой VLAN mapping используется такой синтаксис:
interface GigabitEthernet1/0/1
switchport mode trunk
switchport vlan mapping 100 200
switchport vlan mapping enable
Конкретные команды и ограничения зависят от модели и версии ПО.
Проверить настройки на поддерживаемых платформах можно командой:
show interfaces vlan mapping
Чаще всего VLAN Translation встречается в операторских сетях, при объединении инфраструктур и подключении клиентов с пересекающимися VLAN ID.
Но важно учитывать: трансляция не создаёт изоляцию сама по себе. Если несколько клиентских VLAN отображаются в один общий VLAN, их трафик может оказаться в одном широковещательном домене.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
3 команды для диагностики нестабильного OSPF-соседства
OSPF-соседство периодически переходит из Full в Down, а затем восстанавливается. При этом интерфейс остаётся UP, и обычный ping может не показывать проблем.
На Cisco IOS/IOS XE причину можно искать через три команды.
⏺ Проверяем состояние соседей
Смотрим состояние соседства, Dead Timer, количество переходов между состояниями и время последнего изменения.
Если счётчик переходов растёт, соседство действительно нестабильно, даже если сейчас оно снова Full.
⏺ Проверяем параметры интерфейса
Здесь видны Hello и Dead Interval, тип OSPF-сети, приоритет маршрутизатора и другие параметры.
Особенно важно сравнить таймеры на обоих концах соединения. Несовпадение Hello/Dead Interval обычно не позволяет установить соседство.
⏺ Ищем причину последнего сброса
В логах можно найти сообщения об истечении Dead Timer, изменениях состояния соседей и других событиях OSPF.
Если соседство падает по Dead Timer, стоит проверить потери Hello-пакетов, загрузку control plane и фильтрацию IP-протокола 89.
⚡️ Состояние Full показывает только текущую картину. Для диагностики нестабильного OSPF важнее история переходов, параметры интерфейса и причина последнего сброса соседства.
N.A.
OSPF-соседство периодически переходит из Full в Down, а затем восстанавливается. При этом интерфейс остаётся UP, и обычный ping может не показывать проблем.
На Cisco IOS/IOS XE причину можно искать через три команды.
show ip ospf neighbor detail
Смотрим состояние соседства, Dead Timer, количество переходов между состояниями и время последнего изменения.
Если счётчик переходов растёт, соседство действительно нестабильно, даже если сейчас оно снова Full.
show ip ospf interface GigabitEthernet0/0
Здесь видны Hello и Dead Interval, тип OSPF-сети, приоритет маршрутизатора и другие параметры.
Особенно важно сравнить таймеры на обоих концах соединения. Несовпадение Hello/Dead Interval обычно не позволяет установить соседство.
show logging | include OSPF
В логах можно найти сообщения об истечении Dead Timer, изменениях состояния соседей и других событиях OSPF.
Если соседство падает по Dead Timer, стоит проверить потери Hello-пакетов, загрузку control plane и фильтрацию IP-протокола 89.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Маршруты правильные, но трафик идёт по кругу: как найти MPLS-ловушку
В MPLS-сети может возникнуть ситуация, когда IP-маршрутизация выглядит исправной, но пакеты с метками зацикливаются между двумя LSR.
Причина - несогласованность таблиц пересылки меток после изменения топологии.
⏺ Сначала проверяем LFIB
На Cisco IOS/IOS XE:
Здесь видно, какую входящую метку маршрутизатор заменяет на выходную и какому next-hop отправляет пакет.
Если два соседних LSR пересылают трафик для одного FEC обратно друг другу, возможна петля на уровне MPLS.
⏺ Проверяем путь с метками
На платформах с поддержкой MPLS LSP Ping/Traceroute команда помогает исследовать путь конкретного FEC через MPLS-сеть.
Если трассировка показывает повторяющиеся узлы, сравниваем LFIB на каждом из них.
⏺ Ищем источник расхождения
Проверяем, какие метки получены от соседей и соответствуют ли они ожидаемым FEC.
При этом важно отличать ошибку LDP от временной микропетли при сходимости IGP: таблицы могут быть корректными по отдельности, но обновляться на разных маршрутизаторах не одновременно.
⚡️ В MPLS недостаточно проверить
N.A.
В MPLS-сети может возникнуть ситуация, когда IP-маршрутизация выглядит исправной, но пакеты с метками зацикливаются между двумя LSR.
Причина - несогласованность таблиц пересылки меток после изменения топологии.
На Cisco IOS/IOS XE:
show mpls forwarding-table
Здесь видно, какую входящую метку маршрутизатор заменяет на выходную и какому next-hop отправляет пакет.
Если два соседних LSR пересылают трафик для одного FEC обратно друг другу, возможна петля на уровне MPLS.
traceroute mpls ipv4 10.20.30.0/24
На платформах с поддержкой MPLS LSP Ping/Traceroute команда помогает исследовать путь конкретного FEC через MPLS-сеть.
Если трассировка показывает повторяющиеся узлы, сравниваем LFIB на каждом из них.
show mpls ldp bindings
Проверяем, какие метки получены от соседей и соответствуют ли они ожидаемым FEC.
При этом важно отличать ошибку LDP от временной микропетли при сходимости IGP: таблицы могут быть корректными по отдельности, но обновляться на разных маршрутизаторах не одновременно.
show ip route. Пакеты с метками пересылаются по LFIB, поэтому проблема может находиться в label forwarding, даже когда IP-маршрут выглядит совершенно нормальным.N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
TCAM переполнен: почему новая ACL не применяется
Представим, что сетевой инженер добавил несколько правил ACL на коммутатор. Конфигурация сохранилась, ошибок в синтаксисе нет, но часть трафика продолжает проходить так, будто новых правил не существует.
⏺ Что такое TCAM?
Ternary Content Addressable Memory - специальная память, которую коммутаторы используют для быстрого поиска совпадений по правилам.
В отличие от обычной памяти, TCAM умеет сопоставлять биты со значениями 0, 1 и «неважно». Благодаря этому оборудование может проверять ACL на скорости линии, не передавая каждый пакет процессору.
⏺ Почему она заканчивается?
Одно правило ACL не обязательно занимает одну запись TCAM.
Кроме того, TCAM используется не только для ACL. В зависимости от платформы её ресурсы могут распределяться между маршрутизацией, QoS и другими функциями.
⏺ Как проверить?
На поддерживаемых Cisco Catalyst можно посмотреть использование аппаратных ресурсов:
Команда зависит от модели и версии IOS XE. На других платформах используются собственные средства диагностики.
Также стоит проверить системные сообщения об ошибках программирования ACL в аппаратную таблицу.
⚡️ Успешное сохранение ACL в конфигурации ещё не гарантирует, что все правила установлены в forwarding plane. При нехватке TCAM поведение зависит от платформы: она может отклонить изменение, сообщить об ошибке или применить ограничения. Поэтому после изменения крупных ACL важно проверять не только конфигурацию, но и аппаратные ресурсы.
N.A.
Представим, что сетевой инженер добавил несколько правил ACL на коммутатор. Конфигурация сохранилась, ошибок в синтаксисе нет, но часть трафика продолжает проходить так, будто новых правил не существует.
Одна из возможных причин - закончились ресурсы TCAM.
Ternary Content Addressable Memory - специальная память, которую коммутаторы используют для быстрого поиска совпадений по правилам.
В отличие от обычной памяти, TCAM умеет сопоставлять биты со значениями 0, 1 и «неважно». Благодаря этому оборудование может проверять ACL на скорости линии, не передавая каждый пакет процессору.
Одно правило ACL не обязательно занимает одну запись TCAM.
Например, диапазоны портов, сложные маски и особенности аппаратной архитектуры могут потребовать нескольких записей для одного ACE.
Кроме того, TCAM используется не только для ACL. В зависимости от платформы её ресурсы могут распределяться между маршрутизацией, QoS и другими функциями.
На поддерживаемых Cisco Catalyst можно посмотреть использование аппаратных ресурсов:
show platform hardware fed switch active fwd-asic resource tcam utilization
Команда зависит от модели и версии IOS XE. На других платформах используются собственные средства диагностики.
Также стоит проверить системные сообщения об ошибках программирования ACL в аппаратную таблицу.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Как узнать, что изменилось в сети перед аварией
В 14:30 перестал работать один из VLAN. Интерфейсы UP, оборудование доступно, а в логах нет очевидных ошибок.
Чтобы не искать такие изменения вручную, используют Configuration Drift Detection.
⏺ Сохраняем историю конфигураций
Для этого подходит Oxidized - инструмент, который регулярно подключается к сетевому оборудованию, забирает конфигурации и сохраняет их версии, например в Git.
Если на коммутаторе изменили allowed VLAN, в истории появится разница:
Сразу видно, что VLAN 30 исчез из разрешённого списка.
⏺ Проверяем, когда произошло изменение
На Cisco IOS/IOS XE при заранее включённом архивировании конфигураций можно использовать:
Команда помогает увидеть зарегистрированные изменения и, при соответствующей настройке, пользователя, который их выполнил.
⏺ Сопоставляем события
Теперь сравниваем время изменения конфигурации с syslog, SNMP traps и событиями мониторинга.
Например, в 14:27 изменили trunk, а в 14:30 мониторинг зафиксировал недоступность устройств VLAN 30.
Это уже конкретная гипотеза, которую можно проверить, а не случайный поиск неисправности.
⚡️ Configuration drift - это отклонение текущей конфигурации от сохранённой или эталонной. Если хранить историю изменений и сопоставлять её с событиями сети, расследование аварий становится значительно быстрее.
N.A.
В 14:30 перестал работать один из VLAN. Интерфейсы UP, оборудование доступно, а в логах нет очевидных ошибок.
Через полчаса выясняется, что незадолго до сбоя кто-то изменил конфигурацию trunk-порта.
Чтобы не искать такие изменения вручную, используют Configuration Drift Detection.
Для этого подходит Oxidized - инструмент, который регулярно подключается к сетевому оборудованию, забирает конфигурации и сохраняет их версии, например в Git.
Если на коммутаторе изменили allowed VLAN, в истории появится разница:
- switchport trunk allowed vlan 10,20,30
+ switchport trunk allowed vlan 10,20
Сразу видно, что VLAN 30 исчез из разрешённого списка.
На Cisco IOS/IOS XE при заранее включённом архивировании конфигураций можно использовать:
show archive log config all
Команда помогает увидеть зарегистрированные изменения и, при соответствующей настройке, пользователя, который их выполнил.
Теперь сравниваем время изменения конфигурации с syslog, SNMP traps и событиями мониторинга.
Например, в 14:27 изменили trunk, а в 14:30 мониторинг зафиксировал недоступность устройств VLAN 30.
Это уже конкретная гипотеза, которую можно проверить, а не случайный поиск неисправности.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
DNS over HTTPS vs DNS over TLS: что меняется для корпоративной сети
Раньше администратор мог анализировать DNS-запросы сотрудников на UDP/53, блокировать нежелательные домены и выявлять подозрительную активность.
⏺ DNS over TLS (DoT)
DNS-запросы передаются через отдельное TLS-соединение, обычно на TCP-порту 853.
Это удобно для сетевого контроля: администратор может обнаружить или ограничить такой трафик по порту. Но содержимое запросов без расшифровки уже не видно.
⏺ DNS over HTTPS (DoH)
Здесь DNS-запросы передаются внутри HTTPS, обычно через порт 443.
Для сетевого оборудования такой трафик может выглядеть как обычное HTTPS-соединение. Простая блокировка UDP/53 или TCP/853 уже не гарантирует, что устройства используют корпоративный DNS.
Например, браузер может обращаться к внешнему DoH-резолверу, обходя локальную DNS-фильтрацию.
⏺ Как контролировать DNS в корпоративной сети?
Обычно используют несколько подходов:
• Централизованно задают разрешённые DNS-резолверы через политики устройств и браузеров.
• Ограничивают обращения к неразрешённым DNS-сервисам.
• Анализируют DNS-логи корпоративного резолвера и контролируют настройки клиентов.
Проверить доступность конкретного DoH-сервера можно через:
Но такой запрос проверяет HTTPS-доступность endpoint, а не выполнение DNS-запроса через DoH.
⚡️ DoT проще идентифицировать по отдельному порту, а DoH сложнее отличить от обычного HTTPS. Поэтому корпоративная DNS-безопасность всё больше зависит от управления конечными устройствами, а не только от правил на межсетевом экране.
N.A.
Раньше администратор мог анализировать DNS-запросы сотрудников на UDP/53, блокировать нежелательные домены и выявлять подозрительную активность.
Но с появлением шифрованного DNS привычная схема перестала быть такой надёжной.
DNS-запросы передаются через отдельное TLS-соединение, обычно на TCP-порту 853.
Это удобно для сетевого контроля: администратор может обнаружить или ограничить такой трафик по порту. Но содержимое запросов без расшифровки уже не видно.
Здесь DNS-запросы передаются внутри HTTPS, обычно через порт 443.
Для сетевого оборудования такой трафик может выглядеть как обычное HTTPS-соединение. Простая блокировка UDP/53 или TCP/853 уже не гарантирует, что устройства используют корпоративный DNS.
Например, браузер может обращаться к внешнему DoH-резолверу, обходя локальную DNS-фильтрацию.
Обычно используют несколько подходов:
• Централизованно задают разрешённые DNS-резолверы через политики устройств и браузеров.
• Ограничивают обращения к неразрешённым DNS-сервисам.
• Анализируют DNS-логи корпоративного резолвера и контролируют настройки клиентов.
Проверить доступность конкретного DoH-сервера можно через:
curl -I https://dns.google/dns-query
Но такой запрос проверяет HTTPS-доступность endpoint, а не выполнение DNS-запроса через DoH.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Incast: когда сотни серверов перегружают один порт
В датацентре может возникнуть странная ситуация: сеть почти не загружена, но распределённое приложение периодически сталкивается с резкими задержками.
⏺ Как возникает Incast?
Допустим, приложение запрашивает данные сразу у 100 серверов. Каждый отправляет ответ размером 256 КБ.
В сумме это 25 МБ данных, которые почти одновременно направляются к одному получателю.
Даже если каждый сервер подключён через 10 или 25 Гбит/с, выходной порт коммутатора в сторону получателя имеет ограниченную пропускную способность.
Входящий поток на короткое время превышает возможности выходного порта, и очередь начинает быстро заполняться.
⏺ Почему это опасно?
Когда буфер переполняется, коммутатор отбрасывает пакеты. Если потери затрагивают сразу несколько TCP-соединений, часть отправителей вынуждена повторно передавать данные.
Особенно неприятно, когда приложение ждёт ответы от всех серверов: задержка одного соединения тормозит всю операцию.
⏺ Как с этим бороться?
В датацентрах используют ECN, чтобы сигнализировать о перегрузке до переполнения буферов, а также подходящие алгоритмы управления перегрузкой.
На уровне приложения помогает ограничение числа одновременных ответов или распределение их во времени.
N.A.
В датацентре может возникнуть странная ситуация: сеть почти не загружена, но распределённое приложение периодически сталкивается с резкими задержками.
Причина может быть в TCP Incast — эффекте, когда множество серверов одновременно отправляют данные одному получателю.
Допустим, приложение запрашивает данные сразу у 100 серверов. Каждый отправляет ответ размером 256 КБ.
В сумме это 25 МБ данных, которые почти одновременно направляются к одному получателю.
Даже если каждый сервер подключён через 10 или 25 Гбит/с, выходной порт коммутатора в сторону получателя имеет ограниченную пропускную способность.
Входящий поток на короткое время превышает возможности выходного порта, и очередь начинает быстро заполняться.
Когда буфер переполняется, коммутатор отбрасывает пакеты. Если потери затрагивают сразу несколько TCP-соединений, часть отправителей вынуждена повторно передавать данные.
В некоторых случаях восстановление требует ожидания RTO, что резко увеличивает время выполнения всего запроса.
Особенно неприятно, когда приложение ждёт ответы от всех серверов: задержка одного соединения тормозит всю операцию.
В датацентрах используют ECN, чтобы сигнализировать о перегрузке до переполнения буферов, а также подходящие алгоритмы управления перегрузкой.
На уровне приложения помогает ограничение числа одновременных ответов или распределение их во времени.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
️️️️️️️️️️️️👀 Сеть можно видеть по таблице маршрутизации. А можно понимать, что происходит внутри неё.
19 ноября на открытом уроке разберём LSDB и научимся вручную строить карту сети по данным маршрутизаторов.
Поговорим о:
✅ LSA Type 1–5;
✅ связи Router ID, Link-State ID и IP-адресов;
✅ на практике восстановим топологию по реальному дампу.
Это особенно полезно сетевым инженерам и архитекторам, которые работают со сложными инфраструктурами и хотят глубже понимать OSPF, диагностировать проблемы и проверять работу автоматизированных инструментов.
Урок проходит в преддверии старта курса «Дизайн сетей ЦОД». Все участники получат скидку на обучение.
▪️ 19 ноября в 20:00 МСК.
Принять участие: https://otus.pw/U4JK/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
19 ноября на открытом уроке разберём LSDB и научимся вручную строить карту сети по данным маршрутизаторов.
Поговорим о:
✅ LSA Type 1–5;
✅ связи Router ID, Link-State ID и IP-адресов;
✅ на практике восстановим топологию по реальному дампу.
Это особенно полезно сетевым инженерам и архитекторам, которые работают со сложными инфраструктурами и хотят глубже понимать OSPF, диагностировать проблемы и проверять работу автоматизированных инструментов.
Урок проходит в преддверии старта курса «Дизайн сетей ЦОД». Все участники получат скидку на обучение.
▪️ 19 ноября в 20:00 МСК.
Принять участие: https://otus.pw/U4JK/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
PrivateLink vs VPC Peering: как подключиться к сервису, не объединяя сети
Представим, что две компании используют AWS. Одной нужен доступ к API другой, но открывать сетевую связность между их инфраструктурами необязательно.
Для такой задачи есть два разных подхода: VPC Peering и AWS PrivateLink.
⏺ VPC Peering - соединяем сети
Peering позволяет двум VPC обмениваться трафиком по приватным IP-адресам.
Но есть ограничение: Peering не поддерживает транзитную маршрутизацию. Если VPC A соединена с B, а B - с C, это не означает, что A сможет обращаться к C через B.
⏺ PrivateLink - предоставляем конкретный сервис
Здесь подход другой. Провайдер публикует сервис через endpoint service, обычно с Network Load Balancer, а клиент создаёт Interface VPC Endpoint в своей VPC.
Клиент получает приватные IP-адреса endpoint в собственных подсетях и обращается к сервису через них.
При этом не нужно добавлять маршруты до всей сети провайдера. Более того, PrivateLink позволяет работать даже с пересекающимися CIDR-диапазонами.
⏺ Когда что использовать?
VPC Peering подходит, когда нужна IP-связность между ресурсами двух VPC.
PrivateLink удобнее, когда требуется предоставить доступ к определённому сервису, не раскрывая остальную сетевую инфраструктуру.
N.A.
Представим, что две компании используют AWS. Одной нужен доступ к API другой, но открывать сетевую связность между их инфраструктурами необязательно.
Для такой задачи есть два разных подхода: VPC Peering и AWS PrivateLink.
Peering позволяет двум VPC обмениваться трафиком по приватным IP-адресам.
Для этого настраивают маршруты, security groups и другие правила доступа. При этом CIDR-диапазоны VPC не должны пересекаться.
Но есть ограничение: Peering не поддерживает транзитную маршрутизацию. Если VPC A соединена с B, а B - с C, это не означает, что A сможет обращаться к C через B.
Здесь подход другой. Провайдер публикует сервис через endpoint service, обычно с Network Load Balancer, а клиент создаёт Interface VPC Endpoint в своей VPC.
Клиент получает приватные IP-адреса endpoint в собственных подсетях и обращается к сервису через них.
При этом не нужно добавлять маршруты до всей сети провайдера. Более того, PrivateLink позволяет работать даже с пересекающимися CIDR-диапазонами.
VPC Peering подходит, когда нужна IP-связность между ресурсами двух VPC.
PrivateLink удобнее, когда требуется предоставить доступ к определённому сервису, не раскрывая остальную сетевую инфраструктуру.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
ASPA: как проверить BGP-маршрут, даже если RPKI считает его Valid
RPKI ROA позволяет проверить, имеет ли автономная система право анонсировать определённый IP-префикс. Но есть нюанс: корректный origin AS ещё не означает, что весь AS_PATH легитимен.
⏺ Что меняет ASPA?
Autonomous System Provider Authorization расширяет возможности RPKI.
Владелец AS публикует подписанный объект ASPA, где перечисляет автономные системы, которые являются его авторизованными провайдерами.
Например, AS65010 указывает, что её провайдеры - AS65020 и AS65030.
Теперь маршрутизатор с поддержкой ASPA Path Verification может использовать эти сведения для проверки отношений между AS в полученном AS_PATH.
⏺ Как это помогает?
Допустим, маршрут проходит через последовательность автономных систем, которая противоречит опубликованным ASPA-объектам.
Но ASPA не подтверждает каждый переход между AS и не гарантирует подлинность всего пути. Механизм прежде всего помогает выявлять нарушения отношений customer-provider, характерные для некоторых видов route leak.
⏺ Что с внедрением?
ASPA требует поддержки со стороны RPKI-инфраструктуры, валидаторов и маршрутизаторов. Поэтому наличие ROA само по себе ещё не означает, что сеть проверяет AS_PATH через ASPA.
N.A.
RPKI ROA позволяет проверить, имеет ли автономная система право анонсировать определённый IP-префикс. Но есть нюанс: корректный origin AS ещё не означает, что весь AS_PATH легитимен.
Злоумышленник может сохранить правильную исходную AS, но добавить в маршрут поддельные промежуточные AS.
Autonomous System Provider Authorization расширяет возможности RPKI.
Владелец AS публикует подписанный объект ASPA, где перечисляет автономные системы, которые являются его авторизованными провайдерами.
Например, AS65010 указывает, что её провайдеры - AS65020 и AS65030.
Теперь маршрутизатор с поддержкой ASPA Path Verification может использовать эти сведения для проверки отношений между AS в полученном AS_PATH.
Допустим, маршрут проходит через последовательность автономных систем, которая противоречит опубликованным ASPA-объектам.
В таком случае проверка может определить путь как Invalid, даже если происхождение префикса успешно прошло ROA Validation.
Но ASPA не подтверждает каждый переход между AS и не гарантирует подлинность всего пути. Механизм прежде всего помогает выявлять нарушения отношений customer-provider, характерные для некоторых видов route leak.
ASPA требует поддержки со стороны RPKI-инфраструктуры, валидаторов и маршрутизаторов. Поэтому наличие ROA само по себе ещё не означает, что сеть проверяет AS_PATH через ASPA.
N.A.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2