![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В продолжение темы.
Умение протоколов компрессии/шифрования трафика автоматически восстанавливаться после потерь или переупорядочивания пакетов в сети это, конечно, хорошо. Но если с потерями почти ничего сделать нельзя (разве что передавать данные с избыточностью/перепосылками на транспортном уровне :-), то с небольшим переупорядочиванием можно и побороться.
Представим себе, что недалеко от точки приёма такого трафика возникают неподконтрольные нам перестановки пакетов - то есть, все пакеты доставляются без потерь, но очень часто соседние пакеты приходят переставленными местами (с таким я столкнулся на практике при использовании арендованной виртуалки в LeaseWeb). В таких условиях MPPE вынужден непрерывно выполнять re-keying и скорость на туннеле, проброшенном через такую сеть, падает ниже плинтуса. И даже если использовать PPP-туннель без шифрования/компрессии, мы получаем огромный процент потерь внутри туннеля, потому что GRE вынужден дропать "опоздавшие" фреймы PPP, так как не имеет права доставлять их с нарушением порядка (дропать - имеет право).
Но если обучить GRE восстанавливать порядок пакетов, то PPP/MPPE даже и не узнают, что были проблемы с доставкой (пока не начнутся настоящие потери). Для ноды ng_pptpgre(4), которую использует mpd при создании PPtP-туннелей, сделал патч. Update 07.09.2016: обновление патча для 11.0
Патч даёт возможность управлять глубиной очереди ожидания переупорядоченных пакетов через sysctl net.graph.pptpgre.reorder_max (ноль отключает восстановление порядка) и таймаутом ожидания "опоздавших" пакетов (в милисекундах) через net.graph.pptpgre.reorder_timeout. Тесты показали хороший результат при reorder_max=16 и таймаутом в 1ms, когда точка переупорядочивания близко к нам и в 50ms, если далеко. Изменять значения этих параметров можно "на лету", без переустановки туннелей. В итоге CCP даже не дергается, если низлежащий GRE успешно восстанавливает порядок.
Патч предварительный в том смысле, что параметры глобальные для всех PPtP-туннелей в системе. Можно улучшить его, сделав эти настройки локальными для каждого туннеля, но, к сожалению, этого нельзя сделать без того, чтобы не сломать ABI ноды ng_pptpgre, после чего старые сборки mpd перестанут вообще работать с патченной нодой. С текущим патчем пересобирать ничего не нужно, кроме ng_pptpgre.ko (или ядра, если нода статически слинкована с ним).
В продолжение темы.
Итак, FreeBSD это конструктор, части которого требуют ручной доводки напильником, но результат получается хороший (см. ссылку выше). Тем, кого с души воротит от таких конструкторов, можно дальше не читать, а отправляться искать дистрибьютора Cisco, например.
( 1. Стабильность )
Первый стресс-тест mpd-5.5/PPPoE под FreeBSD 8.2-STABLE/amd64 на реальной нагрузке.
Система настроена решать одну задачу - терминировать пользовательские сессии PPPoE с AAA через RADIUS, с шейпингом трафика и анонсированием абонентских IP-адресов в ядро сети через OSPF. На машине нет NAT (адреса реальные), нет netflow (собирается на другом роутере), нет BGP.
В час наибольшей нагрузки отмечено:
- 1812 сессий PPPoE;
- средняя нагрузка по ядрам процессора 2% user time / 88% (system time + interrupts) (CPU0: 2+90, CPU1: 2+89, CPU2: 2+90, CPU3: 3+86);
- 1184.9Mbit/s трафика в сторону клиентов и 830.9Mbit/s от них (итого 2015.8Mbit/s);
- 549.8Kpps: на интерфейсе lagg0 136.2Kpps in, 120.3Kpps out и на lagg1 139.0Kpps in, 154.3Kpps out;
- до 102K прерываний в секунду (device polling не использовался);
- использовано памяти:
Mem: 101M Active, 41M Inact, 486M Wired, 1644K Cache, 138M Buf, 3314M Free - в среднем на одну PPPoE-сессию приходилось 654.1Kbit/s трафика на вход и 434.2Kbit/s на выход.
То есть, на каждый процент загрузки CPU пришлось по 20 сессий.
Система продолжала быть отзывчивой на ssh так же, как и без нагрузки.
Железо:
- SuperMicro SuperServer 5016T-MTFB с двумя гигабитными интегрированными сетевыми Intel 82574L (драйвер em) и платой IPMI 2.0 с выделенным портом 100M;
- дополнительная двухпортовая сетевая карта Intel 82576 (драйвер igb);
- процессор Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (четыре ядра, гипертрединг отключен в BIOS Setup, 4M Cache, 4.80 GT/s Intel® QPI);
- 4GB памяти ECC;
- в качестве загрузочного носителя SSD 64GB (KINGSTON SNV425S264GB), при загрузке монтируется только для чтения (система собрана в виде NanoBSD, без свопа).
Общая стоимость железа около 60 тысяч рублей (всё железо новое).
Сетевые em0 и em1 объединены в lagg0, на нём есть IP-адрес и нет vlan-ов, это аплинк. Сетевые igb0 и igb1 объединены в lagg1, на котором нет IP, зато создано 596 vlan-ов, каждый из которых несет PPPoE-трафик пользователей. Шейпинг выполнен через ipfw/dummynet - на каждого подключенного пользователя dummynet динамически (pipe ... mask) создает по две индивидуальных трубы, на вход и на выход, в соответствии с тарифом пользователя. Весь шейпинг делается двумя правилами ipfw, список правил не растет при росте количества абонентов:pipe tablearg ip from any to table(11) in
pipe tablearg ip from table(12) to any in
Для сравнения: бывшая в употреблении Cisco 7201 на usedcisco.ru стоит $11400 $10900 (примерно в 5.5 раз дороже), срок поставки 3 недели. На этой же задаче и на этих же пользователях обрабатывает около 10 сессий на процент загрузки CPU (то есть, вдвое меньше), причем при высоких загрузках вносит большие задержки и сама с трудом управляется по telnet. Поэтому приходится ограничивать количество сессий на ней (не более 700), чтобы держать нагрузку в пределах 75%. Стоит отметить, что при маленьких нагрузках (ближе к нулю) количество сессий на процент загрузки CPU у обоих систем растет в разы.
Зато Cisco - продукт, и умеет гораздо больше, например, ISG. А FreeBSD - конструктор, и требует существенного тюнинга. Про тюнинг как-нибудь в другой раз.
Update: для проверки провёл второй тест на FreeBSD с целью удержать загрузку в пределах 75%. При прочих равных условиях для этого оказалось нужным ограничить количество сессий PPPoE в 1500. Подтверждается прямая пропорциональность: 1800/0.9=1500/0.75=2000, что даёт нам прогноз стопроцентной загрузки при 2000 сессиях.
На деле у меня пока достаточно железок, чтобы держать нагрузку в пике на уровне 35% :-)
