Перейти к содержимому
Калькуляторы

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

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

 

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

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

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

 

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

 

kanal.png

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Только впн ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Только впн ?

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пример реализации тут

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

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

Изменено пользователем saaremaa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обычный 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут (стр. 249)?

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

 

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

Изменено пользователем dazgluk

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 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. Не, определенно это не тема для вечера понедельника.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В приложении (MikroTik RouterOS Workshop. Load Balancing. Best Practice) может что будет их этого полезно.

us11-megis-lb.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кому интересно, я такую вещь делал на 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 можно пускать безусловным образом в самый короткий линк.

Изменено пользователем agr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.