2010/10/14 Andrey Blochintsev
последний, соответственно, генерит ответный 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-секундную - в этом и состоит вопрос :) -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/