Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • 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
    IPv6 ping не отвечает — проблема в моей настройке?

    IPv6 ping не отвечает — проблема в моей настройке?

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    IPv6 ping не отвечает — проблема в моей настройке?, RouterOS
     
    hypernik
    Guest
    #1
    0
    15.07.2016 21:56:00
    Я постепенно начинаю разбираться с IPv6, но пока испытываю трудности с настройкой на 1100AHx2. В разделе IPv6 > DHCP Client для WAN-интерфейса я добавил и включил запись, настроив запрос префикса и адреса. Опции Use Peer DNS и Add Default Route активированы. После применения изменений WAN-интерфейс получил IPv6-адрес и префикс /64 от шлюза Comcast. Пока всё нормально.

    Далее я вручную добавил IPv6-адреса на 2 LAN-интерфейса (разные подсети), вписал только 64-битный префикс в поле адреса и отметил опции EUI64 и Advertise. После применения настроек сгенерировался и присвоился IPv6-адрес с префиксом и EUI64. WAN и два LAN-интерфейса уже имели линк-локал (fe80) адреса (появились автоматически, похоже). Три глобальных одноадресных (unicast) адреса на WAN и двух LAN портах все используют один и тот же префикс /64.

    С RB (Через Tools > Ping) я без проблем пингую известный «онлайн» IPv6-адрес (Google DNS сервер): 2001:4860:4860::8888. Стандартная запись в IPv6 > ND кажется работает нормально. IPv6-клиенты в наших LAN автоматически генерируют корректные глобальные одноадресные адреса с использованием рекламируемого префикса (тот же /64, что на LAN и WAN интерфейсах RB).

    С IPv6-клиента я могу пинговать другие IPv6-клиенты в LAN, используя как глобальные одноадресные, так и локальные линк-адреса. Также могу пинговать с клиента линк-локал адрес LAN-интерфейса на RB, но не могу пинговать глобальный одноадресный адрес этого LAN-интерфейса. С клиента попытки пинговать известные «онлайн» IPv6-адреса, например Google DNS, заканчиваются сообщением «Request timed out».

    С RB попытки пинговать линк-локал адреса LAN-клиентов иногда проходят, но чаще нет (в выводе Ping ничего не появляется там, где ожидается ответ). В какой-то момент казалось, что помогает сначала с клиента пропинговать RB (линк-локал адрес), а потом уже в обратную сторону, но это не стабильно.

    Похоже, что моя IPv6-настройка (маршрутизация?) нуждается в корректировке. Буду признателен за любые советы и рекомендации!
     
     
     
    hypernik
    Guest
    #2
    0
    13.08.2016 22:16:00
    Отвлёкся на другие дела и наконец вернулся к этому. Теперь, после того как включил IPv6 DHCP Client с подсказкой префикса 60 и пула префикса 64, ничего не получаю. Просто пишет статус: поиск.
     
     
     
    ZeroByte
    Guest
    #3
    0
    19.08.2016 16:45:00
    Твои настройки DHCPv6-клиента совпадают с моими (хотя, конечно, интерфейс у меня другой). Просто уточню — твой кабельный модем не работает как роутер, да? Если модем в режиме мостика, тогда, на мой взгляд, следующий шаг — запустить сниффер пакетов, чтобы проверить, действительно ли отправляются DHCPv6-запросы, и посмотреть, есть ли ответы, на которые роутер не реагирует. На самом деле, запустить это было совсем несложно. Вот вся моя конфигурация IPv6 (фаервол чуть подкорректирован, чтобы убрать цепочку с порт-кнокингом, которая к базовой работе, в принципе, не относится):

    /interface 6to4  
    add !keepalive mtu=1480 name=6to4relay  

    /ipv6 address  
    add from-pool=Comcast interface=LAN  

    /ipv6 dhcp-client  
    add add-default-route=yes interface=ether6 pool-name=Comcast prefix-hint=::/60 request=prefix use-peer-dns=no  

    /ipv6 firewall address-list  
    add address=xxx:xxxx::/32 list=Whitelist  

    /ipv6 firewall filter  
    add action=accept chain=forward comment="Allow existing connections" connection-state=established,related  
    add action=accept chain=forward protocol=icmpv6  
    add action=accept chain=forward comment="Allow whitelisted hosts and networks" src-address-list=Whitelist  
    add action=drop chain=forward comment="Block Internet from new inbound connections." in-interface=ether6  
    add action=accept chain=input comment="Allow Existing Connections" connection-state=established,related  
    add action=accept chain=input comment="Permit ICMP" log-prefix="" protocol=icmpv6  
    add action=accept chain=input comment="Trust Whitelisted Hosts" log-prefix="" src-address-list=Whitelist  
    add action=accept chain=input comment="Allow DHCPv6 replies on WAN from link-local" dst-address=fe80::/16 dst-port=546 in-interface=ether6 protocol=udp src-address=fe80::/16  
    add action=drop chain=input comment="Block New Connections from Internet" in-interface=ether6 log-prefix=""  
    add action=drop chain=input comment="Block New Connections from Internet" in-interface=6to4relay log-prefix=""  
    add action=drop chain=forward comment="Block Internet from new inbound connections." in-interface=6to4relay  

    /ipv6 nd  
    set [ find default=yes ] advertise-dns=yes

    /ipv6 route  
    add distance=1 dst-address=2002::/16 gateway=6to4relay scope=10  
    add comment="unreachable route for 6to4 block of current IPv4 address" distance=1 dst-address=2002:xxxx:xxxx::/48 type=unreachable  

    Можешь спокойно игнорировать всю эту 6to4-лабуду. Она нужна только для того, чтобы, если вдруг общаюсь с чем-то в блоке 2002::/16, пакеты шли напрямую на IPv4-адрес, ведь у меня в роутере есть и IPv4-соединение. (Для тех, кому интересно: этот интерфейс практически никогда не активен, но это и понятно.)
     
     
     
    hypernik
    Guest
    #4
    0
    20.08.2016 00:59:00
    Шлюз Comcast («модем») настроен, насколько я понимаю, в так называемом псевдо-режиме моста. В настройках шлюза Comcast установлена галочка «Disable Firewall for True Static IP Subnet Only» (Отключить фаервол только для настоящей статической подсети IP). Насколько я понимаю, наш статический IPv4 не будет работать в режиме настоящего моста. В Wireshark я вижу повторяющиеся DHCPv6 запросы и ответы на них — от RouterBoard и шлюза SMC Comcast соответственно. По пакету запроса видно, что RouterBoard запрашивает или намекает на префикс /60. Все ответы с рекламой имеют код статуса 6 — «Нет доступных префиксов для этого интерфейса». Согласно этому посту на форуме Xfinity, возможно, мне нужно связаться с поддержкой Comcast, чтобы решить вопрос. Спасибо!
     
     
     
    ZeroByte
    Guest
    #5
    0
    22.08.2016 13:55:00
    Тебе стоит позвонить в техподдержку и разобраться с этим вопросом. Похоже, у тебя бизнес-услуги Comcast… а это немного иначе. «Псевдомост» — забавно. На самом деле это просто пересылка IP. Наверное, у них в роутере есть один или несколько префиксов /64 (давайте признаем — модем на самом деле роутер, а не мост — фррр) и они ожидают, что ты просто будешь использовать SLAAC и подключаться таким образом. Роутеры не могут применять SLAAC для своей работы, поэтому нужно у них спросить: сколько префиксов ты можешь иметь НА СВОЁМ РОУТЕРЕ (не у них, а у себя). Если не выдаёт по DHCPv6, то Comcast должен настроить маршрутизацию твоих префиксов к тебе через статический маршрут со своей стороны. В качестве следующего хопа маршрута они могли бы использовать твой линк-локальный адрес. Если пойдёшь этим путём, помни, что MAC-адрес важен: если вдруг сменишь роутер, нужно будет поставить тот же MAC-адрес на WAN-интерфейс нового, чтобы линк-локальный адрес остался прежним. Если же они предпочитают маршрутизировать на публичный IPv6-адрес, тогда нужно вручную назначить этот адрес на WAN-интерфейс и попросить их маршрутизировать блок на твой WAN-адрес.
     
     
     
    akey
    Guest
    #6
    0
    13.10.2023 07:27:00
    Я знаю, что это старая тема, но возможно кто-то будет искать решение такой же проблемы, с которой столкнулся я прошлой ночью… В моём случае конечные эффекты были почти точь-в-точь как описал автор темы: Хосты в одной подсети (локальной сети) нормально получают локальный и глобальный IPv6. Они могут пинговать друг друга по локальному и глобальному IPv6 без проблем, но пинг или любой другой доступ к внешнему глобальному IPv6 изначально не работают. Обратите внимание на выделенное «изначально», потому что это важно! По сути, я выяснил, что как только маршрутизатор успешно записывает хост в таблице обнаружения соседей IPv6 (neighbor discovery), пинги к внешнему ресурсу (например, ipv6.google.com) начинают работать! Я смог повторять это каждый раз, меняя настройку конфиденциальности интерфейса моего тестового хоста с «по умолчанию» на «отдавать предпочтение временным адресам». Это важно, потому что в отличие от ARP в IPv4, на MikroTik нельзя очистить кэш ND (neighbor discovery). Из-за этого хост генерирует новый IPv6-адрес каждый раз при поднятии интерфейса, и тогда у маршрутизатора этого адреса нет в кэше ND, из-за чего пинги сначала не проходят. Итак, когда у вас появится новый неподкешированный адрес IPv6 на хосте, вы пингуете, например, ipv6.google.com, и видите, что пинги не проходят. Тем временем вы пингуете глобальный IPv6-адрес маршрутизатора, и это заставляет его «заметить» (обнаружить) новый IP, записать его, и, как по волшебству, пинги начинают проходить. Оказалось, что проблема вызвана включённым «IGMP snooping» на мосту LAN. Как только я выключил эту функцию, всё сразу заработало. Подсказку я нашёл здесь http://forum.mikrotik.com/t/ipv6-neighbor-status-failed/135912/1, так что, надеюсь, это поможет тем, кто столкнётся с похожими проблемами.
     
     
     
    Aerowinder
    Guest
    #7
    0
    19.01.2024 15:16:00
    Спасибо за совет по IGMP snooping! У меня из-за него совсем ломалась связь на каскадно соединённых коммутаторах, когда пытался запинговать IPv6 DNS Google.
     
     
     
    anovojr
    Guest
    #8
    0
    19.01.2024 17:27:00
    Твоя настройка кажется довольно надёжной, но, может, стоит проверить, не конфликтует ли файрвол RB с IPv6. Ещё пробовал сделать трассировку, чтобы понять, где именно затык с пингом? Иногда это проблема маршрутизации.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры