route-cache

Базовая функциональность RouterOS
Ответить
Аватара пользователя
Sir_Prikol
Сообщения: 560
Зарегистрирован: 14 апр 2018, 15:21
Откуда: СССР
Контактная информация:

route-cache

Сообщение Sir_Prikol »

Доброго времени суток

Я нашёл затык, который меня тревожил уже около 2-х лет (ни с того ни с сего затыкался CCR1036 и спасал только ребут, ну или очистка conntrack)
Еслиб затыкался только один, я бы просто забил и заменил его (бывает, железо имеет свойство быть с браком или умирать), но затыкались все, в том числе и только что купленные, которые стоят в продакшене. (на x86 и CCR2004 я такой проблемы не наблюдал, хоть и пытался нагрузить их так-же, а может и больше)

Не буду описивать поиск мучений и что было предпринято для исправления данной ситуации, скажу проще, в один момент затыка, я случайно перепутал команду в cli и офигел

Код: Выделить всё

<system@BR01>/ip route cache print
cache-size: 524288
max-cache-size: 524288
<system@BR01>
Вот тут меня и осенило, "а вдруг всё виснет именно из-за того, что переполняется кеш маршрутов?"

Полез читать мануал. Что есть route cache и почему я о ней помню только смутно.

Оказалось, что эту штуковину выпилили ещё в каком-то далёком ядре 3.6, так как толку от этого параметра было мало и на производительность не влияло, а что-же микротики, с их 2.х ядром? Оказывается, ребята "предусмотрели" отключение данного параметра в

Код: Выделить всё

/ip settings
но почитав форумы с мольбами о помощи и полного (ну почти) игнорирования от команды микротиковцев, набрёл на одну фразу, что отключение этого параметра заставляет БЫСТРЕЕ заполнять кеш, но в то-же время БЫСТРЕЕ очищает его.

Так, подумал я,видимо это и есть решение и полез заново на форумы, перелопатил всё что можно, нашёл, что данная проблема, в основном, возникает когда используются любые ppp соединения. Да, типа в какой-то из версий было пофикшено, но на деле проблема осталась актуальной.

Выключить route-cache я не рискнул (экспериментировать на абонентах - то ещё занятие, надо тестить под нагрузкой, а под нагрузкой их слишком много, могут и тапочками закидать), CCR2004 в продакшен на те узлы поставить, я то-же не рискнул, так как сам CCR2004 рассчитан на ROS v.7 но из-за использования BGP, который недопилен в последней (на данные момент) бетке (7.1beta4), CCR2004 становится непригоден, при использовании на критичных узлах. Даже не смотря на то, что CCR2004 способен переварить 4 фуллвью таблицы за полторы-две минуты и не поперхнуться, но там проблема с фильтрами, отдаёт зеркальные комьюнити (на других устройствах отдаёт правильно).

Единственное решение, которое устраивает меня (более-менее) - это выполнение скрипта раз в сутки

Код: Выделить всё

/ip fi connection tracking set enabled=no;
:delay 90;
/ip fi connection tracking set enabled=auto;
(Может есть что лучше, но сие мне неизвестно и да, conntrack отключать нельзя)

Но, иногда, этого не достаточно. И начинается затык заново, и после применения скрипта раз 5, во время затыка, CCR1036 начинает дышать. Правда никогда не известно на какое время. Проще ребутнуть, чем в cli дёргать conntrack, что нетерпеливые и делают, не давая до конца диагностировать проблему.

Саппорт ответил стандартно - route-cache будет выпилен в ROS v.7, но и в последней (на сегодня) бетке (7.1beta4) до сих пор присутствует этот параметр в

Код: Выделить всё

/ip settings
правда выпилен из CLI.

Кстати в x86 и CHR увеличение кеша делается банальным добавлением памяти в железо (или виртуалку), при этом 1GB равен увеличению кеша на 524288 маршрутов (проверено).

Но я не могу понять, почему на том-же tile CCR1036 при 4Gb RAM и arm RB3011 при 2Gb RAM - количество кеша одинаковое (524288), а вот на x86 (и CHR) на 1Gb RAM - приходится 524288, а на 2Gb уже 1048576. Для меня сие осталось тёмным лесом.

Первый симптом начала затыка - это тухнет форвардинг UDP (конкретно DNS перестаёт проскакивать мимо маршрутизатора)

P.S. Ну или если есть у кого опыт отключения route cache - то поделитесь опытом, стоит ли рискнуть или нет. Интересует, в основном, именно продакшен под большой нагрузкой. Ну и теория приветствуется :)

P.P.S Моё имхо, CCR1036, да и вообще вся линейка tile устарела не только морально, но и физически, при развитии сетей в геометрической прогрессии - они тупо не справляются как пограничные железки. Уже нормально на них нельзя рутить и шейпить, надо или менять железо (хотя пока не на что, CCR2004 ждёт ROS v.7) или разделять, на рутинг одну железку, на шейпинг - другую.

P.P.P.S Ну и цена на них неадекватна, 3к зелени за 1072, который заткнётся чуть позже чем 1036, и только в 2 раза (в лучшем случае) веселее работат чем CCR2004 за 700 баксов - думайте сами

Самый последний P.S. :)

Пинать меня не надо, я прекрасно знаю что железо надо разделять на рутинг и шейпинг, но это может себе позволить не каждый и изначально делается всё на одном железе
Дома: CCR2004 (7-ISP(GPON)белый IP)
Ответить