MRAI の代表的なふるまい
BGP には古くからMRAI (Minimum Route Advertisement Interval) という機能がある．
イマイチ理解していなかったが，動作を確認しておく必要があり いくつかの実装を調査した．
ざっくり言うと
| vSRX | IOS-XRv | Quagga | |
|---|---|---|---|
| 新しいprefix の追加時 | MRAI 待つ | MRAI 待つ(*2) | MRAI 待たない |
| 最後の経路削除時(*1) | MRAI 待つ | MRAI 待たない | MRAI 待たない |
| 経路切替時 | Best Path になってからMRAI 待つ | 前回のUpdate からMRAI 待つ | MRAI 周期でのみUpdate |
- (*1) prefix ごとの，最後の経路(path)
- (*2) 5% 程度，待たないpacket があったため要調査
このようにさまざまな実装がある．
以下目次：
- MRAI (Minimum Route Advertisement Interval) とは
- MRAI の動作
- ここまでのまとめ: MRAI の動作 (経路の追加 / 削除時)
- MRAI の動作 (続き)
- まとめ
MRAI (Minimum Route Advertisement Interval) とは
簡単にいえば「BGP Update Message の送る頻度を，prefix ごとに制限する」機能のこと．多くのルーターではBGP neighbor 単位で設定できる．
インターネットでは，各事業者のネットワーク拡張や障害などによるBGP 経路の変化が日常的に起こっているが，短時間に大量に変化したり，長時間経路がフラップし続けるとヤバい場合がある．たとえば，末端のちいさなルーターで経路計算が追いつかず，通信に影響が出たりする．
BGP は受け取った経路をもとに各ルーターがベストパスを計算し，ピアに伝達する (BGP Update を送る) プロトコルのため，ピアから大量のBGP Update を受け取った場合は力の限り計算し，力の限り 別ピアに送りつける．
MRAI はこの動作を緩和するしくみで，力の限り計算するが，結果を送りつけるときには 一定期間の間をあけて やさしく送ることができる．
多くの実装で「期間」を設定することができるが，「何と何のあいだの期間か」は実装による． だいたい共通するのは，
- BGP neighbor 単位で設定できる
- 単位は秒
- ピア & prefix (BGP 経路の宛先情報) のペアごとにタイマーを持つ
おおまかには，MRAI は経路計算結果をバッファしておいて 一定時間待ってフラッシュするしくみと捉えておけばいいと思う．同じprefix について何度も経路計算したとしてもフラッシュ時には1 Update になるため，結果的にBGP Update の数を抑えることができる．
MRAI にはデメリットもある点に注意．バッファすることでBGP Convergence が遅くなる場合もあり，インターネットを少しずつ不安定にしてしまうかもしれない．これについてはまた別のエントリーで書く．
MRAI の標準化
この機能は10年以上も前から実装があるが，2008 年にInternet Draft が書かれている．最新のI-D もExpire していて 現在でも標準はない．各社独自実装している状況．
最新のI-D によると
The Minimum Route Advertisement Interval (MRAI) timer is specified in RFC4271 [BGP]. This timer acts to rate-limit updates, on a per- destination basis. [BGP] suggests values of 30s and 5s for this interval for eBGP and iBGP respectively. The MRAI must also be applied to withdrawals according to RFC4271, a change from the earlier RFC1771.
Withdrawn にも適用せよ，とのこと．
MRAI の動作
のふるまいを調べてみた．各々設定は
Juniper vSRX
protocols bgp {
group foo {
out-delay 30;
}
}
- default: 0s
Cisco IOS-XRv
router bgp 65000 neighbor 192.168.0.75 advertisement-interval 30
- default: 0s (iBGP), 30s (eBGP)
Quagga
router bgp 65000 neighbor 192.168.0.75 advertisement-interval 30
- default: 5s (iBGP), 30s (eBGP)
こんな感じ．
経路の追加 / 削除時
まず，ベストパス選択がない場合の動作．RIB にない経路を入れ，消す．
左から重複のない新たな経路20000 prefix をBGP Update として入れ，経路処理して右に送り出すまでの時間を見る．十分時間経過したあとにBGP Update (Withdraw) を入れつつ同様に観測する．
経路の追加: Juniper vSRX (MRAI なし)
横軸に時刻(s)，BGP Update Message (パケット) を受信したタイミングを青レーンに描画，BGP Update Message (パケット) を送信したタイミングを黒レーンに描画した．
Best Path Selection がないとはいえ結構な遅延があるが，Update 受信 → 経路処理 → Update 送信 までInterval をおかず処理していることがわかる．
経路の追加: Juniper vSRX (MRAI: 30s)
グラフのスケールが違ってて申し訳ないが，経路処理の遅延に加えて30s のInterval をおいていることがわかる．
経路の削除: Juniper vSRX (MRAI なし)
追加と同様に，MRAI がなければInterval なし．
経路の削除: Juniper vSRX (MRAI: 30s)
追加と同様に，Withdraw 時にも30s のInterval が乗る．
経路の追加: Cisco IOS-XRv (MRAI なし)
次にIOS-XRv の結果．Interval は見られない．
Juniper xSRX に比べてBGP Update 処理遅延が小さいことも興味深い．
(同じような処理プロセスだが爆速なのか，並列化など手続き自体を工夫しているのか調べてない)
経路の追加: Cisco IOS-XRv (MRAI: 30s)
Interval を待たず 何か一部お漏らししているように見えるが，(青い四角の下の黒い線) たぶん30s 待ちたいんだろうなあと汲み取った．Interval なくUpdate を送ってしまっているのは，全体300 packet 中の20 packet．
経路の削除: Cisco IOS-XRv (MRAI なし)
Interval は見られない．
経路の削除: Cisco IOS-XRv (MRAI: 30s)
興味深いのは，Interval が見られない点．
送信したBGP Update (黒い線全体) は60 packet ほど．経路追加時には20 packet ほどInterval を待たないBGP Update があったが，必要になればあとで詳しく調べる予定．
経路の追加: Quagga (MRAI: 30s)
次にQuagga のふるまい．一見Interval をおいているように見えるが，よくみると4s に満たない程度なので，これはBGP Update 処理遅延と考えるのが妥当．
経路の削除: Quagga (MRAI: 30s)
Cisco IOS-XRv のようなふるまいで，Interval がない．
ここまでのまとめ: MRAI の動作 (経路の追加 / 削除時)
長くなったので一旦まとめ．
| vSRX | IOS-XRv | Quagga | |
|---|---|---|---|
| 新しいprefix の追加時 | MRAI 待つ | MRAI 待つ(*2) | MRAI 待たない |
| 最後の経路削除時(*1) | MRAI 待つ | MRAI 待たない | MRAI 待たない |
- (*1) prefix ごとの，最後の経路(path)
- (*2) 5% 程度待たないpacket があったため要調査
MRAI の動作 (続き)
経路切替時
次にBest Path Selection が走る場合．
同じAS と2 ピア張り，連続的にBest Path Selection が実行されるよう強弱 *1 をつけて同じprefix のBGP Update を送る．
経路の切替: Juniper vSRX (MRAI: 30s)
下のグラフは，
- 横軸: 時刻(s)
- 左からBGP Update を受信した時刻 = 正の値をプロット
- 右へBGP Update を送信した時刻 = 負の値をプロット
- 線が長い = 強い経路
- 線の色が同じ = 同じ経路 *2
のように描画したもの．
MRAI: 30s に対して10s ごとに強弱のBGP Update を入れた場合：
40s ごとに強弱のBGP Update を入れた場合：
Juniper vSRX は
- 送信するべき経路がBest Path になってから，30s (MRAI) 経過して初めてBGP Update を送信
- 送信するべき経路のBest Path が<30s の間に変わり続ける場合，BGP Update は送信されない
のようにふるまうことがわかる．
経路の切替: Cisco IOS-XRv (MRAI: 30s)
MRAI: 30s に対して10s ごとに強弱のBGP Update を入れた場合：
(60s すぎのBGP Update 受信(青) と送信(オレンジ) が重複している部分，送信のほうが若干早い)
40s ごとに強弱のBGP Update を入れた場合：
- 前回BGP Update を送信してから，30s (MRAI) を経過して初めてBGP Update を送信
- 30s 待つ間にBest Path が変わっていれば30s ですぐ送信するし，変わっていなければ以降Best Path が変わるまで送信しない
- 変わった時点ですぐ送信
のようにふるまうことがわかる．
経路の切替: Quagga (MRAI: 30s)
MRAI: 30s に対して10s ごとに強弱のBGP Update を入れた場合：
40s ごとに強弱のBGP Update を入れた場合：
Quagga は
- 30s (MRAI) ごとのサイクルでのみBGP Update を送信する
- 30s おきにBest Path が変わっていれば送信するし，変わってなければ送信しない
のようにふるまうことがわかる．
ここまでの3実装のふるまい(経路切替時)について，あるprefix に限定した動作であることに注意．prefix が異なれば送信タイミングは独立している．
2016/07/23 追記
コード読んだところQuagga はprefix ごとのタイマーを持たない．BGP neighbor 単位．prefix が違っても 一定のサイクルでまとめてUpdate 送信する．
まとめ
全体のまとめ．
| vSRX | IOS-XRv | Quagga | |
|---|---|---|---|
| 新しいprefix の追加時 | MRAI 待つ | MRAI 待つ(*2) | MRAI 待たない |
| 最後の経路削除時(*1) | MRAI 待つ | MRAI 待たない | MRAI 待たない |
| 経路切替時 | Best Path になってからMRAI 待つ | 前回のUpdate からMRAI 待つ | MRAI 周期でのみUpdate |
- (*1) prefix ごとの，最後の経路(path)
- (*2) 5% 程度，待たないpacket があったため要調査
見てわかるように，実装によりふるまいがけっこう違う．
目的によってMRAI がハマるとき / ハマらないときがある気がするけど，「このベンダーのこのバージョンでは…」といった具体的な仕様はさておき，多種多様な実装があることを知っておけばひとまず十分．MRAI を検討するときに
- 守りたいものはなにか
- MRAI で自衛できるものか
- 使っているルーターのMRAI はどのように動くか．守りたいものを守れるか
- MRAI を入れる → Convergence Time が伸びて困ることはないか
- 周辺のAS はどのようにふるまうか
などを考えればよいかな，と思う．あとデフォルトが0s でない装置もあるので知らず知らずのうちに使っているかもしれない．
