2010/10/14 Andrey Blochintsev
<bag@iptelecom.net.ua>
> последний, соответственно, генерит ответный TCN, который посылает в тот
> же порт, с которого был получен оригинальный TCN:
Насколько я понимаю - "ответный TCN" - это не TCN, а TCA (типа, "я тебя понял"),
нет, правильнее сказать - BPDU с установленным TC (0x1) битом. Я о том, что в моем примере root bridge генерит такой BPDU при выполнении двух условий:
- если получил аналогичный BPDU ранее
- на том порту, с которого получил аналогичный BPDU ранее
Oct 13 23:16:35.644: STP: VLAN0001 Topology Change rcvd on Fa0/3
Oct 13 23:16:35.644: STP: VLAN0001 Fa0/3 tx BPDU: config
protocol=ieee
Data : 0000 00 00 81 6001EC30915E0F00 00000000
6001EC30915E0F00 8005 0000 1400 0500 0F00
Oct 13 23:16:40.719: STP: VLAN0001 Topology Change rcvd on Fa0/1
Oct 13 23:16:40.719: STP: VLAN0001 Fa0/1 tx BPDU: config
protocol=ieee
Data : 0000 00 00 81 6001EC30915E0F00 00000000
6001EC30915E0F00 8003 0000 1400 0500 0F00
Когда у root-а упал какой-то порт ему не нужно слать TCN, а просто
достаточно отправить следующее BPDU с взведенным TC.
да-да, именно этого-то я и не вижу в своей лабе. Вижу вот это -
Oct 13 23:32:09.248: %LINK-3-UPDOWN: Interface FastEthernet0/3,
changed state to down
Oct 13 23:32:10.246: %LINEPROTO-5-UPDOWN: Line protocol on
Interface FastEthernet0/3, changed state to down
Oct 13 23:32:28.643: STP: VLAN0001 Topology Change rcvd on Fa0/1
Oct 13 23:32:29.641: STP: VLAN0001 Fa0/1 tx BPDU: config
protocol=ieee
Data : 0000 00 00 81 6001EC30915E0F00 00000000 6001EC30915E0F00
8003 0000 1400 0500 0F00
на 10-й секунде - падение порта (note - лог этого события почему-то идет с задержкой), и только через 20 секунд - получение TCN снаружи и посылка собственного BPDU с установленным битом 0x1. То есть падение собственного порта не вызвало генерацию BPDU с установленным TC-битом ни немедленную, ни даже плановую 2-секундную - в этом и состоит вопрос :)