+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблема с ЦАП i40e

Проблема с ЦАП i40e, RouterOS

rpress

Guest

15.08.2020 17:53:00

Версия 7.1beta1 CHR x86 Используя драйвер i40e, поднимите интерфейс с уже вставленным и подключенным DAC. Интерфейс не отображает «линк в порядке». DAC необходимо убрать и снова вставить, чтобы порт заработал. /interface ethernet
set [ find default-name=ether6 ] mtu=9100 name=ether6 Я заметил проблему при использовании драйвера i40e. Мой адаптер — Intel X710-DA4. С DAC в порту SFP+ интерфейс не отображает «линк в порядке», когда он активируется. DAC нужно убрать и снова вставить, чтобы порт заработал. У меня также есть модуль LR (Edimax MG-10GAS1), и, что интересно, с ним таких проблем нет. Проблема возникает как при загрузке роутера, так и если я вручную отключаю и включаю интерфейс. Порт показывает, что он получает байты, но передача отсутствует. Неудивительно, ведь он считает линк отключенным. # ИМЯ RX-БАЙТ TX-БАЙТ RX-ПАКЕТ TX-ПАКЕТ R T TX-QU R T
7 RS ether6 3 972 0 66 0 0 0 0 0 0 Я не замечал этой проблемы при использовании Linux. Вот мой DAC из ethtool: Идентификатор : 0x03 (SFP)
Расширенный идентификатор : 0x04 (GBIC/SFP, определенный по 2-важному интерфейсу ID)
Разъем : 0x21 (Медный отвод)
Коды трансиверов : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0x00
Тип трансивера : Пассивный кабель
Кодирование : 0x00 (не указано)
Бр, Номинальный : 10300MBd
Идентификатор скорости : 0x00 (не указано)
Длина (SMF,км) : 0км
Длина (SMF) : 0м
Длина (50um) : 0м
Длина (62.5um) : 0м
Длина (медный) : 1м
Длина (OM3) : 0м
Пассивная Cu соответствие. : 0x01 (SFF-8431 приложение E) [Только для SFF-8472 rev10.4]
Имя производителя : CISCO-MOLEX
ОUID производителя : 00:09:3a
PN производителя : 74752-9519
Ревизия производителя : 09
Значения опций : 0x00 0x00
Граница BR, макс : 0%
Граница BR, мин : 0%
Код даты : 120917

rpress

Guest

21.09.2020 12:02:00

Эта проблема остается неизменной в версии 7.1beta2. Я также попробовал несколько различных SFP+ медных трансиверов. У них тоже есть эта проблема. Моя теория заключается в том, что существует состояние гонки со статусом ссылки. Когда используется LR оптический трансивер (тот, который работает нормально), ссылка поднимается немного медленнее. Эта дополнительная задержка времени позволяет программному обеспечению Mikrotik зарегистрировать статус ссылки как "все в порядке". А с DAC и медными трансиверами ссылка появляется быстрее, что приводит к тому, что программное обеспечение Mikrotik не фиксирует переход статуса ссылки.

rpress Guest	#3 0 08.12.2020 21:02:00 Эта проблема все еще существует в 7.1beta3.

rpress Guest	#4 0 11.02.2021 11:15:00 Эта проблема по-прежнему существует в версии 7.1beta4.

krafg Guest	#5 0 11.02.2021 19:40:00 Свяжитесь напрямую с поддержкой MikroTik. С уважением.

Spring00 Guest	#6 0 02.01.2023 16:04:00 У меня такая же проблема в 7.7rc3, есть ли какие-то успехи?

Spring00

Guest

29.01.2023 17:36:00

Я заметил, что в 7.8beta2 есть следующие обновления: *) x86 - добавлена поддержка TP-Link TG-3468; *) x86 - исправлена поддержка SR-IOV для сетевой карты Intel X710; *) x86 - улучшена поддержка 10G SFP модуля Intel 500 серии; *) x86 - улучшена стабильность для сетевой карты Intel X550 серии с SR-IOV; Но, к сожалению, когда я пробрасываю сетевую карту x710 в chr на платформе pve 7.3-3, у меня все еще та же проблема.

Spring00

Guest

29.01.2023 17:38:00

Я заметил, что в обновлении 7.8beta2 следующие изменения: *) x86 - добавлена поддержка TP-Link TG-3468; *) x86 - исправлена поддержка SR-IOV для сетевых карт Intel X710; *) x86 - улучшена поддержка 10G SFP модуля Intel 500 серии; *) x86 - улучшена стабильность для сетевых карт Intel X550 серии с SR-IOV; Но, к сожалению, когда я передаю сетевую карту x710 в chr на платформе pve 7.3-3, у меня по-прежнему та же проблема.

arm920t Guest	#9 0 30.01.2023 03:11:00 XXV710 SPF0 не удалось получить ссылку при включении. Интерфейс должен быть отключен и снова включен. Автонастройка всегда завершается неудачей.

arm920t Guest	#10 0 30.01.2023 03:14:00 IRQs являются только для чтения и не могут быть изменены вручную. RPS использует много ресурсов CPU.

irghost Guest	#11 0 04.10.2023 11:34:00 Есть какие-то новости по этому вопросу?

hoeser

Guest

#12

30.01.2024 18:41:00

Похоже, это все еще проблема даже в версии 7.13.3. Minisforum Ms-01 с X710 испытывает ту же проблему. Отключение/включение интерфейса на X86 ROS устройстве ничего не дает, но отключение/включение на CRS326 восстанавливает соединение. Все работает нормально, пока X86 устройство не будет перезагружено снова. Это очень раздражает. Я надеялся создать крутой роутер на базе RouterOS из этого устройства, но похоже, придется перейти на OpnSense или что-то в этом роде.

inteq

Guest

#13

12.04.2024 00:00:00

У меня такая же проблема с MS-01 и X710 на последнем Proxmox и passthrough. Мне приходится отключать и включать интерфейс на коммутаторе или вынимать и вставлять обратно DAC. Пробовал два DAC и два модуля SPF+ RJ45. Никакой разницы. Использую CRS312-4C+8XG в качестве коммутатора и Mikrotik XS+DA0001 DAC. Mikrotik S+RJ10 также не работает. Связался с поддержкой Mikrotik, и они посоветовали обновиться до бета-версии 7.15.х. Все равно такая же проблема. Так что, 7.14.2, все еще та же проблема.

inteq

Guest

#14

14.04.2024 17:24:00

Я нашел странный “обходной путь” для этой проблемы. Я был почти уверен, что это связано с Mikrotik CHR, но похоже, что это не так. Youtube короткая запись с проблемой и “обходным путём”: https://www.youtube.com/watch?v=Dt97NDDTiU0 Краткое описание того, что происходит на видео: Машина только что запущена. SSH на хост Proxmox и выполняю ip a, чтобы показать наличие интерфейса. Логин в веб Proxmox. Запускаю виртуальную машину Mikrotik CHR. Открываю консоль ВМ и проверяю ethernet на наличие соединения. Результат: соединения нет. Перезагружаю машину. SSH на хост Proxmox и выполняю ethtool enp3s0f0 (с watch -n1 или без него - не имеет значения). Логин в веб Proxmox. Запускаю виртуальную машину Mikrotik CHR. Открываю консоль ВМ и проверяю ethernet на наличие соединения. Результат: соединение есть. Я повторил это несколько раз, чтобы убедиться, что это не случайность. Теперь у меня совершенно нет понятия, почему просто выполнение ethtool enp3s0f0 до запуска ВМ решает эту проблему. Ничего не меняется на сетевой карте, просто отображается некоторая информация о ней. Выполнение команды после запуска ВМ выдаст ошибку, что не удается найти интерфейс, и не решит проблему. Как это автоматизировать, пока не будет найдено решение (если вообще будет): Отредактировать файл /etc/network/interfaces и добавить pre-up /usr/sbin/ethtool так: auto enp3s0f0
iface enp3s0f0 inet manual
pre-up /usr/sbin/ethtool enp3s0f0

auto enp3s0f1
iface enp3s0f1 inet manual
pre-up /usr/sbin/ethtool enp3s0f1 Нужно добавить auto enp3s0f0 и auto enp3s0f1, иначе команда pre-up не будет выполнена. Может кто-то более разбирающийся сможет прояснить это?

inteq

Guest

#15

21.04.2024 03:00:00

Забудь все, что было выше. Просто установка управления потоком RX и TX на интерфейсе CHR в режим авто решила мою проблему. (по умолчанию отключено) Странно, но в режиме /interface/ethernet/monitor 0 авто или выключено всё равно остаются выключенными, но почему-то это работает. Думаю, установка в авто меняет что-то еще.

PortalNET

Guest

#16

04.09.2024 04:43:00

Я думаю, что что-то не так с новыми драйверами ixgbe Intel, работающими на routerOS V7.1XX. Я использую bare metal x86_64 на сервере BGP с Mellanox Connect-X4 CX4121 на 2 порта и Intel X710DA4 с 4 портами SFP+, а на другом сервере PPPOE сервер с Mellanox на 2 порта и Intel i5xx с 2 портами SFP+ и 2 портами 1Gb, и подключен Intel порт i5xx, а с другой стороны BGP Intel X710. Я купил Intel GBIC 850nm и патч-корд многомодовый 3 метра. На стороне PPPOE сервера Intel i5xx автоопределение прошло на 10Gbps, но на порту Intel X710DA4 подключение есть, но автоопределение не прошло на 10Gbps. Подключение есть, трафик проходит около 2Gbps, но возникает много ошибок по TX-очереди, падения и RX-ошибки. Я поменял очереди на multi-ethernet с размером пакета 5000 на обоих серверах, но все равно остаются ошибки, что довольно странно. В то же время на BGP сервере порты Mellanox и на PPPOE сервере OLT, подключенные к портам Mellanox, ошибок нет, так что это точно с драйверами ixgbe. Также мне сказали, что прошивки моих Intel сетевых карт устарели, поэтому я зашел на сайт Intel и обновил обе карты до последней версии прошивок ixgbe 2024. Подключил их обратно к серверам, но все равно получаю те же ошибки — примерно от 5k до 200000 RX-ошибок каждые 24 часа. При этом общий трафик через сетевые карты составляет около 100000,00 GiB. Я также получил несколько карт Chelsio Quadcard T540 и собираюсь протестировать их с последними стабильными версиями v7, чтобы посмотреть, будет ли лучше. Еще одно, что я заметил, так это то, что в Ethernet-интерфейсе порты не распознаются как SFP+, а определяются как Ethernet, и поэтому мы не можем видеть диагностику на GBIC. Хотя у меня были 2 разных модели GBIC от Intel, и я тоже их протестировал, но все равно возникают RX-ошибки. Забавно, что мы оставили пинг и traceroute, работающие на BGP сервере к внешнему IP, и ни одного пакета не потеряли по пингу и traceroute, что заставляет задуматься, где именно эти RX-ошибки теряются или отбрасываются внутри локальной сети.

PortalNET Guest	#17 0 04.09.2024 21:38:00 похоже, проблема только в процессоре 0, который используется на всех очередях. В то время как другие карты от поставщиков, таких как Mellanox, Chelsio и т.д., используют автоматическое распределение нагрузки по всем процессорам.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры