BGP - level3 / cogent

Если всего одна таблица с 170k маршрутов может превысить возможности маршрутизации Mikrotik, то где-то в настройках есть серьёзный недочёт. Точно. Я уже написал в поддержку и прислал кучу файлов supout, попросил их посмотреть и, возможно, оптимизировать. У меня хорошее предчувствие, что они разберутся, что не так, и исправят. Я не думаю, что это баг, скорее это просто требует оптимизации – да и к тому же, это тестовый пакет маршрутизации, так что пока что он в бета-версии. У меня полное доверие к ребятам из Mikrotik!

Что касается статуса нашей BGP… У нас есть роутер, обновлённый до версии 2.9.6 с пакетом routing-test, и подключения к Cogent и Level3 по трубам на 100 мегабит. BGP принимает маршруты от обоих провайдеров. Мы начали с полных транзитных маршрутов, и уже через пару минут стало ясно, что это невозможно. Я попросил их отправлять только маршруты клиентов от каждого провайдера. Cogent отправляет около 12 500 маршрутов, а Level3 – около 75 000. Набор маршрутов Cogent маленький, и Mikrotik справляется без проблем – синхронизация происходит примерно за 30 секунд, после чего загрузка процессора падает до простоя. Проблем нет.

Запуск пиринга Level3 приводит к тому, что через 3 минуты всё начинает выходить из-под контроля – сессии BGP начинают обрываться, истекают таймеры удержания и т.д. Процессор загружен на 100% всё время. Если я запускаю `/ip route print count-only` во время синхронизации, то вижу, как счётчик постоянно растёт, и как только он превышает 20 000, роутер как бы умирает. Мы отключили пиринг Cogent, чтобы посмотреть, сможет ли роутер справиться с пирингом только с Level3, но безрезультатно. Единственный способ вернуть роутер под контроль – фильтровать маршруты по мере их поступления. Помню, вначале мы использовали фильтрацию с меткой маршрута, и это работало, вероятно, потому, что не было перекрывающихся маршрутов, из-за которых роутер тратил много времени на принятие решения о том, куда отправлять трафик. Думаю, проблема заключается в том, как RouterOS вводит маршруты в таблицу. Заметил, что когда я отфильтровываю все входящие маршруты, сессия BGP синхронизируется примерно за 5 секунд, и всё готово… Вижу огромный скачок загрузки в 5-10 мегабит при синхронизации. Без фильтра я вижу, как они потихоньку поступают, потому что, похоже, они применяются и обрабатываются по мере поступления каждого маршрута.

Вот наша конфигурация:

`/ routing filter`
`add chain=cogent-a prefix=38.XX.XX.0/24 prefix-length=24 action=accept comment="" disabled=no`
`add chain=cogent-a prefix=38.101.160.XXX prefix-length=32 action=accept comment="" disabled=no`
`add chain=cogent-a prefix=0.0.0.0/0 action=discard comment="" disabled=no`
`add chain=cogent-b prefix=0.0.0.0/0 action=discard comment="" disabled=no`
`add chain=cogent-in set-nexthop=38.XX.XXX.1 comment="" disabled=no`

Это необходимо для настройки пиринга Cogent A & B. 38.101.x.x — это их IP-адрес обратной связи, необходимый для запуска пиринга B.
`add chain=level3-in action=discard comment="" disabled=no`
`add chain=level3-out prefix=38.XX.XX.0/24 prefix-length=24 action=accept comment="" disabled=no`
`add chain=level3-out prefix=0.0.0.0/0 action=discard comment="" disabled=no`

Обратите внимание, что мы `action=discard` для всех входящих правил. Если просто изменить это на `accept` или что-то еще, то роутер зависнет и загрузка процессора будет на 100% в течение нескольких часов.

`/ routing bgp instance`
`set default as=19557 router-id=38.XX.XX.2 redistribute-static=no redistribute-connected=yes redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no name="default" out-filter="" disabled=no`
`add as=19557 router-id=XX.XX.XX.18 redistribute-static=no redistribute-connected=yes redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no name="level3" out-filter="" disabled=no`

Мы настроили 2 экземпляра, потому что могли возникнуть проблемы с использованием одного и того же router-id для обоих пиров. Если установить 0.0.0.0, то он должен сам всё выяснить, но я был осторожен и заставил использовать правильный IP-адрес для каждого пира. Я не хотел создавать сессию пиринга через трубу другого провайдера… и, думаю, это сработало только из-за того, что мы используем ECMP на обратном пути.

`/ routing bgp peer`
`add remote-address=38.XX.XX.1 remote-as=174 multihop=no in-filter="" out-filter=cogent-a keepalive-time=0s hold-time=3m ttl=60 disabled=no`
`add remote-address=38.101.160.XXX remote-as=174 multihop=yes in-filter=cogent-in out-filter=cogent-b keepalive-time=0s hold-time=3m ttl=6 disabled=no`
`add remote-address=63.210.XX.XX remote-as=3356 multihop=no in-filter=level3-in out-filter=level3-out keepalive-time=0s hold-time=3m instance=level3 ttl=60 disabled=no`

У Cogent 2 сессии пиринга, одна для отправки маршрутов и одна для приема маршрутов. У Level3 все в одной сессии пиринга. В общем, думаю, Mikrotik (надеюсь) улучшит процесс введения маршрутов в таблицу, и все будет хорошо. Мы планируем теперь разделить наши пограничные маршруты на 2, по одному на каждое подключение… Надеюсь, нам не придется использовать Crisco или что-то еще, мы действительно верим, что RouterOS сможет справиться с работой. Я изучаю NAPI с картами Intel, надеюсь, это уже является частью ОС, и она используется. Я не узнаю наверняка, пока не настрою dev-среду и не смогу протестировать рейтинги pps.

Thx Sam