Балансировка двух каналов по BGP

[KoloBok]

Привет, Коллеги!

 

Подскажите как грамотно решить такой вопрос:

Есть включение к двум операторам по BGP.

Один из них - с оплатой по трафику и без лимита скорости, Второй - с оплатой по полосе.

Теперь вопрос: как мне реализовать балансировку входящего трафика таким образом, чтобы обеспечить максимальную загрузку канала с оплатой по полосе и добирать в пики с канала с оплатой по трафику?

 

Не уверен, есть ли промышленное решение, поэтому буду рад и идеям.

[edwin]

Привет, Коллеги!

 

входящего трафика таким образом, чтобы обеспечить максимальную загрузку канала с оплатой по полосе и добирать в пики с канала с оплатой по трафику?

По поводу входящего трафика вообще говоря ситуация достаточно непростая, ввиду того что реально на его поступление можно повлиять с помощью AS-prepend

 

Вероятно в Вашем случае необходимо поступить таким образом:

1) Исход мы регулируем с помощью PBR или иными средствами (типа BGP local pref).

2) Делим сети на 2 категории

1 -которым не нужен сильно много качество (к примеру анлимитчики)

2 - которым необходим качественный инет (оплата по Мб)

 

с помощью as-prepend соот. образом анонсим сети peer'ам (не забываем приписать route object'ы ) и вход для потечет соот. образом разделенный .....

[sbca]

Аплинки поддерживают communities например для установки backup localpref для Ваших префиксов?

 

Если да, то я бы наверное думал в сторону написания анализатора сетевой загрузки, который при достижении определенной средней загрузки на flat-rate канале выставлял или снимал для префиксов идущих в канал с учетом по трафику backup-community.

 

правда иннерционность данной системы достаточно велика, особенно если загрузка меняется не плавно.

 

тоже самое можно и по исходящему трафику сделать (если это вообще надо), тут проще: выставляешь одинаковый localpref для префиксов идущих от обоих провайдеров - значит исходящий будет идти по обоим веткам в зависимости от того, у кого маршрут короче. выставляешь на префиксы аплинка1 local-pref по-меньше, чем для аплинк2, то весь исходящий достанется аплинку1.

 

можно и средствами PBR решить балансировку исходящего - тут уж сам решай как тебе проще.

[edwin]

> flat-rate канале выставлял или снимал для префиксов идущих в канал с учетом по трафику backup-community.

 

Для того, что-бы изменения вступили в силу придется reset'ить bgp session

 

 

> тут проще: выставляешь одинаковый localpref для префиксов идущих от обоих провайдеров - значит исходящий будет идти по обоим веткам в зависимости от того, у кого маршрут короче

 

ну можно еще воспользоватся maximum-paths

[sbca]

Для того, что-бы изменения вступили в силу придется reset'ить bgp session

ну да:

clear ip bgp <bgp-router-ip> soft out

а чем это черевато?

[edwin]

> а чем это черевато?

 

Ну вообще говоря при использовании soft reset по идее ничем, однако данный момент для точности отметить стоит.

По крайней мере мне так кажется

[KoloBok]

Аплинки поддерживают communities например для установки backup localpref для Ваших префиксов?

 

Если да, то я бы наверное думал в сторону написания анализатора сетевой загрузки, который при достижении определенной средней загрузки на flat-rate канале выставлял или снимал для префиксов идущих в канал с учетом по трафику backup-community.

 

правда иннерционность данной системы достаточно велика, особенно если загрузка меняется не плавно.

А если не поддерживают?

 

Я тоже думаю про анализатор. Потому и спросил в надежде, что есть промышленное решение, дабы не изобретать велосипед.

 

По поводу анализатора есть ряд принципиальных вопросов:

1.Нужно постоянно анализировать полосу во flat-канале. Не раз в 5 минут, а постоянно. Причем алгоритм должен уметь "предсказывать" превышение макс. полосы).

2.Время реации - как быстро вступят в силу изменения?

3.Главное-как регулировать препендами? Насколько? Как часто?

 

Короче - много вопросов, ответы на которые можно получить только эмпирически.

 

Неужели никто так и не реализовал аналогичную схему?

[sbca]

А если не поддерживают?

2 варианта:

1. попросить аплинков, чтобы добавили поддержку комьюнити для управления твоими анонсами.

2. выставлять комьюнити для "более" вышестоящих аплинков (у меня один из аплинков сам подключен к 2-м аплинкам: ТТК и РТ-Комм - они оба понимают back-up комьюнити). тут будем надеятся, что твой порв не счищает твои комьюнити и пропускает их дальше.

 

Я тоже думаю про анализатор. Потому и спросил в надежде, что есть промышленное решение, дабы не изобретать велосипед.

я не видел.

 

По поводу анализатора есть ряд принципиальных вопросов:

1.Нужно постоянно анализировать полосу во flat-канале. Не раз в 5 минут, а постоянно. Причем алгоритм должен уметь "предсказывать" превышение макс. полосы).

2.Время реации - как быстро вступят в силу изменения?

3.Главное-как регулировать препендами? Насколько? Как часто?

1. постоянно - не имеет смысла. по причине описанной в п.2

2. реакцию на изменение твоих анонсов можешь сам посмотреть через чужие looking-glass. по моим наблюдениям - около минуты

3. не переоценивай препенды. большинство операторов настраивают политику маршрутизации вручную исходя из экономических соображений при помощи тех же localpref. И как бы ты не старался искуственно удлиннить маршрут до себя, чужая автономка будет всё равно стараться сливать в тебя трафик через своего клиента, если нет акой возможности - через пиринг, и уж в крайнем случае через аплинка, вне зависимости от длины as-path. Сам понимаешь, в первом случае ему за это заплатят клиенты, во втором - ни он ни ему не платят, а в 3-м сам пров за это платит.

 

так что на мой взгляд самый удачный способ балансировки входящего - препенды + комьюнити.

 

я бы сдеал так:

 

анализировал например по rrd-файлам от MRTG загрузку flat-rate канала.

1) при достижении средней загрузки за 5 минут >80% снимал бы backup community с trafic-канала

2) при снижении средней загрузки <60% выставлял бы backup community обратно.

 

пороги срабатывания стоит выбирать исходя из ширины каналов и баланса трафика между ними при одновременно поднятых каналах.

Edited November 6, 2006 by sbca

[KoloBok]

Ок.

Не совсем понятен механизм работы backup community, но попробую разобраться.

 

Спасибо большое. Особенно sbca и edwin.

[sbca]

Не совсем понятен механизм работы backup community, но попробую разобраться.

возмем к примеру ТТК (AS20485)

http://www.ripe.net/fcgi-bin/whois?form_ty...&submit.y=0

 

remarks: | - To change the default Local Preference for prefix:

remarks: |

remarks: | 20485:51010 - to announce BACKUP route with Local

remarks: | Preference 10 (lower than all)

remarks: | 20485:51110 - to announce PREFERED route with

remarks: | Local Preference 110 (higher than all)

т.е. если ТТК получит от тебя префикс с комьюнити содержащим "20485:51010", то у себя в базе данных BGP этому префиксу будет присвоен самый низкий local-preference - 10. т.е. если существует несколько вариантов доставки, то через этот маршрут трафик пойдёт в самую последнюю очередь(когда кроме этого способа до тебя достучаться ну никак нельзя будет).

Edited November 7, 2006 by sbca

[kaN5300]

По Данному линку ( http://www.ripe.net/fcgi-bin/whois?form_ty...&submit.y=0 ) уже не доступна инфа из цитаты. Откуда ее можно еще заполучить? Для балансировки входящего трафика в BGP необходимо разослать от себя определенные префиксы своим пирам, чтобы они присвоили нужный local-preference. Я так понимаю?

[Ivan Rostovikov]

Я пытался решить такую же проблему.

и препендами и комьюнити.Ничего не срабатывает как надо, Если 1 из операторов имеет низкую стоимость пути.Например ТТК.

Вы неможете эффеткивно управлять входящим трафиком. С этим надо смириться.

[kaN5300]

А у нас порядка 20 мбит по ТТК простаивает с то время, как по FLEX ISP фигачит сорокет. В среднем по входящему один канал ниже другого на 15 мегабит по входящему.

[chainick]

http://forum.nag.ru/forum/index.php?showtopic=46533

[[anp/hsw]]

если у вас имеется ярко выраженый пик трафика в ЧНН, то не надо городить огород - постройте графики за неделю и определите ЧНН, прибавьте с обоих концов по полчаса для верности, и переключайте cron'ом community.

если же у вас получается очень много пиков (в основном когда народа не больше 500 человек, и есть тарифы хотя бы в 30% от емкости магистрали (типа магистраль 30мбит, а максимальная продаваемая полоса - 10мбит) то тогда вам нужно действительно быстрое переключение, но без NAT тут не обойтись...

 

 

[bitbucket]

А у нас порядка 20 мбит по ТТК простаивает с то время, как по FLEX ISP фигачит сорокет. В среднем по входящему один канал ниже другого на 15 мегабит по входящему.

Впишите в сторону FLEX ISP препенд и посмотрите что получится. Ну и структуру трафика так же советую посмотреть, что бы понять какой трафик создает перекос.

[chainick]

Против непробиваемых операторов с ацким локалпрефом никакие препенды не помогают, только принудительные управление анонсами любым пионерским способом, либо морспецифики на основного аплинка.

 

[iValera]

А у нас порядка 20 мбит по ТТК простаивает с то время, как по FLEX ISP фигачит сорокет. В среднем по входящему один канал ниже другого на 15 мегабит по входящему.

Впишите в сторону FLEX ISP препенд и посмотрите что получится. Ну и структуру трафика так же советую посмотреть, что бы понять какой трафик создает перекос.

BGP prepend разве не увеличивают путь для исходящего трафика? Пробовали, не помогло, входящий трафик от FLEX больше.

[UglyAdmin]

А у них COMMUNITY есть?

Если есть - курите до просветления, если нет - скорее всего они прозрачно пропускают COMMUNITY аплинков.

[Kirya]

А у нас порядка 20 мбит по ТТК простаивает с то время, как по FLEX ISP фигачит сорокет. В среднем по входящему один канал ниже другого на 15 мегабит по входящему.

Впишите в сторону FLEX ISP препенд и посмотрите что получится. Ну и структуру трафика так же советую посмотреть, что бы понять какой трафик создает перекос.

BGP prepend разве не увеличивают путь для исходящего трафика? Пробовали, не помогло, входящий трафик от FLEX больше.

Нет, не увеличивает.

Два пробуйте, три.

Курите коммьюнити Flex-a, если они есть

C мелкими операторами также часто срабатывает управление снятием анонсов через Админа оператора:).

[kaN5300]

Флекс прислал нам вот такие данные для управления:

 

21453:100x When advertising to MSK-IX peers
21453:110x When advertising to Corbina
21453:120x When advertising to GT
21453:130x When advertising to EMAX
21453:140x When advertising to NSV
21453:150x When advertising to RT
...x=0 - do not advertise
...x=1,2 or 3 - prepend 21453 1,2 or 3 times

 

В микротик, как я понял, для одного фильтра можно вписать только один community. Вышло как-то так:

 

 0   chain=FLEX_IN prefix=88.84.218.0/24 protocol=bgp invert-match=no action=passthrough 
     set-bgp-communities=21453:1000 

1   chain=FLEX_OUT prefix=88.84.218.0/24 protocol=bgp invert-match=no action=passthrough 
     set-bgp-communities=21453:1000

 

Установили для MSK-IX "не анонсировать". Как прописать больше коммунити и перекрывает ли 100х все остальные не понтно. Для того чтоб изменения вступили в силу, как я понял, требуется разрывать сессию. Перезагрузили микротик - ничего не изменилось.

[iValera]

Вобщем препенды у флекса не срабатывают (т.к. у вышестоящего оператора флекса все-равно стоит наивысший приоритет) , в то время как у ТТК все ок. На флекс отсылаем community с блокировкой MSK-IX , корбины, гд и т.д. все без изменений, трафик преобладает на флексе, чем ттк.

[1GE]

Комьюнити у Флекса срабатывают или нет в итоге ?

Например: вы закрываете на флексе корбину, лукинг глас Корбины подтверждает изменение пути до вас ? http://noc.corbina.net/usr-cgi/lg.pl

[iValera]

Комьюнити у Флекса срабатывают или нет в итоге ?

Например: вы закрываете на флексе корбину, лукинг глас Корбины подтверждает изменение пути до вас ? http://noc.corbina.net/usr-cgi/lg.pl

Косяк оказался выше нас, с комьюнити разобрались более менее, трафик на флексе уменьшается, но ТТК не хочет загружаться (загрузка становится больше на 10-20%) и ощущаются лаги, потери пингов..