tux-tm

Великолепно описано.В своё время более 12лет назад настраивали MSTP на связке D-Link + ExtremeОчень не хватало адекватного описания как это делать. Грабельки собрали еще и потому что у вендоров есть нюансы и докучи собрать все не всегда получается

столкнулись с проблемой когда не работает на порту это switchport mac-address dynamic maximum 1 и показывает 6 МАС-ов с отличием в последней цифре SNR-S2990G-48T#sh mac-address-table int Ethernet1/0/48 Read mac address table.... Vlan Mac Address Type Creator Ports ---- --------------------------- ------- ------------------------------------- 948 04-8d-38-8d-d3-40 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-41 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-42 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-43 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-44 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-45 DYNAMIC Hardware Ethernet1/0/48 Обновление до свежей версии ничего не дало SNR-S2990G-48T Device, Compiled on Oct 26 16:35:51 2021 ... SoftWare Version 7.0.3.5(R0102.0318) BootRom Version 7.1.41 HardWare Version R01 Починил при добавлении в конфиг mac-address-learning cpu-control Но это наверное не самый лучший вариант решения.

Спасибо за оперативный ответ - заработало по вашей рекомендации. Настройки сбрасывал когда первый раз накатывал, и перед откатом их в файлик слил, теперь снова из файлика вернул и поправил. Может Apple и исправили этот баг в новых ОС, но я не в курсе т.к. пользую еще 10.9.5 релиз. Обновиться не могу до последнего релиза по ряду причин, одна из решающих - глаза не выносят новомодный контрастный и плоский GUI...

Broadcom BCM43xx Ща еще раз накачу прошивку и проверю...

Обновил дуалбендовую модель на версию 4.8.17 и получил блокирование любого трафика через 5Ггц WiFi, хотя к беспроводке как и раньше цепляется, DHCP-адреса и даже IPv6 получает. Но ни сама железка и что-то далее за ней даже в LAN-сети недоступно. Через LAN и WiFi 2.4Ггц - нормальная связь. Причем даже со сбросом всех настроек такая хрень на открытых дефолтных SSID. Клиентский девайс MacBook, если это критично... Откатил прошивку на 4.6.8 - снова заработало.

Писать почти бесполезно. Это чистый Китай.

Спасибо, это и было причиной. Замотался и некогда было проверить. Девайсы отлично заработали после отключения мультикастовой обработки на CPE.

Коллеги, скорее всего у меня не чистый Миракаст, почитал и понял что там такой зоопарк в этих донглах - EzCast, AnyCast, MiraScreen(у меня такой) и т.д. Так что пока не напрягайтесь, сначала я помучаю сам девайс, комбинации настроек и т.п.

Тестировал всё в одном диапазоне - 2.4Гц, хотя конечно пробовал и в разных диапазонах Miracast - на 2.4GHZ, Nexus5 - на 5GHZ. Разницы никакой - точно так же Miracast сначала определяется, но после кратковременного коннекта сразу же отваливается. IP адресация была одинаковой как на старом роутере TP-Link WR1043ND HW ver1.0 , так и на D-Link DIR-620 (оба прошиты в OpenWRT 15.03) - подсеть везде одна и та же 192.168.10.0/24. Так что дело точно не в этом. И еще когда оно работает, то и Miracast (в виде HDMI-свистка в телевизоре) и Nexus одновременно имеют доступ в Интернет через роутер (TP-Link WR1043ND). То что этот протокол на стадии старта реализован через L2 и броадкаст - какие сомнения? ведь оно работает без внешнего DHCP-сервера. Там же сами устройства выступают в качестве DHCP-сервера, а DHCP-протокол как известно начинает свою работу c обмена броадкастовыми пакетами DHCP-Discover, DHCP-Offer. К тому же на стадии обнаружения Miracast устройств в сети IP-адреса WiFi-роутера точно не используются. Для WiFi-роутера весь этот трафик уж точно не является L3, но как-то же его присутствие в качестве AP эту связь нарушает. Попробую на время отключить DHCP-сервис на SNR-CPE, а не всю AP. Если причина в DHCP - это сработает.

Столкнулся с проблемой отказа в работе протокола Miracast (беспроводной экран) в диапазоне 2.4Гц. Работает оно насколько я понял без IP-адресов, чисто на уровне L2, т.е. по коммутации и наверняка там обнаружение девайса на броадкасте реализовано. Причем обнаружил это при замене старого роутера TP-Link на черненький SNR-CPE-MD1, я так понимаю это MT7610-1T1R-5GHZ ? C TP-Link всё работало нормально, а после замены на SNR подключиться не получается. Что интересно, при попытке подключиться смартфон кратковременно подключается к Miracast и сразу же связь разрывается. Но если перед подключением обесточить WiFi-роутер SNR-CPE-MD1 - то связь устанавливается и работает несмотря на то что телефон Google Nexus5 и девайс с Miracast изначально подключены как клиенты к WiFi точке доступа - всё как по шпаргалке к девайсу. Игрался разными параметрами WiFi - ничего не помогает, ни смена канала, ни стандарт WiFi - b,g,n Не могу сказать баг ли это или требуется какая-то тонкая настройка, но точно знаю что не работает именно с MT7610-1T1R. Совместно с MT7620 2.4GHZ не проверял т.к. пока нет под рукой. С роутером на OpenWRT тоже не замечено проблем. Готов предоставить удаленный доступ к роутеру, или другую посильную помощь. В Сети тезисно описана работа этого протокола так: Используя Wi-Fi direct, устройства находят друг друга (обычно — источник видео-данных находит устройство отображения) Используя ту или иную форму аутентификации (в нашем случае — pbc) устройства объединяются в P2P-группу Одно из устройств получает IP-адрес по DHCP (в нашем случае — это источник видео-данных) На источнике данных на порту 7236 запускается RTSP-сервер Клиент подключается к RTSP-серверу, и запрашивает некий предопределенный URL (/wfd1.0/streamid=0) RTSP-сервер начинает передавать видео (и, возможно, аудио) данные в форме MPEG-TS упакованных в RTP-пакеты. Клиент распаковывает данные и отображает их на устройстве вывода. Может быть связано с конфликтом/блокировкой DHCP-пакетов Miracast и WiFi-роутера ?

Если хотите понять почему в корне неверно Ваше стремление разделить IPv6 сеть на кусочки менее чем /64 - рекомендую к прочтению IPv6 для знатоков IPv4 ИМХО наиболее краткий курс практически "без воды", хоть и в некоторых местах самую малость устаревший.

До CPE с приоритезацией в частности мультикаста всё отлично (по вашей классификации сеть "нормальная"), вопрос только в том чтобы на самой CPE тот же мультикаст не похерился юзером при нагрузке портов внутренним трафиком, например в процессе копирования файлов из одного компа на другой и т.п. Но в общем я понял Ваш посыл - если трафик обрабатывается хардварно то QoS настройки лучше не включать.

Параметр называется QoS, а вы мне о шейпере пишете. Как бы это не совсем одно и то же, хотя и связанные вещи. Как посоветуете приоретизировать мультикаст на коробке при условии что он приходит уже покрашенным? Или можно смело забить на это т.к. не работает?

Firmware Version SNR-CPE-W4N-MT-4.1.2.RU.21032016 Попробовал залить параметры отдельными командами nvram_set 2860 Language ru nvram_set 2860 CHECKMAC YES nvram_set 2860 WAN_MAC_ADDR F8:F0:82:51:12:DB nvram_set 2860 ApCliSsid Test-1111 nvram_set 2860 HostName Test-1111 nvram_set 2860 SmbNetBIOS Test-1111 nvram_set 2860 SSID1 Test-1111 nvram_set 2860 WPAPSK1 F8F0825112DB nvram_set 2860 CountryCode RU nvram_set 2860 CountryRegion 5 nvram_set 2860 CountryRegionABand 0 nvram_set 2860 EncrypType AES nvram_set 2860 AuthMode WPA2PSK ... Всё применяется без вопросов и ругани, но после перезагрузки всё такая же шляпа с недоступностью коробки. Почему-то IP коробки становится недоступным, хотя судя по светящемуся SSID и успешном подключении к WiFi вносимые в коробку параметры кастомизации работают, хотя на WiFi так же не выдается адрес через DHCP. Таки придется паять UART... Кстати проверил - все вносимые мною параметры есть в дефолтном конфиге p.s. Можете сами внести параметры из файлика и посмотреть что происходит при загрузке, у меня ошибка воспроизводится на 100%.

Спасибо, я примерно так и предполагал причину потери функционала своей кастомизации. При вставке каждого параметра отдельной командой ведь количество перезаписей nvram будет равно количеству этих параметров, что по идее не так уж и хорошо. Или я не прав? Может мне лучше подождать реализации merge ?

Перестала работать ранее сделанная кастомизация для однобендовых коробок MT-7620. Конкретнее после команды вливания параметров из файла nvram_renew 2860 /etc/custom/nvram_set и последующей перезагрузки коробка теряет IP. И только сброс по кнопке её оживляет. Более точно не могу диагностировать т.к. коробка становится недоступной. причем WiFi в эфире светится и даже подключается с WPA2, но поскольку коробка на IP не отвечает (в ARP-кеше тоже нет её IP) ничего больше сказать не могу. Ранее до версии 3.3.8 никаких проблем не наблюдалось. файлик /etc/custom/nvram_set содержит только малую часть параметров а не все, может в этом причина? Ну или параметры в новых версиях как-то конфликтуют.. Пример файлика прикрепляю, параметры все те что заливаю. nvram_set.txt

Предложения уже озвучивал ранее. Внезапно понял что эта фича очень сильно нужна, иначе с версиями прошивок полный зоопарк. Кроме того очень надо автоматом (а не вручную!!!) вливать в девайсы определенный набор предустановленных настроек под оператора (типа IPTV, ALG и прочее). Готов участвовать в качестве бета-тестера, отладчика и т.п.

прошивка на MT-7620 SNR-CPE-W4N-MT-3.7.4.RU.10122015 сломан механизм генерации SSH-ключей, возможно из-за использования нестандартного порта после каждой перезагрузки ключи у коробки новые, SSH-клиент ругается IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the DSA key sent by the remote host is f0:18:42:8b:2a:81:5b:04:6b:ef:02:5f:97:bb:1e:3f. Please contact your system administrator. Add correct host key in /Users/user/.ssh/known_hosts to get rid of this message. Offending DSA key in /Users/user/.ssh/known_hosts:50 DSA host key for [192.168.1.1]:582 has changed and you have requested strict checking. Host key verification failed.

Пока тут никто не нафантазировал, в качестве простоты и учитывая вашу стабильную привычку в нумерации вида x.x.x, вариации: http://snr.local/modelname/x.x.x/rwfs.tar.gz http://snr.local/modelname/rwfs.x.x.x.tar.gz Вы, кмк, усложняете, была же речь в теме будущих планов про сервер аля tr069, это скорее ему такой функционал уже? Вроде тут у вас в темах кто-то паниковал по поводу лишних нажатий пользователями кнопки на устройствах. Хотя если есть защита от дурака ввиде проверок самого архива и ресурс флешки приличен, почему нет. Почерпнуть аналогичный опыт Eltex по обновлению прошивок STB и кастомизацией. Пару лет тому ковырялся с их системой - вполне продуманное решение было. Вкратце 1. DNS отдает адрес хоста обновления что-то типа eltex-stb.local где на HTTP-сервере в структуре каталогов лежат подписанные сертификатом прошивки и кастомизация 2. При загрузке STB ищет файлики с указанием версии актуального ПО по URL 3. Если найдено обновление прошивки - обновляется, нет - грузится дальше 4. Ищет файлики кастомизации для конкретной версии в дереве подкаталогов. 5. если есть кастомизация - подгружает её без сохранения во флеше девайса 6. Коробка STB запускается с кастомизацией, например с плейлистом оператора и командой запуска при старте IPTV-плеера Более мелкие детали уже не припомню

Пакеты обратно неважны т.к. полиси на входе коробки, т.е. обрабатывается трафик от абона Работающий конфиг context test policy access-list acl-classess-LK-in seq 10 permit udp any any eq domain class cls-PASS seq 20 permit tcp any host x.x.x.x eq www class cls-PASS seq 30 permit tcp any host x.x.x.x eq 443 class cls-PASS seq 40 permit tcp any any eq www class cls-REDIRECT seq 100 permit ip any any class cls-DEFAULT ! forward policy fwd-LOCAL_test ip access-group acl-classess-LK-in test class cls-DEFAULT drop class cls-PASS class cls-REDIRECT redirect destination local ! Но у нас редиректы накладываются на работающую сессию при помощи COA, либо при старте RADIUS-сервер передает их через VSA Используем CLIPS, поэтому главный принцип "все политики ограничения доступа, скорости и т.п. не должны обрывать текущее подключение абона" Либо сам абон обрывает её, либо в крайнем случае менеджер. Поверьте, это сильно облегчило жизнь.

Обновиться до 12.1.1.11 (вроде починили), в 12.1.1.9 у нас тоже временами это бывало. либо релоад модуля с сабом поможет

А можно поподробнее про недоработки RDP? Что именно не работает? Тестирую EcoNAT 2020, правда без особой нагрузки, чисто фичи проверяю как NAT 44 (CG-NAT) железка работает нормально, транслирует по портам TCP/UDP соединения, так же есть ALG для SIP, GRE, PPTP и кое-чего ещё. IPv6 прозрачно пропускает. В общем в плане потребностей простого хомячка не заметил никаких косяков. Из всего что проходит через NAT домашнего WiFi-роутера наверное только UPNP не будет работать. Cистема логирования трансляций довольно гибкая, можно делать аналог нетфлов или просто SRC_IP + диапазон SRC_PORTS По деньгам дешевле конечно чем A10 Для абонентов с экзотическими потребностями планируем сразу выдачу белых адресов. Всех за NAT сажать задачи не стоит.

Это не у меня не так, это в прошивке косяк скорее всего в сочетании с MAC/IP/Port Filtering Смотрю на роутер без файервола и проброса портов В цепочке FORWARD дефолтовая политика DROP А вот правило пропускающее RELATED,ESTABLISHED я бы поместил в самое начало, а уже после него остальные. Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 1313K 1759M MINIUPNPD all -- * * 0.0.0.0/0 0.0.0.0/0 1309K 1759M ACCEPT all -- * br0 0.0.0.0/0 224.0.0.0/4 0 0 ACCEPT all -- br0 * 224.0.0.0/4 0.0.0.0/0 4239 390K ACCEPT all -- br0 * 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * eth2.2 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * !br0 192.168.1.0/24 0.0.0.0/0 146 16692 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED В этом случае проброс портов тоже не будет работать Теперь добавляю на этом роутере проброс портов Chain port_forward_pre (1 references) pkts bytes target prot opt in out source destination 0 0 DNAT tcp -- eth2.2 * 0.0.0.0/0 !192.168.1.0/24 tcp dpt:8880 to:192.168.1.224:8880 и вижу в FORWARD добавление правила из WAN в LAN для вообще любого трафика! Но оно будет работать только при условии преобразования пакетов в PREROUTING 0 0 ACCEPT all -- eth2.2 br0 0.0.0.0/0 192.168.1.0/24 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 4 278 MINIUPNPD all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * br0 0.0.0.0/0 224.0.0.0/4 0 0 ACCEPT all -- br0 * 224.0.0.0/4 0.0.0.0/0 4 278 ACCEPT all -- br0 * 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * eth2.2 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * !br0 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- eth2.2 br0 0.0.0.0/0 192.168.1.0/24 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED А вот когда добавляю фильтрацию где "Правило по умолчанию -- пакеты, которые не подходят ни под одно правило, будут: Пропущены" вижу добавление цепочки Chain macipport_filter (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC F8:F0:82:51:12:13 И далее вижу что в FORWARD исчезло правило для пропуска трафика из WAN в LAN Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 3 266 MINIUPNPD all -- * * 0.0.0.0/0 0.0.0.0/0 3 266 macipport_filter all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * br0 0.0.0.0/0 224.0.0.0/4 0 0 ACCEPT all -- br0 * 224.0.0.0/4 0.0.0.0/0 3 266 ACCEPT all -- br0 * 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * eth2.2 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * !br0 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Получается что при пробросе портов трафику из WAN в LAN разрешается бегать по роуту (если конечно в PREROUTING было преобразование) Но этот проброс сразу же перестает работать как только мы включаем MAC/IP/Port Filtering (даже с пропуском неописанного правилами трафика) Что мешает оставить вот это правило пропуска из WAN в LAN при одновременном использовании проброса портов и фильтеринга? Какая-то особенная религия? 0 0 ACCEPT all -- eth2.2 br0 0.0.0.0/0 192.168.1.0/24

Предполагаю что нашел косяки. Дуалбенд, прошивка SNR-CPE-MD1-5GHZ-MT-3.6.6.RU.14112015 Подключение через PPPoE (VPN) При настройке "Сетевой экран/проброс портов" оное не заработало по двум причинам 1) Если опция проброса была выключена то изменения в iptables появляются только при условии жмаканья "Сохранить и перезагрузить", без перезагрузки жмаканье кнопки "Применить" не добавляет правил в iptables После перезагрузки добавляется цепочка "port_forward_pre_vpn" в PREROUTING и правила в ней. [Wive-NG-MT@/]# iptables -nvL -t nat Chain PREROUTING (policy ACCEPT 31514 packets, 2059K bytes) pkts bytes target prot opt in out source destination 32970 2150K port_forward_pre_vpn all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 MINIUPNPD all -- eth2.2 * 0.0.0.0/0 0.0.0.0/0 19263 1275K MINIUPNPD all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 Chain port_forward_pre_vpn (1 references) pkts bytes target prot opt in out source destination 1 60 DNAT tcp -- ppp0 * 0.0.0.0/0 !192.168.1.0/24 tcp dpt:3022 to:192.168.1.10:22 2) И после перезагрузки проброс не работает т.к. нет разрешающих правил в Chain FORWARD Как только ручками добавляю iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 22 -i ppp0 -j ACCEPT вижу в конце своё правило Chain FORWARD (policy DROP 13 packets, 1985 bytes) pkts bytes target prot opt in out source destination 13379 853K MINIUPNPD all -- * * 0.0.0.0/0 0.0.0.0/0 13376 853K macipport_filter all -- * * 0.0.0.0/0 0.0.0.0/0 12205 753K ACCEPT all -- br0 * 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * eth2.2 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * !br0 192.168.1.0/24 0.0.0.0/0 0 0 ACCEPT all -- * ppp0 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 1 60 ACCEPT tcp -- ppp0 * 0.0.0.0/0 192.168.1.10 tcp dpt:22 И тут же начинает работать как надо проброс портов. ИМХО просто забыли что одного изменения в PREROUTING недостаточно, нужно ещё разрешить трафик в FORWARD. Ну или это регрессия какая-то... Заранее извиняюсь что не покопался в скриптах и не сделал diff. Поначалу пробовал там разобраться в последовательностях выполнения, но до конца так и не уловил где и чего искать, а в WEB тем более не силен.

Проходили мы это. Фильтры эти не на всех свичах одинаково хороши, в совокупности всё-равно есть ограничения и "особенности" реализаций, которые инженерам-сетевикам как кость в горле. Чем держать абонов в одном L2 сегменте и накидывать всякие фильтры на довольно недешевых коммутаторах, проще всех абонов в отдельные вланы на доступе загнать даже на более дешевых свичах. А вот агрегацию лучше поставить чуть подороже и там сделать QinQ и потом уже всё это дотянуть до нормального BRAS, умеющего разбирать QinQ. В итоге получается весьма удобно даже по опорной сети гонять тэги - один SVID на агрегацию, в котором умещается до 4095 CVID (абонентских портов) - этого более чем достаточно. При этом гарантированно между абонентами никакая херь не бегает, проблемы коллизий МАС, кривого DHCP-снупинга с целью навешивания меток (Option 82) и т.п. ересь становятся маловолнующим фактором. Общий влан с ACL - это дороже, геморнее и требования к доступу в разы сложнее, даже авторизация сложнее. Те же D-Link разных серий не на каждой прошивке работают даже приемлемо с DHCP и IP-MAC-Port биндингом, а уж об идеальном свиче остается только мечтать. Влан на порт - это прекрасно работает даже на тупом свиче доступа, умеющем вланы с портов на транки прописывать. Мы переводили целый большой сегмент сети (около 15тыр абонов) со схемы "влан на дом" на схему "влан на порт". Так что есть с чем сравнить. По железу заменили только половину старых коммутаторов агрегации не умеющих QinQ. Да и время старых уже "подходило" - стали потихоньку "дохнуть". До перевода было много наболевших проблем, после - все эти проблемы просто стали неактуальны. Дополнительно после перехода на доступе смогли ставить коммутаторы примерно вдвое дешевле но абсолютно для нас без ухудшения сервиса, что оправдало наши затраты на обновление агрегаций буквально за квартал, а далее ессно позволило снизить затраты на оборудование. Да и вообще выбор коммутаторов доступа стал гораздо шире в схеме "влан на порт".