Hi! On Thu, Oct 14, 2010 at 01:08 +0300, Vladimir Litovka wrote:
2010/10/14 Andrey Blochintsev
последний, соответственно, генерит ответный TCN, который посылает в тот же порт, с которого был получен оригинальный TCN:
Насколько я понимаю - "ответный TCN" - это не TCN, а TCA (типа, "я тебя понял"),
нет, правильнее сказать - BPDU с установленным TC (0x1) битом. Я о том, что http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080... The TCN is a very simple BPDU that contains absolutely no information that a bridge sends out every hello_time seconds (this is locally configured hello_time, not the hello_time specified in configuration BPDUs). The designated bridge acknowledges the TCN by immediately sending back a normal configuration BPDU with the topology change acknowledgement (TCA) bit set.
TC и TCA, это разные биты/флаги
в моем примере 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-секундную - в этом и состоит вопрос :)
В твоем debug-е вообще не видно, что между 10й и 29й секундами отправляются BPDU в интерфейс Fa0/1. Интересно посмотреть именно эти BPDU и/или "show spanning-tree detail" на SW1 (на тему Topology change flag-ов и когда и где оно случалось. Скорей всего тот факт, что после 10й секунду появился TC flag просто не отражен во включенных (приведенных) debug-ах.