無料ブログはココログ

トップページ | 2004年10月 »

【BFD】 6. BFDのまとめ

6. BFDのまとめ

BFDは隣接ルータの死活情報を高速に検知するための軽いプロトコルです。 物理層からの情報が得られない場合や、データリンクの診断が低速な場合に使用すると効果を発揮します。

動作の特徴

  • UDPポート3784を使用します(ソース・デスティネーション共に)。
  • BFDセッションはルータのペア間で基本的に一つです(正確にはIPv4用に1セッション、IPv6用に1セッション)。
  • クライアント(OSPFやIS-IS、LDP)は同じBFDセッションを共有します。
  • BFDセッションはDiscriminator値で識別します。この値は自動で決定します。
  • 3way-handshakeでセッションをネゴシエーションします。
  • 動作モードは2つあります。非同期モードは定期的に送信し、デマンドモードは必要に応じて送信します。
  • 加えて、(必要に応じて)エコー動作にすることができます。
  • パケットは固定長で動作は軽いです。
  • 動作が軽いのでハードウェア(フォワーディングプレーン)上に実装することもできます。その場合、制御プレーン(ソフト)が再起動しているときもセッションを維持できます。これによりGraceful Restartを成功させることができます。

この後もうちょっと詳細を書くかもしれませんが・・・とりあえず、おしまい。

2004年9月30日

【BFD】 5. BFDのセッション確立

5. BFDのセッション確立

前回の実験はどうやらパラメータ設計をミスってたようなので、再度実験しましょう。 OSPFのインタフェース設定を次のように変えてみます。

interface fe-0/0/0.0 {
    metric 10;
    bfd-liveness-detection {
        minimum-transmit-interval 200;
        minimum-receive-interval 100;
        multiplier 3;
    }
}

送信間隔として200msecを指定、multiplierを3とします。したがって600msecでセッションダウンとなります。 受信可能な最小間隔としては100msecを指定しておきます。

まずは、R2のBFDの設定を削除した状態から開始します。 R2にBFDの設定を投入してcommitした後、どのようにしてBFDセッションが確立されるのか観察してみます。

    R1           R2
    ---------------
          → BFD(My=9, Your=0), MinTx=1000, Diag=AdminDown
     1秒間隔
          → BFD(My=9, Your=0), MinTx=1000, Diag=AdminDown
     1秒間隔
          → BFD(My=9, Your=0), MinTx=1000, Diag=AdminDown

設定値に関わらず、BFD制御パケットは1秒に1回送信されてます。 Desired Min Txは1000(msec)になっています。 ICMP Port Unreachableとか出てないところを見ると、R2はパケットの認識はしているようです。

続いてR2で設定をcommitしてみます。

    R1           R2
    ---------------
          ← BFD(My=10, Your=0), MinTx=1000
          → BFD(My=9, Your=10), MinTx=1000, Diag=AdminDown
     1秒間隔
          → BFD(My=9, Your=10), MinTx=1000, Diag=AdminDown (再送?)
          ← BFD(My=10, Your=9), MinTx=1000, Message="I hear you"

      3way-handshakeによるネゴシエーション完了

          → BFD(My=9, Your=10), MinTx=200, Diag=AdminDown, Message="I hear you"
          ← BFD(My=10, Your=9), MinTx=200, Message="I hear you"
          → BFD(My=9, Your=10), MinTx=200, Diag=AdminDown, Message="I hear you"
          ← BFD(My=10, Your=9), MinTx=200, Message="I hear you"
          → BFD(My=9, Your=10), MinTx=200, Diag=AdminDown, Message="I hear you"
          ← BFD(My=10, Your=9), MinTx=200, Message="I hear you"

3way-handshakeでタイマー関連のネゴシエーションを完了すると、以降は定期的に制御パケットを投げ続けます。 エコーはしないので、R1→R2のパケット送信と、R2→R1のパケット送信は独立です。

Etherealのデータ

次に、Juniperのトレース機能を使って様子を観察してみます。 JUNOS6.4R1.6にはprotocols→bfdにトレースオプションがあります。

bfd {
    traceoptions {
        file bfd-trace;
        flag event;
    }
}

次のようにモニターを開始してから、セッションを一度クリアすると、 画面にデバッグ内容が表示されます。

gsi@R2> monitor start bfd-trace
gsi@R2> clear bfd session
gsi@R2>
*** bfd-trace ***
Sep 30 03:27:41 Session 192.168.2.1 (IFL 68) state Up -> Failing
Sep 30 03:27:41 Session 192.168.1.1 (IFL 67) state Up -> Failing
Sep 30 03:27:41 Session 192.168.2.1 (IFL 68) state Failing -> Down
Sep 30 03:27:41 Session 192.168.2.1 (IFL 68) state Down -> Failing
Sep 30 03:27:41 Session 192.168.2.1 (IFL 68) state Failing -> AdminDown
Sep 30 03:27:41 Session 192.168.1.1 (IFL 67) state Failing -> Failing
Sep 30 03:27:41 Session 192.168.1.1 (IFL 67) state Failing -> AdminDown
Sep 30 03:27:41 Session 192.168.2.1 (IFL 68) state AdminDown -> Failing
Sep 30 03:27:41 Session 192.168.1.1 (IFL 67) state AdminDown -> Failing
Sep 30 03:27:42 Session 192.168.1.1 (IFL 67) state Failing -> Down
Sep 30 03:27:42 Session 192.168.2.1 (IFL 68) state Failing -> Down
Sep 30 03:27:43 Session 192.168.2.1 (IFL 68) state Down -> Up
Sep 30 03:27:43 Session 192.168.1.1 (IFL 67) state Down -> Init
Sep 30 03:27:43 Session 192.168.1.1 (IFL 67) state Init -> Up

gsi@R2> monitor stop
gsi@R2>

【疑問】
JuniperでLocal Diagを消すコマンドが分かりません。

【Cisco Tips】 Q. OSPFのASEの種類

OSPF以外のルーティングプロトコルの情報をOSPFドメインへ注入すると、 OSPFドメイン内ではAS Externalという種類のLSA(入れ物)に格納されて伝搬していきます。

このASEにはメトリックタイプの違いで2つあり、type1とtype2に分類されます。 type1はOSPFドメイン内を伝搬するたびにOSPFのコストが足されていく形式、 type2は指定したメトリックのまま伝搬されていく形式の物です。 Ciscoルータのデフォルトはtype2です。

【Cisco Tips】 Q. redistribute connectedは必要ですか?

Ciscoルータはnetworkコマンドで指定したインタフェースのみそのプロトコルが活性化されます。 したがってnetworkコマンドで指定したレンジに入っていないインタフェースのアドレスはredistribute connectedしないといけません。 これがCiscoの基本です。

OSPFでredistribute connectedすると、AS外部経路という形式になってしまいますので、 できるかぎりnetworkコマンドでルータのインタフェースはすべてプロトコルを活性化しましょう。 端っこのネットワークはpassive interfaceの設定をすればよいのです。 基本的にredistribute connectedは不要です。

【Cisco Tips】 Q. スタティックルートはredistributeする必要ありますか?

RIP, IGRP系には不要です。OSPFには明示的に指定する必要があります。

【BFD】 4. BFDのパケット構造

4. BFDのパケット構造

せっかく実機で実験しましたので、BFDパケットをキャプチャしてみました。

Etherealのデータ

パケット1(R1→R2)

No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.1.1           192.168.1.2           BFD Control Diag: Control Detection Time Expired, Flags: 1000 .... = I Hear You

Frame 1 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:90:69:92:34:00, Dst: 00:90:69:61:30:00
Internet Protocol, Src Addr: 192.168.1.1 (192.168.1.1), Dst Addr: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: 3784 (3784), Dst Port: 3784 (3784)
    Source port: 3784 (3784)
    Destination port: 3784 (3784)
    Length: 32
    Checksum: 0x1034 (correct)
BFD Control message
    000. .... = Protocol Version: 0
    ...0 0001 = Diagnostic Code: Control Detection Time Expired (0x01)
    Message Flags: 1000 .... = I Hear You
    Detect Time Multiplier: 3 (= 150 ms Detection time)
    Message Length: 24 Bytes
    My Discriminator: 0x00000006
    Your Discriminator: 0x00000006
    Desired Min TX Interval:   50 ms
    Required Min RX Interval:  100 ms
    Required Min Echo Interval:    0 ms

パケット2(R2→R1)

No.     Time        Source                Destination           Protocol Info
      2 0.024687    192.168.1.2           192.168.1.1           BFD Control Diag: No Diagnostic, Flags: 1000 .... = I Hear You

Frame 2 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:90:69:61:30:00, Dst: 00:90:69:92:34:00
Internet Protocol, Src Addr: 192.168.1.2 (192.168.1.2), Dst Addr: 192.168.1.1 (192.168.1.1)
User Datagram Protocol, Src Port: 3784 (3784), Dst Port: 3784 (3784)
    Source port: 3784 (3784)
    Destination port: 3784 (3784)
    Length: 32
    Checksum: 0xd484 (correct)
BFD Control message
    000. .... = Protocol Version: 0
    ...0 0000 = Diagnostic Code: No Diagnostic (0x00)
    Message Flags: 1000 .... = I Hear You
    Detect Time Multiplier: 3 (= 150 ms Detection time)
    Message Length: 24 Bytes
    My Discriminator: 0x00000006
    Your Discriminator: 0x00000006
    Desired Min TX Interval:   50 ms
    Required Min RX Interval:   50 ms
    Required Min Echo Interval:    0 ms

BFDパケットはUDPポート3784です。 BFDの場合、ルータ間では1セッションしか動きませんので、ソース、デスティネーション共にポート3784を使います。 もう少し正確に言うと、IPv4用で1セッション、IPv6用で1セッション使用し、 クライアントは同じBFDセッションを共有します。 マルチホップのセッションを複数張ると、ポート番号では識別できません。 そのために導入されたのがDiscriminatorです。 BFDセッションは基本的にDiscriminatorで識別し、この値は自動です。

R1→R2とR2→R1のパケットの値が微妙に違いますね。その辺りを紐解いてみましょう。 ドラフト0版 によるとパケットフォーマットは次のようになっています。

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Vers |  Diag   |H|D|P|F|C|A|Rsv|  Detect Mult  |    Length     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       My Discriminator                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Your Discriminator                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Desired Min TX Interval                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Required Min RX Interval                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Required Min Echo RX Interval                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Versは共に0で、プロトコルバージョン0です。

Diagは診断用で、過去に何があったのか判断するのに使います。 R1→R2(1)のパケットにはビットが立ってます。 この具体的な値は次のように定義されています。

        0 -- No Diagnostic
        1 -- Control Detection Time Expired
        2 -- Echo Function Failed
        3 -- Neighbor Signaled Session Down
        4 -- Forwarding Plane Reset
        5 -- Path Down
        6 -- Concatenated Path Down
        7 -- Administratively Down
        8-31 -- Reserved for future use

R1でBFDセッションを表示してみると次のようになっています。 確かにLocal diagnosticsにCtlExpireが立っています。 一度セッションダウンを検出すると、以降はこのビットが立つようです。

gsi@R1> show bfd session detail
                                                          Transmit
Address              State     Interface     Detect Time  Interval  Multiplier
192.168.1.2          Up        fe-0/0/0.0          0.300     0.050      3
  Client OSPF, TX interval 0.050, RX interval 0.050, multiplier 3
  Session up time 15:52:24, previous down time 00:00:00
  Local diagnostic CtlExpire, remote diagnostic None
  Remote heard, hears us
192.168.2.2          Up        fe-0/0/1.0          0.150     0.050      3
  Client OSPF, TX interval 0.050, RX interval 0.050, multiplier 3
  Session up time 15:53:57
  Local diagnostic None, remote diagnostic None
  Remote heard, hears us

2 sessions, 2 clients
Cumulative transmit rate 40.0 pps, cumulative receive rate 30.0 pps

gsi@R1>

メッセージフラグ(HDPFCのフラグ)は、Hのみが立ってます。HはI Hear youです。

Detect Time Multiplierは3になっています。これは設定した通りです。

メッセージ長は24バイトです。固定ですね。

R1→R2のMy Discriminator=6、Your Discriminator=6です。
R2→R1のMy Discriminator=6、Your Discriminator=6です。

Desired Min TX Intervalはローカルシステムが希望する送信間隔(msec)です。 R1, R2共に設定値の50msecになっています。

Required Min RX Intervalはローカルシステムがサポート可能な、最小受信間隔です。 この値は特に設定してないのですが、
R1→R2は100 msec
R2→R1は50 msec
になっています。 なぜこのような違いがでるのか分かりませんが、とりあえず設定はまずそうです。 R2の送信間隔が50msecで、R1が受信できるのが100msecでは、性能不足でうまく動かないはずです。

Required Min Echo RX IntervalはBFD Echoパケットを受信できる最小間隔(msec)です。 この値がゼロの場合、BFD Echoパケットをサポートしていないことを意味します。

つづく。

