Полные таблицы BGP с двумя вышестоящими провайдерами, использующими CHR — вопрос производительности

Привет, ребята! Мы работали с несколькими CHR в качестве eBGP роутеров, и они показывают хорошую производительность. Также рекомендуем установить гипервизор, потому что так можно добавить любой нужный CHR. Но пока мы ждём RouterOS 7, который, возможно, сможет работать с BGP на многопроцессорном уровне, есть ещё один вариант — отличные роутеры на базе серверов ESXi с процессором i7 на 4,2 ГГц на ядро. Они могут загрузить полную маршрутизирующую таблицу (600 тысяч маршрутов) всего за несколько секунд, тогда как на другом роутере это может занять минуты, и при этом всё может «полететь».

Что ж, я новичок в запуске BGP на CHR, но, похоже, всё работает довольно неплохо. Сейчас я запускаю BGP с полными таблицами на своей системе CHR 64-бит, которая представляет собой виртуальную машину на VmWare ESXi 6.5.0. Мой физический сервер — SuperMicro с 128 ГБ оперативки и двумя реальными процессорами Intel Xeon 3 ГГц на 10 ядер каждый (гипертрейдинг отключён) — всего 20 ядер — и сетевыми картами 10-гигабит.

Для моего CHR BGP (64-битного) роутера я выделил 6 ГБ оперативной памяти (это больше, чем нужно), 8 процессорных ядер и 10-гигабитные ethernet-интерфейсы vmnic3.

У моего CHR лицензия уровня P unlimited. Я бы не советовал запускать BGP на 32-битном роутере x86 с ROS. 32-битный ROS под x86 не поддерживает паравиртуальные vmnic3 ethernet-интерфейсы и (по моему опыту) на 32-битном x86 при большой нагрузке происходят сотни зависаний. К тому же, 32-битный ROS под x86 ограничен по максимальному объёму памяти, тогда как 64-битный CHR может использовать более 2 ГБ оперативки. Много оперативной памяти крайне важно при запуске BGP.

К слову, при загрузке мой CHR загружает таблицы BGP (через 10-гигабитные интерфейсы) за секунды, а не минуты.

Хотя я и новичок в BGP на CHR 64-бит, ставлю этому определённо палец вверх.

ПРИМЕЧАНИЕ: В данный момент BGP в Mikrotik ROS работает однопоточно (то есть BGP задействует только одно из доступных ядер процессора). ((( По крайней мере, так я думаю и читал об этом ))) — поэтому, думаю, для BGP нужен очень быстрый процессор с мощным ядром.

Примечание: получение полной таблицы BGP на Mikrotik CCR1016-12S-1S+ с 1-гигабитным интерфейсом занимает до минуты (tilegx 1.2 ГГц, 16 ядер).

Примечание: получение полной таблицы BGP на Mikrotik CHR с 10-гигабитными интерфейсами vmxnet занимает всего несколько секунд (Intel Xeon 3 ГГц, 8 ядер, кеш процессора 25 МБ).

С уважением, North Idaho Tom Jones

Привет! Спасибо, что поделился этим! В своих тестах с Proxmox ты получил менее 80 000 PPS, а с ESXi и Hyper-V — свыше 500 000 PPS. У Proxmox проблемы с обработкой PPS?

Интересные вещи: https://blog.kroy.io/2019/08/23/battle-of-the-virtual-routers/ Возможно, более старая версия chr-Kernel немного замедляет работу. Давайте как можно больше мощности процессора для vmware/chr…

У нас есть несколько случаев, когда CHR работают с двумя и более полными интернет-фидами v4/v6. Вот мои наблюдения.

1. Убедитесь, что проблемы с временем сходимости не связаны с невозможностью пропускать трафик. Я видел много случаев, когда оборудование не справлялось с нагрузкой. Передача трафика замедляла работу маршрутизатора сильнее, чем BGP.

2. Время сходимости может быть медленным, даже на CHR. Мы всегда подтягиваем маршрут по умолчанию плюс полные маршруты специально для этого. Так трафик может уходить по маршруту по умолчанию, пока идет сходимость. Лучше, чтобы трафик шел хоть куда-то, чем вообще не шел.

3. Каждый раз, когда я вношу изменения в BGP, я обычно жду 10-15 минут, прежде чем начать беспокоиться. Изменения анонсов обычно происходят в пределах отведенных 3 минут BGP. Но таблица маршрутов сходится обычно гораздо дольше. Зависит от того, что именно вы делаете. Если добавляете нового пира, сходимость обычно быстрая. Если удаляете пира и не ждете, пока таблицы очистятся, это может занять время, потому что процессор загружен удалением маршрутов и одновременно подтягиванием новых. Это возможно, просто нужно учитывать ограничения, пока v7 не будет готов к эксплуатации.

Я тебя понимаю. Я считаю это бизнес-решением. Когда я обсуждаю такие вопросы с клиентами, разговор обычно идет по одному из двух сценариев.

Сценарий 1  
Я: Ваши варианты для повышения производительности BGP — Juniper, Cisco, Whitebox или Arista.  
Они: Круто. А что для этого нужно?  
Я: Подержанный Cisco, который сможет маршрутизировать несколько портов по 10 гигабит, будет стоить около 6000 долларов на вторичном рынке. К этому добавьте smartnet примерно за 1000 долларов в год.  
Они: А остальные?  
Я: Они стоят примерно столько же за нормальный роутер.  
Они: Мне вполне хватает моего маленького роутера за тысячу долларов — и я могу позволить себе держать запасной. Справлюсь с этим.

Сценарий 2  
Они: Отлично. Дайте я чеком оплачу роутер и запасной. Примерно 15 тысяч, вы говорите?  
Я: Да. Вы знакомы с Cisco?  
Они: Нет. Сколько это будет стоить?  
Я: Ставка — 150 долларов в час, и потребуется 5–10 часов на внедрение. Все последующие изменения обсудим отдельно.

Я только что заказал Cisco, так как не смог найти железо, кроме большого сервера Dell, способного пропускать трафик свыше 40 гигабит. Это мне обошлось в 15 тысяч долларов: сам роутер — 6000, а карта на 40 гига — 7000.