ルーティングと BGP

ルーターが同一プレフィックスへの2つのパスを受信した場合、AS_PATH が短いパスと、より高いローカルプリオリティを満たすパスのどちらかがある。後者が選ばれる可能性がある。しかし、宛先アドレスがより具体的なプレフィックスにも一致する場合、実際の転送ではより具体的なルートが使用される。ルーティングを理解するには、「同一プレフィックスに対する候補パスの選択」と「宛先アドレスに対する最長プレフィックスマッチング」を区別することが重要である。

RIB と FIB：候補情報と転送結果

RIB はルーティング情報の論理的な整理であり、FIB は実際の転送を対象とする。BGP ではさらに、ネイバーから受信した Adj-RIB-In、ローカルで選択された Loc-RIB、およびネイバーへアドバタイズするための Adj-RIB-Out を区別する。これらはプロトコルモデルであり、すべての実装が3つの完全に独立したデータ構造をそのまま保持する必要があるわけではない。RFC 4271：ルーティング情報モデル

Linux ソフトウェアルーティングのシナリオでは、FRR などのデーモンはカーネルインターフェースを介してルートをインストールできる。ハードウェアデバイスでは、さらに ASIC への設定が必要になる場合もある。RIB にルートがあっても、ネクストホップが解決できるとは限らず、インストールが成功するとも限らない。FIB にルートがあっても、出口ネイバーや戻り経路が正常であるとは限らない。

最長プレフィックスマッチはセマンティクスであり、trie、圧縮階層、ハードウェアテーブルなどは実装である。Linux の LC-trie を、規模やアクセス条件にかかわらず常に O(1) と簡略化することはできない。また、絶えず変化するグローバルプレフィックスの総数だけですべてのルーターのメモリ要件を記述することもできない。ネイバー数、アドレスファミリー、候補パス、ポリシーも同様に重要である。

最長プレフィックスを正しく計算する

同じテーブルにデフォルトルート、203.0.113.0/24（A経由）、203.0.113.128/25（B経由）があると仮定する。ターゲット .140 は3つすべてに一致するが、/25（B経由）が選択される。ターゲット .20 は /24（A経由）が選択される。/24 の BGP LOCAL_PREF が高くても、インストール済みの /25 の最長プレフィックスの優位性を上回ることはない。

クロスプロトコルの優先度は、通常、同一プレフィックスの候補競争を解決するために使用され、あるデバイスのスタティックルートの管理距離を、異なる長さのプレフィックスを持つ別のルートと混在して計算すべきではない。ルート集約によりエントリが減少すると、カバーされる範囲が広がるため、より具体的なルートが欠如している場合にトラフィックがブラックホールに流れ込まないかどうかを考慮する必要がある。

Linux ポリシーベースルーティング：まずどのテーブルを参照するか決定する

RPDB はルール優先度に基づいて小さい順に処理され、ソースアドレス、fwmark、入力インターフェースなどに基づいてアクションを選択できる。ルールがマッチするとテーブル参照が実行され、終了結果が得られない場合は、後続のルールが続く可能性がある。したがって、「最初にマッチしたルールが必ず終了する」とは限らない。throw ルートは現在のテーブルの参照を終了してルールチェーンを続けることができ、blackhole、unreachable などは異なる終了セマンティクスを持つ。ip-rule マニュアル、ip-route マニュアル

一般的なプリセットルールは、local（255）、main（254）、default（253）の順に参照する。名前が default のテーブルはデフォルトルートを意味しない：0.0.0.0/0 または ::/0 は main や他のテーブルに存在しうる。カスタムテーブル番号も 1～252 に限定されない。

例えば、あるソースプレフィックスがまずテーブル 100 を参照し、テーブル 100 にマッチするルートがない場合は、main を参照し続けることができる。テーブル 100 にデフォルトルートがある場合、通常はすでに結果が得られているため、main 内のより具体的なルートを探すために参照を続けることはない。⁠最長プレフィックスの比較は、現在の参照コンテキスト内で発生し、すべてのテーブルをマージしてソートするものではない。

# 読み取り専用観察コマンド。実際のインターフェース、ターゲット、ソースアドレスは環境に応じて置き換えること。
ip rule show
ip route show table all
ip route get <ターゲットIPv4> from <ソースIPv4>
ip -6 route get <ターゲットIPv6> from <ソースIPv6>

より具体的なルートが、なぜ参照されないことがあるのか？

main テーブル内のマッチ範囲を常に図に残し、クエリ記録が本当に main に到達したかどうかを確認する。これにより、宛先アドレスが /25 にヒットしても C 経由で転送されるという状況が、ルール終了条件によって説明でき、最長プレフィックスルールを誤って修正する必要がなくなる。

IGP：リンクコストをパスに累積する

OSPF と IS-IS は、それぞれの範囲内でリンクステートを伝播し、パスを計算する。コストは設定されたメトリクスを表し、測定されたレイテンシと一致する必要はない。単一エリアの簡略化されたトポロジーを例にとると、A→B のコストが 10、B→D が 10、A→C が 5、C→D が 30 の場合、B 経由の合計は 20 で、C 経由の 35 より優れている。A→B が失敗した後、C 経由のみが新しい利用可能な最短パスとなる可能性がある。RFC 2328：OSPFv2

実際の収束には、障害検出、ステート伝播、SPF スケジューリング、転送テーブルの更新が含まれる。エリア構造、ルートタイプ、ポリシーにより、さらに多くのルールが追加される。Dijkstra アルゴリズム自体から、固定されたネットワーク全体の切り替えミリ秒数を導き出すことはできない。IGP はまた、BGP NEXT_HOP のドメイン内到達可能性を提供するためにもよく使用され、両者は共同で動作する。

BGP セッション：TCP が接続できたのは始まりに過ぎない

BGP は TCP 179 を使用し、その後 OPEN、KEEPALIVE、UPDATE などのメッセージを交換してプロトコル状態を確立する。OPEN 内のバージョンは 4 であり、BGP Identifier は 32 ビットの識別子であるが、セッションエンドポイントアドレスである必要はない。Hold Time は双方のパラメータでネゴシエーションされ、非ゼロ値は少なくとも 3 秒である。ネゴシエーションでゼロの場合、対応する Hold/Keepalive タイマーは実行されず、一律に 90/30 秒と記述することはできない。

基本 OPEN の My Autonomous System フィールドは依然として 2 バイトである。4 バイト ASN は、能力ネゴシエーションと互換性メカニズムによってサポートされ、単にこのフィールドを長くするわけではない。RFC 6793：4バイトASNUPDATE はプレフィックスをアドバタイズまたは撤回し、属性を保持する。マルチプロトコル拡張は、対応する属性を使用して異なるアドレスファミリーを保持し、IPv4 ユニキャストの基本レイアウトをすべての MP-BGP メッセージに無理やり適用することはできない。

セッションが Established であってもルートがない場合、アドレスファミリーが無効になっている、インポートポリシーで拒否された、またはピアがエクスポートしていない可能性がある。必ずしも TCP 障害ではない。RFC 8212 は eBGP のデフォルトインポート/エクスポートポリシーの制限について述べている。実際の製品では、バージョンと設定モードも確認する必要がある。RFC 4271、RFC 8212：明示的なeBGPポリシー

選路：候補テーブルを用いて優先度を説明する

この例では、両方のパスが有効で、NEXT_HOP が解決可能であり、より早期のローカル属性の差異は発生していない。A の LOCAL_PREF=200 は B の 100 より高いため、A の AS シーケンスが長くても A が選択される。A を 100 に変更すると、他の前続条件が同じ場合にのみパス長が比較され、B が選択される。

使用している実装ドキュメントから、完全な順序とスイッチを確認する必要がある。例えば、FRR の MED 比較、マルチパスの緩和、router-ID に関連するオプションは結果に影響を与える。教育では、明確な仮定に基づいてのみ候補の推論を行い、Cisco、Huawei、FRR のルールを1つの標準アルゴリズムとして混同しないようにする。FRR BGP 選路ドキュメント

パスが短いのに、なぜ選択されないのか？

まず、高い LOCAL_PREF を用いて A の長いパスを相殺し、その後、好意を同じ値に調整することで、後続の条件が機能し始める様子を確認できる。ネクストホップの到達可能性を無効にすると、A はこれらの2つの数値比較に入る前に除外される。図の順序は、ここで明確に限定された候補セットのみを表す。

ループ防止、iBGP とルートリフレクター

通常の eBGP アドバタイズでは、ローカル AS がパスに追加され、ローカル AS を含むパスを受信した場合、通常は除外される。iBGP は、同一 AS 内での伝播において、ローカル AS を繰り返して追加しない。このメカニズムは AS 単位のルートループを抑制するが、データプレーン全体のループや誤ったポリシーチェックを代替するものではない。

従来の iBGP では、1人の iBGP ネイバーから学習したルートは、他の iBGP ネイバーに直接アドバタイズされないため、単純な相互接続では、完全な伝播が自動的に形成されるわけではない。フルメッシュ、ルートリフレクター、アソシエーションは、それぞれ規模または組織の問題を解決するために使用される。リフレクターは、ORIGINATOR_ID、CLUSTER_LIST などの追加メカニズムに依存して、対応するリフレクターループを防止する。RFC 4456：ルートリフレクター

iBGP セッションはマルチホップで確立できるが、ルート内の NEXT_HOP は依然として再帰的に解決可能でなければならない。next-hop-self は、ネクストホップアドバタイズを変更するためのポリシーオプションであり、すべてのデプロイメントで無条件に有効にする必要があるわけではない。

コミュニティとトラフィックエンジニアリング：ラベルにはポリシーによる解釈が必要

