BGP in the Data Centerを読みました (2/6) : Chapter 2 - How BGP Has Been Adapted to the Data Center
今回は2章についてまとめました。 内容はeBGPのDCへの適用であり、RFC 7938に示されているものです。
データセンタネットワーク全般については、”Cloud-Native Data Center Networking” を読むのがおすすめです。 筆者が同じ方で、 "BGP in the Data Center" に記載されている内容も含まれています。 この本はCumulus Networksにより無償で公開されています。 ぜひ読んでみてください。
Download your copy of latest book by Dinesh Dutt, "Cloud Native Data Center Networking." It's a 400-page must-read for all network architects, developers and operators. Don't miss out! #CumulusResources https://t.co/JwAAiOHh1f pic.twitter.com/nVJUZyw67Z
— CumulusNetworks (@CumulusNetworks) 2020年1月13日
各Chapterまとめ
- Chapter 1 - Introduction to Data Center Networks
- Chapter 2 - How BGP Has Been Adapted to the Data Center
- Chapter 3 - Building an Automatable BGP Configuration
- Chapter 4 - Reimagining BGP Configuration
- Chapter 5 - BGP Life Cycle Management
- Chapter 6 - BGP on the Host
Chapter 2 - How BGP Has Been Adapted to the Data Center
BGPはこれまで主に、異なる管理ドメイン (グローバルAS) 間を接続するために、サービスプロバイダのネットワークで使用されてきました。 BGPをデータセンタ (DC) 内に適用するには、設定の変更が必要になります。
サービスプロバイダネットワークでは、ルーティング情報変更の迅速な通知よりも安定性が重視されます。 そのため、BGPは通常、変更に関する通知の送信を一定時間延期します。 一方のDCネットワークでは、ルーティングの更新をできる限りはやく通知することが望まれます。
DC内でBGPをルーティングプロトコルに採用するにあたって、次の懸念事項があります。
- BGPはパスベクタプロトコルのため、リンク障害が1箇所で発生したとしても、全ノード間で大量のBGPメッセージがやり取りされる可能性があります。
- BGPのデフォルトの挙動では、複数のAS番号 (ASN: AS Number) から経路情報が学習しても、単一のベストパスを選択します。 しかしDC内では、複数のベストパスを選択して、マルチパスを利用することが求められます。
DC内にBGPを適用するにあたっての、各挙動に対する変更とその理由について見ていきます。 BGPのDCへの適用はRFC 7938に示されています。
DC内ルーティングプロトコルの選択: eBGP
従来のネットワークでは主に、OSPFやIS-IS、EIGRP等のIGP (Interior Gateway Protocol: 組織内の経路制御で利用) で学習した AS内の経路情報を他のASにアドバタイズするために、BGP (eBGP: external BGP) が使われてきました。
しかし、DC内では経路制御にBGPのみを採用します。 BGPにはiBGP (internal BGP) とeBGP (external BGP) があります。
- iBGP: 同一ASN間で使用
- eBGP: 異なるASN間で使用
DCネットワークは単一の管理ドメイン下にありますが、一般的にeBGPを採用します。
eBGPはiBGPと比べ理解しやすくデプロイもしやすいです。 iBGPでは、ベストパス選択アルゴリズムがややこしいです。 またiBGPでは、同じ経路が2台のルータからアドバタイズされる条件下において、マルチパスのサポートに制限があります。 この場合でもマルチパスは実現可能ですが設定が必要です。
そして、2012年半ば当時、iBGPの実装にバグが多く、DC内に適用するには機能が不足していたとのことです。 当時のeBGPには、iBGPと比較してフル機能の堅牢な実装が複数存在していたようです。 実装が複数存在していたことにより、ベンダーロックインも回避しやすい状況でした。
ASN割り当て
全てのBGPノードにはASNの割り当てが必要です。ASNは次のような用途で利用されます。
- ルーティングループの検出
- プレフィックスへのベストパスの決定
- ネットワークへのルーティングポリシーの適用, 等
DC内ネットワークでは、従来のASN割り当てとは異なる手法を取ります。 DC内でeBGPを採用する場合に一番わかりやすいのが、ルータごとに異なるプライベートASNを割り当てる手法です。
インターネット上のピアリングでは、公的に割り当てられたASNを利用します。
DC内では、ほとんどのルータが外部の管理ドメインとBGPセッションを確立しないため、プライベートASNを利用します。
もしパブリックASNを使用して、誤設定により「DC内で他のパブリックASNに到達可能な AS_PATH を含む経路」を漏洩した場合、
事業者はBGP経路ハイジャックの責任が問われてしまいます。
ネットワーク障害の原因の多くが誤設定ですが、プライベートASNを利用することでBGP経路ハイジャックを回避できます。
なお、 AS_PATH からプライベートASNを削除するには、 remove-private-as のようなBGP設定を利用します。
4-byte ASN
ASNには、2-byte ASNと4-byte ASN (RFC 4893) があります。
- 2-byte ASN:
64512-65534(1023個のASN) - 4-byte ASN:
4200000000-4294967294(約9500万個のASN)
2-byte ASNを利用した場合、1024台以上のルータを使うには allowas-in を設定し、eBGPで自身と同じASNからの経路を許可する必要があります。
4-byte ASNであれば、個々のノードに一意のASNを割り当て可能です。ほぼ全てのBGP実装が4-byte ASNをサポートしています。
Path hunting
個々のノードに一意のASNを割り当てると、path huntingと呼ばれるパスベクタプロトコル特有の問題が発生してしまいます。
path huntingについて、R1から 10.1.1.1 への到達可能性を例に見ていきます。
図のトポロジにおいて、4台のノードはそれぞれ異なるASNが割り当てられているとします。
- (1) R2とR3がそれぞれプレフィックス
10.1.1.1への経路をR1にアドバタイズすると、AS_PATHの異なる2つの経路がR1のforwarding tableに設定されます。 R1はどちらか一方を10.1.1.1のベストパスに選択します。
- (2) R4のノードがダウンすると、R2は
10.1.1.1へのベストパスを失います。 するとR2は、自身のforwarding tableの情報に基づき再計算したベストパスを通知するBGP UPDATE、 および失った経路を削除するBGP withdrawnをR1に送信します。
この例ではR4がダウンするため、R3とR4の間のリンクもダウンしています。
しかしR2は、R3とR4の間のリンクがダウンしたことは認識できません。
そのため、他の経路 ( AS_PATH [R1, R3, R4] ) で 10.1.1.1 へ到達可能であると判断してしまいます。
- (3) R3も
10.1.1.1へのベストパスを失うので、10.1.1.1のBGP withdrawnがR1に届きます。
- (4) R1は
10.1.1.1への経路を削除しR2にBGP withdrawnを送信します。
このようにpath huntingが発生すると、経路情報が収束するまでの間に大量のBGP UPDATEメッセージの交換とベストパスの再計算が実行されます。 そして、ネットワーク内の経路収束に遅延が発生してしまいます。 また、誤った経路情報が必要以上に長くネットワーク内に伝搬し、トラフィックのロスが発生します。
高密度でノードが接続されるClosトポロジでは、path huntingは非常に大きな問題となります。
path huntingを回避するASN割り当てモデル
path huntingの問題を回避するには、Closトポロジで次のようなASN割り当てモデルを採用します。
先ほどの4台からなるネットワークトポロジにこのASN割り当てを適用すると次のようになります。
R1がspine, R2, R3がleaf, R4がToRに相当します。 R2とR3は同じASNが割り当てられます。ここでは図のようにASNを割り当てました。
R1がR2に対して、R3を経由する 10.1.1.1 への経路があることを伝えるには、 AS_PATH [65101 (R1) , 65000 (R2, R3) , 65001 (R4) ] が使われます。
eBGPでは通常、ループ防止のため自身のASNが AS_PATH に含まれる経路を学習しません。
それを踏まえて、先ほどのpath huntingが発生した状況を考えてみます。
R4がダウンして、R2とR3が10.1.1.1 宛の経路を失ったという状況です。
R2とR3はeBGPの AS_PATH によるループ検出ロジックにより、代替パスを計算しません。
R2とR3が 10.1.1.1 宛の経路を削除し、R1へ 10.1.1.1 のBGP withdrawnを送信するのみです。
そして全ルータから 10.1.1.1 宛の経路がforwarding tableから削除されます。
ASN割り当てモデルと経路集約
このASN割り当てモデルの欠点は、経路集約ができないことです。
R2とR3のASNが同じでかつ、
R4の配下に 10.1.1.1/32 から 10.1.1.250/32 までの250台のサーバが収容されている例で、経路集約について考えてみます。
R4の配下には 10.1.1.1/32 のみがあるとします。
R2とR3は、配下のToRを介して 10.1.1.1/32 から 10.1.1.250/32 までのプレフィックスを学習します。
するとR2とR3は、250個のプレフィックスを通知する代わりに、集約した1個のプレフィックス 10.1.1.0/24 のみをR1へ通知します。
この状況でR2とR4の間のリンクがダウンした場合を考えてみます。
R2とR3は同じASNを持つため、R2は AS_PATH [R1, R3, R4] を使用して 10.1.1.1/32 に到達することはできません。
R2では 10.1.1.1/32 がforwarding tableから削除されます。
R1はR2とR3から 10.1.1.0/24 宛のパスを計算しました。
10.1.1.1 宛のパケットを受信すると、 10.1.1.1 に到達できなくなってしまったR2に転送する可能性があります。
そしてR1からR2にパケットが転送されると、ドロップが発生します。
R2とR3が経路集約せずに250プレフィックスの経路情報を個別に送信する場合、
R2は 10.1.1.1/32 に対する経路の削除とBGP withdrawnの送信をして、残りの249プレフィックスの経路情報は保持します。
そしてR1は、R3を経由する 10.1.1.1/32 への経路を保持し続けることで到達可能性を維持できます。
なお、残りの249プレフィックスに対しては、R1はR2を経由したパスとR3を経由したパスのそれぞれを保持します。
このように、path huntingを回避するASN割り当てモデルを採用すると経路集約ができません。
ベストパス選択アルゴリズム
BGPでは、アルゴリズムを使用してノードから特定のプレフィックスへのベストパスを計算します。 BGPのベストパス選択アルゴリズムは、1つ以上のピアから新たにBGP UPDATEメッセージを受信したタイミングで実行されます。 なお、すぐにベストパス選択を実行せずに、バッファリングして一度に処理することも可能です。
OSPFやIS-ISなどのルーティングプロトコルには、どのパスを転送に利用するか決めるための簡単なメトリックがあります。 BGPの場合、次のような8つのメトリックがベストパス選択に利用されます。
| フェーズ | 項目 | 内容 |
|---|---|---|
| 1 | WEIGHT |
最大のパスを優先 (Cisco独自) |
| 2 | LOCAL_PREF |
最大のパスを優先 |
| 3 | Locally Originated | 自信から広告, 経路集約して広告, IGPからの再配布するパスを優先 |
| 4 | AS_PATH |
長さが最小のパスを優先 |
| 5 | MED |
最小のパスを優先 |
| 6 | ORIGIN |
最小のパスを優先。IGP: 0, EGP: 1, Incomplete: 2 |
| 7 | eBGP over iBGP | eBGPパスをiBGPパスより優先 |
| 8 | NextHop IGP Cost | IGPで最小コストのパスを優先 |
上の項目ほどベストパス選択における優先度が高いです。 (RFC 4271 Section 9)
なお、8つのメトリックのうちDC内eBGPで重要なのは AS_PATH のみです。
マルチパスの選出
Closネットワークのように接続密度が高いネットワークにおいて、 ロバスト性がありスケーラブルなネットワークを構築するためには、マルチパスが必要です。
等価なパスをマルチパスとして採用するECMP (Equal-Cost Multi-Path) を利用するのが一般的です。 なおBGPでは、パスのコストが等しくなくてもマルチパスとみなす機能がサポートされています。 しかし、この機能は全ての実装でサポートされているわけではないようです。
先ほどの表の8つの項目それぞれで値が等しい場合、その2つのパスは等価であるとみなされます。
AS_PATH については、長さが等しいだけでなく、含まれるASNリストが一致する必要があります。
では、DC内で異なるASNから同じ経路がアドバタイズされるデプロイシナリオを見ていきます。 2台のToRの下にサーバが1台接続されている、デュアルアタッチ接続モデルです。 この例では、サーバでBGPを利用していません。図の楕円はport-channelやbondingを示しています。
2台のToRが、それぞれ 10.1.1.0/24 のサブネットをアドバタイズする例を考えます。
各leafは 10.1.1.0/24 への経路をToRから受信します。
lleafが受信する経路の一方は AS_PATH [65001] で、もう一方は AS_PATH [65002] です。
ECMPのロジックでは、 AS_PATH に含まれるASNリストが同じである必要がありますが、この例ではASNリストが異なります。
そのため、各leafから 10.1.1.0/24 へはマルチパスになりません。
2つあるパスうち1つのみがベストパスに選出されます。
この問題に対処するために、DCネットワークのBGPでは、ベストパス選択アルゴリズムの設定を変更する必要があります。
設定するのは bestpath as-path multipath-relax です。
AS_PATH の長さが同じであれば、 AS_PATH 内のASNリストが一致するかのチェックを飛ばして、
次の項目が一致するかチェックしていきます。
デフォルトのタイマー設定によるBGPの経路収束時間の遅さ
BGPのパラメータを明示的に設定するのを避けるために、設定していない項目に対しては安全なデフォルト値が設定されます。 タイマーは、明示的に値を設定しない場合にデフォルト値が設定される一般的な項目です。
タイマーはBGPピア間の通信間隔を制御します。 BGPのタイマーのデフォルト値はサービスプロバイダーネットワーク用に調整されており、高速な経路収束よりも安定性が優先されています。 しかしDC内では、安定性よりも高速な経路収束が重要です。
障害発生時や障害からの復旧時に経路収束する速度を制御するタイマーが4つあります。 このタイマーの値を調整することで、OSPFなどと同等の経路収束速度をDC内のeBGPで達成できます。
Advertisement Interval
BGPのネイバーごとに、BGP UPDATEメッセージを送信する間隔を設定するためのタイマーです。 advertisement interval時間内のイベントはまとめられ、一定時間経過後にUPDATEメッセージが送信されます。 短時間で複数の更新が行われた場合でも、不要なベストパスの計算を避けることができます。
advertisement intervalのデフォルト値はeBGPピアで30秒、iBGPピアで0秒です。 DC内ネットワークはひとつの管理ドメインであるため、eBGPでもiBGPピアと同じ0秒にするのが適切です。
この設定変更により、eBGPの収束時間をIGPに近づけることができます。
Keepalive TimerとHold Timer
全てのBGPセッションにおいて、ノードは定期的にkeepaliveメッセージを送信します。 ピアがhold timeの間にkeepaliveメッセージを受信しない場合、 BGPセッションがダウンし、そのセッションで受信した情報を全て破棄します。
keepalive timerのデフォルト値は60秒、hold timerのデフォルト値は180秒です。 そのため、ノードは毎分keepaliveメッセージを送信します。 そして、ピアが3分間でkeepaliveメッセージを1つも受信できない場合、BGPセッションがダウンします。
eBGPのピアは1ホップしか離れていないため、リンク障害が発生して検知されるとすぐにBGPセッションがダウンします。 なので、keepalive timerとhold timerが検知するのは、リンクアップしていても通信ができないケーブルの問題やBGPプロセス自体のエラーなどです。
ケーブルの問題を1秒以内に検出するには、BFD (Bidirectional Forwarding Detection) をリンク間で有効化し、 BFDによるリンク障害検知をBGPデーモンに通知します。
ですが、BGPプロセス自体のエラーを検知するには、keepalive timerとhold timerを調整する必要あります。 DC内で設定される一般的な値は、keepalive timer 3秒、hold timer 9秒です。
Connect Timer
BGPピアとの接続に失敗した場合に、一定時間待機してから再接続を試みるのに使用されます。
connect timerはデフォルト値が60秒です。 BGPがピアとセッションを確立するまで1分間待機します。
connect timerを調整することで、リンク障害からの復旧やノードの再起動後にBGPセッションを確立するまでの時間を早めることができます。 ただ、4つのタイマーの中では重要度が一番低いです。
DC内のBGPのデフォルト設定
異なるグローバルASN間のように管理境界や信頼境界を越える場合は、全ての項目を明示的に設定するのがベストです。
一方のDC内ネットワークはひとつの管理ドメイン内です。
FRRoutingのようなDC向けのオープンソースルーティングスイートではDC向けにデフォルト値が設定されているため、
ユーザが明示的に多くの設定をする必要がありません (frr/defaults.h等) 。
機器のconfigが短く済むので、設定確認が簡単で管理しやすく、自動化でも有利です。
FRRoutingにおけるBGPのデフォルト設定は次のとおりです。
- eBGPとiBGPでマルチパスが有効
- Advertisement interval 0秒 (
BGP_DEFAULT_EBGP_ROUTEADV) - Keepalive timer 3秒 (
DFLT_BGP_KEEPALIVE) , Hold timer 9秒 (DFLT_BGP_HOLDTIME) - Logging adjacency changesが有効 (
DFLT_BGP_LOG_NEIGHBOR_CHANGES)
Chapter 2 まとめ
- DC内IP Closネットワークでは一般的にeBGPを採用
- DC内にeBGPを適用するために次の設定を採用
- 全ノードに一意のASNを割り当てるため4-byte プライベートASNを利用
- path huntingを防止するようにASNを割り当て
- 異なるASNからのパスをマルチパスに選択 (
bestpath as-path multi-relax) - 経路収束時間を短くするためにタイマーを調整
