faq обучение настройка
Текущее время: Вт окт 15, 2019 12:30

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: STP. restricted_tcn на агрегации
СообщениеДобавлено: Пт мар 24, 2017 09:37 
Не в сети

Зарегистрирован: Пт мар 24, 2017 08:53
Сообщений: 8
Добрый день.
Во всех рекомендациях написано, что restricted_tcn стоит включать на портах коммутаторов доступа, смотрящих в сторону агрегации.
Но ,во-первых, это не универсально (для таких устройств придется готовить конфиг отличный от шаблона), во-вторых это не подходит, если сеть не одновендерная ( в кольцах доступа коммутаторы разных производителей на которых просто нет restricted_tcn).
При этом, нужно, чтобы уведомления об изменении топологии в одном из колец не отправлялись в порты агрегатора за которыми находятся другие кольца.

Если включить на агрегации на всех портах в сторону колец доступа restricted_tcn true, какие негативные последствия?
При этом на апплинках коммутаторов агрегации stp вообще выключен, stp только в кольцах доступа( RSTP).

Типовая схема:
Изображение

Скрытый текст: показать
# STP на уровне доступа
enable stp
config stp version rstp
config stp priority 32768 instance_id 0
config stp txholdcount 6 maxage 20 hellotime 2 forwarddelay 15 maxhops 20
config stp nni_bpdu_addr dot1d
config stp fbpdu enable
config stp ports 1-24 externalcost auto edge true restricted_tcn true restricted_role true p2p false state disable priority 128 fbpdu disable
config stp ports 25-28 externalcost auto edge false restricted_tcn false restricted_role false p2p true state enable priority 128 fbpdu enable
config stp mst_config_id name region1 revision_level 0
config stp mst_ports 1 instance_id 0 internalCost auto priority 128
config stp mst_ports 2 instance_id 0 internalCost auto priority 128
config stp mst_ports 3 instance_id 0 internalCost auto priority 128
config stp mst_ports 4 instance_id 0 internalCost auto priority 128
config stp mst_ports 5 instance_id 0 internalCost auto priority 128
config stp mst_ports 6 instance_id 0 internalCost auto priority 128
config stp mst_ports 7 instance_id 0 internalCost auto priority 128
config stp mst_ports 8 instance_id 0 internalCost auto priority 128
config stp mst_ports 9 instance_id 0 internalCost auto priority 128
config stp mst_ports 10 instance_id 0 internalCost auto priority 128
config stp mst_ports 11 instance_id 0 internalCost auto priority 128
config stp mst_ports 12 instance_id 0 internalCost auto priority 128
config stp mst_ports 13 instance_id 0 internalCost auto priority 128
config stp mst_ports 14 instance_id 0 internalCost auto priority 128
config stp mst_ports 15 instance_id 0 internalCost auto priority 128
config stp mst_ports 16 instance_id 0 internalCost auto priority 128
config stp mst_ports 17 instance_id 0 internalCost auto priority 128
config stp mst_ports 18 instance_id 0 internalCost auto priority 128
config stp mst_ports 19 instance_id 0 internalCost auto priority 128
config stp mst_ports 20 instance_id 0 internalCost auto priority 128
config stp mst_ports 21 instance_id 0 internalCost auto priority 128
config stp mst_ports 22 instance_id 0 internalCost auto priority 128
config stp mst_ports 23 instance_id 0 internalCost auto priority 128
config stp mst_ports 24 instance_id 0 internalCost auto priority 128
config stp mst_ports 25 instance_id 0 internalCost auto priority 128
config stp mst_ports 26 instance_id 0 internalCost auto priority 128
config stp mst_ports 27 instance_id 0 internalCost auto priority 128
config stp mst_ports 28 instance_id 0 internalCost auto priority 128
config stp trap new_root enable
config stp trap topo_change enable


Скрытый текст: показать
Агрегация
config stp version rstp
config stp maxage 20 maxhops 20 forwarddelay 15 txholdcount 6 fbpdu disable hellotime 2 nni_bpdu_addr dot1d
config stp priority 24576 instance_id 0
config stp ports 1-24 externalCost auto edge false p2p true state enable restricted_role true restricted_tcn true
config stp mst_ports 1-26 instance_id 0 internalCost auto priority 128
config stp ports 1-26 fbpdu disable
config stp ports 1-26 loop_guard false
config stp ports 25-26 externalCost auto edge false p2p true state disable restricted_role false restricted_tcn false
config stp mst_config_id name region1 revision_level 0
config stp trap new_root enable
config stp trap topo_change enable
enable stp
disable stp multiprocess_rstp


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Вт мар 28, 2017 08:01 
Не в сети

Зарегистрирован: Пт мар 24, 2017 08:53
Сообщений: 8
Никто ничего не ответит?
Какие минусы при такой конфигурации?


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Вт мар 28, 2017 21:57 
Не в сети

Зарегистрирован: Вс май 22, 2005 10:19
Сообщений: 888
Откуда: Moscow
есть простое решение - stp на доступе выключить вовсе, оставив включённым только bpdu forward.
тогда не будет проблем ни с разными вендорами, ни с любым размером колец.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Пт мар 31, 2017 07:48 
Не в сети

Зарегистрирован: Пт мар 24, 2017 08:53
Сообщений: 8
RDC писал(а):
есть простое решение - stp на доступе выключить вовсе, оставив включённым только bpdu forward.
тогда не будет проблем ни с разными вендорами, ни с любым размером колец.


Не приведет-ли это к образованию петель? Если не включать stp, как коммутаторы доступа будут определять и отключать избыточные линки в кольце?
Я так понимаю, что при такой настройке, будет лочится один из портов на агрегации. Но для колец из 14 коммутаторов и более желательно логически бить посередине.

Меня интересует именно включение restricted_tcn на агрегации в сторону доступа. У себя на тестовом узле включил, проблем не наблюдаю, но вдруг есть подводные камни.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Пт мар 31, 2017 16:26 
Не в сети

Зарегистрирован: Вс май 22, 2005 10:19
Сообщений: 888
Откуда: Moscow
Да, будет лочиться один из портов на агрегации.
Зато кольца любых размеров и вендоров.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Пт мар 31, 2017 16:29 
Не в сети

Зарегистрирован: Пт мар 24, 2017 08:53
Сообщений: 8
И цепочка длиною в 16 коммутаторов вместо двух по 8...


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Вс апр 02, 2017 11:23 
Не в сети

Зарегистрирован: Вс май 22, 2005 10:19
Сообщений: 888
Откуда: Moscow
Это имеет значение только в одной ситуации - когда пиковая полоса на все 16 подходит к гигабиту, и нужно балансировать нагрузку.
Тогда да, есть смысл разбить цепочку свичом с включённым STP, а на агрегации STP при этом можно отключить.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Ср апр 05, 2017 13:01 
Не в сети

Зарегистрирован: Чт ноя 01, 2012 05:57
Сообщений: 58
RDC писал(а):
есть простое решение - stp на доступе выключить вовсе, оставив включённым только bpdu forward.
тогда не будет проблем ни с разными вендорами, ни с любым размером колец.


Это решение имеет свои минусы, как впрочем и мысль блокировать tcn.
При изменении топологии tcn рассылается корню, а потом корнем топологии флудится по всей сети. Это заставляет каждый коммутатор выставить какой-то маленький age time записям в fdb и быстро им прокиснуть, если запись не обновится за это время. Соответственно запрещая tcn вы мешаете процессу переучивания и исправления fdb под изменившуюся топологию.

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

/foo


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Ср апр 05, 2017 20:49 
Не в сети

Зарегистрирован: Вс май 22, 2005 10:19
Сообщений: 888
Откуда: Moscow
Пакеты идут "не туда" ровно до первого встречного пакета.
При обычной активности интернета встречный пакет поступит гораздо быстрее, чем сходится rstp на минимальных таймингах.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Чт апр 06, 2017 09:05 
Не в сети

Зарегистрирован: Чт ноя 01, 2012 05:57
Сообщений: 58
RDC писал(а):
Пакеты идут "не туда" ровно до первого встречного пакета.
При обычной активности интернета встречный пакет поступит гораздо быстрее, чем сходится rstp на минимальных таймингах.

Например на кольце стоит коммутатор A который доступен по управлению через плечо 1. Пусть корнем топологии будет коммутатор B в который двумя портами сходится кольцо коммутатора A. Теперь меняется топология и до корня путь начинает идти через плечо 2.

2 случая интересны (в момент сразу после изменения топологии):
(1). Мы запретили tcn на портах B.
Если коммутатор B на который сходится кольцо, не получит tcn, он будет форвардить пакеты для A в старый порт (плечо 1), ровно до тех пор, пока от А не прилетит пакет через плечо 2 (и не переучит коммутатор В), т.е. В форвардит пакеты на mac A в неправильный порт. Это будет происходить до тех пор, пока не прокиснет запись в fdb (что может быть очень долго) или не прилетит пакет от А. Если ещё и на А не работает stp (только форвардятся stp пакеты), то ждать придётся долго однозначно. Но обычно А все таки участвует в stp и прочухал изменение топологии (получил tcn) и проквасил побыстренькому свои маки. И вот А готов отправлять пакеты, но ... зачем ему это делать :) нужно событие - trap, собщение в syslog... он должен _сам_ захотеть что-то послать, и мы со своей стороны (с роутера, где L3 интерфейс управления) не можем его заставить стать доступным, пока А _сам_ не захочет этого.

(2). Мы не запретили tcn на B, но выключили stp на всех коммутаторах кольца. Сам А маки в fdb не переучит, ему нужно прислать пакет с правильного порта, но пока он будет форвардить пакеты в старый неправильный порт.

Каждый сам для себя решает и выбирает меньшее зло :)

/foo


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Чт апр 06, 2017 12:11 
Не в сети

Зарегистрирован: Вс май 22, 2005 10:19
Сообщений: 888
Откуда: Moscow
foo писал(а):
ему нужно прислать пакет с правильного порта, но пока он будет форвардить пакеты в старый неправильный порт.
Повторюсь - этот пакет придёт быстро, в течение нескольких секунд.
Абонентские устройства постоянно с чем-то синхронизируются, перерегистрируются, держат открытыми tcp соединения и т.д, и этот двусторонний фоновый трафик быстро разворачивает fdb в нужную сторону.

Это не теоретические измышления, это у меня реально работает.
И для подстраховки можно fdb aging_time выкрутить на минимум.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Ср апр 12, 2017 12:11 
Не в сети

Зарегистрирован: Пт мар 24, 2017 08:53
Сообщений: 8
foo писал(а):

При изменении топологии tcn рассылается корню, а потом корнем топологии флудится по всей сети. Это заставляет каждый коммутатор выставить какой-то маленький age time записям в fdb и быстро им прокиснуть, если запись не обновится за это время. Соответственно запрещая tcn вы мешаете процессу переучивания и исправления fdb под изменившуюся топологию.

/foo


То есть, рекомендация dlinka, выключать рассылку tcn на порту коммутатора, смотрящего в сторону агрегации, также, по-вашему, плохая идея?
Ведь принцип тот же, корень- агрегатор не будет получать tcn.

И как, по-вашему тогда бороться с рассылкой данных пакетов в изолированные от "флудящего" кольца цепочки?


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Ср апр 12, 2017 16:00 
Не в сети
Сотрудник D-LINK
Сотрудник D-LINK

Зарегистрирован: Ср май 10, 2006 16:40
Сообщений: 12190
Откуда: D-Link, Moscow
Цитата:
То есть, рекомендация dlinka, выключать рассылку tcn на порту коммутатора, смотрящего в сторону агрегации, также, по-вашему, плохая идея?

restricted_tcn запрещает не рассылку, а получение tcn. Корень будет в курсе изменения топологии.

Если в качестве агрегатора используется DGS-3420, то на нём есть такая функция как multiprocess rstp, на нём можно создать несколько виртуальных колец и указать на каких портах они находятся. Рассылка tcn между кольцами происходить не будет.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Чт апр 13, 2017 08:32 
Не в сети

Зарегистрирован: Пт мар 24, 2017 08:53
Сообщений: 8
Можно пример настройки multiprocess rstp на DGS-3420 ?


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: STP. restricted_tcn на агрегации
СообщениеДобавлено: Чт апр 13, 2017 11:28 
Не в сети
Сотрудник D-LINK
Сотрудник D-LINK

Зарегистрирован: Ср май 10, 2006 16:40
Сообщений: 12190
Откуда: D-Link, Moscow
Примерно так:
Код:
enable stp multiprocess_rstp
create stp multiprocess_rstp ring1
create stp multiprocess_rstp ring2
create stp multiprocess_rstp ring3
config stp multiprocess_rstp ring1 add ports 1-2
config stp multiprocess_rstp ring2 add ports 3-4
config stp multiprocess_rstp ring3 add ports 5-6
enable stp


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: Google [Bot] и гости: 12


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB