Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • 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
    Команда /ip/route/check исчезла?

    Команда /ip/route/check исчезла?

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Команда /ip/route/check исчезла?, RouterOS
     
    nostromog
    Guest
    #1
    0
    25.07.2020 11:26:00
    Извините, если этот вопрос уже обсуждали, я не смог его найти в гугле... Что случилось с командой /ip route check <address>? Я использовал её в нескольких скриптах, и они перестали работать после обновления до 7.1beta1...
     
     
     
    anc
    Guest
    #2
    0
    06.09.2023 09:26:00
    Как я могу отследить событие изменения immediate-gw для маршрута при переключении на резервный и отправить уведомление через tg?
     
     
     
    OlofL
    Guest
    #3
    0
    20.12.2021 13:16:00
    Как мне проверить более длинные префиксы или найти более короткий маршрут? Было бы здорово узнать, как разрешить 172.23.253.1 к маршруту в таблице. [olof@80003p-cpe002] /ip/route> print where dst-address=172.23.253.0/24 Флаги: A - АКТИВНЫЙ; s, y - КОПИЯ Столбцы: DST-ADDRESS, GATEWAY, DISTANCE # DST-ADDRESS GATEWAY DISTANCE 1 As 172.23.253.0/24 172.24.1.113 1 [olof@80003p-cpe002] /ip/route> print where dst-address=172.23.253.1
     
     
     
    mrz
    Guest
    #4
    0
    20.12.2021 13:28:00
    Как уже упоминалось ранее в этой теме, "print where x.x.x.x in dst-address" возвращает все маршруты, по которым можно разрешить данный адрес.
     
     
     
    eduplant
    Guest
    #5
    0
    12.12.2021 06:44:00
    +1 за повторную реализацию /ip/route/check. Помимо утраты своей функциональности для скриптов, его отсутствие – это большая потеря для ручной диагностики. Хотя возможно детально просмотреть таблицу маршрутизации, чтобы определить следующий хоп самостоятельно, я считаю, что это не совсем по существу. Можно сказать, что одна из основных целей команд типа "show" заключается в том, чтобы позволить оператору сравнить свою ментальную модель того, что он собирался настроить, с решением, которое принял маршрутизатор в соответствии с конфигурацией. Каждый крупный сетевой операционная система, с которой я работал (Cisco, Juniper, Arista), имеет это в составе своих команд "show" маршрутизации. У Linux даже есть такая возможность через утилиты iproute2. Примеры ниже. Разве это на самом деле сложная задача с точки зрения реализации? Особенно учитывая, что v7.1 работает на Linux 5.6.3 и, предположительно, в нем меньше внутренней обработки пакетов Mikrotik, разве получение точной информации о решениях по пересылке не должно быть проще, чем когда-либо? Может быть, и нет. Cisco/Arista: ====== show ip route [address [mask] [longer-prefixes]] | [protocol [process-id]] Juniper: ======== show route <all> <destination-prefix> <logical-system (all | logical-system-name)> [omitted extra options] Linux: ====== testhost> ip route show to match 1.1.1.1 default via 2.2.2.2 dev ens5 proto dhcp src 2.2.2.24 metric 100 testhost> ip route get 1.1.1.1 1.1.1.1 via 2.2.2.2 dev ens5 src 2.2.2.24 uid 1000 cache
     
     
     
    rekeds
    Guest
    #6
    0
    09.12.2022 09:03:00
    ouch baby, очень больно
     
     
     
    Turbid
    Guest
    #7
    0
    06.12.2021 13:20:00
    Есть ли планы реализовать эту функцию?
     
     
     
    mrz
    Guest
    #8
    0
    06.12.2021 13:28:00
    Маршрут по умолчанию установлен данным интерфейсом, поэтому установлен флаг VPN. Что касается других маршрутов, очевидно, что будет использоваться 192.168.1.0/24. Более конкретный маршрут всегда имеет предпочтение.
     
     
     
    Turbid
    Guest
    #9
    0
    07.12.2021 07:14:00
    Это сейчас невозможно использовать в скриптах. Если есть ≥ 2 маршрута, то просто посчитай маски в уме?
     
     
     
    mrz
    Guest
    #10
    0
    12.12.2021 18:24:00
    Что вы показали в своих примерах, именно это и делает команда routing/route/print.
     
     
     
    Amm0
    Guest
    #11
    0
    20.12.2021 14:45:00
    /ip/route/check дает вам один ответ. В то время как «as-value» вышеуказанного «где в dst-adress» возвращает массив. Хотя скрипт может это воспроизвести, это не так очевидно или надежно, как быстрая функция $ipcheck, которую я написал: :global ipcheck :set $ipcheck do={ :local ip2check [:toip $1] :local typeip [:typeof $ip2check] :if (typeip~"ip|ip6") do={ :local lookup [/ip/route/find where $ip2check in dst-address and active] :local lastone ($lookup->([:len $lookup]-1)) :local rv [/ip/route/get $lastone immediate-gw] :return $rv } else={ :error "\$ipcheck требует в качестве входных данных IP-адрес/диапазон" } }

    # ТЕСТ :put [$ipcheck 1.1.1.1] например, я предполагаю, что самый конкретный маршрут — последний возвращаемый, — если нет, будет еще сложнее воспроизвести /ip/route/check. Или, как предложение по улучшению, возможно, разрешить исправление недостающих команд, подобных этой, с помощью функций скрипта, таких как: :set [/ip/route/check] do={...}
     
     
     
    mrz
    Guest
    #12
    0
    20.12.2021 14:59:00
    Я знаю, что делает команда "check". Если она используется в скриптах, то ее можно заменить на routing print (как ты сам и показал). Более конкретный маршрут из массива также можно легко получить, сравнивая значения маски подсети. И примеры из Juniper, Cisco и т.д. тоже не возвращают единственный элемент. Возможно, в будущем мы добавим команду "check", но сейчас тебе придется либо использовать ROS v6, либо немного поработать со скриптами.
     
     
     
    Amm0
    Guest
    #13
    0
    20.12.2021 15:54:00
    Я не говорил, что ты не делал этого — просто подчеркиваю, что в v7 это не делает ничего, а в v6 это что-то делало. И да, автор темы хотел решение по маршрутизации с точки зрения ROS, а не все возможные варианты. Также отмечаю, что это не такая большая проблема, ведь если ты уже используешь скрипты, то использование функции может решить это довольно просто. На мой взгляд, улучшенная маршрутизация в V7 стоит тех небольших неудобств, связанных с тем, что что-то теряется. Я не думаю, что cisco "ip show" — хороший пример. На самом деле, я бы предложил попробовать использовать функции в CLI Cisco, или тот факт, что команда cisco "show" — это полная неразбериха с неконсистентностью в зависимости от того, где она используется. В ROS это всегда один и тот же синтаксис фильтров, столбцы и так далее.
     
     
     
    marcbou
    Guest
    #14
    0
    02.11.2022 19:11:00
    Я также хотел бы высказать своё мнение о том, что проверка маршрутов IP должна быть добавлена обратно. Её исчезновение — это действительно неприятная регрессия. Уверен, что речь шла о команде "ip route get" в Linux: команда ip route get получает единственный маршрут к цели и выводит его содержимое так, как оно воспринимается ядром. fibmatch возвращает полный маршрут, соответствующий таблице маршрутизации. По умолчанию возвращается разрешённая запись назначения по адресу (по умолчанию) — адрес назначения. from ADDRESS — адрес источника. tos TOS dsfield TOS — тип службы. iif NAME — устройство, от которого ожидается прибытие этого пакета. oif NAME — принудительное указание выходного устройства, через которое будет маршрутизироваться этот пакет. mark MARK — метка брандмауэра (fwmark). vrf NAME — принудительное указание устройства vrf, через которое будет маршрутизироваться этот пакет. ipproto PROTOCOL — IP-протокол, как он воспринимается при поиске маршрута. sport NUMBER — порт источника, как он воспринимается при поиске маршрута. dport NUMBER — порт назначения, как он воспринимается при поиске маршрута. Если не был указан адрес источника (опция from), повторно выполняется поиск маршрута с источником, установленным в предпочтительный адрес, полученный при первом запросе. Если используется политическая маршрутизация, это может быть другой маршрут. Обратите внимание: эта операция не эквивалентна команде "ip route show". show показывает существующие маршруты. get разрешает их и создаёт новые экземпляры, если это необходимо. По сути, get эквивалентен отправке пакета по этому пути. Если аргумент iif не указан, ядро создаёт маршрут для вывода пакетов к запрашиваемому назначению. Это эквивалентно пингу назначения с последующим "ip route ls cache", однако фактически пакеты не отправляются. С аргументом iif ядро делает вид, что пакет пришёл с этого интерфейса, и ищет путь для пересылки пакета.
     
     
     
    ChrisCCC
    Guest
    #15
    0
    25.11.2022 12:05:00
    Я бы сказал, что самой очевидной причиной вернуть /ip route check является то, что выполнение поисков в большой таблице маршрутов практически невозможно. У меня есть CCR1072, работающий на ROS7.6, который имеет 3 полные таблицы соседей (у нас есть и другие маршрутизаторы, которые также являются частью пировочных LAN, поэтому у них более крупные таблицы маршрутов). Поиск на этом устройстве занимает так много времени, что это практически не помогает в диагностических сценариях: я выполнил следующие команды и засек, сколько времени понадобилось для получения результата: /ip route print detail where dst-address=8.8.8.0/24 # 1:25 /ip route print detail where dst-address=8.8.8.0/24 and active # 1:15 /ip route print detail where 8.8.8.8 in dst-address # 1:33 /ip route print detail where 8.8.8.8 in dst-address and active # 1:31 /routing route print detail where dst-address=8.8.8.0/24 # 1:42 /routing route print detail where dst-address=8.8.8.0/24 and active # 1:11 /routing route print detail where 8.8.8.8 in dst-address # 1:21 /routing route print detail where 8.8.8.8 in dst-address and active # 1:46 Должен отметить, что у меня были случаи, когда результаты возвращались намного быстрее, чем указано выше (примерно за 15 секунд, что по-прежнему не круто), но эти случаи абсолютно непредсказуемы, и у меня было столько же случаев, когда команда вообще не завершалась (я буквально уходил заняться другими делами и возвращался через 15 минут), что заставляло меня отменять поиск.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры