Zenn
🌟

RFC 8327: BGPセッション・カリングによるメンテナンスの悪影響を軽減

2024/03/06に公開
#
rfc
#
bgp
tech

要旨

本文書では、メンテナンス作業によって生じるネットワークへの悪影響を軽減するためのアプローチについて概説する。これには、IPネットワークとインターネット・エクスチェンジ(IXP)の両方に対するガイダンスが含まれている。このアプローチは、メンテナンスの影響を受けるBGP-4セッションを、実際のメンテナンス作業が始まる前に強制的に切断することを保証するものである。

⚠️ カリング(Culling)とは

カリング(Culling)とは辞書では、選別、淘汰を意味する。ウィキペディアで調べると、以下の語源の記述がある。

Cullは、「集める(to gather)」を意味するラテン語の動詞colligereに由来する。この単語は、コレクションを2つのグループ (残すグループと破棄されるグループ) に分けるという意味に広く適用できる。Cullingとは、選択の過程で不合格になった拒否されたアイテムのことである。選別の過程は、選択されたグループが適切な大きさと望ましい一貫性が得られるまで繰り返される。

本文書の位置付け

本文書は、インターネットのベスト・カレント・プラクティスを文書化したものである。

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

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

著作権表示

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

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

1. はじめに

BGPセッション・カリングとは、下位層ネットワークでメンテナンス作業(そうでなければ、BGPスピーカー間のデータフローに影響を与える作業)が開始される前に、BGPセッションを強制的に切断することを保証する慣行である。BGPセッション・カリングとは、下位層ネットワークでメンテナンス作業 (そうでなければ、BGPスピーカー間のデータフローに影響を与えるような)を開始する前に、BGPセッションが強制的に切断されるようにする慣行である。

BGPセッション・カリングは、下位層ネットワークのフォワーディング・プレーンが完全に動作し続けている間に、BGPスピーカーが代替パスの先手を打って収束させることで、下位層ネットワークのメンテナンス作業によって引き起こされる中断の量を最小限に抑える。

⚠️ BGPセッション・カリングの説明

BGPセッション・カリングは、主にIXPに適用してもらうもので、BCP 214にもなっている。IXPを利用する際、メンテナンス時にBGPセッション・カリング相当の対策を実施しているかを確認する。(BCP 214を実施していると明確に分かる国内のIXPは見つけられなかった。)

cfig1

  1. 下位層ネットワーク・プロバイダ(IXP)は、メンテナンス作業の開始前に、レイヤ4のACLを適用し、BGPコントロール・プレーンのトラフィックをブロックする
  2. データ・プレーンはトラフィックの転送を続ける
  3. BGPホールタイマが切れると、BGPは新しいパスを選択する
  4. その後、下位層ネットワークがメンテナンス作業を行い、作業が完了するとACLを削除する

BGPセッション・カリングをうまく適用するために必要な猶予期間は、BGPセッションの喪失を検出するのに必要な時間と、BGPスピーカーが代替パスに収束するのに必要な時間の合計である。最初の値は、BGPホールド・タイマー([RFC4271]のセクション6.5を参照)に左右されることが多く、一般的には90～180秒の間である。2つ目の値は実装に依存するが、コントロール・プレーンが遅いルータがインターネットのフル経路を受信している場合、15分程度になる可能性がある。

本文書全体を通じて、「ケアテイカー」は下位層ネットワークを管理するもの、「オペレータ」はBGPスピーカーを直接管理するものとして定義される。BGPセッション・カリングを実装するオペレータとケアテイカーは、固定猶予期間の使用を避け、代わりにカリングが行われている間、フォワーディング・プレーンのアクティビティを監視し、トラフィック・レベルが最小に下がった時点で完了とみなすことが推奨される(セクション3.3)。

2. 要件言語

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

3. BGPセッション・カリング

オペレータの視点から見ると、BGPセッション・カリングには2つのタイプがある。

自発的(Voluntary)なBGPセッションの停止(Teardown): オペレータは、管理シャットダウンを発行することによって、影響を受ける可能性のあるBGPセッションの停止を開始する。

非・自発的(Involuntary)なBGPセッションの停止: 下位層ネットワークのケアテイカーが(上位層)BGPコントロール・プレーン・トラフィックを中断し、影響を受けるBGPセッションのBGPホールドタイマーが期限切れとなり、その後エンドユーザ・トラフィックの再ルーティングを引き起こす。

3.1. 自発的なBGPセッションの停止に関する推奨事項

オペレータは、下位層ネットワークを通じてデータ・フローに中断を引き起こす恐れのある作業を開始する前に、下位層ネットワーク上で実行されているすべてのBGPセッションに対して管理シャットダウンを発行し、データプレーンのトラフィックが落ち着くまで数分間待機することで、トラフィックの損失を軽減することができる。

BGP Prefix Independent Convergence (PIC) [BGP_PIC]など、ネットワークの迅速な再コンバージェンスを促進するアーキテクチャは存在するが、オペレータはリモート側にそのような機能があるとは想定できない。そのため、管理シャットダウンと影響するメンテナンス活動の間には猶予期間を設ける必要がある。

メンテナンス作業が終了した後、オペレータはBGPセッションを元の管理状態に戻すことが期待される。

3.1.1. メンテナンスに関する考慮事項

管理シャットダウンのイニシエータは、セッション停止前にトラフィックのスムーズな排出を促進するためにグレースフル・シャットダウン[RFC8326]を使用すること、およびリモート側にメンテナンス作業の性質と期間を通知するためにシャットダウン通信 [RFC8203]を使用することを検討してもよい(MAY)。

3.2. 非・自発的なBGPセッションの停止に関する推奨事項

インターネット・エクスチェンジ・ポイント(IXP)でよく見られるように、BGPスピーカー間の多者間相互接続がスイッチド・レイヤ2ファブリックを通じて円滑になる場合、さまざまな運用上の考慮事項が適用されることがある。

運用経験によると、多くのオペレータは、必要な2つの設定変更を調整するための運用コストとリスクのために、自発的なBGPセッション停止の推奨事項を実行できない。これはインターネットのパフォーマンスに悪影響を及ぼす。

スイッチド・レイヤ2ファブリックで計画されたメンテナンス作業と一致する下位層からの通知(イーサネット・リンクダウンなど)がない場合、ファブリックのケアテイカーは、ファブリックに接続されているオペレータに代わってBGPセッションをカリングすることを選択できる。

このようなコントロール・プレーン・トラフィックのカリングは、ファブリックのケアテイカーの介入なしにBGPホールド・タイマーの期限切れが発生する時点よりも前に、期限切れを引き起こすことで、エンド・ユーザのトラフィックの損失を回避する。

このシナリオでは、BGPセッション・カリングは、次のサブセクションで説明するように、ケアテイカーのスイッチ・ファブリックに導入されたレイヤ3とレイヤ4(レイヤ3/4)を組み合わせたパケットフィルタを適用することで実現される。

3.2.1. パケットフィルタの考慮事項

IXPが使用するピアリングLANのプレフィックスはコントロール・プレーンを形成し、パケットフィルタの設計には以下の考慮事項が適用される。

  • パケットフィルタは、単に通過するだけのマルチホップBGPトラフィックではなく、レイヤ2ファブリックに固有のBGPトラフィック、つまり、説明したシステムのコントロール・プレーンの一部を形成するトラフィックにのみ影響を与えなければならない(MUST)。

  • パケットフィルタは、BGP、つまりTCPポート179にのみ影響しなければならない(MUST)。

  • パケットフィルタは、BGPの双方向性、つまり、セッションはどちらの方向にも確立される可能性があることを考慮する必要がある(SHOULD)。

  • パケットフィルタは、すべてのアドレス・ファミリ識別子に影響を与えなければならない(MUST)。

付録Aには、さまざまなプラットフォームに対する正しいパケットフィルタの例が含まれている。

3.2.2. ハードウェアに関する考慮事項

すべてのハードウェアが、レイヤ3/4フィルタを組み合わせてレイヤ2ポートに配置できるわけではない。そのような機能をサポートしていると主張するプラットフォームであっても、制限が存在したり、フィルタの展開中にハードウェア・リソースの割り当てに失敗したりすることがあり、予期しない結果を引き起こすことがある。これらの問題には以下のようなものがある。

  • プラットフォームは、既にレイヤ2フィルタが適用されているポートにレイヤ3/4フィルタを適用できない。

  • IPv4でレイヤ3/4フィルタはサポートされているが、IPv6ではサポートされていない。

  • 物理ポートでレイヤ3/4フィルタはサポートされているが、IEEE 802.1AXリンク・アグリゲーション・ポート[IEEE802.1AX]ではサポートされていない。

  • ケアテイカーがすべてのIEEE 802.1AXリンク・アグリゲーション・ポート[IEEE802.1AX]にフィルタを適用できない。

  • アクセス制御リスト(ACL)のハードウェア・メカニズムの制限により、フィルタが適用されない。

  • ACLルックアップ・メモリの断片化により、一時的なACL適用の問題が発生し、ACLの削除/再適用後に解決する。

  • ハードウェア・プログラミング中の一時的なサービスの損失。

  • プラットフォームでロスレスACLアプリケーションを有効にする場合、ハードウェアACL容量が減少する。

ケアテイカーは、ハードウェアの制限を認識し、本番への展開時に問題が発生しないよう、複雑な構成はすべて事前に徹底的にテストすることが望ましい。

3.3. 手続き上の考慮事項

下位層ネットワークのケアテイカーは、データプレーンのトラフィックを監視し(例えば、インタフェース・カウンタなど)、セッション・カリングが完了したら、トラフィックに影響を与えることなくメンテナンスを実行できる。

パケットフィルタはメンテナンスの間のみ導入し、メンテナンスが終了したら直ちに削除することを推奨する。不必要なトラブル・シューティングを防ぐため、ケアテイカーはメンテナンスが行われる前に影響を受けるオペレータに通知し、非・自発的なBGPセッション・カリング手法が適用されることを明示することが推奨される(RECOMMENDED)。

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

セキュリティに関する考慮事項はない。

5. IANA に関する考慮事項

本文書には IANAに対するアクションはない。

6. 参考文献

6.1. 引用規格

[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.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, https://www.rfc-editor.org/info/rfc4271.

[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.

6.2. 参考規格

[BGP_PIC] Bashandy, A., Ed., Filsfils, C., and P. Mohapatra, "BGP Prefix Independent Convergence", Work in Progress, draft-ietf-rtgwg-bgp-pic-06, November 2017.

[IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014, http://ieeexplore.ieee.org/servlet/opac?punumber=6997981.

[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.

[RFC8326] Francois, P., Ed., Decraene, B., Ed., Pelsser, C., Patel, K., and C. Filsfils, "Graceful BGP Session Shutdown", RFC 8326, DOI 10.17487/8326, March 2018, https://www.rfc-editor.org/info/rfc8326.

付録A. パケットフィルタの例

本セクションでは、ピアリングLANプレフィックス192.0.2.0/24と2001:db8:2::/64をコントロール・プレーンとして使用し、IXPで非・自発的BGPセッション停止を実行するパケットフィルタの例を示す。

さまざまなプラットフォーム用の設定例のリポジトリは、https://github.com/bgp/bgp-session-culling-config-examples にある。

A.1. Cisco IOS、IOS XR、およびArista EOSの設定例

ipv6 access-list acl-ipv6-permit-all-except-bgp
   10 deny tcp 2001:db8:2::/64 eq bgp 2001:db8:2::/64
   20 deny tcp 2001:db8:2::/64 2001:db8:2::/64 eq bgp
   30 permit ipv6 any any
!
ip access-list acl-ipv4-permit-all-except-bgp
   10 deny tcp 192.0.2.0/24 eq bgp 192.0.2.0/24
   20 deny tcp 192.0.2.0/24 192.0.2.0/24 eq bgp
   30 permit ip any any
!
interface Ethernet33
   description IXP Participant Affected by Maintenance
   ip access-group acl-ipv4-permit-all-except-bgp in
   ipv6 access-group acl-ipv6-permit-all-except-bgp in
!

A.2. Nokia SR OS の設定例

ip-filter 10 create
    filter-name "ACL IPv4 Permit All Except BGP"
    default-action forward
    entry 10 create
        match protocol tcp
            dst-ip 192.0.2.0/24
            src-ip 192.0.2.0/24
            port eq 179
        exit
        action
            drop
        exit
    exit
exit

ipv6-filter 10 create
    filter-name "ACL IPv6 Permit All Except BGP"
    default-action forward
    entry 10 create
        match next-header tcp
            dst-ip 2001:db8:2::/64
            src-ip 2001:db8:2::/64
            port eq 179
        exit
        action
            drop
        exit
    exit
exit

interface "port-1/1/1"
    description "IXP Participant Affected by Maintenance"
    ingress
        filter ip 10
        filter ipv6 10
    exit
exit

謝辞

著者らは、本文書に貢献してくれた以下の人々に感謝する: サク・イッティ、グレッグ・ハンキンス、ジェームズ・ベンズレー、ヴォルフガング・トレンメル、ダニエル・ローゼン、ブルーノ・デクレーヌ、トール・アンダーソン、ジョン・ヒーズリー、ウォーレン・クマリ、スティグ・ヴェナース、ブライアン・カーペンター。

著者のアドレス

ウィル・ハーグレイブ
LONAP Ltd
5 Fleet Place
London EC4M 7RD
イギリス
メール: will@lonap.net

マット・グリスウォルド
20C
1658 Milwaukee Ave # 100-4506
Chicago, IL 60647
アメリカ合衆国
メール: grizz@20c.com

ジョブ・スナイデルス
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
オランダ
メール：job@ntt.net

ニック・ヒリアード
INEX
4027 Kingswood Road
Dublin 24
アイルランド
メール: Nick@inex.ie

更新履歴

  • 2024.3.6
GitHubで編集を提案

Discussion