gurum

Спасибо. Какую тему там надо выбрать: помощь в настройке, не указано или другое ? Остальное просто совсем не в тему.

Нет, сломалось через некоторое время само. Поработало немного и всё.

Так, дёрнуть порты коммутатора и ISIS ожил. Странная хрень, однако, но зато лечение найдено, кажется. Надо ответственным внести на вики :)

Приветствую. Спасибо за участие. Понимаю про то, что IGMP snooping реагирует на IGMP, это достаточно очевидно и тут вопросов нет. Но IGMP имеет отношение к IP мультикасту, а одним IP мультикастом дело не ограничивается - ISIS тому пример. По поводу того, что snooping не должен препятствовать всего мультиксат-трафика: на NAG WIKI, по ссылке https://nag.wiki/pages/viewpage.action?pageId=38765536 сказано буквально так: В момент включения IGMP Snooping в данной VLAN входящий multicast-трафик будет остановлен! Что я и вижу примерно. Или на WIKI имеется в виду группа 01:00:5E:xx:xx:xx, например ? То, куда мапится IP-мультикаст ? То, что коммутатор шлёт пакеты с целевым L2 мультикаст адресом (IP мультикаст - подмножество; для общего понимания: группа IP мультикаст транслируется в L2 группу 01:00:5E:xx:xx:xx) на порты, на которых есть получатели таких пакетов. Самый тупой случай, без настроек - когда получатели подразумеваются на всех портах, где VLAN прописан в ACL. Snooping предназначен для автоматического удаления получателей там, где их нет, и добавления туда, где они есть. Но предназначен только для IP мультикаст. Я подразумевал, что можно задать статическую привязку L2 мультикаст группы (IP мультикаст группу можно в SNR привязать статически, а L2 пока не знаю, как) на некий вилан и порты. Например, в документации на Cisco Catalist 3560 указан вариант для аналогичного случая: ip igmp snooping vlan 1 static 0100.5e02.0203 interface gigabitethernet0/1 Нет, ISIS и другие протоколы, не использующие IP, не будут слать никаких JOIN, в их понимании нет IGMP, и JOIN тоже отсутствует. Пока ситуация выглядит так: либо мультикаст поливает во все порты, где прописан VLAN, либо есть возможность автоматически добавлять/удалять получателей для IP мультикаста посредством протокола IGMP, но в этом случае полностью выкидывается за борт мультикаст, который не IP-мультикаст. SNR-S2985G-24T-UPS Device, Compiled on Oct 14 17:30:55 2022 SoftWare Version 7.0.3.5(R0241.0551) BootRom Version 7.2.40 HardWare Version 1.0.1 Кстати, приведу странное наблюдение, сперва конфиг коммутатора, имеющий отношение к: vlan 4094 ! Interface Ethernet1/0/14 switchport discard packet tag flow control lldp transmit optional tlv portDesc sysName sysDesc sysCap switchport access vlan 4094 ! Interface Ethernet1/0/20 switchport discard packet tag flow control lldp transmit optional tlv portDesc sysName sysDesc sysCap switchport access vlan 4094 ! ip igmp snooping no ip igmp snooping proxy ip igmp snooping vlan 4094 К портам 1/0/20, 1/0/14 подключены две циски, на которых настроено соседство ISIS. Если снупинг в вилане 4094 отключить - соседство работает. Если включить - перестаёт. Но почему-то перестаёт только на одной циске. Смотрю снифером: на порту 1/0/20 трафик ISIS мультикаст проходит, а на порту 1/0/14 - нет. Какая-то избирательная фильтрация мультикаста. На картинке в аттачменте это ether2 и ether3 - там видно прохождение пакетов. Есть способ посмотреть привязку получателей L2 мультикаст групп к портам на коммутаторе ? Ещё раз спасибо за попытку разобраться и помочь.

