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