M-a-x-Z

Странным я его назвал потому, что WireShark его в одном поле идентифицирует как CTP, а в другом - уже как LOOP. Ну и не понятно, почему он оказался несовместим с 1000BaseT. Точнее LBD на его базе по версии Cisco. " Зафильтруйте STP и блокируйте по счетчикам флуда. " - так, по сути, и сделано. По счётчикам флуда только пару раз прибило Acronois, который, оказывается, бродкаст уважает. Хотя реализация LBD от Eltex и недо-кошки, ИМХО надёжнее.

Да, я же сразу пояснил что хочу отсекать запетлёванные сегменты, не управляемые основным деревом. И ничего особенного в этом нет. Многие умеют LBD. Да и алгоритм такого поведения простецкий. Даже у самой циски он был для FE. А теперь нет. Вот оно чё, Михалыч.... оттуда и элтекс это умеет. Фреймворк от Marvell. Вдвойне обидно, что они смогли LBD, а первичная циска нет.

А он сам его (свой) не генерит? Ну тогда любой другой свитч, который их генерит))) Гуарду ведь глубоко фиолетово - свой это бпду вернулся или чужой пришёл.

Уточнил же выше. Если к такому порту подключить вместо DES1008, например, DES2108 - порт будет залочен даже без наличия петли. Просто за сам факт подключения управляемого устройства. BPDU Guard - это не совсем механизм защиты от петель.

Конечно не обязательно. Просто раз уж есть пакеты... Но почему у Cisco вообще нет реализации LBD? Ни отдельной, ни через STP. Или я невнимательно искал?

Вопрос сугубо теоретический Бывают два типа петель: между портами STP домена и ЗА портом STP домена. В первом случае всё просто, протокол STP успешно петлю забарывает (иногда с нюансами, но в целом всё хорошо). Но самое интересное начнётся, если подключить к управляемому порту мыльницу с замкнутыми портами. Никакой STP на это не среагирует, а сеть ляжет. С точки зрения протокола это объяснимо - STP блокирует только несколько портов в один сегмент. Если в бажный сегмент идёт один порт, то ничего с этим не сделать. Но как раз такая ситуация, на практике, попадается гораздо чаще чем то, что несколько соседей соединят свои порты. Я попытался немного систематизировать способы борьбы с этой напастью и вот, что получилось. - самый логичный способ есть у Eltex (а, наверное, и у дргуих, но мне попался он) spanning-tree loopback-guard - порт блокируется в том случае, если получает обратно тот же BPDU, который именно в этот порт отправил ранее. Любые дргуие BPDU или фильтруются или обрабатываются в логике STP. Это самое красивое и логичное решение из найденных. Но его нет у Cisco. У кошек есть технология guard loop, но она ничего общего с описываемой ситуацией не имеет и вообще про другое. - можно включить loop guard. Эффект при петле будет хороший. Проблема только в том, что если абонент подключить железку с претензией на управляемость - её тоже отрубит. Добавлять bpdu фильтер нельзя, так как она нейтрализует guard. - можно врубить шторм-контроль,но параметры надо подбирать под сеть. Тоже может рубить много лишнего - функция down-when-loop по идее обещает решить проблему, но на практике работает только с FE. От 1000BaseT нос воротит (хотя не очень понятно, почему: уж отражённый сигнал от передаваемого-то можно различить же). В качестве транспорта использует странный Configuration Test Protocol, который Wireshark называет LOOP. Соответственно вопрос - не упустил ли я у кошки каких-то механизмов обнаружения петли за одним портом? Почему они упорно не могут запилить реакцию свитча на свой же BPDU пакет, как это делают некоторые вендоры? Ну и кто чем пользуется от такой напасти?

15 метров это на каком-то внекатегорийном кабеле 66 МГц. Если вспомнить, то 100BASE-TX вполне себе передавал 100 Мбит/с на 100 м. по одной паре. Но только в одну сторону. Но некоторые умельцы при помощи диода и какой-то матери (была статья на наге) ухитрялись в полудуплексном режиме запустить оба потока по одной же паре. Неужели эту задачу нельзя решить, перейдя к дифференциальной передаче, если взяв категорию типа 5е?

Добрый день, форумчане! Недавно узнал, что существуют стандарты 100BASE-T1 (802.3bw, 2015) 1000BASE-T1 (802.3bp, 2016) и даже 10BASE-T1 (802.3cg, разработка) - до 1200м! Стандарты эти помечены как автомобильные и индустриальные. Типа должны убить CAN. В связи с этим возникло два вопроса: 1. На сколько я понял из имеющихся обрывочных сведений - эти стандарты близки Ethernet, т.е. позволяют соединять устройства в режиме точка-точка. Но фишка CAN была именно в общей шине. Не будут же разработчики к каждому контроллеру лампочки в машине тянуть свой провод от центрального свитча. Или появляются свитчи в каждой фаре? Или, вообще, эти протоколы откат к старым технологиям общей шины в Ethernet? 2. Если сигнал можно манипулировать с такой скоростью в достаточно жёстких индустриальных условиях - зачем мы тогда продолжаем мотать километры провода в домашних и офисных подключениях? Почему не делают коммутаторов с Т1 портами? Или делают? Вобщем, заговор какой-то. UPD: The scope of this project is to specify additions to and appropriate modifications of IEEE Std 802.3 to add a point-to-point 1 Gb/s Physical Layer (PHY) specifications and management parameters for operation over a single twisted pair copper cable. Да, действительно, возврата к широковещанию нет. Но не понятно, как они собрались конкурировать с шиной. ИЧСХ, стандарты идут на нестандартных категроиях.

Кто-нибудь знает, в какой момент у сабжа стоковая прошивка применяет правила Firewall? Из-за того, что при пробросе портов нельзя указать определённый диапазон для подключений (например, мне надо прокидывать шаровую домашнюю папку, но только таким образом, чтобы я её видел с работы и ниоткуда больше), мне пришлось задействовать штатный брандмауэр. Выглядит это следующим образом: 1. На вкладке "Трансляция сетевых адресов (NAT)" включена трансляция 445 TCP порта на 445 порт внутреннего сервера 192.168.0.2 (фото 1) 2. На вкладке межсетевого экрана для домашней сети разрешён трафик сервера 192.168.0.2, порт 445 к рабочим ПК на любой порт 3. Весь остальной IP-трафик от узла 192.168.0.2 запрещён (фото 2) В принципе, эта схема даёт желаемый эффект. Но не понятно, в какой момент включаются правила. Например, я сделал настройки из п. 1 и 3. Естественно с работы шара была недоступна. Затем я добавил правило из п. 2 и всё мгновенно заработало. А вот когда я его снова выключил - связь не прервалась и шара была доступна! (Точно это был не кэш, т.к. воспользовался Wireshark для того, чтобы убедиться в наличии трафика). Перезагрузка роутера помогла. Т.е. правило 2 применяется мгновенно, а отключается вообще не понятно как. Гистерезис какой-то. В чём может быть логика?

А почему по L2? По L3 веером сканит сетку и привет. Если на сетий управления ACL на входе нет...

Вот вам две оговорки: 1. Проброс L2 (интересно, а чем ещё занимается L1 и можно ли у него забрать адрес) 2. Вместо /30 берём /32. И уж точно не стоит попусту расходовать паблик на точку-точку между R1 и R2. Проще прокинуть роут и получить 4 белых адреса на R2. А в задаче вы хотите 3 адреса в землю зарыть)

vpdn-group DEFAULT ! Default L2TP VPDN group accept-dialin protocol pptp Вот это циска не хочет жрать. L2TP есть. И даже с IPSec работает, но только не поддерживается. В соседней теме копипастил ответ из TAC по этому поводу. Мол работает? Ок. Не работает - ничем не можем помочь. Ветка заморожена.

Не "не работает", а "никто не поддерживает" (((

По условиям задачи она не разрешима. Если белый адрес остаётся на R1, то его не исопльзовать под NAT на R2. ....если не L2 через R1 на R2. Но тут надо точнее знать железо и ограничения.   Ну и потом в условиях вы пишете про /30, а я говорю, что моно и /32 обойтись.

Так вроде не обязательно абонентов иметь? По L3 IP должен быть виден из любой части сети с клиентами... настоятельно рекомендую на влан управления deny tcp any any eq 4786 log