JunosでIX BGP Route Serverを作る

概要

Junos 17.4からBGP Route Serverの機能が実装されました。
最近プライベートな活動でもIXを立ち上げようとしているので触ってみました。

BGP Route Serverとは

通信事業者が相互接続してトラフィック交換をする手段の一つに、Internet eXhange(IX)があります。
IXに接続するとこでトランジット事業者への依存度を下げ、コスト削減や効率的なトラフィックコントロールができる場合があります。
IXに接続した事業者はそこで経路情報の交換を行いトラフィックを流しますが、IXの接続には大きく分けて2種類の方式(Peering)があります。

Bilateral Peering
- IX上で特定の相手と一対一で接続する
- 各事業者との個別の接続交渉が必要
Multilateral Peering
- Multi-Lateral Peering Agreement(MPLA)に同意した事業者とRoute Serverとの接続を介して経路情報を交換する
- 個別の接続交渉や設定などが不要で複数の事業者とpeerしているように見える
- Bilateralと比較してトラフィックコントロールが難しい

IXには昔から接続ユーザのトラフィック交換に干渉すべきではないという考え方があり、通常はL2セグメントを介しての接続になります。Multilateral PeeringはRoute ServerとBGP peerを張って接続するので、Control PlaneはL3接続になります。

Route Serverに必要な機能

Route Serverにはその特性故に、必須の機能がいくつかあります。
IXは複数の事業者が相互接続するので、eBGP接続になりますが、通常のeBGPの動作(RFC4271)では実現できない機能があります。

BGP Attributeの透過

先述のように、IXはユーザのトラフィック交換に干渉しないという考え方と、Route Server自体の負荷を軽減するために、Data Planeを流れるユーザトラフィックはRoute Serverを経由しないようにする必要があります。
BGPのTCP 179番ポートでやり取りされるControl Planeの通信のみRoute Serverを経由し、それ以外の通信はIXのL2セグメント上でダイレクトに交換されるようにします。

これを実現するにはRoute ServerはRoute Server ClientからのUPDATEメッセージをすべて受け入れ、いくつかのBGPの経路情報に付いた属性をそのまま透過しなければなりません。

NEXT_HOP
- Route ServerはRoute Server Clientが広報した経路のNEXT_HOPを変更せずに他のClientに送信します
- 通常eBGPはNEXT_HOPを自身のアドレスに書き換え(NEXT_HOP_SELF)をしますがRoute Serverはこれを行いません
- これによりData PlaneがRoute Serverを経由することなく、直接IXのL2セグメント上でトラフィック交換が可能になります
MED
- Route Serverは転送プロセスには不干渉のためMED値を変更しません
AS-PATH
- Route Serverは経路情報をclientに伝搬させる時にAS-PATHに自身のAS番号を付加しません
- Route Server Clientから見ると、Route Serverから受信した経路のAS-PATH情報にはRoute ServerのAS番号が付いてい無いので、経路情報的には直接相手から貰ったように見えます。
- これはルータのデフォルト動作だと不正なAS-PATHと判定されることがあるので、Route Serverと接続するClient Routerで隣接ASから受信した経路のAS-PATHの先頭にそのASが無い場合に当該経路を弾くvalidationを無効にしなければならないこともあります
Community
- DDoS対策などIXがローカルで定義している特殊用途のcommunityを除いて、Route Serverはcomminity値の変更、処理、または削除をしません

上記のいくつかはRFC4271違反の動作でしたが、2016年にRoute Serverの仕様について規定したRFC7947と、そのオペレーションについてRFC7948が策定されました。

BGP Path Hidingの防止

BGP環境をスケールさせる上で時々課題になるのが、ベストパス選択の問題です。　
f:id:cognify:20180108113026p:plain
通常のBGPの経路処理プロセス
https://frrouting.org/user-guide/Description-of-the-Route-Server-model.html
　
上の図はQuagga(FRR)の実装を例に取った非Route Server環境(Bilateral Peer)でのBGPの経路処理プロセスを表しています。

各peerから受信した経路がadj-RIB-in Tableに格納後、import filterを通過しBGP Table(Loc-RIB)でベストパスが選択されグローバルルーティングテーブルにインストール、out filter適用後に各peerに送信されます。

Route Server ClientからRoute Serverに同じ経路が広報されると、Route Serverは接続されているすべてのClientに伝播するための単一のパスを選択します。
これが時々問題になることがあります。

また、IXにはユーザが特定のメンバとの経路交換をしないようにRoute Serverへフィルタを設定できるようになっていることがあります。たとえば複数のRoute Server Clientが同一の経路をRoute Serverへ広報した場合、特定のRoute Server Clientへのベストパスをフィルタ処理するようにRoute Serverが設定されている場合、そのRoute Server Clientはその経路へのパスを受け取りません。しかしRoute Serverの単一のルーティングテーブルで計算したベストパスが、このフィルタされたパスに向いている場合、Route Server Clientは当該経路が見えない状態になってしまうことがあります。

f:id:cognify:20180108123657p:plain
http://ripe61.ripe.net/presentations/260-ripe61-draft-jasinska.pdf

このように各Route Server Clientから受信した経路をすべて同一のRIBに載せてしまうと問題が発生します。
これをBGP Path Hidingといいます。

