zhekius Posted August 14, 2018 Добрый день! Есть такая схема: С помощью какой технологии можно равномерно загружать сессиями все EoIP от рабочих станций до сервера? При этом учитывать, что скорость меняется время от времени? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
maxkst Posted August 14, 2018 Вы уверены, что в вашей схеме использование N-ного количества EoIP туннелей обосновано? Напрашивается PCQ queue, но сначала схемку бы уточнить Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted August 15, 2018 (edited) 19 часов назад, maxkst сказал: Вы уверены, что в вашей схеме использование N-ного количества EoIP туннелей обосновано? Напрашивается PCQ queue, но сначала схемку бы уточнить Добрый день. Не вопрос. Что конкретно уточнить? И с какого места? Edited August 15, 2018 by zhekius Ну или вот так, что-ли... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted August 15, 2018 В 14.8.2018 в 19:17, zhekius сказал: С помощью какой технологии можно равномерно загружать сессиями все EoIP от рабочих станций до сервера? При этом учитывать, что скорость меняется время от времени? Может развернуть на соединениях VRRP? С балансировкой загрузки? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
HarDik Posted August 16, 2018 Bonding? работает на 2х точно... на 4 думаю тоже будет... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted August 16, 2018 (edited) Балансировать соединения L2 на таких разных каналах - плохая идея. Роль играет не только скорость, но и задержка и mtu Edited August 16, 2018 by nkusnetsov Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
HarDik Posted August 16, 2018 тогда костыли, нормальных решений нет... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted August 16, 2018 (edited) Это странное кроилово, имея каналы от 10 и от 20Мбит/с - пытаться одновременно подключить еще ненадёжные каналы от 1Мбит/с, назначение которых разве что backup. Такое кроилово приведет к попадалову. Edited August 16, 2018 by nkusnetsov Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
HarDik Posted August 16, 2018 Наверно какие нить каналы от моб. Операторов , 3g ,4g.. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted August 16, 2018 4 часа назад, HarDik сказал: Наверно какие нить каналы от моб. Операторов , 3g ,4g.. И такие есть. Через них также прокладывается EoIP. Вот к этому и вопрос про способы загрузки того, что есть. Только не пакетно, а сессиями... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted August 16, 2018 OSPF поднять по всем каналам и перейти на L3 транспорт. Тогда можно даже медленные каналы использовать. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
pingz Posted August 16, 2018 @Saab95 и по верх наложить mpls ))) З.ы. Тс всегда есть возможность, завести полноценный интернет, хотя бы тот же wi-fi Имхо не стоит писать против ветра. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
maxkst Posted August 17, 2018 Поддерживаю идею 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/ Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted August 17, 2018 В 16.08.2018 в 21:36, Saab95 сказал: OSPF поднять по всем каналам и перейти на L3 транспорт. Тогда можно даже медленные каналы использовать. Бред. OSPF даст ECMP-маршрут. Для балансировки/загрузки L2 линка это будет фейл. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
maxkst Posted August 17, 2018 В случае с Transit Fabric любая полоса сначала нарезается на кусочки равной ширины, а потом equal cost присваивается каждому отдельному кусочку Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted August 18, 2018 (edited) 14 часов назад, maxkst сказал: В случае с Transit Fabric любая полоса сначала нарезается на кусочки равной ширины, а потом equal cost присваивается каждому отдельному кусочку Это для стабильных каналов. В приведённой схеме, линки 1 и 2 имеют случайный 20 кратный разброс по пропускной способности. И ваша методика становится неприменимой. Если же исходить из минимальных значений, то имея альтернативные каналы 30+10 Мбит/с, нет смысла прицеплять еще и 1+1 Мбит/с Edited August 18, 2018 by nkusnetsov Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
adron2 Posted August 18, 2018 Технология называется SD-WAN. Делает именно то, что вам нужно. Сколько вам необходимо ГАРАНТИРОВАНОГО канала между этими точками? 40 мегабит хватит? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted August 20, 2018 В 18.8.2018 в 17:02, adron2 сказал: Технология называется SD-WAN. Делает именно то, что вам нужно. Сколько вам необходимо ГАРАНТИРОВАНОГО канала между этими точками? 40 мегабит хватит? Вполне хватит. Следовательно, вопрос: как при наличии текущих условий (см. начало) можно развернуть данную систему? Я имею ввиду, мне как-то на RouterOS это наложить получиться? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
adron2 Posted August 20, 2018 2 часа назад, zhekius сказал: Вполне хватит. Следовательно, вопрос: как при наличии текущих условий (см. начало) можно развернуть данную систему? Я имею ввиду, мне как-то на RouterOS это наложить получиться? Никак. РоутерОС не умеет SD-WAN. И вряд ли когда то будет уметь. Нужно менять прошивку на OpenWRT и использовать софт который это умеет. Софт закрытый и платный. Весь вопрос на сколько вам это нужно и экономически оправдано и соответственно сколько вы готовы за это заплатить. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted September 7, 2018 (edited) В 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted September 9, 2018 В 08.09.2018 в 01:27, zhekius сказал: Добавляю два интерфейса на один шлюз по умолчанию - хрен! Почитайте еще раз, что я выше написал. Так и будет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted September 9, 2018 7 часов назад, nkusnetsov сказал: Почитайте еще раз, что я выше написал. Так и будет. если про ECMP, то ясно. Ситуация с 93.157.173.6:1935 не понятна. Вопрос, конечно, уходит в плоскость балансировки трафика именно для этого адреса, который отказывается работать с ECMP. К другим видам трафика (http и прочие нагрузки) вопросов нет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted September 9, 2018 Что бы OSPF работало правильно, адресация устройств должна быть уже на интерфейсах OSPF за транзитным. Если вы создаете интерфейсы и вешаете в них адреса камер, то и работать все должно без проблем по любому порту, при отсутствии связи (обрыве одного канала), связь повторно устанавливается по резервному, ведь в этом случае 40 секунд связь может отсутствовать (настраивается в настройках). Тут уже надо смотреть на само ПО, которое с камерами работает, и нет ли где-то на каком-то микротике фильтров, по которым некоторый трафик обрубается. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted September 10, 2018 В 7.9.2018 в 21:27, zhekius сказал: Может где-то маршруты замыкаются для этого видеопотока? Ну, в смысле, рекурсия какая-нибудь. Или обязателен контроль трафика (куда ушел-оттуда пришел)? Чего-то не догоняю я. Подскажите. Прошёл по цепочке формирования трафика. Косячок-с у меня где-то в туннелях. Прикол в том, что этот фидеопоток по 1935 порту не идет ни через EoIP, ни через IPIP, ни через GRE. Прикольно получается... Через L3-маршрутизацию видео проходит. Как отследить, в чем проблема? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhekius Posted September 10, 2018 (edited) 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...