Comments 27
UFO just landed and posted this here
Значит BGP демон не сможет с ним связаться и анонсировать ему наши сети. Следовательно, весь входящий пойдет по оставшемуся каналу.
Ну а для исходящих надо или мониторить эти 2 канала с автоматическим изменением default маршрута, или настраивать BGP так, чтобы он изменял свои локальные маршруты.
У меня используется 1й вариант — моя AS не пропускает транзитный трафик, достаточно обойтись статическими маршрутами.
В итоге, каждые 5 минут проверяется доступность 8.8.8.8 через оба канала (мониторить сами шлюзы смысла нет — проблема может быть дальше). Если оба доступны, то:
ip route change default scope global nexthop via [IP шлюза 1 пров] dev [eth 1 пров] weight 1 nexthop via [IP шлюза 2 пров] dev [eth 2 пров] weight 1
Если один, то:
ip route change default via [IP шлюза оставшегося прова] dev [eth оставшегося прова]
В результате, при пропадании одного из каналов, в течении 5 минут, происходит переключение исходящего маршрута на оставшийся канал. Входящий анонсируемый маршрут остается один — оставшегося канала.
N достигает минимума или максимума, таким и остается. Но на работу это уже не сказывается. Ну, натиться все будут одним диапазоном, и что?
Единственный минус — оставшийся канал оказывается перегружен. Ведет это к большим потерям. Но, это форс-мажор, авария… И обычно не так долго.
Такой мониторинг работает у меня давно (больше года). Время от времени пропадает то 1 канал, то другой. Все отрабатывает нормально, еще и сообщение на мыло присылает.
При восстановлении канала все быстро приходит в норму.
Ну а для исходящих надо или мониторить эти 2 канала с автоматическим изменением default маршрута, или настраивать BGP так, чтобы он изменял свои локальные маршруты.
У меня используется 1й вариант — моя AS не пропускает транзитный трафик, достаточно обойтись статическими маршрутами.
В итоге, каждые 5 минут проверяется доступность 8.8.8.8 через оба канала (мониторить сами шлюзы смысла нет — проблема может быть дальше). Если оба доступны, то:
ip route change default scope global nexthop via [IP шлюза 1 пров] dev [eth 1 пров] weight 1 nexthop via [IP шлюза 2 пров] dev [eth 2 пров] weight 1
Если один, то:
ip route change default via [IP шлюза оставшегося прова] dev [eth оставшегося прова]
В результате, при пропадании одного из каналов, в течении 5 минут, происходит переключение исходящего маршрута на оставшийся канал. Входящий анонсируемый маршрут остается один — оставшегося канала.
N достигает минимума или максимума, таким и остается. Но на работу это уже не сказывается. Ну, натиться все будут одним диапазоном, и что?
Единственный минус — оставшийся канал оказывается перегружен. Ведет это к большим потерям. Но, это форс-мажор, авария… И обычно не так долго.
Такой мониторинг работает у меня давно (больше года). Время от времени пропадает то 1 канал, то другой. Все отрабатывает нормально, еще и сообщение на мыло присылает.
При восстановлении канала все быстро приходит в норму.
+2
при такой смене дефолт-роута может сложиться ситуация, что открытые соединения изза коннтрака пойдут по новому умолчательному маршруту, но будут снатиться по прежнему на старый адрес.
0
И бог с ними!
Главное, чтобы существовал анонс для этого «старого адреса» на «живой» маршрут. При этом, длина этого маршрута не имеет значения — он остался один.
Смотрите.
Клиент натится адресом ВнешнийАдресКлиента.
Пока живы оба канала, анонсируются два маршрута на этот ВнешнийАдресКлиента. Один чуть длиннее другого. Следовательно, трафик этому клиенту пойдет по короткому маршруту.
Если в живых остается один канал, то и анонсируется только один маршрут (на оставшийся канал). Следовательно, весь трафик этому клиенту пойдет только по живому каналу. При этом все остальное не имеет значения.
Это особенность работы BGP — автоматическое поддерживание «живых» маршрутов. И автоматическая очистка от «мертвых».
Главное, чтобы существовал анонс для этого «старого адреса» на «живой» маршрут. При этом, длина этого маршрута не имеет значения — он остался один.
Смотрите.
Клиент натится адресом ВнешнийАдресКлиента.
Пока живы оба канала, анонсируются два маршрута на этот ВнешнийАдресКлиента. Один чуть длиннее другого. Следовательно, трафик этому клиенту пойдет по короткому маршруту.
Если в живых остается один канал, то и анонсируется только один маршрут (на оставшийся канал). Следовательно, весь трафик этому клиенту пойдет только по живому каналу. При этом все остальное не имеет значения.
Это особенность работы BGP — автоматическое поддерживание «живых» маршрутов. И автоматическая очистка от «мертвых».
0
UP. Замечу, что хотя полное анонсирование своего маршрута на весь Интернет, — дело долгое (до 6 часов), информация до ближайших маршрутизаторов доходит быстро (по моим наблюдениям 5-10 минут). И это оказывает решающее значение. Даже если какой-то хост в далекой Америке (например) отправит пакет по уже «мертвому» маршруту, то где-то вблизи от меня этот пакет переправится по «живому» пути.
0
а если все тоже самое, но без бгп ?)
0
Хм… Чтобы принимать трафик на одни и те-же адреса через несколько каналов — это надо иметь автономную систему (AS). Т.е. независимые от провайдера адреса. Никакой провайдер не станет маршрутизировать свои адреса через другого.
Ну, а где AS, там и BGP.
ИМХО, балансировать входящий без равноправности адресов в разных каналах — это создавать большие проблемы клиентам. Придется постоянно менять внешний адрес клиента, что далеко не гуд.
Или менять «N» изредка. До получения AS так и делали, но это «N» менялось вручную по мере надобности. Подобрать оптимального просто не получалось. В результате в течении суток то один канал переполнялся, то другой. А это — потери. Опять «не гуд».
Ну, а где AS, там и BGP.
ИМХО, балансировать входящий без равноправности адресов в разных каналах — это создавать большие проблемы клиентам. Придется постоянно менять внешний адрес клиента, что далеко не гуд.
Или менять «N» изредка. До получения AS так и делали, но это «N» менялось вручную по мере надобности. Подобрать оптимального просто не получалось. В результате в течении суток то один канал переполнялся, то другой. А это — потери. Опять «не гуд».
0
не, я имел ввиду обычный фейловер на случай падения основного канала — как быть с открытыми соединениями. рвать принудительно через conntrack -D при смене маршрута по-умолчанию?
0
А зачем? Если ответа нет, то по тайм-ауту сами отвалятся. Только IP стек надо настроить — уменьшить этот тайм-аут до адекватных 30 минут (например). А лучше 5 минут. По-умолчанию там что-то около недели.
Но это уже другой разговор — оптимизация IP стека на шлюзе.
Но это уже другой разговор — оптимизация IP стека на шлюзе.
0
5 минут ?) а если цель — обеспечить воип с мин простоями?
0
Кратковременное прерывание все равно будет, от этого никак не уйти. Это если «оборвался» как раз канал, по которому идет основной трафик клиента. Иначе вообще никаких прерываний.
Чтобы уменьшить время прерывания — AS и BGP. Т.е. сохраняется внешний адрес клиента независимо от входящего/исходящего канала.
Другой вариант — bond на 2 провайдера. Но это не реально. Если 2 подключения к одному, это еще как-то возможно. А к разным… Им это надо?
Чтобы уменьшить время прерывания — AS и BGP. Т.е. сохраняется внешний адрес клиента независимо от входящего/исходящего канала.
Другой вариант — bond на 2 провайдера. Но это не реально. Если 2 подключения к одному, это еще как-то возможно. А к разным… Им это надо?
0
А чем это решение лучше/хуже настройки bond-интерфейса? И не получится ли так, что для одного и того же адресата исходящие пакеты отправляются по разным каналам в разные моменты времени?
-2
у бонд-интерфейса 1 ип-адрес, нужна поддержка со стороны «другого конца проводов»
+1
2 разных провайдера никогда не дадут создать такое подключение.
+2
И не получится ли так, что для одного и того же адресата исходящие пакеты отправляются по разным каналам в разные моменты времени?
Более того, и исходящие от клиента, и входящие к клиенту, могут идти одновременно по обоим каналам (т.е. часть по одному, часть по другому). И это нормальное явление в Интернете.
+1
Пусть себе отправляются — какая разница? :) Все равно в конечном итоге приедут куда надо.
0
никто не мешает дополнительно в BGP описать (т.е. анонсировать) 1.1.144.0/24, 1.1.145.0/24, 1.1.146.0/24 и 1.1.147.0/24
Вот Вы совсем не самурай. Самураи так не делают, т.к. это увеличивает и так раздутый full view и, как следствие, повышает энтропию вселенной, приближая тепловую смерть.
Правильно брать у обеих аплинков физику с запасом и канал по burstable billing.
0
К сожалению, нахожусь я недалеко от Тихого Океана, цены за трафик у нас не маленькие и всего два провайдера с достаточными мощностями.
Так что особо выбирать и кочевряжиться не получится. И переплачивать в два раза — тоже «не фонтан».
А про «full view» согласен… Но куда деваться? На сколько знаю, мелкие узлы его режут. Т.е. мои /24 просто проигнорируют.
Так что особо выбирать и кочевряжиться не получится. И переплачивать в два раза — тоже «не фонтан».
А про «full view» согласен… Но куда деваться? На сколько знаю, мелкие узлы его режут. Т.е. мои /24 просто проигнорируют.
0
UFO just landed and posted this here
Мне повезло на 50%. У одного провайдера сразу были возможны препенды, второй разрешил после недели переписки.
0
PS. И действительно, у вышестоящих провайдеров были разные local-pref от пиров. Пришлось выравнивать своими «set as-path prepend». Но получилось. ;)
Не зря писал
И с этим довольно долго помучился…
Не зря писал
Во-первых, надо настроить все «set as-path prepend» в bgp.conf.
Задача — чтобы если все натить исходящим 1.1.146.0/24 (это условно, конечно), то получить большой перекос в сторону РТК.
И наоборот, если все натить исходящим 1.1.147.0/24, то получить сильный перекос в сторону ТТК.
И с этим довольно долго помучился…
0
UFO just landed and posted this here
Если честно — не знаю. Работает, и не заморачиваюсь.
Основной трафик идет издалека, и он регулируется. Так что если от кого-то трафик будет идти только по одному каналу (как аплинк приказал, а такое скорее всего имеется), то основной массой трафика выравнивается.
Кстати, а и не всегда выравнивается! Ночью, когда трафика мало — диапазона регулировки часто не хватает. И между каналами идет перекос. Но это ночью, каналы почти пустуют, так что не страшно. Главная задача — не допустить переполнения каналов при эффективном их использовании, и задача эта успешно выполняется.
Хм… Вот и объяснение, почему ночью плохая балансировка (т.е. отклонение от заданного соотношения). А я все голову ломал…
Основной трафик идет издалека, и он регулируется. Так что если от кого-то трафик будет идти только по одному каналу (как аплинк приказал, а такое скорее всего имеется), то основной массой трафика выравнивается.
Кстати, а и не всегда выравнивается! Ночью, когда трафика мало — диапазона регулировки часто не хватает. И между каналами идет перекос. Но это ночью, каналы почти пустуют, так что не страшно. Главная задача — не допустить переполнения каналов при эффективном их использовании, и задача эта успешно выполняется.
Хм… Вот и объяснение, почему ночью плохая балансировка (т.е. отклонение от заданного соотношения). А я все голову ломал…
0
PS. Думаю, найдется много AS, чей трафик указанным методом не выровнять. Но общая масса, особенно «в час пик», — выравнивается. И это для меня главное.
0
А ещё можно почитать есть ли у провов public community list, проверить там с каким localpref у них сидят префиксы от клиентов, а с каким — от транзитников. И потом от себя задавать на разные префиксы разные community чтоб приоритизировать траффик у прова. Это, конечно, берёт время, но результат будет на лицо. Prepend-ы это далеко не наше всё. Но, хотя, если у вас так работает, то заморачиваться нет смысла.
0
Sign up to leave a comment.
Балансировка каналов — два провайдера, AS, BGP, NAT