Jump to content
Калькуляторы

Загрузить равномерно 3 канала передачи данных. Есть 3 канала от разных провайдеров...

Есть 3 канала передачи данных от разных провайдеров:

 

1.РРЛ 250 мегабит с оплатой по трафику.

2.Оптика 100 мегабит безлимит.

3.Оптика 50 мегабит безлимит.

 

Есть сервер 1, подключенный к интернету 1000мбит безлимит, есть сервер 2, куда надо передать как можно больше интернета.

 

kanal.png

 

Требуется по 3-м VPN каналам передавать интернет на максимальной скорости, при этом сперва загружая каналы 2 и 3, и только при их полной занятости начинать передавать трафик через канал 1.

 

На сервере 1 есть куча IP белых адресов, на сервере 2 белые адреса не нужны, достаточно работой за натом.

 

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

Share this post


Link to post
Share on other sites

У cisco это может сделать eigrp(там можно балансировать с учётом пропускной способности и загруженности), но фактически тоже самое можно делать с помощью ip route add ... weight и раз в N секунд пересчитывать веса и делать ip ro change ... weight, нужно будет написать костыль объёмом ~экран кода

 

При предложенной схеме трафик через сервер2 должен быть IP, а не ppp.

Share this post


Link to post
Share on other sites

А автоматически по BGP/MPLS это сделать нельзя?

 

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

Share this post


Link to post
Share on other sites

А автоматически по BGP/MPLS это сделать нельзя?

 

Только через mpls-te. Пример реализации тут http://iwing.wordpress.com/black-box/belajar-mengkonfigurasi-mpls-te-unequal-cost-load-sharing/ .

 

Но судя по слову "сервер" вряд ли ваше оборудование/софт поддерживает TE

 

Обычный bgp умеет только equal-cost

 

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

 

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

Share this post


Link to post
Share on other sites

Требуется по 3-м VPN каналам передавать интернет на максимальной скорости, при этом сперва загружая каналы 2 и 3, и только при их полной занятости начинать передавать трафик через канал 1

Только впн ?

Share this post


Link to post
Share on other sites

А нельзя OSPF с разными параметрами cost ?

Share this post


Link to post
Share on other sites

Требуется по 3-м VPN каналам передавать интернет на максимальной скорости, при этом сперва загружая каналы 2 и 3, и только при их полной занятости начинать передавать трафик через канал 1

Только впн ?

 

Да можно по любому другому протоколу.

Share this post


Link to post
Share on other sites

А вот было бы интересно посмотреть на балансировку по mpls-te.

Share this post


Link to post
Share on other sites

А вот было бы интересно посмотреть на балансировку по mpls-te.

я ж давал ссылку на пример

Только через mpls-te. Пример реализации тут http://iwing.wordpress.com/black-box/belajar-mengkonfigurasi-mpls-te-unequal-cost-load-sharing/ .

Share this post


Link to post
Share on other sites
Пример реализации тут

так тож на Cisco. :) (Saab95 не уточнил что у него используется) Для Микротика такое не нашел. У нас, например, MPLS как-раз на Микротик и работает. http://wiki.mikrotik.com/wiki/MPLS_Lab_Setup

Балансируем адресными листами с маркировкой пакетов.

Edited by saaremaa

Share this post


Link to post
Share on other sites

Обычный bgp умеет только equal-cost

есть еще необычный bgp :)

вернее он обычный но под сторонним воздействием Cisco PfR

For example, if the range is specified as 25-percent, and the utilization of the exit link at BR1 (in the diagram above) is 70-percent, then if the utilization of the exit link at BR2 (in the diagram above) falls to 40-percent, the percentage range between the two exit links will be more than 25-percent and PfR will attempt to move some traffic classes to use the exit link at BR1 to even the traffic load

Share this post


Link to post
Share on other sites

Вендоронезависимо - только OSPF, IMHO.

OSPF умеет только Equal Cost.

Share this post


Link to post
Share on other sites

Тут (стр. 249)?

Собственно в концепте MPLS TE это справедливо. Но если на обычной сети, вы просто выставите bandwith (либо ospf cost), вы можете искуственно выровнять стоимость и сделать equal cost load sharing. Но трафик будет лится в линки поровну, без учета их реального bandwith (стоимости)

 

P.S. Вот Тут человек предлагает CEF обманывать, но это решение уже не становится вендоронезависимым :)

Edited by dazgluk

Share this post


Link to post
Share on other sites

В FAQ есть:

Q. How does OSPF use two Multilink paths to transfer packets?

A. OSPF uses the metric aCost, which is related to the bandwidth. If there are equal cost paths (the same bandwidth on both multilinks), OSPF installs both routes in the routing table. The routing table tries to use both links equally, regardless of the interface utilization. If one of the links in the first multilink fails, OSPF does not send all the traffic down the second multilink. If the first multilink peaks 100%, OSPF does not send any traffic down the second multilink because OSPF tries to use both links equally, regardless of the interface utilization. The second is used fully only when the first multilink goes down.

 

EIGRP вроде как может (+- остановка, но хоть как то), но проприетарщина.

Вроде BGP dmzlink-bw смог бы помочь, но, опять же, проприетарщина (хотя м.б. еще где есть dmzlink-bw).

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

 

P.S. Не, определенно это не тема для вечера понедельника.

Share this post


Link to post
Share on other sites

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

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

Опять же, в трафиковый канал можно запихать тех, кто не льет, но кому нужна скорость.

Share this post


Link to post
Share on other sites

Saab95, у Вас что-нибудь получилось по этой теме. Тоже этот вопрос интересует.

Share this post


Link to post
Share on other sites

Кому интересно, я такую вещь делал на juniper'е при помощи cos-based forwarding. Делать следующим образом:

1) На интерфейс, смотрящий в Интернет вешаем фильтр, который будет в зависимости от объема трафика приписывать его(трафик) к определенному forwarding class

agr@srx210# show interfaces ge-0/0/0
per-unit-scheduler;
unit 0 {
   family inet {
       filter {
           input CLASSIFY;
       }
       address x.y.z.242/29;
   }
}

agr@srx210# show firewall filter CLASSIFY
term ef {
   then {
       policer ef-class;
       count ef-counter;
       forwarding-class expedited-forwarding;
       next term;
   }
}
term af {
   from {
       forwarding-class assured-forwarding;
   }
   then {
       policer af-class;
       count af_counter;
       next term;
   }
}
term accept {
   then accept;
}

agr@srx210# show firewall policer ef-class
if-exceeding {
   bandwidth-limit 2m;
   burst-size-limit 125k;
}
then forwarding-class assured-forwarding;

[edit]
agr@srx210# show firewall policer af-class
if-exceeding {
   bandwidth-limit 2m;
   burst-size-limit 125k;
}
then forwarding-class best-effort;

 

2) в разделе class-of-service создаем next-hop-map, которая для каждого forwarding class'а задает отдельный next-hop

agr@srx210# show class-of-service forwarding-policy
next-hop-map CBF {
   forwarding-class expedited-forwarding {
       next-hop 192.168.168.2;
   }
   forwarding-class best-effort {
       next-hop 192.168.4.2;
   }
   forwarding-class assured-forwarding {
       next-hop 192.168.5.2;
   }
}

 

3) создаем policy, которая в зависимости от адреса назначения использует ранее созданную next-hop-map, и вешаем ее(policy) на экспорт в routing options forwarding-table

agr@srx210# show policy-options policy-statement cbf
from {
   route-filter 192.168.98.0/24 exact;
}
then cos-next-hop-map CBF;
agr@srx210# show routing-options forwarding-table
export cbf;

 

вот в общем то и все. В таблице маршрутизации должны быть маршруты к указанному в policy адресу назначения через указанные в next-hop-map узлы. У меня сделано статиком, но можно и через динамический протокол маршрутизации сделать.

agr@srx210# show routing-options static
[...]
route 192.168.98.0/24 next-hop [ 192.168.168.2 192.168.4.2 192.168.5.2 ];

 

При такой конфигурации линки будут загружаться последовательно, сначала тот где next-hop 192.168.168.2, потом где 192.168.5.2, потом где 192.168.4.2.

У этого метода есть еще один плюс - можно при помощи фильтра более гибко классифицировать трафик по разным параметрам, таким как src ip/port и т.п., например voip можно пускать безусловным образом в самый короткий линк.

Edited by agr

Share this post


Link to post
Share on other sites

Saab95, у Вас что-нибудь получилось по этой теме. Тоже этот вопрос интересует.

 

На данный момент использую тупую топорную, но работающую схему:

 

Через каждый канал поднят EoIP туннель, 3 туннеля объединены в бондинг. На компе с виндой стоит прога, которая по телнету забирает данные о загрузке через входной канал роутера. Если нагрузка меньше, чем пропуская способность первого канала, два других туннеля отключены, как только поднимается выше - включается второй канал и данные идут через него. Как опять нагрузка упадет - один канал отключается. Это если в двух словах. На самом деле через каждый канал поднято несколько туннелей=) работает криво конечно, но пока лучше не придумано.

Share this post


Link to post
Share on other sites

Imho → Manual:Tools/Traffic Monitor → При срабатывании триггера можно добавлять или убирать каналы.

 

Это решение немного для других целей. При его использовании, особенно во время когда канал почти загружен, происходило постоянное включение и выключение каналов. А стороннее управление позволяет анализировать поток данных в течении некоторого времени и на основе полученных данных включать и выключать каналы. Кстати во время таких манипуляций происходит кратковременная пауза в передачи данных.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this