+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Мультипуть и балансировка нагрузки в BGP

Мультипуть и балансировка нагрузки в BGP, RouterOS

aaudhachhabria

Guest

14.08.2015 07:09:00

Добрый день, пользователи! Я – интернет-провайдер в Индии. Хотя я не новенький в работе с Mikrotik, несмотря на множество экспериментов и исследований, мне не удалось найти решение. Сейчас у меня есть только один WAN-канал от ISP1, и я планирую подключить еще один от ISP2.

Основной маршрутизатор: CCR1016-12G
Граничные роутеры: все RB1100AHx2
Версия RouterOS на всех роутерах: 6.30

Чтобы представить спецификации, вот они:
ether1 = WAN1 (ISP1)
ether2 = WAN2 (ISP2)
ether3 = LAN1
ether4 = LAN2
ether5 = LAN3
ether6 = LAN4 … ether10 = LAN10

Всего у меня 10 публичных пулов IPv4 с маской /24, выделенных на мой AS номер, и я держу BGP-сессию с ISP1. Второй WAN-канал от ISP2 также будет на BGP-сессии с такой же пропускной способностью, как у ISP1. Каждый LAN-порт подключен к одному или нескольким граничным роутерам, которые распределяют подключение конечным пользователям. Каждый граничный роутер имеет публичный IP для маршрутизации и управления. Клиенты без публичных IP маскируются на граничных роутерах.

Я хочу сделать балансировку нагрузки по соединениям между двумя WAN-каналами.
WAN1 IP = 125.1.1.2/30
WAN2 IP = 122.1.1.2/30

Публичные IP-пулы, выделенные моему AS:
14.1.0.0/23
103.1.0.0/22
45.1.0.0/22

Я облазил весь интернет в поисках решений. Все найденные варианты предполагают, что у меня только один LAN-интерфейс. Вот тут я и запутался, ведь у меня больше одного LAN-интерфейса с публичными IP, которые распределяются по граничным роутерам и клиентам по мере необходимости.

Прошу команду поддержки Mikrotik и пользователей форума помочь мне с этим решением.

ronniee

Guest

09.01.2018 07:37:00

Привет! Такая же проблема с BGP, подскажи, правильно ли я всё делаю. У меня 2 BGP-соединения с двумя провайдерами на CCR1036: ISP1 — 300 Мбит/с, он присылает 816 префиксов, ISP2 — 400 Мбит/с, присылает 88 префиксов с гарантированной скоростью. Как мне сделать хотя бы какую-то балансировку трафика, если одно из соединений загружено на 99%? Я настроил фильтры маршрутов, чтобы отрезать часть префиксов, но не понимаю, хорошее ли это решение. Также я поставил distance 21 для дефолтного маршрута ISP1, чтобы дефолтный маршрут ISP2 использовался больше. Сейчас 100% трафика идет через ISP1 (300 Мбит), а через ISP2 (400 Мбит) — только 25%. Что посоветуешь? Я не хочу улучшать ISP1, ведь ISP2 загружен меньше чем на 50%. Думаю, такая проблема знакома многим пользователям BGP, дайте, пожалуйста, совет. Спасибо, ronn.

Vooray Guest	#3 0 09.01.2018 09:58:00 Повышайте локальный приоритет для префиксов, которые вы получаете от ISP2.

ronniee

Guest

09.01.2018 11:20:00

Спасибо за ответ, извиняюсь, но у меня нет опыта настройки BGP. Я сделал фильтр с правилом accept и BGP Local Pref = 200 и применил его к пиру ISP2 (менее используемому) в in-filter. Теперь префиксы этого BGP-пира имеют значение local pref 200. Но я не вижу резких изменений в трафике, возможно, вечером посмотрю графики. Если трафик всё ещё не пойдёт на ISP2, нужно ли мне отрезать больше префиксов от ISP1? Спасибо.

StubArea51

Guest

09.01.2018 15:28:00

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

ZeroByte

Guest

09.01.2018 15:33:00

Прежде всего — о чём мы вообще говорим: об исходящем трафике или входящем? Local_Pref (и другие похожие метрики) настраивают ваше ПРЕДПОЧТЕНИЕ для ИСХОДЯЩЕГО трафика, но только по тем префиксам, которые вы получаете. Если у вас в руках всего пара десятков или сотен префиксов, то балансировка нагрузки практически отсутствует, ведь глобальная таблица маршрутизации насчитывает около 660 тысяч маршрутов. Значительная часть вашего исходящего трафика, соответственно, уходит по умолчанию через префикс шлюза.

Входящая маршрутизация не настолько тонкая, как многие здесь бы хотели. Для управления входящим трафиком есть несколько способов:

- Объявление более специфичных префиксов определённым провайдерам (самый эффективный метод);
- BGP Communities — если у ваших провайдеров есть поддержка сообществ, можно посмотреть, какие политики они предлагают, и использовать их;
- AS-Prepending ваших анонсов (удлинение AS-PATH обычно заставляет трафик выбирать другой маршрут).

Но помните: так же, как вы можете ставить local_pref, weight и прочие параметры для управления исходящим трафиком, другие сети тоже могут делать то же самое. Если их политики приводят к тому, что входящий трафик идёт не так, как вам хотелось бы, то, увы, вам это может не понравиться.

ronniee

Guest

09.01.2018 20:41:00

Спасибо за ответы. Да, моя проблема связана с входящим трафиком — мои клиенты скачивают, и они используют 100% пропускной способности BGP-пира ISP1.