【BFD】 3. BFDの実証実験

3. BFDの実証実験

BFDのあるなしでどのくらいダウンタイムを短くできるのか、実験してみます。 次の図で、R6からR2にCisco pingをうち続けます。 リンク①をダウンさせたときに、通信断がどのくらい続くか観察してみます。

BFDなしの場合
R6c7206#ping
Protocol [ip]:
Target IP address: 192.168.254.2
Repeat count [5]: 100000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 192.168.254.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
~途中省略~
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!..................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 99 percent (2232/2250), round-trip min/avg/max = 1/1/12 ms
R6c7206#

ドット(.)になっている部分が通信断時間で、ドット一つで2秒の通信断です。 BFDがない場合、通信断はおよそ40秒ってところです。 リンク①が抜けても、R1とR2はそれを検出しないので、 OSPF Helloのメカニズムでネイバーのロストを検出しなければならないためです。

BFDありの場合
R6c7206#ping
Protocol [ip]:
Target IP address: 192.168.254.2
Repeat count [5]: 100000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 192.168.254.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
~途中省略~
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (1449/1450), round-trip min/avg/max = 1/1/40 ms
R6c7206#

BFDを有効にすると、通信断時間は2秒程度でした。 たとえリンクダウンしなくても、BFDで隣接ルータの障害を検出できるためです。

つづく。

【BFD】 2. BFDの設定(Juniper)

2. BFDの設定(Juniper)

2004年9月時点でBFDを実装している機器はあまり多くないようです。 Cisco IOSには実装がないので、Juniperで試してみます。 といっても、機器がたくさんあるわけではないので、最低限の実験しかできません。 ここでは次の環境を作ってみました。

R1とR2はJuniper(JUNOS 6.2)で、FastEther×2で接続しています。 OSPFのコストを操作して、fe-0/0/0側を通るようにしています。 そしてJuniper間ではBFDを使うように構成します。

BFDの設定は次のようになります。

protocols {
    ospf {
        area 0.0.0.0 {
            interface fe-0/0/0.0 {
                metric 10;
                bfd-liveness-detection {
                    minimum-interval 50;
                    multiplier 3;
                }
            }
            interface fe-0/0/1.0 {
                metric 20;
                bfd-liveness-detection {
                    minimum-interval 50;
                    multiplier 3;
                }
            }
        }
    }
}

【参考】完全な設定 (R1, R2)

この設定で分かるように、実はBFDそのものの設定というのはありません。 クライアント(この場合はOSPF)でBFDを使うか、 使わないかの設定をインタフェースごとにするだけです。 BFDセッションの接続先の情報とか、いっさい不要です。

minimun-interval 50は50mSecごとにBFD Helloを送信することを意味します。 秒速20個のHelloを送信することになります。

multiplier 3は、3回来なければダウンと見なす、という意味です。

R1とR2に設定を入れてcommitすると、無事にBFDセッションがアップします。

gsi@R1# run show bfd session
                                                          Transmit
Address              State     Interface     Detect Time  Interval  Multiplier
192.168.1.2          Up        fe-0/0/0.0          0.150     0.050      3
192.168.2.2          Up        fe-0/0/1.0          0.150     0.050      3

2 sessions, 2 clients
Cumulative transmit rate 40.0 pps, cumulative receive rate 40.0 pps

[edit]
gsi@R1# run show bfd session detail
                                                          Transmit
Address              State     Interface     Detect Time  Interval  Multiplier
192.168.1.2          Up        fe-0/0/0.0          0.150     0.050      3
  Client OSPF, TX interval 0.050, RX interval 0.050, multiplier 3
  Session up time 00:08:04
  Local diagnostic None, remote diagnostic None
  Remote heard, hears us
192.168.2.2          Up        fe-0/0/1.0          0.150     0.050      3
  Client OSPF, TX interval 0.050, RX interval 0.050, multiplier 3
  Session up time 00:09:34
  Local diagnostic None, remote diagnostic None
  Remote heard, hears us

2 sessions, 2 clients
Cumulative transmit rate 40.0 pps, cumulative receive rate 40.0 pps

[edit]
gsi@R1#

秒速20ppsというと結構なトラフィック量ですよね。

さて、ここでいくつか疑問が沸いてきます。

疑問① Juniperはどうやってセッション相手を知るのだろう?

BFDの仕様ではオートディスカバリーは存在しないので、 クライアントからの要望でセッションを確立するはずです。 つまり、OSPFがBFDを使うように設定すると、 OSPF Helloで見つけたネイバーに対してBFDセッションを確立するわけです。

疑問② だとしたら、ブロードキャストセグメント上でのセッション確立はDRとの間だけなのだろうか?

おそらくYESだと想像しますが・・・
これは正直、確かめるのが難しい話しですね。少なくとも4台のルータがいないと確認できそうもありません。

ここではとりあえず先に進みましょう。 BFDを使うと、本当に高速に障害を検知して経路が切り替わるのか、確かめてみましょう。

つづく。

【BFD】 1. BFDについて

1. BFDについて

IETF Bidirectional Forwarding Detection WGで検討中のBFDについて考えてみたいと思います。

【参考】http://www.ietf.org/html.charters/bfd-charter.html

まずは、現実の世界でのBFDの存在意義について考えます。

隣接ルータへの到達可能性を素早く検知して意味があるのは、迂回路があるケースです。 迂回路がなければどうがんばっても通信は途絶えてしまうので、障害を素早く検知しても意味がありません。

相手ルータへのリーチャビリティを失ったら、それを契機として迂回動作を取る。 それをいかに短時間で行ってダウンタイムを短くするかがポイントなわけです。

BFDを使うと本当にダウンタイムが短くなるのか? 逆に言えば、普通にルーティングで迂回したら、実用にならないほど遅いのか、ってことですね。

ここではOSPFを使うことを想定してみます。

Ciscoの場合、SPF Delay=5秒がデフォルトなので、 ルータが障害を検知してから迂回するまで約5秒強で迂回可能です。 このタイマ値は設定変更可能なので、もっと短くできます。

Juniperはかなり強気でSPF Delay=0秒です。なので障害を検知すれば即、迂回可能です。 つまり障害を知りさえすれば、OSPFの切り替えは十分高速なのです。

問題は、ルータが隣接ノードの障害を知らずにいるケースというのはどの程度あるかということになります。

ケース1

一般的に問題だとされているのは、LANスイッチを経由した場合のリンク状態の伝搬です。 次のようなネットワークでR1のイーサ①がリンクダウンしたとします。 R1-R2間にはL2スイッチが介在していますので、R2はリンクダウンしません。

で、このケースでOSPFでのルーティングは遅いのでしょうか?

実際にやってみると分かるのですが、切り替えは高速です。 ほとんどパケットロスしません。 Juniperでやってみると、SPF Delayがゼロなので、瞬時に経路が切り替わります。 R1はリンクダウンと同時にルータLSAを作り直してフラッディングするからです。 迂回路さえあれば、そのLSAはR2にも届きますので、すぐに切り替わるわけです。

ということでこのケースにBFDの出番はありません。 (というよりも、こんなネットワーク自体、出番がありません)

ケース2

もう少し現実的なネットワークは、アップリンクが2本あって、別のルータに繋がっているケースでしょう。

この場合も、リンク①がダウンした程度では、BFDの意味はありません。 ルータR1が責任もってルータLSAを更新、フラッディングするからです。

では、ルータR1そのものが突然ダウンした場合はどうでしょう。

R3はリンクダウンしないので、R1は生きていると思っています。 R1からのOSPF Helloがしばらく来ないとRouter Dead Interval(普通40秒)に達します。 その時点でOSPFは経路を切り替えます。

どうやら、このケースでBFDは生きてきそうです。 R1-R3間でBFDを適用すれば、OSPF Helloに頼らず、相手ルータの死活状態を高速に検知できるからです。

ケース3

広域イーサ接続で、リンクステータスが伝わらないケースを考えてみましょう。

広域イーサ①に障害が発生すると、ルータR1,R3はリンクアップしているのに通信できないという状況に陥ります。

こういう場合もBFDは有効でしょう。

ただし、広域イーサにBFDの制御パケットを投げすぎると回線帯域を無駄に消費してしまいます。 現実的には使えないんでしょうね。

ケース4

L3スイッチ同士の接続で、レイヤ3から見たときのインタフェースがVLANになっている場合について考えてみます。

リンク①が抜けても、同じVLANに参加しているポートが他にあれば、VLANそのものはダウンしません。 したがって、L3SW1, L3SW2共にOSPF Helloを待って切り替えるしかありません。

このケースもBFDが有効に生きるでしょう。

ということで、BFDは場面を選べば使えそうです。

次は実機で試してみましょう。

つづく。

トップページ | 2004年10月 »