Есть ли у D-Link защита от STP root spoofing, аналог root guard на Cisco или это можно сделать только закрутив настройки приоритетов на портах? Сегодня столкнулись с интересной проблемой внезапно отвалился один (третий) коммутатор DES-3226S в линейке из четырех свичей есть подозрение, что проблема связана именно с STP потому как последняя запись в его логе именно о New root selected. Отвалился он так что у него перестал отвечать интерфейс управления и перестали работать все кто был подключен к нему и к следующему в цепочке. Может кто встречался с подобной проблемой, душить STP насмерть на клиентских линках не хочется (чтобы петли все таки определялись).

на обычном STP клиентские порты, не являющиеся заведомо резервными путями, можно вообще отключить из работы STP. В RSTP есть спец. настройки - Вы можете назанчить порты клиентскими - Edge или PtP - т.е. порты, учавтсвующие в работе RSTP. См. мануал.

_________________
С уважением, Карагезов Владислав

Если я отключаю порт из STP вообще то на сколько я понимаю он перестает рассылать BPDU и как следствие петля на этом порту приводит к сваливанию сегмента (Такое уже было!). Что происходит у D-Link в случае явного выставления порта как Edge? Перестает ли он рассылать BPDU или все таки продолжает их рассылать для определения петель, но игнорирует получение BPDU от другого оборудования?

Это не у D-Link, это в тандарте так! ))
Если порт помечен как Edge - с ниме просто игнорируются сообщения STP. И т.к. у Вас сеть построена грамотно, то, думаю, на клиентских портах вряд ли должна появлятся петля.

_________________
С уважением, Карагезов Владислав

У нас то да, но вот у клиентов уже наталкивались на умельца у которого было крайне интересное решение которое приводило к возврату части фреймов! в том числе arp и BPDU.

ну, с этим конечно сложно бороться, только административно что ли?

_________________
С уважением, Карагезов Владислав

На самом деле, лично я в вопросе проблемы не вижу.
Клиентский порт - это просто по-определению такой порт, от которого можно ждать всяческие неприятности и вообще что угодно, собственно для этого в коммутаторах есть такой механизм, который называется port security. Соответственно, если мы имеем список маков которые могут работать на порту A, и аналогично на порту B, то что нам с того если клиент A и B вдруг решат соединить эти кабелёчки между собой? Свитч всё равно из порта A будет выпускать только пакеты с адресами источника из списка, аналогично для B... Ну у клиентов A и B чёрт знает что, конечно, будет твориться, но будут уже как-бы их проблемы и ни нас, ни клиентов C, D, E... они не коснутся

Если посмотреть шире, то D-Link как-то не акцентирует внимание на распределение ролей портов, в то время как для большинства случаев, имхо, можно вполне обозначить два набора настроек портов

Клиентский:
- включён port_security, желательно все маки в статике, max_address=0
- GVRP выключен
- STP выключен

"Транковый"
- port_security нет
- GVRP включён
- STP включён

При таких раскладах, имхо, и овцы целы и волки сыты.

Все не так просто как кажется, при полном выключении STP происходит следюущее:

Клиент берет свич и замыкает два его порта - мы получаем петлю которая не детектиться ближайшим коммутатором, а детектиться вышестоящим (тоже под вопросом!) в результате весь сегмент сваливается, будем именно это тестить уже в понедельник в тестлабе, сегдня до этого просто руки не дошли SDH переключали...

btw я имел в виду не глобальное выключение STP, а только на порту

это как же он её задетектит?

про port-security главное не забывайте

Если на чисто отключить STP на порту то не перестанет работать определение петель на этом порту и получим ситуацию которую я уже описывал.

На счет как же он ее задетектит, то у него есть возможность пропускать чужие STP фреймы и именно они позволят вышестоящему коммутатору задетектить петлю (но если они в общем STP дереве то конечно не поможет).

Ну а port-security точно не поможет в случае петли.

Ой-вей?

Сейчас надо уже уезжать до дому, а то после полуночи гаишники преврятятся в тык... впрочем, чё это я Собсно, быстренько собрал на подручном коммутаторе (DES-3250TG fw.3.00-B09) схемку:

порт 1 - шлюз в инет
порт 17 и порт 31 будут соединены патчкордом
порт 2 - собственно я - для чистоты эксперимента
порт 4 - тоже что-нибудь, что линк зажжёт. я принт-сервер воткнул.

на свитче делаем такие команды (stp выключен вообще!):в предыдущей редакции поста в строке 1 по ошибке было написано admin disable вместо правильного admin enable. Сори если кого попутал
два мака на портах - это типа наши злостные юзеры с хабом

соответственно, включаем патч корд порт 17 - порт 31, и начинаем как-нибудь генерить броадкастовые и левые пакеты с маршрутизатора, например (например пинговать несуществующий адрес в сетке или широковещательный трафик)
И что?
А ничего, продолжаем спокойно лазить по инету и слушать поток с радио-сервера; на портах по show pa po 17 и show pa po 31 наблюдаем небольшие симеетричные "течения" пакетов. В целом абсолютно аналогичные (по передаче) по сравнению с портом 4, где принт-сервер честный висит.

соответственно как только мы говорим

всё, как и положено, летит в тар-тарары

Собственно, механизм данного "феномена" имхо настолько тривиален, что даже пояснять лень Да, это не spanning tree - оно не думает, как жить лучше, но не даёт жить плохо. Что вообщем и требуется в большинстве случаев

А если один мак может быть на 2 портах.

Пример: выдаем пользователю 2 порта на коммутаторе, а у него ноут, и он то в одну, то в другую розетку патч сует (пример из жизни). Что делать? 802.1X и Radius, и проверять соответствия мак-ип на сервере? У кого нибудь это работает?

_________________
Igor

Не очень правильный эксперемент, надо воткнуть один порт! коммутатора DES воткнуть другой коммутатор (мыльницу) и на ней устроить петлю проблема именно в этом.

802.1x на обоих портах

ой. я только сейчас заметил что опечатался когда писал второпях. Читать следует как

Сейчас специально по просьбам трудящихся повторил эксперимент, соединив порты через тупой коммутатор (Hardlink какой-то... что нашёл, вообщем). Картина не изменилась

show packet port 31 (или sho pa po 31 - мне так даже больше нравится ) после примерно минуты пингования с роутера броадкастового адреса пишет примерно такое:



Ошибки естесно по нулям, всё весело бегает и прыгает Вот даже сообщение это уйдёт сейчас