Zenn
🛑

RFC 8326: グレースフルなBGPセッションのシャットダウン

2024/03/06に公開
RFC
bgp
tech

要旨

本文書は、パスのグレースフルなシャットダウンを通知するために、新しいウェルノウンBGPコミュニティGRACEFUL_SHUTDOWNを標準化する。また、この文書では、計画されたメンテナンスなどでBGPピアリング・セッションが意図的にシャットダウンされようとするときに、このウェルノウン・コミュニティを使用して失われるトラフィックの量を軽減する運用手順についても説明する。

本文書の位置付け

本文書はインターネット標準化過程の文書である。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8326 で入手できる。

著作権表示

Copyright (c) 2018 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

BGPのルーティング変化は、計画的なメンテナンス作業によって起因する可能性がある。本文書は、BGPセッションを影響のない形で(グレースフル)にシャットダウンする管理オーバーヘッドを軽減する目的で、GRACEFUL_SHUTDOWNというウェルノウン(well-known)コミュニティ[RFC1997]を定義する。実装者は、ウェルノウン・コミュニティによって、メンテナンス時にルータの再設定を必要としない、自動化されたグレースフル・シャットダウンのメカニズムを提供することができる。

本文書では、メンテナンス作業中のパケット・ロスを軽減または取り除くために適用すべき運用手順について説明する。ロスは、2つの自律システム境界ルータ(ASBR)間のEBGPピアリング・セッションのシャットダウンに続く、BGPコンバージェンス中の一時的な到達不能によって発生する。

本文書では、フォワーディング・プレーンがメンテナンスの影響を受ける場合、つまりグレースフル・リスタートが使用できない場合の手順を説明する。

本文書に記載されている手順は、シャットダウンするピアリング・リンクを通って最初に転送されるアウトバウンドおよびインバウンド・トラフィック・フローのパケット・ロスを軽減または回避するために適用できる。どちらの自律システム(AS)も、これらの手順により、代替パスがAS内に存在する場合、代替パスが学習されるまで古いパスの使用が許可しながら、代替パスへの再ルーティングが始動する。これにより、ルータはコンバージェンス・プロセスの間、常に有効な経路を利用できるようになる。

⚠️ 本RFCについて

RFC 8326は、RFC 8327と対をなすもので、以下のようにまとめることができる。

  • RFC 8326: 自発的シャットダウン (あなたが行う)
    • メンテナンス作業前に、トラフィックを迂回させ、作業影響を最小限にするための行動
      • BGPシャットダウン通信(RFC 9003)を使用
      • グレースフルBGPセッション・シャットダウンを使用
  • RFC 8327: 非・自発的シャットダウン (ISP/IXP)
    • 下位層のネットワークのメンテナンス作業により、リンクはアップし続けるが、エンドツーエンドのパスが切断される。
    • BGPホールドタイマが切れた後、セッションがダウンする
    • トラフィックが再ルーティングされるまでの間、トラフィックがブラックホールになる可能性がある
      • ネットワーク・プロバイダがBGPカリングを使用

通常のシャットダウン(vanilla shutdown)でブラックホール化がいつ起こるかというと、

cfig1

  • ルータによっては代替パスがない
  • 一時的なルーティングの不整合が発生する
  • ルート・リフレクタは最適パスのみ伝播する可能性がある
  • バックアップASBRは、ノミナル・パスを優先するため、バックアップ・パスを広告しない

上記のシナリオでは、短時間のブラックホールが発生する。

次にグレースフル・シャットダウンの場合、以下のようになる。

cfig1

  • オペレータがメンテナンス作業前に、GRACEFUL_SHUTDOWNウェルノウン・コミュニティ(65535:0)を送信する。
  • 受信側のEBGPピアは、LOCAL_PREFERENCEを0に設定し、イニシエータからトラフィックをルーティングするパスを選択する。
  • BGPセッションがダウンした場合、代替パスがすでにインストールされているため、トラフィックへの影響を最小限に抑えることができる。

本文書の目的は、BGPを変更することなく、[RFC6198]に記述されている要件を可能な限り満たすことである。

IBGPセッションのシャットダウンやEBGPセッションの確立など、他のメンテナンスの事例は、本文書の範囲外である。情報提供の目的で、付録Cで簡単に説明する。

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

2. 用語

グレースフル・シャットダウン・イニシエータ
メンテナンスのためにセッション・シャットダウンが実行されるルータ。

