スイッチのMACアドレステーブルが消えるタイミング

以下のようなネットワークがあったとする。

MAC-Address-Table_01

このネットワークでTokyoからBostonをpingで60秒ごとに死活監視しているとする。
その時、このBostonをL2SW11からL2SW21へ差し替えたとする。
このBostonの死活監視は最大何分間downを検出するか。

的なことを考えた時、L2SW11のMACアドレステーブルは抜線のタイミングでLinkDownするので
テーブルが消えることはわかるのだが、L2SW01のMACアドレステーブルが消えるタイミングは
どうなんだっけ?と思って試験環境組んで試してみた。
(TokyoのデフォルトGWは172.16.1.200
BostonのデフォルトGWは10.1.1.200をそれぞれ指している。)

まず最初テーブルが空の状態から流れで考える。

  1. Tokyoは10.1.1.1にpingを送ると、自分と異なるセグメントへの送信なので、デフォルトGWへ送るためデフォルトGWのMACアドレスを問い合わせるARPを飛ばす。
  2. L3SW01は自身のFDBにTokyoのIPアドレスとMACアドレス情報をポートに紐づけて記憶し、ARP応答を返す。
  3. TokyoはARPテーブルにL3SWの情報を記憶し、宛先IP10.1.1.1、送信元IP:172.16.0.1、宛先MAC:3333:1111:2222、送信元MAC:AAAA:AAAA:AAAAのPingを送る。
  4. L3SW01はルーティング情報を参照し、宛先セグメントを判別する。その際FDB(ARPテーブル)にIPに対するMACアドレスが無いのでPingは破棄される。
  5. L3SWはPingを受信した以外のポートに対してBostonのIPアドレスのMACアドレスを問い合わせるARPを飛ばす。
  6. L2SW01は受信したARPをフラッディングすると同時にL3SW01のMACアドレス情報をMACアドレステーブルに記憶する。
  7. L2SW11は同様にARPをフラッディングとMACアドレステーブルの記憶を行う。
  8. L2SW21は送り先がないのでMACアドレステーブルの記憶とともにパケットを破棄して終わる。
  9. BostonはARPを受け取り、L3SW01の情報をARPテーブルに記憶すると同時に、自分のIP宛なのでMACアドレス情報をL3SWへ返す。
  10. L2SW11はBostonからのARP応答を受け取るとBostonのMACアドレスをMACアドレステーブルに記憶し、自分のMACアドレステーブルを参照し、L3SWのいるポートのみへパケットを返す。
  11. 同様にL2SW01もBostonのMACアドレスをMACアドレステーブルに記憶し、L3SWのいるポートのみへパケットを返す。
  12. L3SW01はARP情報を受け取ると、自身のFDBを更新する。4でpingを破棄しているのでここで一旦終わる。TokyoはPingがタイムアウトする。
  13. Tokyoから2度目のPingが送られる。宛先IP10.1.1.1、送信元IP:172.16.0.1、宛先MAC:3333:1111:2222、送信元MAC:AAAA:AAAA:AAAA
  14. L3SW01はFDBを参照し、宛先IP10.1.1.1、送信元IP:172.16.0.1、宛先MAC:BBBB:BBBB:BBBB、送信元MAC:3333:1111:1111に書き換え送信する。
  15. PingパケットはL2SW01、L2SW11を通り、Bostonへ届く。
  16. Bostonは応答パケットを宛先IP172.16.0.1、送信元IP:10.1.1.1、宛先MAC:3333:1111:1111、送信元MAC:BBBB:BBBB:BBBBで送信する。
  17. Bostonからの応答が、L2SW11、L2SW01、L3SW01へ届き、L3SW01はIP情報はそのまま、宛先MAC:AAAA:AAAA:AAAA、送信元MAC:3333:1111:2222で送信する。
  18. Tokyoにping応答が届く。

という流れになる。
(パケットかフレームかはどうせ分割されないサイズなので無視してね)
この一連の動作の後の状態は以下のような感じになる。

MAC-Address-Table_02

この状態で60秒に一回pingを送っているとする。
その時に、L2SW11のPort2からBostonに繋がっているLANケーブルを抜き、
そのLANケーブルをL2SW21のPort2へ挿す。
そうすると、L2SW11のMACアドレステーブルからはPort2がLinkDownするため、Bostonの情報が消える。
しかし、L2SW01のMACアドレステーブルはPort2がLinkUpしているままなので、情報はそのまま残る。

MAC-Address-Table_03

さて、この状態の時に、Tokyoから来たPingはどうなるかというと、

  1. Tokyoは、宛先IP10.1.1.1、送信元IP:172.16.0.1、宛先MAC:3333:1111:2222、送信元MAC:AAAA:AAAA:AAAAのPingを送信する。
  2. L3SW01は、宛先IP10.1.1.1、送信元IP:172.16.0.1、宛先MAC:BBBB:BBBB:BBBB、送信元MAC:3333:1111:1111に書き換え送信する。
  3. L2SW01は、MACアドレステーブルを参照し、Port2に対してパケットを送る。
  4. L2SW11は、MACアドレステーブルを参照しますが、宛先がわからないためフラッディングしようとします。しかし他に接続先がないのでここで破棄されて終わります(たぶん)。

L2SW01が新しい宛先(Port3)へパケットを送信するまで、上記のやり取りを繰り返しPingがタイムアウトし続けます。
そして、L2SW01のMACアドレステーブルのAgingTimeが経過すると、MACアドレステーブルの参照フラグをクリアします。
この参照フラグというのは、フレームの送信元MACアドレスとMACアドレステーブルのMACアドレスが一致したときにセットされるフラグです。
最初のPingの流れ(1~18)の中では、11のタイミングで、L2SW01のMACアドレステーブルのBostonのフラグがセットされます。
また、17のタイミングで受信した時にも送信元MACアドレス情報を見てMACアドレステーブルのフラグをセットします(この場合はすでにセットされていますが・・・)

そして、このAgingTime経過時にMACアドレステーブルのフラグがオフのMACアドレステーブルはレコードが消去されます。
デフォルトではMACアドレステーブルのAgingTimeは300秒なので、最大で599秒、最短では301秒程度、一度もMACアドレステーブルが
参照されなかったレコードは消去されます。

MAC-Address-Table_04

そして、L2SW01からMACアドレステーブルが消去されると、次にL2SW01がパケットを受け取った時には、宛先がわからないためフラッディングを行い、L2SW21にもパケットが送られます。そうすると、L2SW21も宛先がわからないのでフラッディングを行い、結果Bostonへpingが届きます。
BostonはPingの応答を返しますので、L2SW21、L2SW01のMACアドレステーブルに新たにレコードが記憶され、次のpingは正常にBostonの経路のみへ送られます。

MAC-Address-Table_05ちなみに、LANケーブルをL2SW21に接続した後に、Bostonから自発的にGARPやL3SW01へのPingなど送信を行えば、そのパケットの送信元MACアドレス情報でL2SW01のMACアドレステーブルは置き換えられ、Port2からPort3へ移ったことが反映されるので、pingの欠落無しで行けるはずです。

このあたりのMACアドレステーブルの動作について、L2SWひとつでの説明はよく見かけるのですが、このようにカスケード接続した際の動作があまりネット上に転がってなかったので、参考になれば幸いです。
もし誤りなどあれば指摘をお願いします。

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)