YAMAHA RTX BGP 経路フィルタの設定|import と export filter の使い分け

  • URLをコピーしました!
目次

はじめに

YAMAHA RTX で BGP の広告経路や受信経路を絞り込もうとすると、最初に迷うのがbgp import filterbgp export filterのどちらを使うかという点です。Cisco IOS のdistribute-list in / outに慣れていると、「広告を絞るなら out 相当だから export では?」と考えがちですが、RTX では逆になります。この方向感のズレが、フィルタ設計でつまずきやすい原因の一つです。

この記事でわかること
  • bgp import filterbgp export filterの役割の違い
  • Cisco のdistribute-list in / outとの対応関係
  • 経路を絞り込むフィルタの考え方(広告側・受信側)
  • フィルタ設計でつまずきやすい方向感の整理

結論を先に示すと、RTX の経路フィルタは「BGP プロセスから見た方向」で命名されています。import filterは自局の経路を BGP に取り込む際の絞り込み、すなわち広告(送信)を絞るフィルタです。export filterは BGP が受け取った経路をルーティングテーブルへ書き出す際の絞り込み、すなわち受信を絞るフィルタにあたります。Cisco の感覚とは in / out が逆になる、と覚えると整理しやすくなります。

なお、基本設定やネイバー確立の手順は本記事では扱いません。これらは関連記事『YAMAHA RTX の BGP 設定手順』で解説しています。本記事はフィルタ設計に絞って整理します。

RTX の経路フィルタの全体像

RTX のフィルタを理解する近道は、フィルタ名の基準が「自局のルーティングテーブル」ではなく「BGP プロセス」にある、と捉えることです。ここを押さえると、import / export の方向感が一度で整理できます。

import filter(広告・送信用)と export filter(受信用)の役割

RTX には Cisco のnetworkコマンドに相当するものがなく、自局の経路はbgp importで BGP プロセスへ取り込む方式を取ります。この取り込み時に「どの経路を取り込むか」を絞り込むのがbgp import filterです。取り込まれた経路が結果的に対向へ広告されるため、import filterは実質的に広告(送信)経路を絞るフィルタとして働きます。

一方、対向から受信した経路に対して「どれをルーティングテーブルへ採用するか」を絞り込むのがbgp export filterです。

参考: BGP-4 設定ガイド(YAMAHA 公式)
このコマンドで受理された経路だけが、実際のルーティングに使われたり、OSPFやRIPで広告されます
https://www.rtpro.yamaha.co.jp/RT/docs/bgp/bgp4-guide.html

つまりexport filterで受理された経路だけがルーティングに反映されるため、export filterは受信経路を絞るフィルタとして働きます。名前は送信を連想させますが、実際の役割は受信側の制御です。

両フィルタとも、ネットワークを複数指定した場合はプレフィックスが最も長く一致する設定が採用されます(ロングプレフィックスマッチ)。また、allキーワードは0.0.0.0/0と同じ意味で、全経路を対象にする際に使用します。

Cisco の distribute-list in / out との対応

Cisco エンジニアが RTX のフィルタを設計する際は、次の対応関係で読み替えると混乱を避けられます。

目的Cisco IOSYAMAHA RTX
広告する経路を絞る(送信)distribute-list … outbgp import filter …
受信する経路を絞る(受信)distribute-list … inbgp export filter …

ポイントは、Cisco が「自局インターフェイスを基準にした in / out」で命名しているのに対し、RTX は「BGP プロセスを基準にした import / export」で命名している点です。基準が異なるため、同じ「広告を絞る」操作でも、Cisco では out、RTX では import filter と語感が逆方向になります。

設計時は「広告を絞るなら import、受信を絞るなら export」と、操作の目的から逆引きするのが安全です。

import filter で広告経路を絞り込む

自局の経路を対向へ広告する際は、bgp import filterで対象経路を定義し、bgp importで BGP プロセスへ取り込みます。この 2 段構えが RTX の広告設定の基本形です。

bgp import filter の基本構文(include / refines / equal)

フィルタ本体は次の書式で定義します。

bgp import filter <フィルタ番号> [reject] <kind> <ip_address/mask> ... [parameter ...]

kind(種別)には次の 3 つを指定できます。広告したいネットワークの粒度に応じて使い分けます。

kind意味
include指定したネットワークに含まれる経路(ネットワークアドレス自身を含む)
refines指定したネットワークに含まれる経路(ネットワークアドレス自身を含まない)
equal指定したネットワークに完全一致する経路

kindの前にrejectを置くと、その条件に一致する経路を拒否できます。ネットワークの代わりにallを指定すると0.0.0.0/0(すべての経路)が対象になります。複数条件を書いた場合は、プレフィックスが最も長く一致する設定が採用されます(ロングプレフィックスマッチ)。なおparameterでは広告時の MED(metric)や優先度(preference)も指定できますが、属性制御は後述の実装パターンで触れます。

参考: bgp import filter(YAMAHA 公式コマンドリファレンス)
kind の前に reject キーワードを置くと、その経路が拒否される
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/bgp/bgp_import_filter.html

bgp import で BGP プロセスへ取り込む

定義したフィルタは、bgp importコマンドで「どのプロトコルの経路に適用するか」を指定してはじめて機能します。

bgp import <相手のAS番号> <protocol> [from_as] filter <フィルタ番号> ...

protocolには、取り込む経路の種別を指定します。現行リファレンスで指定できるのは次の 5 つです。

protocol対象経路
static静的経路(implicit 経路を含む)
ripRIP
ospfOSPF
bgpBGP(from_asで受信元 AS を指定)
aggregate集約経路

ここで注意したいのが、直結経路やループバックインターフェースの経路は、directではなくstatic(implicit 経路)として取り込む点です。現行のコマンドリファレンスにdirectの記載はなく、直結経路は static に含まれる implicit 経路として扱われます。

また、フィルタは省略できず最低 1 つの定義が必要です。フィルタに該当しない経路は導入されないため、広告対象をincludeequalで明示する設計が基本になります。

参考: bgp import(YAMAHA 公式コマンドリファレンス)
このコマンドが設定されていないときには、外部経路は導入されない
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/bgp/bgp_import.html

設定例として、自局の192.168.100.0/24のみを AS65001 へ広告する場合は次のようになります。

# 広告したい経路を定義
bgp import filter 1 include 192.168.100.0/24

# static(implicit 経路を含む)から、フィルタ 1 に該当する経路を取り込む
bgp import 65001 static filter 1

include / refines / equal の使い分け

3 つの種別は、広告範囲をどこまで含めるかで選択します。

  • equalは、指定したプレフィックスと完全一致する経路だけを対象にする。192.168.100.0/24を広告し、より細かい/25などは広告したくない場合に向く。
  • includeは、指定ネットワークとその配下の経路をまとめて対象にする。集約した範囲をまとめて広告したい場合に向く。
  • refinesは、指定ネットワーク配下の経路のみを対象にし、ネットワークアドレス自身は含めない。

意図しない経路の広告を防ぐには、まずequalincludeで許可対象を絞り込み、必要に応じてrejectで特定経路を除外する、という組み合わせが扱いやすい設計です。

export filter で受信経路を制御する

対向から受信した経路のうち、どれを自局のルーティングテーブルへ採用するかを制御するのがbgp export filterbgp exportです。名前は送信を連想させますが、役割は受信経路の絞り込みにあたります。

bgp export filter の基本構文

書式とkindは import filter と共通です。

bgp export filter <フィルタ番号> [reject] <kind> <ip_address/mask> ... [parameter ...]

include / refines / equalreject修飾子、allキーワード、ロングプレフィックスマッチの挙動はすべて import filter と同じです。違いは、定義したフィルタをbgp exportコマンドで受信経路に適用する点です。

参考: bgp export filter(YAMAHA 公式コマンドリファレンス)
BGP で受信する経路に適用するフィルタを定義する。このコマンドで定義したフィルタは、bgp export コマンドの filter 節で指定されてはじめて効果を持つ
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/bgp/bgp_export_filter.html

受信経路がルーティングテーブルに載る条件

適用は次の書式です。

bgp export <相手のAS番号> filter <フィルタ番号>

ここで重要なのは、フィルタに該当した経路だけがルーティングテーブルに載り、該当しない経路は採用されないという挙動です。受信フィルタを設定した時点で、明示的に許可した経路以外は暗黙的に拒否されます(rt-common および vRX のリファレンスで、該当しない経路はルーティングにも他プロトコルにも反映されないと記載されています)。

設定例として、対向(AS65001)から1.1.1.0/24のみを受信・採用する場合は次のようになります。

# 受信したい経路を定義
bgp export filter 10 include 1.1.1.0/24

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

採用された経路はshow status bgp neighbor <対向IP> received-routesの出力で、有効な経路を示す*(アスタリスク)付きで表示されます。フィルタで拒否された経路は、受信はするものの*が付かずルーティングテーブルには載りません。確認コマンドや「経路が広告されない・受信されない」ときの切り分けは、関連記事『RTX BGP 確認コマンドと切り分け』(rtx-bgp-troubleshooting、フェーズ 1 の 2 本目)で扱う想定です。

よく使うフィルタ実装パターン

実務で頻出するフィルタの書き方を、目的別に整理します。いずれもinclude / refines / equalrejectの組み合わせで表現します。

特定ネットワークだけを広告する(equal)

192.168.100.0/24だけを広告し、より細かいプレフィックスを広告したくない場合はequalで完全一致させます。

bgp import filter 1 equal 192.168.100.0/24
bgp import 65001 static filter 1

特定経路を除外して残りを広告する(reject)

「基本は広告するが、特定経路だけは出したくない」場合は、reject付きの条件を併記します。

# 192.168.99.0/24 は広告しない
bgp import filter 1 reject equal 192.168.99.0/24
bgp import filter 1 include 192.168.0.0/16
bgp import 65001 static filter 1

経路を集約して広告する(aggregate)

複数の細かい経路を 1 つに集約して広告したい場合は、bgp aggregate filterで集約対象を指定し、bgp importprotocolaggregateを指定します。集約後プレフィックスの定義を含む手順は、公式の BGP-4 設定ガイド(https://www.rtpro.yamaha.co.jp/RT/docs/bgp/bgp4-guide.html )の集約設定例を参照してください。

RTX BGP の制約: community 属性は非対応

ここが Cisco や他ベンダーから移ってきた場合の落とし穴です。RTX の BGP は community 属性(no-export、no-advertise 等)をサポートしていません。 広告範囲を community で制御することはできず、広告対象の絞り込みは import / export filter で行う、というのが RTX 流の設計です。

なお、ルーティングテーブルに存在しない経路をあえて広告したい場合は、bgp force-to-advertise による強制広告が用意されています。強制広告した経路はルーティングテーブルには反映されず、bgp import の設定に関わらず指定した AS へ広告されます。

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

経路の優先度を調整したい場合は、フィルタのparameterで MED(metric)や優先度(preference)を指定できます。なお、bgp importで適用できるフィルタは最大 102 個(現行リファレンス)です。大規模構成では、この上限を意識したフィルタ設計が必要になります。

フィルタ反映と確認

フィルタを書いただけでは動作に反映されません。反映コマンドと、結果の確認方法を押さえておきます。

bgp configure refresh で反映する(無停止変更は不可)

フィルタを追加・変更した後は、bgp configure refreshを実行するか、ルーターを再起動するまで設定は有効になりません。ただしこのコマンドは BGP セッションを一時的に切断し、OSPF を併用している場合は OSPF も同時に再収束します。無停止での変更ができない点を含む制約の詳細は、関連記事『YAMAHA RTX の BGP 設定手順』で解説しています。フィルタ変更はメンテナンス枠での実施が無難です。

advertised-routes / received-routes で結果を確認する

フィルタが意図どおり効いているかは、ネイバー単位の経路表示で確認します。

# 自局から対向へ広告している経路(import filter の結果)
show status bgp neighbor <対向IP> advertised-routes

# 対向から受信して採用した経路(export filter の結果)
show status bgp neighbor <対向IP> received-routes

received-routesでは、有効な経路に*(アスタリスク)が付きます。フィルタで拒否された経路は*が付かず、ルーティングテーブルには載りません。経路が想定どおり出ない・入らないときの段階的な切り分けは、関連記事『RTX BGP 確認コマンドと切り分け』(rtx-bgp-troubleshooting、フェーズ 1 の 2 本目)で扱う想定です。

まとめ

RTX の BGP 経路フィルタは、Cisco のdistribute-listとは方向感が逆になる点が最大のつまずきどころです。import filter が広告(送信)、export filter が受信を絞るフィルタ、と役割で覚えると設計時に迷いません。種別や反映方法、RTX 固有の制約を押さえれば、広告・受信経路を意図どおりに制御できます。

  • import filter は広告(送信)、export filter は受信を絞るフィルタ
  • kind は include・refines・equal の 3 種と reject 修飾子
  • 直結・ループバック経路は direct ではなく static 扱い
  • import・export ともフィルタ未該当の経路は不採用
  • RTX BGP は community 属性に非対応、広告制御はフィルタ
  • フィルタ変更の反映は bgp configure refresh(無停止変更は不可)
  • 送信・受信の結果は advertised-routes / received-routes で確認

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

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次