Привет всем. Коммутатор SNR-S2985G-24T-UPS (но, думаю, это не особо важно), в пару портов включены роутеры. а. Между роутерами ходит IP мультикст. б. Между роутерами установлено соседство ISIS Я хочу включить IGMP snooping, чтобы более адекватно коммутировать IP мультикаст. Да, это работает. Но при при этом ложится соседство ISIS, потому как оно не имеет отношения к IP и IGMP, но всё равно на уровне ethernet это мультикаст (см. картинку). Как включить IGMP snooping так, чтобы работала привязка мультикаст-адреса 01-80-c2-00-00-15 к некоторым портам, там где роутеры ? Статическую запись в mac-address-table создать не получается с таким адресом. Спасибо.

Нет сведений, сорри. Мопед не мой.

Привет. Этой информации нет, всё на столе у наших партнёров, они там морочатся. У меня информация только та, что привёл выше. Я, если найдётся желающий, дам координаты моего босса и он будет насчёт цены разговаривать. Спасибо, попробуем запустить и такой процесс.

Привет. У партнёров инженеры не могут справиться с eltex MES3324F 28-port 1G/10G Managed Switch Version: 4.0.16.5. Не могут запустить SFP модули, которые на приложенной фотке. Текст от заказчика с описанием проблемы: "Собираем на столе в одном коммутаторе в разных портах линк. Один модуль SFP 1310 нм 1G, второй 1390 нм линк работает. Меняем на другую пару модулей уже 10 G на тех же длинах волн уже не работает. Брали уже разные модули разных производителей, линк не поднимается почему-то. Порты на коммутаторе sfp+ разумеется, модули определяются, уровни сигналов отличные, но между собой линк не поднимается. По факту мне нужен комплект SFP+ 10G с длинами 1310 и 1390." Требуется спец, который бы проконсультировал по проблеме, при необходимости удалённо помог диагностировать/настроить.

Нет. На том, что отправляет LLDP - E4:8D:8C:B8:E4:29; на том, который не отправляет - E4:8D:8C:C9:F3:5E

Не отправляет пакеты. Снифером смотрю с соседнего микротика для чистоты эксперимента.

Всем привет. Хочу настроить на микротиках взаимные анонсы/обнаружения по L2 в сети ethernet. Протокол LLDP. Есть два идентичных микротика hAP-Lite, одинаковая версия ПО 6.49 (stable), соединены медным полуметровым патчкрдом. Настройки, собственно, примитивные, ошибиться трудно, но один микротик отправляет анонсы LLDP, а другой - нет. Оба принимают анонсы при этом. Настройки: /ip neighbor discovery-settings set discover-interface-list=DISCOVER protocol=lldp /interface list add name=DISCOVER /interface list member add interface=up_br list=DISCOVER /interface bridge add name=up_br protocol-mode=none /interface bridge port add bridge=up_br interface=ether1 add bridge=up_br interface=ether2 Фаерволы сброшены. LLDP, по задумке, отправляется в бридж, где находится пара медных портов, один из которых взаимно смотрит на другой микротик. Другой порт идёт куда-то дальше, тут это неважно. Вопрос: почему один из микротиков не анонсирует себя по LLDP ? Что ещё поглядеть в настройках ?

Спасибо, вот удачно про radius-mac-authentication=yes, не сообразил. ОС - ArchLinux, но сейчас в WiFi канале до сертификатов и TLS всё равно не доходит дело. И глядя в дамп WiFi понимаю, что не заводится EAP, но не догоняю, где искать. В логе микротика пусто (почти пусто, кроме общих фраз). Буду ещё пытаться понять, конечно. Если у вас будет возможность - посмотрите в дамп, там десяток пакетов, может, найдёте подсказку, буду благодарен. Ещё раз спасибо. connect.cap

