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

zhekius

Пользователи
  • Публикации

    25
  • Зарегистрирован

  • Посещение

1 подписчик

О zhekius

  • Звание
    Абитуриент
    Абитуриент

Посетители профиля

Блок посетителей профиля отключен и не будет отображаться другим пользователям

  1. Можно ли самого Микротика отправить в сон и разбудить другим Микротиком по функции WoL?
  2. Имеется RBM33G и модем QUECTEL EP06-E. (см. рис.) Версия ROS 6.44beta9 Проделаны все операции, чтобы превратить его интерфейс из USB3.0 в USB2.0 (на рисунке выделены красным квадратом ножки, которые нужно заклеить PCI-E pins 23, 25, 31, 33) В системе после всех манипуляций (в режиме ppp модем переведен в режим at+qcfg="usbnet",1 ), после переключения Ignore DirectIP Modem в Sysytems -> Ports определяется как lte1. Всё хорошо, всё по плану, DHCP и все маршруты по умолчанию добавляются. Но связи с 8.8.8.8 нет. Включаем логирование lte-интерфейса. В итоге постоянно показывает, что вроде бы всё нормально. К слову сказать, один раз у меня запустилось и были показаны великолепные результаты. Но к сожалению, на радостях, не помню на какой из версии ROS всё это было (я перепробовал уже все и повторить те условия не смог). На версии ниже 6.42 lte1 не соединяется и выдает такую ошибку (красный шрифт): В версиях ниже 6.42 модем не определяется (в принципе, в документации так и описано). Подскажите, что поменять, чтобы пошёл пинг. Вот бьюсь уже второй день к ряду, и не как не въеду, что же не так. P.S.: слоты в норме, модемы в норме. Проверял на R11e-LTE - всё ОК.
  3. Друзья! Вы не поверите... Несколько раз, ведь, прозвучал этот порт -1935. И туннели не причем, как оказалось. Обилие dst-nat запутало следы расследования...Но способ полного сноса и поэтапного повторения схемы - один, наверное, из самых проверенных. Проблема, как всегда, банальна - этот видеопоток на порту 1935 попадал под dst-nat на порт 1935 и переадресовывался во внутрь. Ну и все из этого исходящее. Однако, всем огромное спасибо за развернутые комментарии. P.S. Всем рекомендую максимально информативно зарисовывать и комментировать все ваши технические решения. Чем больше и детальнее схема - тем лучше... Кто знает, может в этих ваших записях кроется кандидатская...
  4. Идем дальше. Отключил все туннели. Проверял на OVPN и SSTP. Тот же сайт для экспериментов: http://camera.avk-wellcom.ru/get-camera-map/95/. Выбирается любая активная камера... Итог такой же: все сайты, которые я нашел - норм. Этот капризничает. Схема для проверки: P.S. Да, в общем-то, без VPN-ов от белого до белого айпи бросил EoIP. Не прёт связь с этими видеокамерами. Странно...
  5. Прошёл по цепочке формирования трафика. Косячок-с у меня где-то в туннелях. Прикол в том, что этот фидеопоток по 1935 порту не идет ни через EoIP, ни через IPIP, ни через GRE. Прикольно получается... Через L3-маршрутизацию видео проходит. Как отследить, в чем проблема?
  6. если про ECMP, то ясно. Ситуация с 93.157.173.6:1935 не понятна. Вопрос, конечно, уходит в плоскость балансировки трафика именно для этого адреса, который отказывается работать с ECMP. К другим видам трафика (http и прочие нагрузки) вопросов нет.
  7. "поднял" на данной схеме OSPF - прикольная штука, этот OSPF. Дополнительно отстроил выход в Интернет под одним айпи на сервере. Тоже забавно получается - подхват отвалившихся потоков ну и т.д. Всё удовлетворяет...почти всё, блин. Оказывается, в маршрутах с несколькими интерфейсами строится ECMP (меня это устраивает), но не устраивает протокол RTMP по 1953 порту. Затыкается он и никак не дружит с ECMP. Причем, проверял на отдельном микротике, не связанном с данной схемой, с двумя выходами в сеть Интернет. Шлюз по умолчанию 0.0.0.0\0 - на любой рабочий интерфейс ставлю - видеопоток идет (см. картинки). Добавляю два интерфейса на один шлюз по умолчанию - хрен! Именно затывкается видео. Всё остальное работает, просто кайф!!! В случае одного шлюза по умолчанию: В случае второго картинка висит и не запускается. Всё остальное, что я хотел (видеокамеры по отдельным IP-адресам, все http-запросы и прочая "требуха" - всё нормально. По крайней мере, не нашел я, что не работало бы на ECMP. Может где-то маршруты замыкаются для этого видеопотока? Ну, в смысле, рекурсия какая-нибудь. Или обязателен контроль трафика (куда ушел-оттуда пришел)? Чего-то не догоняю я. Подскажите.
  8. Вполне хватит. Следовательно, вопрос: как при наличии текущих условий (см. начало) можно развернуть данную систему? Я имею ввиду, мне как-то на RouterOS это наложить получиться?
  9. И такие есть. Через них также прокладывается EoIP. Вот к этому и вопрос про способы загрузки того, что есть. Только не пакетно, а сессиями...
  10. Может развернуть на соединениях VRRP? С балансировкой загрузки?
  11. Добрый день. Не вопрос. Что конкретно уточнить? И с какого места?
  12. Добрый день! Есть такая схема: С помощью какой технологии можно равномерно загружать сессиями все EoIP от рабочих станций до сервера? При этом учитывать, что скорость меняется время от времени?
  13. Убирал Bridge'ы и сделал так... Скорость между IP-шниками на концах EoIP1 и EoIP2 нормальная (как было выше) Думаю дальше...
  14. Ставил галочки. Всё хорошо. Скорость такая же, как и без галочки. Мысль. Но связь по OVPN (как в режиме IP, так и в режиме Ethernet) показала себя лучше чем SSTP. Насчет маршрутизации - она есть, но служит для прокладывания EoIP - по схема от mAp 2nD и RBM33G до CCR-1036. Тест Bandwidth через маршрутизацию проводил - результаты такие же хорошие. Но версию по исключению EoIP из схемы для проверки видеопотока отработаю. Отпишусь. (Хотя, скепсис, конечно...) Но ведь через BANDWIDTH нормуль скорость! Как-то можно TCP пакеты с камеры сделать соответствующими TCP-пакетам Bandwidth? P.S. Хотя, справедливости ради, видео с сайтов открывается нормальненько... (в зависимости от радиоволн LTE-оператора, которые время от времени ветром сдувает...)
  15. Имеется вот такая схема. EoIP проброшен через OVPN сервер, расположенный на Mikrotik CCR-1036. Не вдаваясь в детали реализации, скажу, что если вместо LTE - соединение к Интернету происходит по проводам, то всё фурычит как надо в соответствии с BWServer'ом и BWTester'ом. По LTE BandWith работает вполне исправно! и выдает нужные скорости в соответствии со скоростями модемов. НО! При подключении клиента к камере в режиме LTE, видеопоток (TCP - 554 порт) тянет слабо сквозь тунели и скорость ваще не дает!! Справедливости ради, протестировал всякие видеопотоки и со всех параметров. Проверил работу с ноутбука (10.10.10.199) до SMB-сервера (10.10.10.2). ТО ЖЕ САМОЕ! Низкая скорость. Что бы это могло быть? Пинги-шминги всё отрегулировал. У LTE MTU - 1500. У OVPN MTU - 1450 У EoIP MTU - 1408