STP/RSTPの動作確認経過

PCあ ----- L2 === L2 ---- PCい

基本的な802.1d STP
L2*2台の間に2本の渡りで最も単純な構成
ここでPC あ ---> PC い ping断時間のメモ


まず、L2間を1本だけ/カスケードの形から始める。

ここへ2本目のリンクを追加:STP構成に変わった場合のping断時間　29秒

次に
STP構成において
ブロックされていない方の渡りを切り離した場合　29秒

この渡りを戻した場合 28秒

ブロックされている側を切り離した場合　0秒

これを戻した場合 0秒
leaningからblockingまで15秒


次に、ブロックされる方の渡りの間に非CiscoなL2を介して。

STP構成において
ブロックされていない方の渡りを切り離した場合　1分21秒

この渡りを戻した場合　30秒

ブロックされている側のリンクをルートブリッジ側で切り離した場合　0秒

これを戻した場合 0秒

ブロックされている側のリンクをブロッキングポート側で切り離した場合　0秒

これを戻した場合 0秒


ここまでは基本的なSTPで、PC向けに特別な設定をしていない動作。



次の構成は

          L2(IEEE802.1d)
                 |
PCあ ----- L2(.1w) === L2(.1w) ---- PCい
 
.1dなL2と.1dなL2の間はリンク1本、.1wなL2間はリンク2本で。


ここで.1dなL2を切り離した場合、
.1wなL2配下につながっているPCあ－PCいの間のping断は　1分55秒

同じ時間帯ではPCあから.1wなL2それぞれへのping断時間も同様


.1dなL2をつなぎ直した場合。
PCあ から PCい へのpingほか .1wなL2へのpingそれぞれ断30秒

<----.1dなL2はルートブリッジになるMACアドレスを持っていたため、いったんこの存在は切り離してPCのみで確認続行。

ところがPC間のPingがSTP並みに落ちまくってちっとも高速コンバージェンスでないので何やこれは!? と思ったらPCの接続ポートで

*Mar  1 12:12:03.612: RSTP(1): transmitting a proposal on Fa0/5
*Mar  1 12:12:05.047: RSTP(1): Fa0/5 fdwhile Expired

なイベントが2回で都合30秒ほど通信が途絶されてしまっていた。これはどうやら

CCStudy  RSTPの設定
http://ccstudy.org/study/stp/rstp/rstp.html

こちら様に書かれている事象のようだ。つまるところ

spanning-tree mode rapid-pvst

と

L2間リンクポートの trunk 設定だけでは不足で、エンドノード向けのポートもいちいち設定しなくてはならないと、なるほど。


…と思ったら、この認識が全く正しくないようで。機器によっては、PCの接続ポートに対して spanning-tree portfast を明示的に設定せずとも、RSTPエッジポートとして動作する。この場合、PCを接続した当初こそ

RSTP(1): transmitting a proposal on …

なイベントは生じるが、リンクが確立した後は、RSTPのトポロジチェンジが発生してもいちいちプロポーザルな通信途絶は生じない。

ま、試している機器も古いので。大昔のCiscoの仕様ということで。



で、話を戻してコレ。


          L2(IEEE802.1d)
                 |
PCあ ----- L2あ(.1w) === L2い(.1w) ---- PCい

.1dなL2の接続時に、BPDUを受信して次のようなイベントが、


L2あ(.1w) の deb spa ev なログ

*Mar  1 12:43:05.623: RSTP(1): initializing port Fa0/1
*Mar  1 12:43:05.623: RSTP(1): Fa0/1 is now designated
*Mar  1 12:43:07.561: RSTP(1): updt rolessuperior bpdu on Fa0/1 (synced=0)
*Mar  1 12:43:07.628: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar  1 12:43:08.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
*Mar  1 12:43:09.558: RSTP(1): updt rolessuperior bpdu on Fa0/1 (synced=0)
*Mar  1 12:43:09.558: RSTP(1): Fa0/1 is now root port
*Mar  1 12:43:10.556: RSTP(1): Fa0/1 received a tc ack


L2い(.1w) の deb spa ev なログ

*Mar  1 12:42:42.832: RSTP(1): updt roles, received superior bpdu on Fa0/21
*Mar  1 12:42:42.832: RSTP(1): Fa0/23 is now designated
*Mar  1 12:42:42.832: RSTP(1): updt roles, received superior bpdu on Fa0/23
*Mar  1 12:42:42.832: RSTP(1): Fa0/23 is now alternate

この場合での、PC間のping断時間は3秒だった。では、切り離し時はどうなるかというと、PC間のping断時間は123秒にも及んだ。

L2あ(.1w) の deb spa ev なログ

Nov 16 16:51:17.077: RSTP(1): updt rolesroot port Fa0/1 is going down
Nov 16 16:51:17.077: RSTP(1): we become the root bridge
Nov 16 16:51:18.084: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
Nov 16 16:51:19.090: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down


L2い(.1w) の deb spa ev なログ

Nov 16 16:51:17.088: RSTP(1): updt roles, received superior bpdu on Fa0/21
Nov 16 16:51:17.088: RSTP(1): Fa0/23 is now root port
Nov 16 16:51:17.088: RSTP(1): Fa0/21 blocked by re-root
Nov 16 16:51:17.088: RSTP(1): Fa0/21 is now designated
Nov 16 16:51:17.088: RSTP(1): updt roles, received superior bpdu on Fa0/23
Nov 16 16:51:17.096: RSTP(1): transmitting a proposal on Fa0/21
Nov 16 16:51:17.096: RSTP(1): updt roles, received superior bpdu on Fa0/21
Nov 16 16:51:17.096: RSTP(1): Fa0/21 is now root port
Nov 16 16:51:17.096: RSTP(1): Fa0/23 blocked by re-root
Nov 16 16:51:17.096: RSTP(1): Fa0/23 is now alternate

イベントはコンマ何秒の世界。しかしping断は123秒。この時、L2あ、L2い それぞれから、pingの送信PC、受信PCに対してpingを実施すると、どれもOKである。しかし、PC間におけるpingは約2分間にわたってNG。

そこで、pingをツール上でなく コマンドで直接確認したところ

 ***からの応答: 転送中に TTL が期限切れになりました。
 ***からの応答: 転送中に TTL が期限切れになりました。
 ***からの応答: 転送中に TTL が期限切れになりました。
 ***からの応答: 転送中に TTL が期限切れになりました。


***は、PCあ 上の別NICのデフォルトG/W。そもそもRSTP側に投げてさえいなかった。別NIC側でレイヤ3のループとは、RIPルータ間の問題か。これ以前に、Windowsが別NICにトラフィックを流す時点で意味不明だが、何らかの仕様を私が知らないだけのことなのだろう。


別NICを殺し、あらためてRSTP側の動作を確認したところ、ping程度で落ちるような断はなかった。