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

Равномерная загрузка EoIP

Добрый день!

Есть такая схема: 

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

 

 

4 EoIP туннеля.jpg

Share this post


Link to post
Share on other sites

Вы уверены, что в вашей схеме использование N-ного количества EoIP туннелей обосновано? Напрашивается PCQ queue, но сначала схемку бы уточнить

Share this post


Link to post
Share on other sites
19 часов назад, maxkst сказал:

Вы уверены, что в вашей схеме использование N-ного количества EoIP туннелей обосновано? Напрашивается PCQ queue, но сначала схемку бы уточнить

Добрый день. 

Не вопрос.

Что конкретно уточнить? И с какого места? 

4 EoIP туннеля-2.jpg

Edited by zhekius
Ну или вот так, что-ли...

Share this post


Link to post
Share on other sites
В 14.8.2018 в 19:17, zhekius сказал:

 

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

 

 

 

Может развернуть на соединениях VRRP? С балансировкой загрузки?

Share this post


Link to post
Share on other sites

Bonding? работает на 2х точно... на 4 думаю тоже будет...

Share this post


Link to post
Share on other sites

Балансировать соединения L2 на таких разных каналах - плохая идея. Роль играет не только скорость, но и задержка и mtu

 

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

тогда костыли, нормальных решений нет...

Share this post


Link to post
Share on other sites

Это странное кроилово, имея каналы от 10 и от 20Мбит/с  - пытаться одновременно подключить еще ненадёжные каналы от 1Мбит/с, назначение которых разве что backup.
Такое кроилово приведет к попадалову.

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

Наверно какие нить каналы от моб. Операторов , 3g ,4g..

Share this post


Link to post
Share on other sites
4 часа назад, HarDik сказал:

Наверно какие нить каналы от моб. Операторов , 3g ,4g..

И такие есть. Через них также прокладывается EoIP. 

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

Share this post


Link to post
Share on other sites

OSPF поднять по всем каналам и перейти на L3 транспорт. Тогда можно даже медленные каналы использовать.

Share this post


Link to post
Share on other sites

@Saab95 и по верх наложить mpls )))

 

З.ы. Тс всегда есть возможность, завести полноценный интернет, хотя бы тот же wi-fi

Имхо не стоит писать против ветра.

Share this post


Link to post
Share on other sites

Поддерживаю идею Saab95 насчет OSPF, почитайте про Transit Fabric, похоже ваш случай. 

Единственное, что хотел добавить так это то, что у вас часть полосы забирает Overhead EoIP в нынешней конфигурации.

http://www.stubarea51.net/2016/10/27/wisp-design-using-ospf-to-build-a-transit-fabric-over-unequal-links/

Share this post


Link to post
Share on other sites
В 16.08.2018 в 21:36, Saab95 сказал:

OSPF поднять по всем каналам и перейти на L3 транспорт. Тогда можно даже медленные каналы использовать.

Бред. OSPF даст ECMP-маршрут. Для балансировки/загрузки L2 линка это будет фейл.

 

Share this post


Link to post
Share on other sites

В случае с Transit Fabric любая полоса сначала нарезается на кусочки равной ширины, а потом equal cost присваивается каждому отдельному кусочку

Share this post


Link to post
Share on other sites
14 часов назад, maxkst сказал:

В случае с Transit Fabric любая полоса сначала нарезается на кусочки равной ширины, а потом equal cost присваивается каждому отдельному кусочку

Это для стабильных каналов.
В приведённой схеме, линки 1 и 2 имеют случайный 20 кратный разброс по пропускной способности. И ваша методика становится неприменимой.
Если же исходить из минимальных значений, то имея альтернативные каналы 30+10 Мбит/с, нет смысла прицеплять еще и 1+1 Мбит/с

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

Технология называется SD-WAN. Делает именно то, что вам нужно.

 

Сколько вам необходимо ГАРАНТИРОВАНОГО канала между этими точками?

40 мегабит хватит?

Share this post


Link to post
Share on other sites
В 18.8.2018 в 17:02, adron2 сказал:

Технология называется SD-WAN. Делает именно то, что вам нужно.

 

Сколько вам необходимо ГАРАНТИРОВАНОГО канала между этими точками?

40 мегабит хватит?

Вполне хватит. Следовательно, вопрос: как при наличии текущих условий (см. начало) можно развернуть данную систему? 

Я имею ввиду, мне как-то на RouterOS это наложить получиться?

Share this post


Link to post
Share on other sites
2 часа назад, zhekius сказал:

Вполне хватит. Следовательно, вопрос: как при наличии текущих условий (см. начало) можно развернуть данную систему? 

Я имею ввиду, мне как-то на RouterOS это наложить получиться?

Никак. РоутерОС не умеет SD-WAN. И вряд ли когда то будет уметь. Нужно менять прошивку на OpenWRT и использовать софт который это умеет. Софт закрытый и платный. Весь вопрос на сколько вам это нужно и экономически оправдано и соответственно сколько вы готовы за это заплатить.

Share this post


Link to post
Share on other sites
В 15.8.2018 в 18:07, zhekius сказал:

 

4 EoIP туннеля-2.jpg

 

"поднял" на данной схеме OSPF - прикольная штука, этот OSPF. Дополнительно отстроил выход в Интернет под одним айпи на сервере. Тоже забавно получается - подхват отвалившихся потоков ну и т.д. Всё удовлетворяет...почти всё, блин.

Оказывается, в маршрутах с несколькими интерфейсами строится ECMP (меня это устраивает), но не устраивает протокол RTMP по 1953 порту. Затыкается он и никак не дружит с ECMP. Причем, проверял на отдельном микротике, не связанном с данной схемой, с двумя выходами в сеть Интернет. Шлюз по умолчанию 0.0.0.0\0 - на  любой рабочий интерфейс ставлю - видеопоток идет (см. картинки). Добавляю два интерфейса на один шлюз по умолчанию - хрен! Именно затывкается видео. Всё остальное работает, просто кайф!!!

В случае одного шлюза по умолчанию:

1.jpg

11.JPG111.JPG

В случае второго картинка висит и не запускается. Всё остальное, что я хотел (видеокамеры по отдельным IP-адресам, все http-запросы и прочая "требуха" - всё нормально. По крайней мере, не нашел я, что не работало бы на ECMP.

2.JPG22.JPG

 

Может где-то маршруты замыкаются для этого видеопотока? Ну, в смысле, рекурсия какая-нибудь. Или обязателен контроль трафика (куда ушел-оттуда пришел)? Чего-то не догоняю я. Подскажите.

Edited by zhekius

Share this post


Link to post
Share on other sites
В 08.09.2018 в 01:27, zhekius сказал:

Добавляю два интерфейса на один шлюз по умолчанию - хрен!

Почитайте еще раз, что я выше написал. Так и будет.

Share this post


Link to post
Share on other sites
7 часов назад, nkusnetsov сказал:

Почитайте еще раз, что я выше написал. Так и будет.

если про ECMP, то ясно. Ситуация с 93.157.173.6:1935 не понятна. Вопрос, конечно, уходит в плоскость балансировки трафика именно для этого адреса, который отказывается работать с ECMP.

К другим видам трафика (http и прочие нагрузки) вопросов нет.

Share this post


Link to post
Share on other sites

Что бы OSPF работало правильно, адресация устройств должна быть уже на интерфейсах OSPF за транзитным. Если вы создаете интерфейсы и вешаете в них адреса камер, то и работать все должно без проблем по любому порту, при отсутствии связи (обрыве одного канала), связь повторно устанавливается по резервному, ведь в этом случае 40 секунд связь может отсутствовать (настраивается в настройках). Тут уже надо смотреть на само ПО, которое с камерами работает, и нет ли где-то на каком-то микротике фильтров, по которым некоторый трафик обрубается.

Share this post


Link to post
Share on other sites
В 7.9.2018 в 21:27, zhekius сказал:

 

Может где-то маршруты замыкаются для этого видеопотока? Ну, в смысле, рекурсия какая-нибудь. Или обязателен контроль трафика (куда ушел-оттуда пришел)? Чего-то не догоняю я. Подскажите.

 

Прошёл по цепочке формирования трафика. Косячок-с у меня где-то в туннелях.

Прикол в том, что этот фидеопоток по 1935 порту не идет ни через EoIP, ни через IPIP, ни через GRE. Прикольно получается... Через L3-маршрутизацию видео проходит.

Как отследить, в чем проблема? 

Share this post


Link to post
Share on other sites
1 час назад, zhekius сказал:

Прошёл по цепочке формирования трафика. Косячок-с у меня где-то в туннелях.

Прикол в том, что этот фидеопоток по 1935 порту не идет ни через EoIP, ни через IPIP, ни через GRE. Прикольно получается... Через L3-маршрутизацию видео проходит.

Как отследить, в чем проблема? 

Идем дальше. Отключил все туннели. Проверял на OVPN и SSTP. Тот же сайт для экспериментов: http://camera.avk-wellcom.ru/get-camera-map/95/. Выбирается любая активная камера... Итог такой же: все сайты, которые я нашел - норм. Этот капризничает.

Схема для проверки: 

Презентация1.jpg

P.S.

Да, в общем-то, без VPN-ов от белого до белого айпи бросил EoIP. Не прёт связь с этими видеокамерами. Странно...

 

Презентация2.jpg

Edited by zhekius

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