Добрый день. Стоит задача:
пердполагается сеть(маленькая сеточка пока из пятка коммутаторов) на dec3200, звезда - в центе 76-ая, сеть исключительно для бизнес-клиента. Идея состоит в том чтобы отвязаться от клиентов и предоставить ему возможность "хулиганить в пределах разумного конечно" те в не зависимости какой трафик приходит от клиента(tag or untag) обеспечить его проключение из точки А в точку Б. Для этого на 3200 поднимается QinQ. Проблема возникла на этапе решения проблемы с возможными петлями на стороне клиента. Опыта работы с stp у меня нет. Собрал "на коленках" несколько 3200 включил rstp настройки оставил по умолчанию, чтоб посмотреть механизм работы, [с моим вариантом примером как то не очень)) работает...] я пока в самом начале этого пути.
Задача:
1) чтоб в момент появления петли, разрыв был на стороне клиента
2) кореневой коммутатор не должен убежать к клиенту
прошивка 3200 - 1.21.B006
ps. может есть мысли пока я "курю" тему. примерам буду крайне признателен))

Планируемую топологию нарисуйте (физику и логику), т.к. из вашего объяснения мало что понятно.

Это как?

Включите на клиентских портах restricted_role

те выбрать значение true?

что бы разрыв петли происходил на порт к которому подключен клиент.

Петлю на схеме изобразите.

Если подразумевается, что клиент замкнет свое оборудование создава петлю, то получатеся весьма неудобное решение с точки зрения оператора...
Обычный stp не подойдет в данном случае...петля может быть, но клиентское оборудование может, допустим, не пропускать pbdu поэтому оборудование не сможет обнаружить эту самую петлю.
К томуже вам придется пускать пользователя в свой stp домент, что вообще крайне опасно....
Я бы просто жетско отрезал полосу на портах 3200 для клиента, и включил весь возможный пакет storm-cotrol + QoS (полисинг).... ну а дальше клиент пусть сам отвечает за свои петли.

[url][URL=http://www.radikal.ru][/url][/url]



в этом и состоит проблема:
1) желательно что бы pbdu не ходили между нами и сетью клиента вопрос в том как строить топологию только внутри нашего сегмента и не зависить от того что сделает клиент, и как в этом случае мониторить петли, как я понимаю это получается практически не возможным.
2) если stp разорвет петлю, то опять же это должно быть на клиентском порту.

Такой вариант возможен на 3200 есть L2-tunneling protocol... его можно использовать для прозрачного проброса bpdu...

бегло ознакомился,
А не попадаем ли мы в данной ситуации на "индивидуальную работу с клиентом"?
хотелось бы иметь типовую схему, подходящую для 95% клиентов, 5% обычно выдвигают очень "интересные ТУ"...

скажем что мы будем иметь в таком случае:

насколько это правельно? относительно моей задачи. сейчас "на коленках" сделана петля на портах 21 и 23 - все порты (100 vlane), в 1 порте на двух коммутаторах подключены два бука. проблем в работе нет:

Простите вы где stp конфигурируете? Это эмуляция клиентского железа?
На вашем оборудованиии stp вообще не надо включать, вам надо его просто прозрачно пробросить....

Может я копаю не в том русле?, я хочу в независимости от клиента предоставить ему "две дырки" на двух точках и обеспечить защиту от петель. Если меня не туда несет, дайте управляющего пинка. Вопрос в том, а если у клиента кто то случайно воткнет два хвоста из нашего 3200 в скажем в обычный switch.
могли бы привести пример? конфигурации правельно с вашей точки зрения. я был бы очень признателен.

Мы уже вроде выяснили:
1) Вы не можете гарантировать клиенту защиту от петель, потому что не можете отвечать за оборудование клиента как физически та и административно
2) Отвественность за петли разумно и правильно преложить на самого клиента, вы предоставляете клиенту полосу и транспорт, о петлях клиент заботится сам.
В преведенных вами схемах и примерах, если клиенту предоставить транспорт bpdu и он включит stp на егго оборудовании защита от колец будет замечательно отрабатывать.
3) Если ваши собственные специалисты начнут включать провода туда куда не надо, пусть даже случайно, тут врядли поможет уже какая либо защита.

т.е. Вы против stp...
и как я понимаю вы предлагаете воспользоваться набором Storm-cotrol+Loopdetect?

Я не против и не за...
Вы - оператор, я вам предлагаю удобное решение с точки зрения оператора, высокая безопасность сети и минимальная отвественность.

решили все таки остановиться на stp, выбрать версию mstp (чтоб было удобнее подружить с циской) и разделить по деревьям управление и клиентов. Прошу посмотреть что я наколдовал и если не сложно тыкнуть носом в ошибки

# STP




config stp version mstp
//выбрал версию

config stp maxage 20 maxhops 20 forwarddelay 15 txholdcount 6 fbpdu enable // оставил по умолчанию


config stp priority 32768 instance_id 0
// как я понял instance_id 0 не удаляется, и там находятся все vlanы не распределенные по веткам

create stp instance_id 1
// ветка для управления

config stp instance_id 1 add_vlan 50
//соответственно vlan для управления

config stp priority 8192 instance_id 1
// поставил почти самый высокий приоритет , наивысший будет у 76-ой

create stp instance_id 2
// для клиентов

config stp instance_id 2 add_vlan 3100-3101 //клиентские vlanы


config stp priority 8192 instance_id 2
//поставил почти самый высокий приоритет , наивысший будет у 76-ой

config stp mst_config_id name me_gts revision_level 1
// придумал имя и задал уровень

config stp ports 1-24 externalCost auto hellotime 2 edge true p2p auto state enable
// включит порты в группу instance_id 2, сказал что порты 1-24 крайние

config stp ports 1-28 hellotime 2


config stp mst_ports 1-28 instance_id 0 internalCost auto priority 128
// уровнял приоритеты по всем портам

config stp ports 1-28 fbpdu disable
// запретил пересылку bpdu пакетов из чужих сетей

config stp ports 1-24 restricted_role true
// пометил порты 1-24 чтобы никогда не становились корневыми

config stp ports 1-24,26-28 restricted_tcn false
// запретил изменения топологии сети с этих портов

config stp ports 25 externalCost auto hellotime 2 edge false p2p auto state enable
// включил stp, сказал что 25 рорт не крайний

config stp ports 25 restricted_role false
// 25 порт корневой

config stp ports 25 restricted_tcn true
// разрешил изменение топологии

config stp mst_ports 25 instance_id 1 internalCost auto priority 128
// задал приоритет

config stp mst_ports 1-28 instance_id 2 internalCost auto priority 128
// уравнял приоритеты

enable stp

--