YAMAHA RTX BGP の確認コマンド｜show status bgp の見方と切り分け

はじめに

YAMAHA RTX の BGP トラブルは、show status bgp neighbor の出力の読み方と、状態に応じた切り分けの順序さえ押さえれば、その多くを自力で特定できます。逆に、出力のどこを見ればよいか分からないまま設定を見直しても、原因にたどり着くまで時間がかかります。

結論を先に示すと、ネイバーの状態は BGP state で読み、Established 以外なら状態名から原因を絞り込みます。経路が想定どおり流れないときは、「ルーティングテーブル → フィルタ → bgp configure refresh の反映」の順で切り分けると、原因の所在を素早く特定できます。

なお、フィルタの書き方そのものは関連記事『RTX BGP 経路フィルタの設定』を、基本設定やクラウド接続時の切り分けは関連記事『YAMAHA RTX の BGP 設定手順』を参照してください。本記事は確認コマンドの読み方と切り分けに絞ります。

show status bgp neighbor の見方

BGP の状態確認は show status bgp neighbor が基点です。引数に対向 IP を指定すると、そのネイバーの詳細が表示されます。

出力の主要フィールド

次は Established（正常確立）状態の出力例です。

# show status bgp neighbor 10.1.1.2
BGP neighbor is 10.1.1.2, remote AS 65001, local AS 65000, external link
  BGP version 4, remote router ID 1.1.1.101
  BGP state = Established, up for 00:02:30
  Last read 00:00:46, hold time is 180, keepalive interval is 60 seconds
  Received 6 messages, 0 notifications, 0 in queue
  Sent 8 messages, 0 notifications, 0 in queue
  Connection established 1; dropped 0
  Last reset never
  Local host: 10.1.1.1, Local port: 179
  Foreign host: 10.1.1.2, Foreign port: 61702

切り分けで重要なフィールドは次のとおりです。

• remote AS / local AS: 対向と自局の AS 番号。両者が同一なら iBGP で行末はinternal link、異なれば eBGP でexternal linkと表示される。意図と異なる場合は AS 番号の設定ミスを疑う。
• BGP state: 最も重要な項目。Establishedが正常で、それ以外は未確立を意味する。状態別の原因は次章で扱う。
• up for: セッション確立からの経過時間。Connection establishedの回数が増えていたりLast resetが頻繁な場合は、セッションが不安定と判断できる。
• hold time / keepalive interval: 採用中のタイマー値。keepalive は hold time の約 1/3 で自動算出される。対向との不一致は不安定化の原因になる。
• Local port / Foreign port: BGP は TCP/179 を使う。179側が接続を受けた側で、もう一方が接続を開始した側を示す。

advertised-routes / received-routes の見方

経路がやり取りできているかは、show status bgp neighbor <対向IP>に経路種別を付けて確認します。種別によって表示対象が変わる点が重要です。

参考: show status bgp neighbor（YAMAHA 公式コマンドリファレンス）
received-routes を指定した時には、隣接ルーターから受信した経路をすべて表示する。routes を指定した時には、隣接ルーターから受信した経路のうち、bgp export filter などで受け入れられた経路だけを表示する
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/showstatus/show_status_bgp_neighbor.html

ここで押さえたいのが、行頭の*（アスタリスク）の意味です。*: valid routeが示すとおり、*が付いた経路だけが有効としてルーティングテーブルに載り、*が付かない経路は受信はしているが採用されていないことを表します。

# show status bgp neighbor 10.1.1.2 received-routes
Total routes: 2
*: valid route
  Network            Next Hop        Metric LocPrf Path
  2.2.2.0/24         10.1.1.2         0    100 IGP     ← * なし: 受信したが不採用
* 1.1.1.0/24         10.1.1.2         0    100 IGP     ← * あり: 採用されルーティングテーブルへ

この例では、2.2.2.0/24は受信しているものの*が付かず、ルーティングテーブルには載りません。received-routesに出るのに*が付かない場合は、受信側のbgp export filterで弾かれている可能性を疑います。一方、advertised-routesに対象経路が出ない場合は、自局のbgp import設定側に原因があります。この切り分けの詳細は後半のセクションで扱います。

BGP state の意味と状態別の切り分け

BGP はネイバーを確立するまでに、いくつかの状態を順に遷移します。show status bgp neighbor の BGP state がどこで止まっているかで、調査すべき対象が変わります。

Idle / Connect / Active の原因

Idle は、BGP プロセスがまだ動いていない状態です。bgp use on や bgp autonomous-system が未設定、あるいは設定後に bgp configure refresh を実行していないケースが大半です。設定を入れただけでは反映されない点が、RTX で最初につまずきやすいところです。

Connect / Active は、TCP コネクションを張りにいっているものの完了していない状態です。Active のまま留まる場合は、対向 IP への到達性がないか、経路上で TCP/179 が遮断されている可能性が高くなります。AWS Site-to-Site VPN のように IPsec トンネル上で BGP を張る構成では、トンネルが UP していないと Active のままになります。

OpenSent / OpenConfirm の原因

ここまで進んでいれば TCP コネクション自体は確立しています。OpenSent / OpenConfirm で止まる場合は、OPEN メッセージのネゴシエーションに失敗しています。代表的な原因は、bgp neighbor で指定した対向 AS 番号の不一致や、Router-ID の重複・不正です。AS 番号は自局・対向の両方を見比べて確認します。

Established（正常）の確認ポイント

Established が表示され、up for が継続的に伸びていれば正常です。ただし、Connection established の回数が増え続けていたり Last reset が短い間隔で更新される場合は、確立と切断を繰り返すフラッピングが疑われます。この場合はタイマー（hold time）や回線品質を確認します。

ネイバーが Established にならないとき

Active や Idle から進まないときは、レイヤの下から順に切り分けると原因に早くたどり着けます。

TCP/179 の到達性を確認する

BGP は TCP/179 を使うため、到達性は次の順で確認します。

# L3 到達性の確認
ping <対向IP>

# TCP/179 への到達性の確認
telnet <対向IP> 179

telnet はポートを指定でき、23 以外のポートでは TELNET のオプションネゴシエーションを行わないため、TCP/179 への素の接続可否を確認できます。接続できれば TCP/179 は到達しており、できなければ経路上のファイアウォールや ip filter で 179 が双方向に許可されているかを見直します。

参考: TELNET クライアント（YAMAHA 公式コマンドリファレンス）
port 番が 23 の場合はネゴシエーションし、そうでない場合はネゴシエーションしない
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/operation/telnet.html

AS 番号・Router-ID・neighbor 設定を確認する

TCP/179 が到達しているのに確立しない場合は、設定の不整合を確認します。

• bgp neighbor <番号> <対向AS> <対向IP> の対向 AS と IP が、相手側の実際の値と一致しているか。
• bgp autonomous-system の自局 AS 番号が意図どおりか。eBGP では対向と異なる AS、iBGP では同一 AS になる。
• bgp router id が他ルーターと重複していないか。明示設定していない場合はインターフェイスのプライマリアドレスから自動選択されるため、意図しない値になることがある。
• OSPF を併用する場合は、BGP と OSPF の Router-ID を同一にする必要がある点に注意する（詳細は公式の BGP-4 設定ガイド https://www.rtpro.yamaha.co.jp/RT/docs/bgp/bgp4-guide.html を参照）。

これらを確認・修正した後は、bgp configure refresh で反映します。反映時にセッションが一時的に切断される点は、関連記事『YAMAHA RTX の BGP 設定手順』で解説しています。

経路が広告されない・受信されないときの切り分け

ネイバーは Established なのに、対向で経路が見えない・自局に経路が入らない、というケースの切り分けです。送信側と受信側で確認の入り口が異なります。

広告されない: ルーティングテーブル → import filter → 反映の順

自局から広告されないときは、次の順で確認します。

なお、ルーティングテーブルに存在しない経路をあえて広告したい場合は、bgp force-to-advertise による強制広告が用意されています。

参考: bgp force-to-advertise（YAMAHA 公式コマンドリファレンス）
本コマンドで設定した経路がルーティングテーブルに存在しない場合でも、指定された AS 番号のルーターに対して BGP で経路を強制的に広告する
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/bgp/bgp_force-to-advertise.html

強制広告した経路はルーティングテーブルには反映されず、bgp import の設定に関わらず広告されます。フィルタの書き方そのものは関連記事『RTX BGP 経路フィルタの設定』を参照してください。

受信されない: export filter と received-routes の * を確認

対向から受信できないときは、受信経路の表示で切り分けます。

ログを活用する

状態変化を時系列で追いたいときは、BGP のログを有効化します。

bgp log neighbor でネイバー状態の変化を記録する

bgp log neighbor を設定すると、ネイバー関連のログが記録されます。初期値ではログは記録されません。

bgp log neighbor

参考: bgp log（YAMAHA 公式コマンドリファレンス）
指定した種類のログを INFO レベルで記録する
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/bgp/bgp_log.html

記録後は show log で確認します。さらに詳細な情報が必要な場合は syslog debug on を併用します。短い間隔で確立と切断が繰り返し記録されている場合は、hold-time の値が短すぎるか、回線の遅延・パケットロスを疑います。タイマーは対向との整合も含めて見直すと安定します。

まとめ

RTX の BGP トラブルは、show status bgp neighbor の出力を「状態」と「経路」に分けて読むことで、原因の所在を素早く絞り込めます。状態が止まる位置から原因を逆引きし、経路の問題はルーティングテーブルからフィルタ、反映の順にたどるのが基本です。

• 状態は show status bgp neighbor の BGP state で読む
• Established が正常、それ以外は状態名から原因を逆引き
• TCP/179 の到達性は ping と telnet 179 で確認
• 広告不可は ルーティングテーブル → フィルタ → 反映 の順で切り分け
• 受信経路は received-routes の * で採用可否を判断
• ルーティングテーブルにない経路は bgp force-to-advertise で広告
• ネイバー状態の変化は bgp log neighbor で記録

以上、最後までお読みいただきありがとうございました。