グレースフル・シャットダウン・レシーバー
グレースフル・シャットダウン・イニシエーターでシャットダウンされるBGPセッションを持つルータ。

2. EBGPセッションの手動シャットダウンによるパケット損失

EBGPセッションを手動でシャットダウンすると、以下の2つの理由で、BGPコンバージェンス中にパケットが失われることがある。

まず、ルータによっては、影響を受けるプレフィックス向けのパスがなく、そのプレフィックス宛てのトラフィックをドロップしてしまうことがある。これは、代替パスがASのノードによって隠される可能性があるためである。[RFC7911]で定義されている拡張機能が使用されておらず、a) EBGPセッションでパスを受信するASBRがパスを最適として選択しない、またはb) ルート・リフレクタがパスを最適として選択しないため、IBGPトポロジ内でパスをさらに伝播しない場合に発生する。

第2に、AS内のルータ間でFIBに一貫性がなくなる可能性があり、AS内でカプセル化が使用しない限り、影響を受けるプレフィックスに向かうパケットがループしてドロップされる可能性がある。

⚠️ コメント

as-fib-inconsis

本文書では最初の理由のみを取り上げる。

4. EBGPグレースフル・シャットダウン手順

本セクションでは、EBGPピアリング・リンクをグレースフル・シャットダウンのための設定とアクションについて説明する。

この手順の目的は、ピア間でシャットダウンされるパスを保持することだが、LOCAL_PREF値を低くすることで、単にパスを撤回するのではなく、代替パスが選択され伝播される間、パスが使用され続けることを可能にする。LOCAL_PREF値は、どの代替パスよりも低くする必要がある(SHOULD)。推奨(RECOMMENDED)値は0である。

適用範囲が限定されるいくつかの代替手法が、情報提供の目的で付録Aで考察していることに留意する。

4.1. 事前設定

グレースフル・シャットダウン・レシーバーの手順をサポートする各ASBRでは、ASBRのすべてのEBGPセッションにインバウンドBGP経路ポリシーが適用される。そのポリシーは:

  • GRACEFUL_SHUTDOWNコミュニティに一致する。

  • GRACEFUL_SHUTDOWNコミュニティでタグ付けされたパスのLOCAL_PREF属性を低い値に設定する。

情報提供の目的で、付録Bに設定例を示す。

4.2. メンテナンス時の操作

グレースフル・シャットダウン・イニシエータでは、メンテナンス時にオペレータが次の操作を行う:

  • シャットダウンするEBGPセッションにアウトバウンドBGP経路ポリシーを適用する。このポリシーは、セッション上で伝播されるパスにGRACEFUL_SHUTDOWNコミュニティのタグを付ける。これがトリガーとなり、BGP実装は、前に広告したすべてのアクティブな経路を再広告し、GRACEFUL_SHUTDOWNコミュニティでタグ付けする。

  • シャットダウンするEBGPセッションにインバウンドBGP経路ポリシーを適用する。このポリシーは、セッション上で受信したパスにGRACEFUL_SHUTDOWNコミュニティのタグ付けをし、LOCAL_PREFを低い値に設定する。

  • EBGPセッション上で経路の再広告と、両ASBRでBGPルーティングの収束を待つ。

  • EBGPセッションをシャットダウンし、オプションで[RFC8203]を使用してシャットダウンの理由を伝える。

ルータ全体のシャットダウンの場合、すべてのEBGPセッションのグレースフル・シャットダウンに加えて、このルータが発信した経路(例えば、スタティック経路を含む他のプロトコルから再配布されたBGP集約)をグレースフル・シャットダウンする必要がある。これは、これらの経路にGRACEFUL_SHUTDOWNコミュニティをタグ付けし、LOCAL_PREFを低い値に設定することで実行できる。

4.3. グレースフル・シャットダウンのBGP実装のサポート

BGP実装者は、GRACEFUL_SHUTDOWNコミュニティを利用する設定ノブを提供し、差し迫ったネイバー・シャットダウンに備えてBGPネイバーに通知すべきである(SHOULD)。実装の詳細は、本文書の範囲外である。

5. IANAに関する考慮事項

IANAは以前、「BGP Well-known Communities」レジストリの「planned-shut」コミュニティにコミュニティ値0xFFFF0000を割り当てた。IANAは、名前「planned-shut」を「GRACEFUL_SHUTDOWN」に変更し、本文書を指すように参照を更新した。

6. セキュリティに関する考慮事項

