BGP-балансировка, резервирование

[timonsterrr]

Всем привет. У меня следующая ситуация.
есть 2 магистральных провайдера, с которыми установлены сессии БГП. В данный момент трафик балансирую между ними вручную, с помощью ната (фейковые сети распихиваю по анонсированным в того или иного провайдера реальным пулам). Данная схема досталась мне в наследство от предыдущих админов и не дает мне спокойно спать.

Я хочу сделать балансировку нагрузки между этими провайдерами и резервирование.
задачи:
1 Использоваться каналы обоих провайдеров должны более менее равномерно
2 Нат будет не статический, а cg на специализированной железке
3 Надо обеспечить отказоустойчивость. При падении провайдера1 чтобы весь трафик начинал ходить через провадера2 и наоборот.

Сейчас часть пулов анонсирована в провайдера1 и другая часть в провайдера2 и в случае падения одного из них связь пропадает у всех абонентов, кто в него натится и анонсится (абоненты с реальными адресами)

Что хочу сделать - анонсировать все имеющиеся реальные пулы обоим провайдерам. Но пулы, через которые ходят в провайдер1 во второй провайдер анонсировать с BGP Prepend повыше, дабы удлинить путь и чтобы в этот путь пакеты шли только при падении провайдера 1. И наоборот пулы, которые ходят через второго провайдера анонсировать первому провайдеру с удлиненным препендом.

http://isp-servis.ru/config_mikrotik.html Вот здесь нашел как это примерно сделать. Подскажите может у кого уже есть опыт решения подобных задач. Ибо чутье подсказывает мне, что моя задумка не совсем универсальна и недостаточно гибкая.

А гибкости нет в следующем, как мне кажется - что делать если в одном из провайдеров сильно ухудшилось качество канала? (потери, ддос и тд) Он по сути поднят....но по факту инет в нем толком не работает у абонентов и наш БГП микрот об этом ничего не знает. Да, существуют скрипты, которые будут проверять состояние канала и при его ухудшении либо его отключать либо менять настройки фильтров бгп или маршрутов и тд. Но хотелось бы как то обойтись без костылей в виде скриптов и дополнительных правил и маршрутов.

[Chupaka]

Да, всё правильно, анонсировать в оба канала, но с препендами.

Нет, без костылей не обойдётесь

[timonsterrr]

Да, всё правильно, анонсировать в оба канала, но с препендами.

Нет, без костылей не обойдётесь

Как быть с исходящим трафиком? надо чтобы и входящий и исходящий ходили через один канал. Удлинять исходящие маршруты? каким образом?

[timonsterrr]

Вот наткнулся на интересную статью.
https://itservice-bg.net/mikrotik-bgp-d ... ree-peers/

Как раз описан мой случай по сути. через BGP_local_pref решается вопрос с выбором предпочитаемого исходящего маршрута.
Итого мой план:
1 - Анонсировать все префиксы в оба провайдера, но с препендами
2 - У префиксов, которые резервируются так же BGP_local_pref понизить, дабы исходящий трафик ходил через основного, не резервного, для этого префикса провайдера.
3 - Придумать скрипт, который будет оценивать качество канала каждого из провайдеров и если есть просадки на протяжении например последних 5 минут - либо совсем его отключать на какое то время, дабы трафик пошел в резервного для префиксов проблемного провайдера...либо делать что то еще...я еще не придумал))

О результатах - отпишусь здесь) на следующей неделе.

[Chupaka]

Для руления исходящим трафиком надо использовать Policy Routing.
Например, так:

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

/ip route add routing-mark=ISP1 gateway=1.1.1.1
/ip route add routing-mark=ISP2 gateway=2.2.2.2
/ip route rule add src-address=192.168.1.0/0 action=lookup table=ISP1
/ip route rule add src-address=192.168.2.0/0 action=lookup table=ISP2

Local Pref - это для того, чтобы исходящий трафик от всех подсетей направлять в лучшие пиры при использовании Full View, например

[timonsterrr]

Для руления исходящим трафиком надо использовать Policy Routing.
Например, так:

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

/ip route add routing-mark=ISP1 gateway=1.1.1.1
/ip route add routing-mark=ISP2 gateway=2.2.2.2
/ip route rule add src-address=192.168.1.0/0 action=lookup table=ISP1
/ip route rule add src-address=192.168.2.0/0 action=lookup table=ISP2

Local Pref - это для того, чтобы исходящий трафик от всех подсетей направлять в лучшие пиры при использовании Full View, например

Так а если исходящий будет руками направлен (что, кстати, у нас сейчас и сделано) от определенных префиксов в определенных ISP то при падении ISP у префикса пропадет исходящий маршрут.
А если я установлю для каждого префикса localpref в зависимости от предпочтений
например сеть 1.1.1.1/24 анонсирована в ISP1 с localpref 100 и штатным препендом и в ISP2 с localpref 50 и препендом = 5. То по сути в штатной ситуации она должна ходить через ISP1 и исходящий и входящий трафик, верно? И если ISP1 падает, то в данном случае пойдет ли исходящий трафик через ISP2?
В данный момент с обоими провайдерами у нас fullview

[timonsterrr]

В общем...подумал я подумал....зачем все эти костыли...и решил сделать проще:
исходящего трафика не так уж и много и по сути не критично через какого провайдера кто будет выходить. Поэтому от всех костылей, связанных с удлинением исходящих маршрутов и тд решено отказаться. Пусть уходят по кратчайшим.
При этом от препенда тоже решил отказаться и сделать по-другому.
все свои префиксы /24 разбить каждый на 4 префикса более мелких с 26 маской. Все префиксы /24 будут анонсированы во всех провайдеров. А вот префиксы /26 будут распределены более менее равномерно по ISP1 и ISP2. В случае падения одного из провайдеров трафик пойдет по укрупненному маршруту /24 т.к. /26 станут недоступны для упавшего провайдера.
Профит - резервирование будет работать, балансировка - ручная, да, но эту задачу я еще буду пытаться решать средствами специализированного ната путем управления пулами и acl (на абонентов с реальными адресами правда тут уж никак не повлиять, только путем перекидывания префиксов по провайдерам, но их у нас не много)

Идею почерпнул отсюда: https://habrahabr.ru/post/184350/

[Chupaka]

Вы только учтите, что анонсы мельче /24 не принимаются Как минимум все магистралы их фильтруют: и так таблица большая, не надо её мусором всяким заполнять.

Чтобы при отваливании одного ISP трафик шёл через другой, делается что-то вроде

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

/ip route add routing-mark=ISP1 gateway=1.1.1.1
/ip route add routing-mark=ISP1 gateway=2.2.2.2 distance=10
/ip route add routing-mark=ISP2 gateway=2.2.2.2
/ip route add routing-mark=ISP2 gateway=1.1.1.1 distance=10

Local Pref вы на исходящих анонсах отправить не можете, только на входящих. Так что просто можно с ним не загоняться

[timonsterrr]

Вы только учтите, что анонсы мельче /24 не принимаются Как минимум все магистралы их фильтруют: и так таблица большая, не надо её мусором всяким заполнять.

Чтобы при отваливании одного ISP трафик шёл через другой, делается что-то вроде

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

/ip route add routing-mark=ISP1 gateway=1.1.1.1
/ip route add routing-mark=ISP1 gateway=2.2.2.2 distance=10
/ip route add routing-mark=ISP2 gateway=2.2.2.2
/ip route add routing-mark=ISP2 gateway=1.1.1.1 distance=10

Local Pref вы на исходящих анонсах отправить не можете, только на входящих. Так что просто можно с ним не загоняться

да, я уже прочел про анонс префиксов менее 24.....не проканает))) поясните про выше приведенный пример. Не совсем понятно

[Chupaka]

Сорри, правильный пример такой:

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

/ip route add routing-mark=ISP1 gateway=1.1.1.1 check-gateway=ping
/ip route add routing-mark=ISP1 gateway=2.2.2.2 distance=10
/ip route add routing-mark=ISP2 gateway=2.2.2.2 check-gateway=ping
/ip route add routing-mark=ISP2 gateway=1.1.1.1 distance=10

Как только шлюз 1.1.1.1 перестаёт пинговаться - первый и последний маршруты становятся неактивными, поэтому трафик в обеих таблицах пойдёт на 2.2.2.2

[timonsterrr]

Всех приветствую, оживлю немного тему.
Предпринял я несколько попыток осуществить балансировку и отказоустойчивость по следующей схеме.
1 - анонсирую обоим провайдерам префиксы /22
2 - анонсирую первому провайдеру префикс х.х.1.0/24
3 - анонсирую второму провайдеру префикс x.x.2.0/24
/24 и /22 префиксы провайдерами принимаются, адвертайзы приходят. В БД RIPE прописаны и /22 и /24 префиксы

От обоих провайдеров FV, в дефолтовую таблицу без каких либо локал префов и тд.

Все это включаю, сессии устанавливаются. Маршруты приходят. Но получается следующая картина:
если в качестве исходящего маршрута выбран маршрут от ISP1 (х.х.1.0/24 мы ему анонсируем помимо 22 этот префикс) то у абонентов входящих в префикс х.х.1.0/24 все работает, ресурс доступен, а вот у абонентов, которые попадают под префикс x.x.2.0/24 ресурс становится недоступен, трассировка за пределы сети уходит...но до ресурса не доходит. И наоборот. Есть мысли у кого-нить что не так? Пробовал так же анонсировать следующим образом:
ISP1:
x.x.0.0/22
х.х.1.0/24
x.x.2.0/24 set prepend 3

ISP2
x.x.0.0/22
х.х.1.0/24 set prepend 3
x.x.2.0/24

И ситуация не поменялась.

[Chupaka]

А если только /22 анонсировать сначала на одного, потом на другого провайдера - всё работает?

[timonsterrr]

А если только /22 анонсировать сначала на одного, потом на другого провайдера - всё работает?

22 постоянно анонсированы. Так делать не пробовал - поочередно анонсить. Но в этом и нет смысла ибо я не смогу балансировать нагрузку.

[Chupaka]

Я имею в виду, проверить анонсы по отдельности на каждого из аплинков. Анонсировать только /22 и только на одного, а исходящий трафик пустить через другого

[timonsterrr]

Я имею в виду, проверить анонсы по отдельности на каждого из аплинков. Анонсировать только /22 и только на одного, а исходящий трафик пустить через другого

На завтра на ночь - запланировал тест...попробую.

[timonsterrr]

Собственно отписываюсь о результатах. Все заработало. Проблема была в настройке ip/settings rp-filter Выставил значение loose и трафик пошел как надо. До этого он стоял в режиме - дропать пакет, если он пришел не с того интерфейса, с которого ушел.