BGP-пиринги:
ISP1 — 300 Мбит/с — присылает 816 префиксов = маршрут по умолчанию + один community xxx:100
ISP2 — 400 Мбит/с — присылает 88 префиксов = маршрут по умолчанию + 88 префиксов без community

Загрузка на загрузку с ISP1 — 95%
Загрузка на загрузку с ISP2 — 25%

Сейчас маршрут по умолчанию идёт с ISP2, с более высоким локальным приоритетом, загрузка (upload) идёт через ISP2, но скачивание (download) происходит через ISP1. Можно ли это изменить, если сделать фильтр, чтобы отбросить половину префиксов от ISP1?

ZeroByte

Guest

09.01.2018 21:05:00

Если вы сделаете так, и ISP2 выйдет из строя, то любой IP из тех префиксов, которые не объявлены ISP1, останется без подключения к Интернету. Допустим, у вас есть блок IP из /20, все подряд, как один блок /20, например 100.64.8.0/20. Вы можете объявить 100.64.8.0/20 обоим провайдерам, а затем отдельные субпрефиксы (например, 100.64.10.0/23), для которых хотите, чтобы маршрутизация шла через конкретного провайдера, объявлять только этому провайдеру. Если эта ссылка откажет, то основной префикс /20 будет работать как резервный маршрут для всех IP внутри субпрефикса.

Итак, в этих примерах, если вы хотите, чтобы 100.64.10.0/23 шёл через ISP2, вы объявляете этот префикс только ISP2, но при этом 100.64.8.0/20 объявляете обоим провайдерам. Если ISP2 выйдет из строя, то 100.64.10.0/23 останется доступен, так как это субпрефикс 100.64.8.0/20, объявленный через ISP1. Когда ISP2 снова появится в сети, хосты из этого /23 снова пойдут через ISP2 для исходящего трафика.

Однако я бы сказал, что при работе с BGP нужно научиться мыслить иначе. Если у вас есть два канала, скорее всего, их хочется, чтобы они были одинакового размера, и чтобы суммарный трафик не превышал пропускную способность ни одного из них. Если это происходит, то при сбое вы рискуете получить перегрузку и медленный Интернет.

ronniee Guest	#9 0 10.01.2018 08:26:00 Нет, я имею в виду префиксы маршрутов, которые получаю от ISP1, а не префиксы моих собственных рекламируемых сетей. У меня есть префикс /22 и два префикса /24, которые я рекламирую обоим провайдерам.

ZeroByte Guest	#10 0 10.01.2018 14:37:00 Это повлияет только на выбор пути для исходящего трафика. На самом деле, правильнее всего для префиксов, полученных от вышестоящих операторов, задавать веса с помощью метрик, обычно local_preference.

StubArea51

Guest

#11

10.01.2018 14:43:00

Ты проверял у своих провайдеров, какие BGP-сообщества они предлагают? Я раньше работал с Reliance и TATA в Индии, и, насколько я знаю, у них обоих есть BGP-сообщества для управления трафиком. Также можно разделить анонсы /22 и /24 и рекламировать более специфичные префиксы через канал с большей пропускной способностью, но это обычно последний вариант, когда от upstream ISP нет поддержки BGP-сообществ.

airbanduk

Guest

#12

15.01.2018 21:51:00

Вы можете попробовать AS path prepending для ISP1. Это должно заставить больше ваших префиксов предпочитать маршрут через вас по сравнению с ISP2, так как вы будете видны ближе по числу AS-хопов. Если только вы не подключены к одному и тому же провайдеру по обоим каналам, настройка сообществ имеет ограниченный смысл, разве что вы договоритесь с обоими провайдерами использовать сообщества друг друга для управления трафиком или что они будут передавать ваши сообщества друг другу (сообщества могут быть удалены и переписаны).

shaoranrch Guest	#13 0 16.01.2018 00:10:00 Сообщества IParchitechs работают практически во всех сценариях, которые позволяют избирательно транслировать маршруты соседних провайдеров на основе разных факторов, таких как: геолокация их апстримов (обычно по континентальному признаку — APAC, Америка, Европа и т.д.); тип пирового соединения (клиент, платный транзит, IX и т.д.); геолокация самого пира (IX SF, IX LA, IX DE и так далее). Некоторые провайдеры также позволяют управлять маршрутами к определённым пирами, делая такие вещи, как: добавлять As-path prepend в 5 раз к европейским пирам, но не к APAC, что повышает вероятность использования резервной линии европейскими пирами; транслировать маршруты во все места, кроме APAC, чтобы при высокой нагрузке на входящий трафик из APAC использовалась резервная линия. И, конечно, существуют сообщества, которые позволяют снизить приоритет ваших транслируемых маршрутов. К сожалению, не все провайдеры обладают этим функционалом (насколько мне известно, большинство его не предлагают). Возвращаясь к теме, главная проблема — недостаток знаний о маршрутизации на уровне интернета. Мы могли бы дать помощь и советы, но, по моему честному мнению (а также многих с подобными вопросами), лучший выход — либо нанять специалиста, который шаг за шагом проведёт вас, либо самому изучать, как работает BGP и маршрутизация в интернете (что я и советую). Это поможет вам легче понять все отличные рекомендации, приведённые здесь. Запускать WISP (беспроводного провайдера) с небольшим NAT — одно, а развиваться с BGP — совсем другое. Логика совсем иная, и подход к решению проблем тоже меняется.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры