Привет, я немного запутался в этом вопросе. Видел много (ДЕЙСТВИТЕЛЬНО МНОГО) постов про время сходимости BGP, когда полный таблицы маршрутные обновления идут долго. А потом наткнулся на тест от stubarea51 (http://www.stubarea51.net/2015/07/25/mikrotik-ccr1072-1g-8s-review-part-2-bgp-performance/), в котором CCR1072 загружает полную таблицу BGP за 1 минуту 33 секунды, и делается вывод, что это по скорости сравнимо с Cisco ASR 1002. Это кажется довольно быстро... что я упускаю?
Думаю, вы заметите, что многие жалобы на время сходимости BGP чаще всего связаны со скоростью апстрим-пира (хотя обычно это и не признают), ведь CCR1036 и CCR1072 очень быстро обрабатывают один канал при идеальных условиях. Если добавить второй канал, скорость немного падает, но всё равно остаётся хорошей.
Мы ежедневно настраиваем полное BGP-табличное пирингование на MikroTik, и если вы используете стабильную версию RouterOS с необходимыми функциями, то существенной разницы во времени сходимости между роутером Cisco и MikroTik вы не заметите. Вопрос с BGP на одном ядре, который обсуждается уже много лет, на мой взгляд, сильно преувеличен. Конечно, важно стремиться к лучшей производительности, но текущие показатели вполне достойны, пока речь не идёт о большом количестве пир-устройств с полной таблицей.
Проблема с таблицей, где больше миллиона маршрутов, для меня в основном связана со временем поиска, а не с конвергенцией или загрузкой. Вот почему Cisco и другие платформы для меня оказались круче Mikrotik — если я хочу найти текущую активную запись маршрута для 8.8.8.8 (например), на 1036 с всего 40 тысячами маршрутов время поиска просто бесит, не говоря уже о том, если бы там было два полных фида. При этом я уже два года использую 1036 в ядре и, несмотря на некоторые проблемы с блоком питания (по всей видимости, конденсаторы там полное г…но, и переход на твердотельные намного лучше), по производительности они меня не подвели. Самое большое время без перезагрузки у меня было больше года на версии 6.27, пока не сдох блок питания.
Mikrotik BGP имеет утечку памяти… У меня это происходит на ccr1016 и CHR. Когда один-два пира с полной таблицей переподключаются, используемая память растёт на 300-400 Мб, и Mikrotik перестаёт отвечать в Winbox и по SSH, работает только mac-telnet. В этом случае одно ядро загружено на 100%, и возникают случайные проблемы с маршрутизацией и трафиком. При нормальной работе использование памяти — 800-900 Мб с 2 пирами в полном просмотре. При утечке — 1300-1400 Мб с теми же пирами.
Дело в том, что при наличии более миллиона маршрутов в таблице для меня главная проблема — это время поиска, а не скорость сходимости или загрузка. Вот где Cisco и другие платформы меня гораздо больше устраивают по сравнению с Mikrotik — если я хочу найти текущую активную запись маршрута для 8.8.8.8 (например), время поиска на 1036 с всего 40 тысячами маршрутов просто бесит, не говоря уже о двух полноценных каналах в таблице. Если использовать поиск через команду /ip route print where 8.8.8.8 in dst-address, он очень медленный. Обходной вариант — использовать что-то вроде: /ip route print where dst-address in 8.8.8.0/24. Конечно, это не так удобно, но по крайней мере работает. Nick
У меня было несколько полноразмерных таблиц BGP, и время составляло около минуты на RouterOS с x86. Это не очень быстро, но как только пир устанавливается, проблем не возникает месяцами.
НО что если активный маршрут для 8.8.8.8 — это 8.8.8.0/23, тогда твой пример его пропустит. А если есть несколько маршрутов разного размера и с разными локальными приоритетами, то потенциально может быть несколько активных маршрутов, и всё равно придётся разбираться. Мне нужно знать, какой именно активный маршрут сейчас для 8.8.8.8. Но да, я использую твой пример как временное решение, когда спешу.
8.8.0.0/16 может иметь до 100 активных маршрутов. И некоторые из этих активных маршрутов могут пересекаться, например, если у вас есть 8.8.8.0/23 и 8.8.8.0/24, оба будут активными маршрутами. Тогда вам придется самому просматривать этот список и определять, какой маршрут используется для 8.8.8.8, а это влечёт за собой человеческий фактор и возможность ошибки. Как я уже сказал — я ЗНАЮ, как искать сейчас с этими ограничениями, и пользуюсь этим, но всё равно это слабое место в системе Mikrotik, которое нужно исправлять.