Всем привет. Хочу попробовать настроить WPA2-Enterprise на микротике - просто минимальный тестовый стенд для понимания, как оно вообще. Из вариантов EAP предпочтительным вижу EAPoW TTLS-MSCHAPv2 по той причине, что не требуется сертификат пользователя, а ещё потому, что outer-tunnel (phase1), то есть шифрованный туннель TLS, строит сам микротик с клиентом wifi, а в RADIUS-сервер отправляется только inner-tunnel (phase2) запросы - собственно AUTH MSCHAPv2. Интересно вот, не ошибаюсь ли я с пониманием этого на этом этапе ? Вот коротенько настройки микротика: /interface wireless security-profiles add authentication-types=wpa2-eap eap-methods=eap-ttls-mschapv2 mode=dynamic-keys name=enterprise radius-called-format=ssid radius-mac-authentication=yes supplicant-identity=hap555 tls-certificate=hap-eap tls-mode=dont-verify-certificate /interface wireless set [ find default-name=wlan1 ] band=2ghz-b/g/n country=russia4 disabled=no distance=indoors mode=ap-bridge security-profile=enterprise ssid=eap-e wps-mode=disabled /radius add address=192.168.99.1 authentication-port=1812 called-id=eap-e secret=hap-eapow service=wireless timeout=3s Есть ещё сертификаты на микротике: самодельный CA а также сертификат с именем "hap-eap", подписанный CA и key-usage=digital-signature,key-encipherment,data-encipherment,key-agreement,tls-server - надеюсь, этих расширений x.509v3 достаточно для функционирования. Настройка клиента wpa_supplicant, линукс: passive_scan=0 country=RU p2p_disabled=1 eapol_version=2 fast_reauth=0 device_name=o_client network={ ssid="eap-e" scan_ssid=1 key_mgmt=WPA-EAP eap=TTLS identity="alice" anonymous_identity="anon-phase1" password="passme" phase2="auth=MSCHAPV2" } Дополнительно настроил на wlan0 на линуксе mon0 (monitor mode) интерфейс и захватываю там радиообмен; забегая вперёд скажу, что при попытке подключения не вижу никаких TLS сессий, сертификатов; получаю отлуп на стадии Association с точкой доступа (Status code: Association denied due to reason outside the scope of this standard (0x000c)). При попытке подключиться к точке доступа, в логе RADIUS-сервера вижу такое: (0) Service-Type = Framed-User (0) NAS-Port-Id = "wlan1" (0) NAS-Port-Type = Wireless-802.11 (0) User-Name = "F8:D1:11:12:E3:63" (0) Calling-Station-Id = "F8-D1-11-12-E3-63" (0) Called-Station-Id = "eap-e" (0) User-Password = "\354͛R\t\376\216\033e\355T^\353w\267\031" (0) NAS-Identifier = "hap_router" (0) NAS-IP-Address = 192.168.99.176 Что это ? На MSCHAPv2 не очень похоже, и имя пользователя в inner-tunnel (phase2) ненормальное какое-то: должно быть alice, а оно в виде MAC-адреса клиента; на начало EAP-сессии тоже не похоже, нет атрибута EAP-Message.. Что-то не едут лыжи. Где неправильно, подскажите, плз. Спасибо.

Понятно, спасибо

те рокеты, что у меня, они открытые и на чипе чётко читается название. Но, впрочем, я уже не уверен, что кетайцы не перепутают надпись на чипе и содержимое :)

41 точно

Внешне 1в1 как прежние. Я изначально ошибся и указал, что XW, а на деле оказались XM.

А из китая - у кого заказывали ? На али ? Там много таких чипов предлагается, но хз, что там за качество.

Я, вероятно, ошибся в самом начале этой темы: Rocket XM. Я уточню в понедельник, и, вероятно, ещё и фотку для надёжности выложу :) Сорри.

Тэкс, ремонт закончен: чипы из "рекомб" битые, из 4ip.info - норм.

ОК, спасибо за инфу.

Брали у некоего ООО "Рекомб" в Омске. Наобум совершенно - чёт и не думалось, что Atheros будет делать и продавать много битых чипов. Они, канеш, могли и на али взять. А что за парт ? Ну, я могу загуглить, просто чтобы уж не гадать, что за партс такой.

ОК, буду думать. Спасибо :) Напишу, к чему пришло в конце концов.   О, интересно. Уже было подобное с такими чипами ?

По защиту теперь стало ещё непонятнее :) OTP - однократно программируемая область ? Это не тот самый кусок 64к в конце флэша ? Он же mtd5 в линуксе ? И поясните, плз, механизм защиты. Я понял, что, а) прошивка/драйвер atheros сверяет контрольную сумму вокруг уникальнх параметров в том же mtd5, и если что-то поменяли, то начинает выгибаться б) прошивка проверяет соответствие уникального номера процессора какому-то влитому в один из уникальных параметров в mtd5. Что-то лишнее придумал или не так понял ? Прокомментируйте, плз. Далее. Недопай-непропай: потенциально может быть, но на сразу трёх девайсах ровно идентичные симптомы ?... Маловероятным кажется. Визуально пайка чистая, ровная и т.д. Менялся SoC Atheros AR7241-AH1A. Насколько понимаю, ethernet MII+PHY в самом чипе, поэтому меняли их. Суппрессоры - я их просто отпаял для начала, и, конечно, когда стало ясно, что они не влияют, то и взялись менять SoC. По поводу переменных окружения U-Boot: как я написал выше, U-Boot не даёт управление. Он печатает что-то (покаазал что именно) и немедленно ребутается. То есть, вклиниться в процесс я не могу. На исправном рокете, канеш, всё это дело бы прокатило. Благодарю за ответ.

Всем привет. Погорели от грозы Ethernet порты на трёх рокетах M5, XM (изначально решил, что XW, был неправ). Сдули феном и запяли на их место новые процессоры (SoC, то есть). На вид - идентичные. Далее в отладочном порту (UART) вижу, что u-boot не заводится. Что-то пытается делать, но консоль не отдаёт и ребутается по кругу. Вот что пишет в консоль, все три девайса ведут себя идентично: U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50) DRAM: 64 MB Flash: 8 MB PCIe WLAN Module found (#1). Net: ERROR:s26_wr_phy failed:phy:4 reg0 ERROR:s26_wr_phy failed:phy:4 reg4 ERROR:s26_wr_phy failed:phy:4 reg0 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:4 reg:0 rddata:80000000 ERROR:s26_wr_phy failed:phy:4 reg1D ERROR:s26_wr_phy failed:phy:4 reg1E ERROR:s26_rd_phy failed:phy:4 reg:11 rddata:80000000 ERROR:s26_wr_phy failed:phy:0 reg0 ERROR:s26_wr_phy failed:phy:1 reg0 ERROR:s26_wr_phy failed:phy:2 reg0 ERROR:s26_wr_phy failed:phy:3 reg0 ERROR:s26_wr_phy failed:phy:0 reg4 ERROR:s26_wr_phy failed:phy:0 reg0 ERROR:s26_wr_phy failed:phy:1 reg4 ERROR:s26_wr_phy failed:phy:1 reg0 ERROR:s26_wr_phy failed:phy:2 reg4 ERROR:s26_wr_phy failed:phy:2 reg0 ERROR:s26_wr_phy failed:phy:3 reg4 ERROR:s26_wr_phy failed:phy:3 reg0 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 ERROR:s26_wr_phy failed:phy:0 reg1D ERROR:s26_wr_phy failed:phy:0 reg1E ERROR:s26_rd_phy failed:phy:3 reg:0 rddata:80000000 Я было затеялся взять полный дамп с флэшки такого-же рокета, но с новой прошивкой - проверил, что там загрузчик поновее, и счёл, что проблема может быть в том, что, например, старый загрузчик (во флэшке) может некорректно распознать (возможно) более новый процессор. Но почитал тут темы и понял, что, видимо, мне предстоит встретиться с проблемами, вызванными защитой - типа, прошивка привязана к ID процессора. Но это, как я понимаю, будет, когда линукс запустится - если запустится. Собсна, пара вопросов: 1. Реально оживить девайс перепрошивкой с рабочего или требуется что-то ещё ? 2. Будут ли проблемы с защитой ? Заранее благодарен содержательно ответившим :)