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

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

Добрый день!

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

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

 

 

4 EoIP туннеля.jpg

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


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

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

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


Ссылка на сообщение
Поделиться на других сайтах
19 часов назад, maxkst сказал:

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

Добрый день. 

Не вопрос.

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

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

Изменено пользователем zhekius
Ну или вот так, что-ли...

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


Ссылка на сообщение
Поделиться на других сайтах
В 14.8.2018 в 19:17, zhekius сказал:

 

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

 

 

 

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

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


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

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

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


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

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

 

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

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


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

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

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


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

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

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

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


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

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

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


Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, HarDik сказал:

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

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

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

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


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

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

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


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

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

 

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

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

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


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

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

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


Ссылка на сообщение
Поделиться на других сайтах
В 16.08.2018 в 21:36, Saab95 сказал:

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

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

 

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


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

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

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


Ссылка на сообщение
Поделиться на других сайтах
14 часов назад, maxkst сказал:

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

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

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

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


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

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

 

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
В 18.8.2018 в 17:02, adron2 сказал:

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

 

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

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

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, zhekius сказал:

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

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
В 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

 

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
В 08.09.2018 в 01:27, zhekius сказал:

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, nkusnetsov сказал:

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

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

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

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


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

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

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


Ссылка на сообщение
Поделиться на других сайтах
В 7.9.2018 в 21:27, zhekius сказал:

 

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

 

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

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

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

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


Ссылка на сообщение
Поделиться на других сайтах
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

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

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


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас