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