BGP が経路を学んでも、通信はトンネルを迂回し続ける

拠点のゲートウェイは BGP テーブルにクラウドのプレフィックスを表示し、プロバイダーとのセッションも確立しているのに、そのプレフィックス宛ての利用者の要求はいまも誤ったインターフェースから出ていきます。監視が示すほど何かが壊れているわけではありません。「BGP が学習した」は制御プレーンについての文だからです。そのテーブルとパケットの間には四つの別々の遷移があり、流れはそのどれか一つで止まります。ゲートを順にたどり、最初に失敗するゲートで止まってください。

第一のゲート: 隣接が実際に送ってきたもの

要約された形ではなく、受信したままのプレフィックスから始めます。BGP テーブルで厳密なネットワークとマスクを調べ、ネクストホップ、AS パス、輸入ポリシーが照合しうるコミュニティを記録します。ダッシュボードの集約経路は、その具体的なプレフィックスが一度も受理されなかったという事実を隠してしまいます。

輸入ポリシーは、経路がエラーも出さずに消えるいつもの場所です。プレフィックスリスト、コミュニティフィルタ、受信ルートマップは、セッションが上がったまま健全な状態でも更新を落とせます。だからこそ緑の隣接ランプはほとんど何も証明しません。ログ行がないことは判断がないことではありません。たいていは、設定どおりに静かに判断されたという意味です。

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

出力はこの順に読みます。最初の二つのコマンドは情報が届いたか、ピアが何を送ったと主張しているかを示し、後の二つは何かが経路テーブルと転送テーブルに到達したかを示します。最初のコマンドにあり三番目にないプレフィックスは、選択かインストールの問題であり、接続性の問題ではありません。

第二のゲート: 選択、そしてインストール

BGP は最良の経路を選びますが、選ばれた経路が自動的にインストールされるわけではありません。ネクストホップは解決される必要があります。また、別の経路源がより良い管理距離でそのプレフィックスをすでに持っているかもしれません。移行時に残ったスタティック経路は、有効な BGP 経路にやすやすと勝ち、通信を別の場所へ送ってしまいます。

RFC 4271 は三つの考えを分けて保ちます。ピアが送ったもの、このスピーカーが最良として選んだもの、そして次に広告するもの。これらは概念上の役割であり、ベンダーが公開しなければならない三つの物理データベースではありません。しかし、その区別があるからこそ「BGP に入っている」は不完全な答えになります。

どのルーティングコンテキストを読んでいるかも確認します。利用者のインターフェースが属さない VRF にインストールされた経路は、その利用者のパケットには見えず、テーブルはその間ずっと正しく見えます。

第三のゲート: このフローに適用される検索

ここで経路について尋ねるのをやめ、パケットについて尋ね始めます。利用者の送信元アドレス、宛先、プロトコル、ポート、受信インターフェースを記録します。どれも異なるポリシーを選びうるからです。そのうえで、一般的な経路テーブルではなく、その組み合わせに適用される検索を見ます。

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

ここで最も多い驚きはより具体的なプレフィックスで、二番目はポリシールートです。どちらも見ていた集約を上書きし、どちらも BGP テーブルの要約には現れません。

ゲートウェイ自身からの ping は、利用者のセッションについての証拠になりません。送信元アドレスが違い、ポリシーの経路も違い、しばしば結果も異なります。アプリケーションが使う同じ送信元で試すか、その試験は別の問いに答えていると受け入れてください。

第四のゲート: 経路の遠い側

ローカルの検索がトンネルを選んだとしても、パケットは保護ポリシーに受理され、転送ルールに許可され、向こう側の何かから応答を受ける必要があります。アドレスの組を含まない暗号 ACL は、トンネルが上がっていると報告したまま通信を落とし、ルーティング障害と区別できないタイムアウトを生みます。

戻りの経路は行きの経路と同じだけ重要です。クラウド側は、拠点の送信元にどう到達するかを知っていなければなりません。経路でも、意図して設定した変換でも構いません。非対称な戻り経路は、片方向からしか試験していない設計でよく見られます。

新しい許可済みの接続を三つの観察で突き合わせます。一致したローカルポリシー、動いたトンネルのカウンタ、そして見える場合の遠い側での受信です。カウンタが動かなければ、経路テーブルが何を言おうとパケットはトンネルに入っていません。動いているのに何も届かないなら、遠い側が落としているか誤って経路を選んでいます。この二つの結果はまったく別のチームに渡ります。

失敗した遷移に名前を付ける

結果を五つの状態のどれかとして書きます。受信していない、ポリシーに受理されていない、選択されていない、インストールされていない、このフローに一致していない。六つ目として、ローカルの経路は正しいのに遠い端が応答できない場合を加えます。その一文が成果物であり、確立した隣接のスクリーンショットよりはるかに役に立ちます。

受け入れ計画には否定的な試験も残します。トンネルを通ってはいけない宛先を、変更後に確認します。うまくいく経路だけを証明するチェックリストでは、次の保守時間帯に誰かが加える広いポリシールールを捕まえられません。