/привет занимаюсь тут одной академической задачей, в рамках которой столкнулся с вопросом, который непонятен. Есть STP (не rapid) в следующей топологии: / шо, не видно картинку? она в аттаче ;-) /в этой топологии - root@sw5, а кольцо разорвано на (sw2-sw1)@sw2. Ситуация состоит в следующем: 1) если я рву линк sw4-sw2, то sw4 генерит TCN в сторону sw5 и последний, соответственно, генерит ответный TCN, который посылает в тот же порт, с которого был получен оригинальный TCN: / _sw4(config-if)#shut sw4(config-if)#_ *Oct 13 23:16:35.647: STP: VLAN0001 sent Topology Change Notice on Gi1/0/3* Oct 13 23:16:35.647: %LINK-5-CHANGED: Interface GigabitEthernet1/0/1, changed state to administratively down Oct 13 23:16:36.653: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down _sw5#_ Oct 13 23:16:35.644: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from FastEthernet0/3 , linktype IEEE_SPANNING , enctype 2, encsize 17 Oct 13 23:16:35.644: STP: enc 01 80 C2 00 00 00 EC 44 76 F7 28 83 00 07 42 42 03 Oct 13 23:16:35.644: STP: Data 00000080 Oct 13 23:16:35.644: STP: VLAN0001 Fa0/3:0000 00 80 *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 /Когда sw2 раздупляется о происходящем, он тоже посылает TCN в сторону root (sw1->sw5), который обрабатывается рутом по той же схеме - получил с порта от sw1 и туда же отправил:/ Oct 13 23:16:40.711: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from FastEthernet0/1 , linktype IEEE_SPANNING , enctype 2, encsize 17 Oct 13 23:16:40.711: STP: enc 01 80 C2 00 00 00 A4 0C C3 27 42 81 00 07 42 42 03 Oct 13 23:16:40.719: STP: Data 00000080 Oct 13 23:16:40.719: STP: VLAN0001 Fa0/1:0000 00 80 *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 /2) НО, если я рву линк sw4-sw5 (независимо от того, с какой стороны), то sw5 ни хера не генерит в ответ на падение порта, а начинает реагировать только когда ему приходит TCN со стороны sw2->sw1:/ Oct 13 23:32:09.240: STP[1]: Generating TC trap for port FastEthernet0/3 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 rx BPDU: config protocol = ieee, packet from FastEthernet0/1 , linktype IEEE_SPANNING , enctype 2, encsize 17 Oct 13 23:32:28.643: STP: enc 01 80 C2 00 00 00 A4 0C C3 27 42 81 00 07 42 42 03 Oct 13 23:32:28.643: STP: Data 00000080 Oct 13 23:32:28.643: STP: VLAN0001 Fa0/1:0000 00 80 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 /причем происходит это с полагающейся задержкой в 20 секунд (стандартные величины таймеров), пока sw2 раздупляется с десятью неполученными Hello по линку sw5-sw4-sw2:/ Oct 13 23:32:09.609: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:11.152: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:13.157: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:15.162: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:17.167: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:19.172: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:21.177: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:23.181: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:25.186: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:27.191: STP: VLAN0001 heard root 32769-ec44.76f7.2880 on Fa0/1 Oct 13 23:32:27.611: STP: VLAN0001 new root port Fa0/2, cost 119 Oct 13 23:32:27.611: STP: VLAN0001 Fa0/2 -> listening Oct 13 23:32:28.642: STP: VLAN0001 Topology Change rcvd on Fa0/1 Oct 13 23:32:28.642: STP: VLAN0001 sent Topology Change Notice on Fa0/2 Oct 13 23:32:42.618: STP: VLAN0001 Fa0/2 -> learning Oct 13 23:32:57.625: STP: VLAN0001 sent Topology Change Notice on Fa0/2 Oct 13 23:32:57.625: STP: VLAN0001 Fa0/2 -> forwarding /Вопрос - это фича или баг, что "отрыв ноги" непосредственно на root bridge не приводит к моментальному TCN? И отсюда следует интересное наблюдение - root bridge надо размещать на коммутаторе, в который не входит внешняя оптика, т.е. что типа: (внешние линки) >>> [edge switch] --- [root bridge] --- [edge switch] <<< (внешние линки) для того, чтобы "ненадежные" соединения включались в edge-коммутаторы, которые будут слать TCN в сторону root. Это так? Или это я хожу по well-known граблям? :-) Спасибо. /
Hi! On Thu, Oct 14, 2010 at 00:14 +0300, Vladimir Litovka wrote:
/привет
занимаюсь тут одной академической задачей, в рамках которой столкнулся с вопросом, который непонятен. Есть STP (не rapid) в следующей топологии: / шо, не видно картинку? она в аттаче ;-)
/в этой топологии - root@sw5, а кольцо разорвано на (sw2-sw1)@sw2. Ситуация состоит в следующем:
1) если я рву линк sw4-sw2, то sw4 генерит TCN в сторону sw5 и последний, соответственно, генерит ответный TCN, который посылает в тот же порт, с которого был получен оригинальный TCN:
Насколько я понимаю - "ответный TCN" - это не TCN, а TCA (типа, "я тебя понял"), Механизм TCN/TCA предназначен для "донести до root-а информацию, что топология поменялась". Когда у root-а упал какой-то порт ему не нужно слать TCN, а просто достаточно отправить следующее BPDU с взведенным TC. В принципе и в случае получения TCN от кого-то все равно ВСЯ сеть узнает про изменение топологии именно из TC бита. Так как само по себе TC не вызывает мгновенный сброс MAC таблиц, а только сокращение aging time, то и уведомление про это спокойно откладывается до следующего (максимально через hello time) BPDU
/Вопрос - это фича или баг, что "отрыв ноги" непосредственно на root bridge не приводит к моментальному TCN? не приводит. TCN != TCA != TC
И отсюда следует интересное наблюдение - root bridge надо размещать на коммутаторе, в который не входит внешняя оптика, т.е. что типа:
(внешние линки) >>> [edge switch] --- [root bridge] --- [edge switch] <<< (внешние линки)
для того, чтобы "ненадежные" соединения включались в edge-коммутаторы, которые будут слать TCN в сторону root. Это так?
Или это я хожу по well-known граблям? :-)
Трудно найти черную кошку в темной комнате, особенно если ее там нет
Спасибо.
/
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/
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-ах.
2010/10/14 Andrey Blochintsev
да, нулевой и седьмой соответственно, я это знаю ;-)
В твоем debug-е вообще не видно, что между 10й и 29й секундами отправляются BPDU в интерфейс Fa0/1. Интересно посмотреть именно эти BPDU
Ёпрст, похоже, это дебаги каталистов так работают :-\ Включил debug spanning-tree bpdu receive на sw1 и увидел BPDU'шки с включенным TC-битом. sw5#sh deb Spanning Tree: Spanning Tree BPDU Transmitted debugging is on Spanning Tree BPDU Received debugging is on Spanning Tree event debugging is on sw5# Oct 14 10:27:28.893: STP[1]: Generating TC trap for port FastEthernet0/3 Oct 14 10:27:28.901: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down Oct 14 10:27:29.899: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down [ ... в логах на sw5 здоровенная дыра между 29 и 48 секундами ...] Oct 14 10:27:48.547: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from FastEthernet0/1 , linktype IEEE_SPANNING , enctype 2, encsize 17 Oct 14 10:27:48.547: STP: enc 01 80 C2 00 00 00 A4 0C C3 27 42 81 00 07 42 42 03 Oct 14 10:27:48.547: STP: Data 00000080 Oct 14 10:27:48.547: STP: VLAN0001 Fa0/1:0000 00 80 Oct 14 10:27:48.547: STP: VLAN0001 Topology Change rcvd on Fa0/1 а на sw1 - все путьком: вот простой hello: Oct 14 10:27:28.572: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from FastEthernet0/1 , linktype IEEE_SPANNING , enctype 2, encsize 17 Oct 14 10:27:28.572: STP: enc 01 80 C2 00 00 00 EC 30 91 5E 0F 03 00 26 42 42 03 Oct 14 10:27:28.572: STP: Data 00000000006001EC30915E0F00000000006001EC30915E0F0080030000140002000F00 Oct 14 10:27:28.572: STP: VLAN0001 Fa0/1:0000 00 00 *00* 6001EC30915E0F00 00000000 6001EC30915E0F00 8003 0000 1400 0200 0F00 Oct 14 10:27:28.580: STP(1) port Fa0/1 supersedes 0 а следующая BPDU'шка - с уже установленным TC-битом: Oct 14 10:27:30.577: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from FastEthernet0/1 , linktype IEEE_SPANNING , enctype 2, encsize 17 Oct 14 10:27:30.577: STP: enc 01 80 C2 00 00 00 EC 30 91 5E 0F 03 00 26 42 42 03 Oct 14 10:27:30.577: STP: Data 00000000016001EC30915E0F00000000006001EC30915E0F0080030000140002000F00 Oct 14 10:27:30.585: STP: VLAN0001 Fa0/1:0000 00 00 *01* 6001EC30915E0F00 00000000 6001EC30915E0F00 8003 0000 1400 0200 0F00 Oct 14 10:27:30.585: STP(1) port Fa0/1 supersedes 0 Cцуко, несколько часов коту под хвост.. вместо того чтобы дебаги толком включить - читал документацию... Почти как тут - " Дева побежит не к стадy. Он побежит в секс-шоп. По пyти освежит в памяти "Кама-Сyтpy". И когда добеpется-таки до того места, где пpоходило вожделенное стадо, yвы - коpов там yже не бyдет... Пpидется - опять! - заняться самообслyживанием. Листая пpедyсмотpительно кyпленный "Пентхаyз" :-) Андрей, спасибо за участие :) -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
participants (2)
-
Andrey Blochintsev -
Vladimir Litovka