M-a-x-Z

Ничего противоречивого. Вынули порты одного типа, задействовали другого. Одновременно они не нужны.

Да, то что нужно. Не знал, что 6500 можно переводить из redundand в combined. Теперь всё сработало и проблема решена. Всем спасибо! Ну да, не дорого. Но зачем, если его хватает на работу всех необходимых плат в redundant режиме)

Спасибо, мысль интересная. Жаль попробовать не получится: карта была изъята для высвобождения бюджета питания для другой карты)))

Для provision достаточно бедный ассортимент команд: 6509(config)#module provision 4 ? dynamic Provision module for any line card first-insert Provision module for first inserted line card естественно оба этих варианта под ситуацию не подходят (

... без перезагрузки. Собственно ситуация простая: изъяли из шасси плату на 48 GE. И больше ставить её не будем. Однако, все интерфейсы этой платы всё-ещё перечислены в конфиге. Фишек с редактированием provision как в стеках 3850 не нашёл. Можно ли без ребута объяснить Cisco что этих портов больше нет?

Странным я его назвал потому, что 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 на входе нет...