ネイバーASにグレースフル・シャットダウン・サービスを提供することで、ISPはこのネイバーAS、そして場合によってはそのダウンストリームASに、このネイバーASから受信したパスに割り当てられたLOCAL_PREF値を下げる手段を提供する。

ネイバーはこの技術を利用(abuse)し、いくつかのプレフィックスがメンテナンス中であると宣言し、トラフィックを別のピアリング・リンクに切り替えることで、インバウンドのトラフィック・エンジニアリングを行うことができる。

この動作がISPによって許容されない場合、ISPはグレースフル・シャットダウン・コミュニティの使用を監視する必要がある(SHOULD)。

7. 参考文献

7.1. 引用規格

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <https://www.rfc-editor.org/info/rfc1997>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC6198] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., Elizondo Armengol, A., and T. Takeda, "Requirements for the Graceful Shutdown of BGP Sessions", RFC 6198, DOI 10.17487/RFC6198, April 2011, <https://www.rfc-editor.org/info/rfc6198>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. 参考規格

[BEST-EXTERNAL] Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. Gredler, "Advertisement of the best external route in BGP", Work in Progress, draft-ietf-idr-best-external-05, January 2012.

[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <https://www.rfc-editor.org/info/rfc7911>.

[RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP Administrative Shutdown Communication", RFC 8203, DOI 10.17487/RFC8203, July 2017, <https://www.rfc-editor.org/info/rfc8203>.

付録A. 適用範囲が限定される代替技法

グレースフル・シャットダウン機能を提供するために、いくつかの代替技法が検討されてきたが、適用範囲が限定されているため却下された。本セクションでは、参考のためにこれらの技法について説明する。

A.1. Multi-Exit Discriminatorの微調整

回避するパスのMulti-Exit Discriminator(MED)属性を増やすことで、ネイバーASのルータに影響を与えて他のパスを選択させることができる。

この解決策は、代替パスがLOCAL_PREF値とASパス長値に関して初期のパスと同程度である場合にのみ機能する。他のケースでは、MED値を増やしても、ネイバーASのルータの決定プロセスには影響しない。

A.2. IGP距離ポイズニング

維持されているセッションに対応するBGP NEXT_HOPまでの距離をIGPで大きくして、IGP距離タイブレーク・ルールの適用中に古いパスの優先度が下がるようにすることができる。しかし、この解決策は、LOCAL_PREF値、ASパス長、MED値に関して、代替パスが古いパスと同程度のパスに対してのみ有効である。

また、BGPの「NEXT_HOP self」が使用されている場合、IGPにはポイズニングするセッション固有のBGP NEXT_HOPが存在しないため、このポイズニングは適用できない。

付録B. 設定例

この付録は非・規範的(non-normative)である。

この付録には、ウェルノウンBGPコミュニティGRACEFUL_SHUTDOWNを受け取るためのルーティング・ポリシーの設定例が含まれている。

B.1. Cisco IOS XR

community-set comm-graceful-shutdown
  65535:0
end-set
!
route-policy AS64497-ebgp-inbound
  ! 通常、このポリシーにはもっと多くの記述がある
  if community matches-any comm-graceful-shutdown then
    set local-preference 0
  endif
end-policy
!
router bgp 64496
 neighbor 2001:db8:1:2::1
  remote-as 64497
  address-family ipv6 unicast
   send-community-ebgp
   route-policy AS64497-ebgp-inbound in

  !
 !
!

B.2. BIRD

function honor_graceful_shutdown() {
    if (65535, 0) ~ bgp_community then {
        bgp_local_pref = 0;
    }
}
filter AS64497_ebgp_inbound
{
        # 通常、このポリシーにはもっと多くの記述がある
        honor_graceful_shutdown();
}
protocol bgp peer_64497_1 {
    neighbor 2001:db8:1:2::1 as 64497;
    local as 64496;
    import keep filtered;
    import filter AS64497_ebgp_inbound;
}

B.3. OpenBGPD

AS 64496
   router-id 192.0.2.1
   neighbor 2001:db8:1:2::1 {
           remote-as 64497
   }

   # 通常、このポリシーにはもっと多くの記述がある

   match from any community GRACEFUL_SHUTDOWN set { localpref 0 }

付録C. EBGPのグレースフル・シャットダウンを超えて

C.1. IBGPのグレースフル・シャットダウン

IBGPセッションのシャットダウンの場合、セッションのメンテナンス後にIBGPトポロジが存続可能であれば(つまり、ASのすべてのBGPスピーカーが、このグレースフル・シャットダウンのIBGPセッションで広告されるすべてのプレフィックスに対するIBGPシグナリング・パスを持っていれば)、IBGPセッションのシャットダウンは一時的な到達不能につながることはない。結果として、特定のグレースフル・シャットダウン・アクションは必要ない。

C.2. EBGPセッションの確立

EBGPセッションの確立時に一時的なパケット・ロスが発生する原因として、2つの可能性が考えられる。1つ目は起動イニシエータにローカルなものである。2つ目は、IBGPトポロジ内に新しい最適パスを注入された後のBGPコンバージェンスによるものである。

C.2.1. ASBRローカルの到達不能

新しく確立されたEBGPセッションで受信したパスを最適パスとして選択するASBRは、一時的にトラフィックをドロップすることがある。これは通常、NEXT_HOP属性がEBGPピアのIPアドレスと異なり、受信ASBRがサードパーティのNEXT_HOPのIPアドレスに関連付けられたMACアドレスをまだ解決していない場合に起こる。

BGPスピーカーの実装は、サードパーティのNEXT_HOPを使用するパスをRIBにインストールする前に、サードパーティのNEXT_HOPが解決されていることを確認することで、このようなロスを回避してもよい(MAY)。

もう1つの方法として、オペレータ(スクリプト)はセッションを確立する前に、使用されると予想されるサードパーティのNEXT_HOPにpingを送信してもよい(MAY)。このように開始することで、これらのサードパーティNEXT_HOPに関連付けられたMACアドレスは、起動イニシエータによって解決される。

C.2.2. IBGPのコンバージェンス

EBGPセッションの確立中に、ルータが影響を受けるプレフィックスへのパスを持たず、接続性が失われる場合がある。

あるプレフィックスに対する一時的な到達不能の典型的な例を以下に示す:

3つのルート・リフレクタ(RR)、RR1、RR2、RR3を考える。その間に、IBGPセッションのフルメッシュがある。

  1. RR1は当初、IBGP RRフルメッシュのメンバーに現在の最適パスを広告している。そのパスはRRフルメッシュ内で伝播される。RR2は、そのプレフィックスに向かうパスしか知らない。

  2. RR3は、RRクライアントの1つである起動イニシエータが発信した新しい最適パスを受信する。RR3はそれを最適パスとして選択し、RRフルメッシュ内、つまりRR1とRR2にUPDATEを伝播する。

  3. RR1はそのパスを受信し、決定プロセスを再実行し、この新しいパスを最適なものとして選択する。その結果、RR1はRRフルメッシュのIBGPセッション上で、以前にアナウンスした最適パスを撤回する。

  4. 何らかの理由で、RR3がステップ2で生成された更新を処理する前に、ステップ3で生成された撤回を処理した場合、RR3は影響を受けるプレフィックスに対して一時的に到達不能に陥る。

⚠️ 参考図

ibgp1

ibgp2

ibgp3

ibgp4

IBGPフルメッシュのRR間で[RFC7911]または[BEST-EXTERNAL]を使用することで、AS内で新しい経路の広告が以前の経路の撤回に反映されないことを保証することで、このような特殊ケースを解決することができる。

実際には、最適な外部経路を広告することで、ASBRがIBGPセッション上で追加の優先パスを受信したときに、前に広告した(EBGP)パスを撤回しないことが保証される。また、最適なクラスタ内経路を広告することで、RRがIBGPセッションで新しい優先パスを受信したときに、RRの非・クライアント(例えば、RRのメッシュ内の他のRR)に対して、前に広告した(IBGP)パスを撤回しないことが保証される。

謝辞

著者らは、有益なコメントをくれたオリヴィエ・ボナバンチュール、プラドシュ・モハパトラ、ジョブ・スナイデルス、ジョン・ヒーズリー、クリストファー・モローに感謝する。

著者のアドレス

ピエール・フランソワ（編集者）
Individual Contributor
メール: pfrpfr@gmail.com

ブルーノ・デクレーン (編集者)
Orange
メール: bruno.decraene@orange.com

クリステル・ペルサー
Strasbourg University
メール: pelsser@unistra.fr

ケユル・パテル
Arrcus, Inc.
メール: keyur@arrcus.com

クラレンス・フィスフィルス
Cisco Systems
メール: cfilsfil@cisco.com

変更履歴

  • 2024.3.6
  • 2024.3.17: withdraw = 撤回
  • 2024.6.7: Errata追記
GitHubで編集を提案

Discussion