このような事象を防ぐためのいくつかの方法があります。
最も一般的な方法が、 Multi Client RIB Proccess で各peer毎にRouting Tableを管理し、独立したベストパス選択を実施する方法です。

f:id:cognify:20180108113545p:plain
Multi Client RIBのBGPのプロセス
https://frrouting.org/user-guide/Description-of-the-Route-Server-model.html

上の図はBilateral PeerとMultilateral Peerの混在環境でのBGPの経路広報プロセスについて表したものです。
非Route Server環境との違いは、Route ServerはClientに代わってベストパスの選択を行う必要があることです。

Multi Client RIBの他にもADD-PATHなどを用いて経路の選択肢を増やすなどのやり方もありますが、長くなるので割愛します。

また、IXによってはCommunityやIRR情報を用いて特定のメンバにのみ経路を広報しないという動作(Selective Announcement)をさせることも可能ですが、これもPath Hidingの原因になりますので注意が必要です。

Route Serverに利用されるBGP実装

今回試すようにJunosのようなルータでもRoute Serverとして動作させることは可能ですが、世界的にはAPIの利用や拡張性の高さ、運用の効率化の観点からRoute ServerはLinux上でBGPデーモンを動かして利用することが一般的です。

Route Serverの実装は以下のようなものがあります。

BIRD
- 世界的に広く利用されているルーティングデーモンで、Route ServerとしてのシェアはEU方面を中心に圧倒的です
Quagga(FRR)
- こちらも広く利用されているルーティングデーモンですが、海外のIX Route Serverにはパッチを当てた特殊仕様のQuaggaが利用されています
GoBGP
- NTTとJPNAPが共同で開発したBGPに特化したルーティングデーモンでその名の通りGoによる実装です
- quaggaやBIRDではフィルタ更新に時間がかかりCLIの応答がしばらくなくなるなどのパフォーマンス上の問題があったため、マルチコア化などで近年のIXの運用レベルまでスケール出来るように設計されています
- JPNAPでは商用導入されています
OpenBGPD
Cisco
Junos
- Junos 17.4からRoute Serverとしての基本機能が実装されました

Junos でのRoute Serverの設定

Linuxでやったほうが手っ取り早いのですが、今回はJunosで試してみます。
Route ServerとしてJunos 17.4R1.16を利用します。

構成は以下の通りです。

f:id:cognify:20180108135316p:plain

Route Server Clientは自身のprefixを広報します。

JunosをRoute Serverにする

JunosをRouter Serverとして動作させるのはFRR(Quagga)と同様で簡単です。
通常のBGP設定に加えてBGPネイバーに対してroute-server-clientの設定を入れるだけでRoute Server機能を有効化できます。

root@RouteServer> show configuration protocols bgp
group RSC1 {
    type external;
    route-server-client;
    family inet {
        unicast;
    }
    peer-as 4200000001;
    neighbor 192.168.100.11;
}
group RSC2 {
    type external;
    route-server-client;
    family inet {
        unicast;
    }
    peer-as 4200000002;
    neighbor 192.168.100.12;
}

Clinet1 / Client2 の状態確認をします。

root@lab_vMX> show bgp summary logical-system RSC1
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.100.1    4200000000        279        278       0       0     2:04:20 1/1/1/0              0/0/0/0

root@lab_vMX> show route logical-system RSC1 protocol bgp

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.202.0/24   *[BGP/170] 01:43:36, localpref 100, from 192.168.100.1
                      AS path: 4200000002 I, validation-state: unverified
                    > to 192.168.100.12 via ge-1/0/0.0

root@lab_vMX> show bgp summary logical-system RSC2
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.100.1    4200000000        272        271       0       0     2:00:50 1/1/1/0              0/0/0/0

root@lab_vMX> show route logical-system RSC2 protocol bgp

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.201.0/24   *[BGP/170] 01:45:19, localpref 100, from 192.168.100.1
                      AS path: 4200000001 I, validation-state: unverified
                    > to 192.168.100.11 via ge-1/0/1.0

それぞれのClinetで受信した経路を確認すると、Route ServerのAS番号がAS pathに付いていないことと、Next-hopが直接対向のClientになっていることでControl PlaneとData Planeが分離されていることが確認できます。これでは各Clientは直接BGPピアを確立することなく、直接経路を交換した状態と同様の状態になりました。

まとめ

Route Serverの最低限の動作確認しかしていませんが、実際のIXではRoute ServerだけでなくSwitch Fabricの部分まで含めて細かい設定やチューニングが必要になります。
今回はJunosでRoute Serverを作りましたが、実環境で導入する際には運用の効率化や自動化の観点からLinux上でGoBGPのようなBGPデーモンを利用するほうが手軽だと感じています。 BGPコンテナを利用した検証環境の構築も手軽にできるのがメリットです。
また実環境ではIX上のRoute Serverは冗長構成で複数台あることが普通なので、異なるルーティングソフトウェアを利用して構築してあることもあるようです。
最近のIXにはDDoS対策として Black hole community(65535:666)を用いたRTBHや、VLANを用いた特定ユーザグループでのマルチクラウド(Azure, AWS ..etc)/トランジット接続の提供、CDNのコンテンツキャッシュアクセスへの提供など、帯域の効率的利用やポート単価などの時代の変遷に合わせた付加価値サービスも提供しています。
細かい技術要素を検証するのも楽しいですが今回はここまでにします。