通常の Community は 32 ビットであり、通常、2つの 16 ビット 10 進数値として表記される。Extended は 8 バイト、Large は 12 バイトであり、これらが単に表示形式が異なるだけであると考えることはできない。RFC 8092：Large Communities 通常のラベルには自動アクションがなく、双方がマッチングとポリシー適用方法を合意する必要がある。

NO_ADVERTISE は、任意の BGP ネイバーへのアドバタイズを制限する。NO_EXPORT の境界はコンファederation 境界であり、あらゆる形式の eBGP セッションでの伝播禁止と単純に等価視することはできない。コンファederation 内部では、NO_EXPORT_SUBCONFED などのセマンティクスを区別する必要がある。RFC 1997：標準コミュニティ

AS_PATH prepend は、特定パスの見かけ上の長さを増加させ、遠端のインバウンド選択に影響を与える可能性があるが、遠端の LOCAL_PREF が先に結果を決定する可能性がある。したがって、「prepend を2回行えば、必ず別の出口に切り替わる」とは限らない。アウトバウンドの好意は、自分のポリシーによって直接制御されることが多い。インバウンドは通常、アドバタイズと合意を通じて相手に影響を与えることしかできない。

ECMP：分散されるのはハッシュ結果であり、正確なバイト割り当てではない

複数の条件を満たすネクストホップを FIB にインストールでき、アドレス、ポート、Flow Label、または選択された他のフィールドに基づいてハッシュ処理される。使用するフィールドは、プロトコルファミリー、カーネル、および設定によって異なる。Linux ドキュメントでは fib_multipath_hash_policy が提供されており、常にソース/宛先 IP のみを使用するわけではない。

安定したメンバーセットとハッシュポリシーの下では、同一フローは順序化を減らすためにパスの一貫性を保つ。メンバーの増減やルートの変化により、フローのマッピングが再実行される可能性がある。重みが 2:1 であっても、大規模フローのサイズが不均等であると、実際のバイト量は 2:1 から遠ざかり、単一接続が2つのリンクの合計スループットを得ることはさらに保証されない。Linux マルチパスハッシュ設定

収束と起源検証：緑色のセッション状態だけを見てはいけない

1つのパスが失效した後、デバイスは検出、撤回または候補の除外、再選路、FIB のインストールを行い、変更を他のノードに伝播する必要がある。BFD などのプロトコルは検出プロセスを変更できるが、チェーン全体のオーバーヘッドを消除するものではない。Graceful Restart は旧転送テーブルの仮定を保持するが、成立しない場合、状態の保持がブラックホールを延長する可能性がある。

RPKI 起源検証は、ルートプレフィックス、起源 AS、および権限情報を比較し、Valid、Invalid、NotFound を得る。Valid は、AS_PATH 全体を検証するものではなく、ルートリークが存在しないことを保証するものでもない。NotFound は、明確なエラーを意味するものではない。破棄するか優先度を調整するかは、ポリシーの履行による。RFC 6811：起源検証

照会する際は、次の順序で回答する：何を受信したか、どのポリシーによって処理されたか、なぜ選択または除外されたか、NEXT_HOP がどのように解決されたか、インストールされたか、そして実際のパケットと戻り経路が通過したか。これにより、「BGP にはルートがあるが接続できない」という問題を、具体的かつ検証可能な問題に分解できる。

ローカル推論：プレフィックスとポリシーの順序

from ipaddress import ip_network, ip_address

def lookup(address, entries):
    matches = [(ip_network(prefix), hop) for prefix, hop in entries
               if ip_address(address) in ip_network(prefix)]
    return max(matches,key=lambda item:item[0].prefixlen)[1] if matches else None

main = [('0.0.0.0/0','default'),('203.0.113.0/24','A'),('203.0.113.128/25','B')]
assert lookup('203.0.113.140',main) == 'B'
assert lookup('203.0.113.20',main) == 'A'
policy_table = [('0.0.0.0/0','C')]
assert (lookup('203.0.113.140',policy_table) or lookup('203.0.113.140',main)) == 'C'

# 前続条件が一致している場合のみ、LOCAL_PREF と AS シーケンス長の2項目をシミュレートする。
paths = [('A',200,[64501,64502,64503]),('B',100,[64504,64503])]
def best(candidates):
    return min(candidates,key=lambda x:(-x[1],len(x[2])))[0]
assert best(paths) == 'A'
paths[0] = ('A',100,[64501,64502,64503])
assert best(paths) == 'B'
assert min(10+10,5+30) == 20
print('最長プレフィックス、ポリシーテーブル優先、2つのBGP候補、パスコストチェックが通過')

これは完全な BGP 実装ではなく、MED、ルートリフレクター、収束タイマーもシミュレートしていない。

継続的な参照

• IPv4 プロトコル：アドレス、ネクストホップ、転送フィールド。
• ICMP と PMTUD：パスの観測とエラーフィードバック。
• TCP：ネットワークパス上の信頼性のある転送。