YAMAHA RTX の BGP 設定と Cisco 対向の落とし穴｜import/export の方向感

はじめに

SOHO や企業の拠点ルータとして、デファクトスタンダードである YAMAHA RTX シリーズ。かつては静的ルーティング（Static）や OSPF での運用が主でしたが、近年は AWS Direct Connect や Azure ExpressRoute といったクラウド接続、IP-VPN や SD-WAN の併用環境において、BGP（Border Gateway Protocol）を使用するケースが増えています。

しかし、Cisco IOS に慣れたエンジニアほど、YAMAHA 独自の BGP 設定の作法に戸惑うことが多い領域です。「network コマンドが見当たらない」「import って受信設定では？」――こうした疑問は、YAMAHA の import / export が Cisco の直感とは逆向きに命名されていることに由来します。

本記事では、Cisco ルータを対向とした実例を通して、YAMAHA 流の BGP 設定を公式リファレンスに沿って整理します。

参考: BGP-4 設定ガイド（YAMAHA 公式）
“BGP-4 を使用するためには、bgp use コマンドを設定する必要があります。このコマンドを設定しない限り、BGP-4 は動作しないので注意してください”
https://www.rtpro.yamaha.co.jp/RT/docs/bgp/bgp4-guide.html

構成図と前提環境

今回の検証環境は以下のとおりです。YAMAHA RTX と Cisco ルータを eBGP（External BGP）で直結し、互いの保有するネットワーク情報を交換します。

構成のポイント

• 接続リンク: 10.1.1.0/30 のセグメントで直結
• 広告するネットワーク（Loopback）: 検証用として、実際の LAN 機器の代わりにループバックインターフェース（Loopback）を作成し、そのネットワークを BGP で広告します。これにより、LAN ケーブルを繋ぎ変えずに BGP の経路交換を確認できます。

なお、AS 番号の 64512〜65535 はプライベート用途として予約されており、検証環境ではこの範囲を使用するのが一般的です。

参考: BGP-4 仕様（YAMAHA 公式）
“64512 から 65535 の範囲の番号は、プライベートな利用を想定しており、重複して割りあてられる可能性があります”
https://www.rtpro.yamaha.co.jp/RT/docs/bgp/

検証に使用する機種について

本記事のコマンドは、現行ラインナップである RTX830 / RTX840 / RTX1210 / RTX1220 / RTX1300 / RTX3500 / RTX5000 および vRX シリーズでの動作を想定しています。RTX1200 など旧モデルでも考え方は同じですが、RTX1200 は既に修理対応も終了しているため、本番運用での新規導入は推奨されません。

YAMAHA BGP の考え方（Cisco との違い）

設定に入る前に、YAMAHA RTX の BGP で最初に戸惑いやすいポイントを整理します。Cisco エンジニアであれば、BGP で経路を広告する際にこう考えるはずです。

「router bgp モードに入って、network 192.168.100.0 コマンドを設定しよう」

しかし、YAMAHA RTX に network コマンドは存在しません。では、自局のネットワークをどうやって相手に広告するのでしょうか。

network ではなく import を使う

YAMAHA の BGP は、「自分のルーティングテーブルにある経路を、BGP の世界に取り込んで（import して）広告する」という考え方を取ります。Cisco 用語で言えば「再配送（Redistribute）」に近い動きです。

つまり YAMAHA で BGP を設定する際は、まず「ルーティングテーブルに経路が存在すること」、次に「その経路の種類（static や direct）を指定して BGP に取り込むこと」の 2 ステップが必要です。

💡 YAMAHA の bgp import は「相手から経路をもらう（受信）」設定ではありません。「自分の持っている経路を BGP に渡す（送信準備）」設定と理解するのが正確です。

import / export の命名は「BGP プロセス視点」で覚える

YAMAHA の用語が混乱の元になるのは、命名の基準が BGP プロセス自身の視点になっているためです。

• import: ルーティングテーブルから BGP プロセスへ取り込む（≒ 外部へ広告する準備）
• export: BGP プロセスから ルーティングテーブルへ書き出す（≒ 受信した経路を採用する）

Cisco 流に「out / in」で考えると逆になるため、「自局のルーティングテーブルが基準ではなく、BGP プロセスが基準」という置き換えで覚えるとずれません。

YAMAHA RTX 側の設定

現行の RTX シリーズでの設定例です。「基本設定」「広告設定（送信）」「フィルタ設定（受信）」の 3 ステップで記述します。

# ループバック（広告用ネットワーク）の作成
ip loopback1 address 192.168.100.101/24

# --- BGP 基本設定 ---
# 1. BGP の有効化
bgp use on

# 2. 自局の AS 番号
bgp autonomous-system 65000

# 3. Router-ID の設定（ユニークな IP を指定）
bgp router id 192.168.100.101

# 4. ネイバー設定（対向 AS:65001、対向 IP:10.1.1.2）
# "neighbor 1" の "1" は設定管理用の識別番号
bgp neighbor 1 65001 10.1.1.2 hold-time=180

# --- 経路広告（network コマンドの代わり）---

# 1. 取り込みフィルタの定義（広告したい経路を指定）
# bgp import filter = BGP に取り込む経路の許可リスト（→ 結果的に外部へ広告される）
bgp import filter 1 include 192.168.100.0/24

# 2. 経路の取り込み
# 「AS 65001 に対して、static / direct 経路のうち
#  フィルタ 1 に合致するものを BGP プロセスへ import する」
bgp import 65001 static filter 1
bgp import 65001 direct filter 1

# --- 経路受信フィルタ（distribute-list in に相当）---

# 1. 受信フィルタの定義（受け取りたい経路を指定）
# 対向の Loopback (1.1.1.0/24) のみ許可する例
bgp export filter 10 include 1.1.1.0/24

# 2. AS 65001 から受信した経路にフィルタを適用
bgp export 65001 filter 10

bgp configure refresh

Cisco ルータ側の設定

比較として、対向となる Cisco ルータ（IOS）の設定も見ておきます。

! --- 基本設定 ---
router bgp 65001
 bgp router-id 1.1.1.101
 bgp log-neighbor-changes

 ! --- ネイバー設定 ---
 neighbor 10.1.1.1 remote-as 65000

 ! --- 経路広告（network コマンド）---
 ! YAMAHA の "bgp import ... static" に相当
 address-family ipv4
  network 1.1.1.0 mask 255.255.255.0

  ! ネイバーの有効化
  neighbor 10.1.1.1 activate
 exit-address-family

Cisco の network コマンドには、「ルーティングテーブルに完全一致するエントリが存在しない限り BGP テーブルに載らない」という重要な前提があります。広告対象が直結経路や IGP 学習経路としてルーティングテーブルに存在するか、事前に確認が必要です。

参考: Troubleshoot Border Gateway Protocol Routes that Do Not Advertise（Cisco 公式）
“BGP does not install an entry in the BGP table unless there is an exact match in the IP routing table”
（ルーティングテーブルに完全一致する経路がない限り、BGP は BGP テーブルにエントリを登録しない）
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html

設定コマンドの対比まとめ

YAMAHA と Cisco の用語対応を、正しい方向感で整理します。

YAMAHA の import / export は 「BGP プロセスから見た方向」を示しています。「自局のルーティングテーブル基準」で考えると逆になるため、設計時は十分な注意が必要です。

確認コマンドとステータスの見方

設定が終わったら、BGP ネイバーの確立と経路情報の交換状況を確認します。

① ネイバー状態の確認（Established）

show status bgp neighbor 10.1.1.2

▼ 出力例とチェックポイント

BGP neighbor is 10.1.1.2, remote AS 65001, local AS 65000, internal 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
  ...

• BGP state = Established: 正常に接続されています。
• Active / Connect / Idle: 接続が確立できていません。Ping 疎通、AS 番号の一致、IP 設定、ファイアウォール（TCP/179 の到達性）などを順に確認します。

② 受信ルートの確認（Received Routes）

対向ルータ（Cisco）から経路情報を受け取れているか確認します。

show status bgp neighbor 10.1.1.2 received-routes

▼ 出力例

Total routes: 1
*: valid route  <-- 「*」が付いているか確認
  Network            Next Hop        Metric LocPrf Path
* 1.1.1.0/24         10.1.1.2         0    100 IGP

• *（アスタリスク）: 有効なルートとしてルーティングテーブルに載ったことを示します。
• 表示されない場合は、対向側の network 設定や、自局の受信フィルタ（bgp export filter）を見直します。

③ 送信ルートの確認（Advertised Routes）

自局（YAMAHA）から対向へ経路情報を渡せているか確認します。「設定したのに相手に届かない」という場合はここを確認します。

show status bgp neighbor 10.1.1.2 advertised-routes

▼ 出力例

Total routes: 1
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 192.168.100.0/24   10.1.1.1              100 IGP

192.168.100.0/24 が表示されていれば、YAMAHA 側の取り込み設定（bgp import ... static / direct）は成功しています。

設定変更時の制約とハマりやすいポイント

YAMAHA RTX の BGP は、Cisco IOS と比べて運用上の制約がいくつかあります。設計時に押さえておかないと、本番運用で予期せぬ通信断につながる項目を整理します。

bgp configure refresh は無停止変更ができない

bgp configure refresh は BGP の設定を反映させるためのコマンドですが、実行すると相手に CEASE メッセージを送信したうえで BGP セッションを再接続します。つまり、設定変更のたびに BGP ピアが一時的にダウンします。

参考: BGP-4 設定ガイド（YAMAHA 公式）
“BGP がすでに動作している状態でこのコマンドを実行すると、相手に CEASE メッセージを送信してから、再びコネクションを接続します。この動作には 1 分以上の時間がかかることがあります”
https://www.rtpro.yamaha.co.jp/RT/docs/bgp/bgp4-guide.html

無停止での設定変更ができない点は、Cisco IOS の clear ip bgp soft のようなソフトリセット相当の動作がないことを意味します。変更作業はメンテナンス枠の確保を前提に計画することが推奨されます。

bgp configure refresh は OSPF も巻き込む

OSPF を併用している場合、OSPF の状態も同時に初期化されるという挙動があります。

参考: BGP-4 設定ガイド（YAMAHA 公式）
“OSPF を併用している場合には、bgp configure refresh コマンドを実行するときに、OSPF の状態も初期化される点に注意してください。同様に、ospf configure refresh コマンドを実行すると、OSPF の状態だけでなく、BGP の状態も同時に初期化されます”
https://www.rtpro.yamaha.co.jp/RT/docs/bgp/bgp4-guide.html

つまり、「BGP の経路フィルタを 1 行追加するだけのつもり」が、OSPF ネイバーまで巻き込んで再収束することになります。OSPF と BGP を併用する拠点では、再収束時間と内部ルーティングへの影響を事前に見積もっておくと安全です。

セカンダリアドレス割当時は BGP を使えない

特定のインターフェースにセカンダリアドレスを設定している場合、そのルータでは BGP 自体を使うことができません。L3 セグメントを共存させたい場合は、セカンダリアドレスを使わずに別インターフェースや VLAN サブインターフェースで分離する設計が推奨されます。

vRX シリーズの注意点

クラウド上で動作させる vRX シリーズには固有の制約があります。

参考: BGP-4 仕様（YAMAHA 公式）
“vRX シリーズでは LAN インターフェースがリンクダウンしないため、経路広告に LAN インターフェースの implicit 経路を含めている場合、その経路は近隣ルーターに広告され続けます。また、LAN インターフェースのリンクダウンを契機とした近隣ルーターおよび経路情報の更新も行われません”
https://www.rtpro.yamaha.co.jp/RT/docs/bgp/

物理機ではリンクダウンを契機に経路が引き上がりますが、vRX では仮想 NIC が常時アップ扱いとなるため、bgp neighbor の hold-time を適切に設定し、KEEPALIVE 不通を契機とした経路更新に頼る必要があります。

タイマー調整の制約

YAMAHA RTX では hello / keepalive を直接指定するコマンドはなく、hold-time のおおむね 1/3 が KEEPALIVE 送信間隔として自動設定されます。

参考: bgp neighbor（YAMAHA 公式コマンドリファレンス）
“hold-time パラメータに設定した時間の 1/3 程度の間隔で KEEPALIVE メッセージを送信する。hold-time パラメータの時間だけ待っても KEEPALIVE メッセージを受信できなかったとき、コネクションがダウンしたものと判断する”
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/bgp/bgp_neighbor.html

クラウド接続で対向側のタイマーが異なる場合は、両端の値を一致させる設計が望ましいですが、YAMAHA 側は KEEPALIVE を直接指定できない点を踏まえて hold-time を逆算する必要があります。

その他の制約

• bgp neighbor コマンドは最大 32 個まで設定可能
• bgp import filter のフィルタ番号は最大 100 個

複数拠点と eBGP を張る大規模構成では、上限値を意識した設計が必要です。

トラブルシューティング: BGP が確立しない／経路が広告されないとき

設定したのにネイバーが上がらない、Established まで到達しない、あるいは経路がうまく広告されない――そんなときの確認ポイントを段階的に整理します。

状態別の意味と切り分け

show status bgp neighbor <対向 IP> の BGP state を確認します。状態によって調査対象が変わります。

