Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Ошибка: проблема с SNMP через интерфейс VRRP

    Ошибка: проблема с SNMP через интерфейс VRRP

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Ошибка: проблема с SNMP через интерфейс VRRP, RouterOS
     
    eqo
    Guest
    #1
    0
    02.08.2016 10:33:00
    Привет! Хочу сообщить о странном багаже. Мониторинг на основе SNMP маршрутизатора Mikrotik перестал работать сразу после внедрения новой конфигурации с VRRP. Маршрутизатор R1 не отвечает на SNMP-запросы по IP-адресу, назначенному интерфейсу VRRP, если запросы приходят с сервера мониторинга S1. Вот пример команды Linux, которую я использую для проверки: root@S1:~$ snmpwalk -v1 -c public 10.28.0.> 10 Timeout: No Response from 10.28.0.10 Но всё отлично работает, если запросы идут по IP-адресу, назначенному физическому интерфейсу. Пример команды: root@S1:~$ snmpwalk -v1 -c public 10.28.0.> 8 iso.3.6.1.2.1.1.1.0 = STRING: “RouterOS CCR1036-8G-2S+” iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.14988.1 iso.3.6.1.2.1.1.3.0 = Timeticks: (7105900) 19:44:19.00 ... Проблема проявляется в SNMP-трафике, но и другой UDP-трафик не работает (например, DNS). TCP-трафик, например SSH, работает без проблем. Я тестировал на RouterOS 6.37rc11, а также 6.34.6 (только багфикс) и 6.36 (текущая), поведение всё равно одинаковое. Самое странное в этой проблеме — если поставить прямое соединение между S1 и R1, заменив R2 на кабель и при этом перенести IP-адрес R2 10.28.0.1 на S1, то всё работает даже с IP, назначенным VRRP-интерфейсу (10.28.0.10).

    Конфигурация R1 (VRRP-маршрутизатор):  
    # aug/02/2016 11:18:38 by RouterOS 6.37rc11  
    /interface vrrp  
    add interface=ether3 name=vrrp priority=150 vrid=10  
    /interface wireless security-profiles  
    set [ find default=yes ] supplicant-identity=MikroTik
    /ip address  
    add address=192.168.88.1/24 comment="default configuration" interface=ether1 network=192.168.88.0  
    add address=10.28.0.8/24 interface=ether3 network=10.28.0.0  
    add address=10.28.0.10 interface=vrrp network=10.28.0.10  
    /ip route  
    add distance=1 dst-address=10.30.0.128/30 gateway=10.28.0.1  
    /ip service  
    set api disabled=yes  
    /snmp  
    set enabled=yes  
    /system clock  
    set time-zone-name=Europe/Berlin  
    /system package update  
    set channel=release-candidate  
    /system routerboard settings  
    set cpu-frequency=1200MHz memory-frequency=1066DDR protected-routerboot=disabled  

    Конфигурация R2 (маршрутизатор подсети):  
    # jan/07/1970 19:46:59 by RouterOS 6.35.4  
    /ip address  
    add address=10.28.0.1/24 interface=ether3 network=10.28.0.0  
    add address=10.30.0.129/30 interface=ether1 network=10.30.0.128  
    /system routerboard settings  
    set cpu-frequency=650MHz protected-routerboot=disabled  

    Сетевая конфигурация сервера мониторинга:  
    ip address add 10.30.0.130/30 dev eth0  
    ip route add default via 10.30.0.129
     
     
     
    Zaesch
    Guest
    #2
    0
    23.06.2017 12:17:00
    Привет! У меня такая же проблема. DNS на интерфейсе VRRP не работает. Странно то, что он работал месяц. А с сегодняшнего утра DNS-запросы вообще не отвечаются. Настроек не меняли. Короче: клиент создает запрос и отправляет его на VRRP-адрес роутера. Пакеты доходят до VRRP-адреса, DNS-сервер на активном роутере получает DNS-информацию из интернета, кладет её в свой кеш, но на запрос клиента не отвечает. Ты уже нашел решение?
     
     
     
    Zaesch
    Guest
    #3
    0
    23.06.2017 16:12:00
    Хорошо. Я сделал небольшой тестовый стенд и связался с поддержкой Mikrotik. Может, кто-то здесь захочет разобраться с этой проблемой. Вот схема сети: Полные .rsc конфигурационные файлы для RB750GL приложены. Все роутерборды (RB750GL для тестирования) работают на последней версии ROS 6.39.2.

    Краткое описание:  
    RB_001 не получает ответа на DNS-запросы, если он обращается к RB_003 по VRRP-адресу (10.0.0.3).  
    RB_003 при этом получает DNS-запрос, забирает информацию из интернета и кладёт её в свой кэш, но не отправляет ответ RB_001.  
    Если RB_001 обращается к RB_003 по адресу ether-интерфейса (10.0.0.2), ответ приходит мгновенно, независимо от того, есть ли имя в кэше RB_003 или нет.  
    RB_002 всегда получает ответ, независимо от того, обращается ли он к RB_003 по ether-адресу (10.0.0.2) или VRRP-адресу (10.0.0.3).  
    Очень странное поведение.

    RB_001.rsc (1.47 КБ)  
    RB_002.rsc (1.15 КБ)
     
     
     
    Zaesch
    Guest
    #4
    0
    23.06.2017 16:13:00
    И файл RB_003.rsc RB_003.rsc (1,54 КБ)
     
     
     
    idlemind
    Guest
    #5
    0
    24.06.2017 01:13:00
    Попробуй назначить /32 на мост. Можно назначить один и тот же /32 на несколько устройств как loopback (без портов в мосту). Этот адрес узнаётся через протокол маршрутизации, например OSPF, и запросы будут идти к ближайшему /32 естественным образом, а при сбое переключаться на более удалённые. Пожелание: выкладывай свои конфигурации в виде обычного текста. К слову, VRRP должен отправлять трафик с IP-адреса на базовом интерфейсе, а не с общего адреса. Если у тебя есть какие-то политики безопасности или NAT, связанные с общим IP, это может усугублять проблему.
     
     
     
    troffasky
    Guest
    #6
    0
    24.06.2017 21:48:00
    Я могу назвать хотя бы одну причину, почему полезно, чтобы DNS-запросы на виртуальный IP работали — это высокая доступность. Если в настройках DHCP указать в качестве DNS-сервера IP одного из физических маршрутизаторов, что произойдет, когда этот маршрутизатор перейдет в режим отказа и переключится на другой?
     
     
     
    idlemind
    Guest
    #7
    0
    24.06.2017 23:54:00
    Прочитай мой пост. Используй /32, иначе говоря anycast. Они могут одновременно находиться в разных местах в твоей сети. Идеально подходит для DNS-резолверов и NTP-серверов. Попробуй сам. Возьми три маршрутизатора и назначь им один и тот же /32, который не входит в твою схему сети, а затем пробрось этот /32 через протокол маршрутизации, например OSPF. Это буквально то, что делает Google с нашим любимым 8.8.8.8.
     
     
     
    Zaesch
    Guest
    #8
    0
    30.06.2017 10:45:00
    Хм. Никогда не думал о решении с anycast. Звучит интересно. Тем не менее, Mikrotik ответили на мой запрос в поддержку. У них есть такое решение, и оно работает.

    /ip firewall mangle add action=mark-connection chain=input dst-address=10.0.0.3 new-connection-mark=to_vrrp passthrough=yes

    /ip firewall mangle add action=mark-routing chain=output connection-mark=to_vrrp new-routing-mark=from_vrrp passthrough=yes

    Не уверен, баг это или фича, но с этими правилами mangle работает.
     
     
     
    idlemind
    Guest
    #9
    0
    01.07.2017 02:37:00
    Отлично, рад, что вы нашли обходной путь для использования интерфейса VRRP. Если у вас возникнут вопросы по использованию loopback, дайте знать.
     
     
     
    loic69
    Guest
    #10
    0
    15.10.2017 06:40:00
    Всем привет! Просто скажите, это та же проблема, что описана ниже? У меня есть 2 роутера CCR, у каждого свой публичный IP. На интерфейсе каждого (с публичным IP) настроен VRRP-интерфейс с другим публичным IP. Когда VRRP отключен на обоих роутерах, мы можем получать SNMP с каждого CCR. Когда VRRP включен на обоих, SNMP доступен только по IP VRRP и по нативному IP “VRRP BACKUP” CCR. Нативный IP “MASTER VRRP” CCR не отвечает на SNMP-запросы… SSH работает на обоих CCR, даже если VRRP включен. Как думаете, это та же проблема? Странно, ведь вроде наоборот должно быть… Мне бы хотелось мониторить оба CCR по их нативным IP, а не по VRRP IP. Спасибо!
     
     
     
    idlemind
    Guest
    #11
    0
    15.10.2017 13:03:00
    Да, похоже наоборот. Попробуйте установить исходящий IP-адрес для SNMP. К тому же я обычно не управляю устройством по публичному IP. Обычно я разворачиваю приватную сеть управления. Это может быть VLAN, выделенная для CPE и изолированная. Я не знаю вашу конкретную топологию, но в целом неразумно выполнять функции управления через открытые сети.
     
     
     
    stralis
    Guest
    #12
    0
    16.11.2017 20:32:00
    Сегодня мы столкнулись с точно такой же проблемой. VRRP-мастер недоступен по своему уникальному адресу при использовании SNMP. Вы нашли какое-нибудь решение этой ошибки?
     
     
     
    troffasky
    Guest
    #13
    0
    17.11.2017 22:21:00
    Смотрите выше на странице: http://forum.mikrotik.com/t/bug-snmp-over-vrrp-interface-problem/100372/18
     
     
     
    pe1chl
    Guest
    #14
    0
    21.11.2017 09:55:00
    Думаю, это не связано конкретно с VRRP, у меня есть другие устройства MikroTik с несколькими IP-адресами, и когда маршрутизация становится асимметричной, SNMP-сервер иногда не отвечает. Похоже, что SNMP-сервер не отвечает с того адреса, на который приходит запрос, а отправляет ответ через нестандартный сокет, при этом исходящий адрес определяется по маршруту. Надеюсь, это когда-нибудь исправят, потому что приходится постоянно возиться с обработкой таких ошибок в таблице mangle на каждом устройстве — это не слишком удобно.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры