- ライター：安田 賢治
- 主にJuniper製ルータ・スイッチ担当として技術調査、検証評価、提案および導入支援に従事。
技術・市場調査や製品評価検証で得た知見を元に、製品・サービスの提案や拡販を支援。
目次
SR Policyとは
SR PolicyはSR-TE(Segment Routing-Traffic engineering)環境においてトラフィックの操作を行うための仕組みです。
これまでのJUNOSではTraffic-Engineeringを行う際にTunnel インタフェースを作成していましたが、SR Policy では Tunnel を使用せず代わりに Policy を定義します。Tunnel ではなく Policy を使用する理由は、Segment Routing （以下、SR） が source routing であり途中の経路状態を考慮する必要がないため、Head-End ルータによる経路制御をより柔軟に行うためと考えられます。Tunnel を使用した SR-TE も当面は使用可能である模様です。
構成
今回はSR Policy構成としてルータ3台で実施しました。
IGPはIS-ISを使用しています。
トラフィックの流れ。
IGPのコスト的には上のパス(sr1)を通るが、SR-Policyを用いて下のパス(sr4)を通るようにする。
設定確認
設定確認(PE2)
communityを用いてColor情報を対向のPE1に伝える。
設定確認(PE2)
PE1向けのcolor communityを有効化
状態確認
Color community状態確認(PE2)
PE1へBGPでアドバタイズした200.0.0.0/24に対し、Colorの設定(3.3.3.3宛はcolor 1200)が
紐付いていることを確認。
Color community状態確認(PE1)
PE2からBGPで受け取った200.0.0.0/24に対し、Colorの設定(3.3.3.3宛はcolor 1200)が
紐付いていることを確認。
PE1のルート情報を見てみます。
3.3.3.3宛へのルートがColor1200で紐づいており、P経由(10.0.1.2)へ向いている。
color情報1200で受け取っていることを確認。
まとめ
SR-Policyを使用して、colorを指定したTraffic Engineeringを指定及び、状態を確認できました。
SR policy は従来の tunnel-te インタフェースに比べてより柔軟な Traffic engineering を実現します。
例えば、CLI だけでなく BGP/ PCEP / Netconf などからもパス情報を受け取ることが出来るため、様々な要求にマッチしたパスを提供することが可能です。
この柔軟性は来るべきネットワーク自動化実現のための重要な一要素になると考えています。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