TCP/179 の到達性確認

BGP は TCP/179 を使うため、ファイアウォールやアクセスリストで遮断されているとセッションは確立しません。以下を順に確認します。

• 対向 IP への ping 疎通
• 対向の TCP/179 への到達性（telnet 10.1.1.2 179 で接続可否を確認）
• 経路上のファイアウォールで TCP/179（双方向）が許可されているか

経路が広告されない場合のチェック順序

ネイバーは Established なのに対向で経路が見えないケースは、典型的なつまずきです。以下の順で確認します。

show ip route

show status bgp neighbor 10.1.1.2 advertised-routes

経路が「BGP テーブルには載るがルーティングテーブルに載らない」

対向から経路を受信しているのに show ip route に反映されないケースもあります。YAMAHA では bgp export filter で受け入れた経路だけがルーティングテーブルに載るため、bgp export 系コマンドの設定漏れがないかを確認します。

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

ログを活用する

事象がリアルタイムで再現できるなら、bgp log でネイバー状態の変化を syslog に出力できます。

bgp log neighbor

show log でログを確認し、hold timer expired が頻発していれば hold-time の値が短すぎるか、回線の遅延・パケットロスが疑われます。

クラウド接続でつまずきやすい点

オンプレミス間の eBGP に加えて、AWS Direct Connect / Azure ExpressRoute / Google Cloud VPN との接続用途で RTX を使うケースが増えています。クラウド接続特有の落とし穴を整理します。

キープアライブのズレ

クラウド事業者ごとに BGP タイマーのデフォルト値が異なります。たとえば Google Cloud VPN は KEEPALIVE 20 秒・hold-time 60 秒が既定ですが、YAMAHA 側で hold-time=30 を設定すると KEEPALIVE は 10 秒になり、両端で不一致が生じます。

YAMAHA 側は hold-time の指定だけで KEEPALIVE が自動算出される仕様のため、対向側の KEEPALIVE 値を確認したうえで、YAMAHA 側の hold-time を逆算（KEEPALIVE × 3）して設定する運用が推奨されます。

Next Hop の取り扱い

Direct Connect や ExpressRoute との接続では、対向から広告される経路の Next Hop がリンクローカル相当のアドレスになることがあります。bgp neighbor の local-address パラメータを設定しない場合、Next Hop の選択にインターフェース依存の挙動が入るため、トンネル経由 BGP では local-address を明示する設計が安全です。

IPsec VPN over BGP 構成

AWS Site-to-Site VPN や Cloud VPN のように、IPsec トンネル上で BGP を張る構成では、IPsec の確立 → トンネル UP → BGP セッション開始、という順序で立ち上がります。BGP が Active のままになる場合、まずは IPsec トンネルが UP しているかを show status tunnel で確認するのが先です。

参考: Yamaha カスタマーゲートウェイデバイスのトラブルシューティング（AWS 公式）
“Yamaha のカスタマーゲートウェイデバイスの接続をトラブルシューティングする場合は、IKE、IPsec、トンネル、BGP の 4 つの要素を考慮します”
https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/Yamaha_Troubleshooting.html

クラウド側で BGP セッションが立たないときは、「BGP より下のレイヤから順に切り分ける」という基本に立ち返ると、原因に早くたどり着けます。

まとめ

本記事では、YAMAHA RTX における BGP 設定方法を、Cisco ルータとの接続を題材に解説しました。

• YAMAHA の BGP には Cisco の network コマンドに相当するものが存在せず、bgp import で BGP プロセスへ経路を取り込む方式を取る。
• import / export の方向感は BGP プロセス視点で命名されており、import filter は送信用、export filter は受信用にあたる。
• bgp configure refresh は BGP セッションを切断し、OSPF 併用時は OSPF も同時に再収束する。
• KEEPALIVE は hold-time の 1/3 で自動算出されるため、クラウド接続時はタイマー設計に注意が必要
• 経路が広告されないときは、ルーティングテーブル → 取り込みフィルタ → bgp configure refresh 実行の順で切り分ける。
• vRX シリーズは LAN リンクダウンを検知できないため、KEEPALIVE による経路更新を前提とした設計が必要

対向を Cisco ルータとして解説しましたが、AWS Direct Connect や Azure ExpressRoute、Google Cloud VPN に置き換えても、BGP 設定の考え方は同じです。Cisco エンジニアが最初に戸惑う import / export の方向感さえ整理できれば、YAMAHA RTX の BGP は十分に扱える範囲のプロトコルです。

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