Jump to content
Калькуляторы

msdt

Активный участник
  • Content Count

    163
  • Joined

  • Last visited

1 Follower

About msdt

  • Rank
    Студент
  1. DAC-кабели длиной в метр-два не намного толще оптических паткордов. Вот если более длинные - то да, там кабель чуть ли не в сантиметр диаметром.
  2. В крайнем случае лампу ДРЛ можно зажечь и без дросселя, достаточно просто включить последовательно что-нибудь, ограничивающее ток. Хотя бы лампу накаливания. Только мощность подбирать придется.
  3. И тут закрались смутные сомнения действительно ли это так?  Параметр Distance у маршрута не имеет отношения к балансировке, поэтому в статье явная дезинформация.
  4. Саппорт Mikrotik предложил мне в похожем случае выяснить, что пишется в консольный порт при самопроизвольном ребуте. Видимо там должна быть какая-то расширенная информация о его причинах.
  5. Свич по Shift+6 при загрузке не входит в режим, в котором можно сбросить конфиг в дефолтный?
  6. Насколько я понял, там все заточено под конкретную задачу создания VRRP-кластера, и конфиг просто полностью копируется с активного устройства на бэкапное. Тот скрипт, который я сделал, позволяет манипулировать конфигами более избирательно.
  7. Имеет смысл проверить, включен ли RTCP и не блокируется ли его трафик. Некоторые ip-атс рвут соединения по таймауту, если ожидают RTCP-пакеты и не получают их.
  8. Есть два микротика, один из которых основной, другой резервный. Основной я настраиваю любым удобным мне способом. Через промежуток времени, заданный в cron, на резервный накатываются те настройки, что были сделаны на основном. При этом учитывается, что какие-то секции или конкретные настройки в них защищены от изменения (аналог модификатора protect в Junos). Также при этом переносятся только реально сделанные изменения, а не вся конфигурация целиком. Как бы Ansible помог бы решить данную задачу?
  9. Скрипт вообще-то к VRRP отношения не имеет, это только пример задачи, где он может быть использован. Именно для VRRP у меня тоже есть скрипты, которые отслеживают состояние VRRP интерфейсов, и предотвращают ситуацию, когда VRRP на разных физических интерфейсах оказываются на разных роутерах, но они плотно "завязаны" на конкретную сетевую конфигурацию, поэтому вряд ли могут быть использованы где-то еще.
  10. По рабочей необходимости написал скрипт для копирования изменений в конфигурации с одного устройства RouterOS на другое по SSH. Мне понадобилось найти решение для автоматической синхронизации конфигов двух роутеров, работающих как кластер VRRP, и т.к. ничего подходящего найти не удалось, создал свое. Логика работы в первом приближении следующая: скрипт подключается к роутерам по ssh, получает конфиги с помощью команды 'export', сравнивает их между собой и конструирует скрипт, который описывает только изменения, после чего через ssh выполняет его на целевом роутере. Предусмотрена возможность работать только с определенными секциями конфигурации, а также игнорировать помеченные специальным комментарием линии. Кроме того, вместо работы напрямую через ssh можно считывать конфигурации из файлов и записывать в них. Скрипт написан на Perl, для работы требуется linux, стандартные утилиты и модули Perl, а также либо модуль Net::SSH::Perl, либо утилиты ssh и sshpass (в последнем случае отображение вывода ошибок роутера работает хуже). Возможно кому-нибудь это пригодится, исходник здесь - https://github.com/dsterentyev/mt_sync/
  11. vtund вроде подходит под требования
  12. Если вынести сервер в отдельную подсеть, отличную от той, где находятся клиенты, то source-nat для трафика от клиентов к серверу можно будет отключить, оставив только destination-nat. Тогда сервер будет видеть реальные ip клиентов вне зависимости, в интернете они или в локальной сети. А если они в одной подсети, и к серверу обращаются по внешнему ip, то задача нерешаема, т.к. если нет source nat, то обратный трафик от сервера к клиентам пойдет напрямую, а не через Mikrotik. Еще один, совсем плохой способ обойти проблему - прописать всем в hosts сопоставление dns ->внутренний_ip сервера.
  13. идея была в том, чтобы с помощью netwatch отслеживать падение линка на локальном интерфейсе.
  14. В последних версиях RouterOS ip-адрес на интерфейсе продолжает пинговаться, даже если линка в дауне. Интересно, это баг или официально объявленное изменение поведеения?