- ナレッジセンター
- 匠コラム
ODNとXTCによる快適なSR-TE policy運用
- 匠コラム
- 設計構築
- ネットワーク
ビジネス開発本部 第3応用技術部
第3チーム
高田 聡士
目次
- はじめに
- ODN（On-Demand Nexthop）概要
- XTC（IOS-XR Traffic Controller）概要
- 検証構成
- Config設定内容
- 状態確認
- 障害時動作確認
- まとめ
- 関連記事
はじめに
5Gのための通信基盤で必要となるネットワークスライシングを実現させる手法の1つとして、Traffic Engineeringがあります。
Segment Routing（以下「SR」）では、SR-TE policyと呼ばれるpolicyを使用して、このTraffic Engineeringを実現します。
今後はネットワークスライシングを前提とした通信の需要が増えていくこと見込まれており、これに伴ってSRネットワーク上のRouterが取り扱うSR-TE policyの数も増大していくことが想定されます。
さらにSR-TE policyの数が増えていくと、それに比例してネットワークの管理や運用にかかる手間も増えていくことになります。
このような状況に対応するために、Cisco社のIOS-XRを使用するRouter製品（ASR9000シリーズやNCS5500シリーズ 等）には、SR-TE policyを使用するネットワークの運用改善に役立つ機能が存在します。
その中でもODN（On-Demand Nexthop）やXTC（IOS-XR Traffic Controller）はそれぞれ “Config設定の煩雑さ” や “Routerへの負荷” といった問題を解決するための大きな助けとなります。
本コラムではODNやXTCがどのように運用改善に役立つかを解説し、実際にこれらの機能を使用した環境の構築方法と動作確認結果についてご紹介します。
ODN（On-Demand Nexthop）概要
ODNは、Head-End Router（以下「HE Router」）がTail-End Router（以下「TE Router」）からcolor community情報を受け取ったことをトリガとしてSR-TE policyを自動的にインスタンス化し、TE RouterをBGP next-hopとして設定する機能です。
普段は、HE Routerにてインスタンス化されていないSR-TE policyがTE Routerから必要な情報を受け取った時に（つまりOn-Demandに）インスタンス化され、同時にnext-hopが設定されるためOn-Demand Nexthopと呼ばれます。
ODNを使用するメリットとして『configの設定量が削減される』というものがあります。
通常、同じcolor情報を使用する複数のTE Routerが存在する場合は、HE RouterにおいてそれぞれのTE Router毎にSR-TE policyを設定する必要があります。
＜通常のSR-TE policy設定＞
これに対してODNでは、同じcolor情報が使用されていればTE Routerが幾つ存在してもHE Routerでの設定は1つで済みます。
＜ODNを使用した設定＞
これはODNがTE RouterをBGP next-hopとして設定できるため、Configでnext-hop（End-point）を指定する必要が無いために実現される動作となります。
このようにODNを使用することでHE Routerのconfigを削減し、運用の手間を減らすことが可能となります。
XTC（IOS-XR Traffic Controller）概要
XTCはIOS-XRに内包されているSRに対応したPCEP Controller（SR-PCE）です。
通常はHE RouterがSR-TE policyに関するパス計算を実施しますが、XTCはこのパス計算を代わりに実施することができます。
XTCをネットワークに組み込むことで次のようなメリットが得られます。
- HE Routerの負荷低減
取り扱うSR-TE policyの数が増えてくると、それを維持/管理するHE Routerにかかる負荷も増大していきます。
パス計算をXTCに任せることでHE Routerにかかる負荷を低減させることができます。
- パス情報の集中管理
HE Routerでパス計算を実施していると、ネットワークで使用されているパス情報がHE Router毎に点在していることになります。
パス計算をXTCに任せるとネットワーク内の各HE Routerが使用しているパス情報をXTCが保持することとなり、結果としてパス情報の集中管理が可能となります。
- Domainを跨いだEnd-to-Endのパス計算
HE Routerは自身が所属するDomain内の情報しか取得することができないため、異なるDomainを経由するパスの計算を行うことはできません。
XTCに全てのDomainのNetwork情報（Link State情報）を持たせることができれば、XTCでDomainを跨いだEnd-to-Endのパス計算を行うことができ、その結果をHE Routerに伝えることでEnd-to-EndのTraffic Engineeringが可能となります。
このようなメリットがあるため、XTCを使用することは特に大量のSR-TE policyを運用していくうえで大きな助けとなります。
検証構成
ここからは実際にODNとXTCを使用した動作確認の内容と結果についてご紹介していきます。
まず構成についてですが、今回は下記のような検証構成で動作確認を行いました。
＜構成図＞
＜通信経路図＞
【構成内容】
- IGPとしてOSPFを使用しています
- 各Routerのloopback0のIP addressは、RouterAから順に1.1.1.1,1.1.1.2,1.1.1.3,1.1.1.4です
- 各RouterのNode-SIDは、RouterAから順に16001,16002,16003,16004です
- OSPFでTI-LFAとBFD（50msec x3）を有効化しています
- L3VPNのサービスを設定しています
vrfとして『RED』と『BLUE』の２つを設定しています - vrf REDはTE metric、vrf BLUEはlatencyを元に計算されたパスを使用して通信を行います
- 検証機の台数が不足していたため、RouterCとRouterDをXTCとして兼用で使用しています
- 今回の検証では全てCisco社のルータを使用しています
それぞれの機種とOS versionは下記の通りです
Config設定内容
ODNとXTCの機能を使用するにあたり必要となるConfig設定のポイントを紹介します。
ODN設定
＜HE Router側＞
＜TE Router側＞
今回はvrf設定セクションでexport設定をしています。
BGPのneighbor設定セクションでの設定も可能です。
XTC設定
複数のRouter（RouterC/RouterD）をPCEとして設定し、冗長化します。
＜PCE設定＞
PCC側（全てのRouter）でprecedence値を設定し、優先度を決定します。
・数値が小さい方が優先されます
・デフォルト値は255（最大値）です
＜PCC設定＞
PCEにはこれ以外にNetworkのlink state情報を取得するために、IGPにdistribute link-stateの設定が必要です。
＜PCE への設定＞
本来、さらにIGPに参加しないXTCにlink state情報を引き渡すためにBGP-LSの設定も必要ですが、今回はIGPに参加しているRouterをXTCとして動作させているためBGP-LSの設定は行っていません。
Performance-measurement設定
今回の検証ではmetricとしてlatencyも使用します。
latencyでの経路計算を確定させるために手動でdelay値を設定します。
状態確認
設定した各機能の動作状態について紹介します。
ODN状態確認
＜color情報取得状況＞
＜SR-TE policy情報：vrf RED/color 101＞
＜SR-TE policy情報：vrf BLUE/color 102＞
XTC状態確認
＜PCE状態確認＞
＜PCC状態確認＞
Performance-measurement状態確認
＜OSPF database情報＞
各LinkのDelay値がConfigで設定した値となっています。
障害時動作確認
ODNとXTCを設定した環境での障害発生時の動作について確認しましたので紹介します。
Link障害時の動作
vrf REDとvrf BLUEの通信がともに使用しているRouterBとRouterDの間のLinkをDownさせました。
この時、通信経路は下図のように切り替わります。
SR-TE policyの情報を確認するとパス計算結果が上図の新しい経路のものに変更されていることが分かります。
＜SR-TE policy情報：vrf RED/color 101＞
＜SR-TE policy情報：vrf BLUE/color 102＞
Link障害時の通信断時間
Link障害を発生させた際の通信の断時間を測定してみました。
結果は下記のようになりました。
＜RouterD側のInterfaceをDownさせた場合＞
- 復旧時は全て断無し
- RouterA -> RouterB方向はRouterDのinterfaceをshutdownしており、瞬時にTI-LFAによる経路切り替えが行われるため、断時間が0msになっていると考えられる
- RouterB -> RouterA方向はBFD（50ms x3）による断検知後、TI-LFAによる経路切り替えが行われていると考えられる
＜RouterB側のInterfaceをDownさせた場合＞
- 復旧時は全て断無し
- RouterA -> RouterB方向はBFD（50ms x3）による断検知後、TI-LFAによる経路切り替えが行われていると考えられる
- RouterB -> RouterA方向はRouterBのinterfaceをshutdownしており、瞬時にTI-LFAによる経路切り替えが行われるため断時間が0msになっていると考えられる
XTC障害時の動作
RouterAとRouterBの代わりにパス計算を行っているXTC、すなわちbest PCEとなっているRouterBのPCE設定を削除してXTC障害を疑似しました。
この時、通信経路の切替りは発生しませんでした。
SR-TE policyの情報を確認するとパス計算を実行するPCEがRouterD（1.1.1.4）に変更されていることが分かります。
＜SR-TE policy情報：vrf RED/color 101＞
＜SR-TE policy情報：vrf BLUE/color 102＞
またPCCの状態を確認するとbest PCEがRouterD（1.1.1.4）に変更されていることが分かります。
＜PCC状態確認＞
XTC障害時の通信断時間
XTC障害を発生させた際の通信の断時間を測定してみました。
結果は下記のようになりました。
この結果から、PCEのPrimaryからSecondaryへの切り替えは既存のパスやそのパスを使用する通信に影響を与えないことが分かりました。
まとめ
ST-TE policyの運用改善に役立つODN、XTCの概要とCisco社のIOS-XR Routerを用いた環境構築と動作確認結果についてご紹介しました。
ODNやXTCが大量のSR-TE policyを運用していく上で、有用な機能であることを感じていただけたかと思います。
また、今回行った環境構築と動作確認結果はあなた自身の設計や構築の参考になるかと考えております。
このコラムの内容がSR検討の一助となれば幸いです。
関連記事
- Configuration Guide
Segment Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 7.1.x
Segment Routing Configuration Guide for Cisco NCS 5500 Series Routers, IOS XR Release 7.2.x
執筆者プロフィール
高田 聡士
ネットワンシステムズ株式会社 ビジネス開発本部 第3応用技術部 第3チーム
SP事業会社のコアネットワークにNIerとして7年弱携わる
当時の主な担当製品はCisco社のCRSシリーズ
8年ほど前に現部署に異動し、Cisco社を含めたハイエンドルータ製品を担当
最近はArista社製品も担当
- 情報処理「ネットワークスペシャリスト」
- CCIE RS #50857
Webからのお問い合わせはこちらから
ナレッジセンターを検索する
カテゴリーで検索
タグで検索