[zhekius]

Добрый день!

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

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

 

 

[maxkst]

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

[zhekius]

19 часов назад, maxkst сказал:

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

Добрый день. 

Не вопрос.

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

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

[zhekius]

В 14.8.2018 в 19:17, zhekius сказал:

 

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

 

 

 

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

[HarDik]

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

[nkusnetsov]

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

 

Edited August 16, 2018 by nkusnetsov

[HarDik]

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

[nkusnetsov]

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

Edited August 16, 2018 by nkusnetsov

[HarDik]

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

[zhekius]

4 часа назад, HarDik сказал:

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

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

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

[Saab95]

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

[pingz]

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

 

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

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

[maxkst]

Поддерживаю идею 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/

[nkusnetsov]

В 16.08.2018 в 21:36, Saab95 сказал:

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

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

 

[maxkst]

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

[nkusnetsov]

14 часов назад, maxkst сказал:

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

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

Edited August 18, 2018 by nkusnetsov

[adron2]

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

 

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

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

[zhekius]

В 18.8.2018 в 17:02, adron2 сказал:

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

 

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

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

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

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

[adron2]

2 часа назад, zhekius сказал:

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

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

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

[zhekius]

В 15.8.2018 в 18:07, zhekius сказал:

 

 

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

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

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

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

 

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

Edited September 7, 2018 by zhekius

[nkusnetsov]

В 08.09.2018 в 01:27, zhekius сказал:

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

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

[zhekius]

7 часов назад, nkusnetsov сказал:

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

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

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

[Saab95]

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

[zhekius]

В 7.9.2018 в 21:27, zhekius сказал:

 

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

 

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

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

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

[zhekius]

1 час назад, zhekius сказал:

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

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

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

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

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

P.S.

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

 

Edited September 10, 2018 by zhekius