サマリ
- SR-MPLS で構成されたネットワークにおいて、リンクの遅延を測定し Delay-Based TE を実現
- IOS XR + Junos の Multi-vendor 環境での動作検証
この記事は Multi-AS Segment Routing 検証連載の第 7 回です。目次は こちら
概要
イノベーションセンターの竹中です。本記事ではリンク遅延値を用いる Delay-Based TE について説明します。
Delay-Based TE は各リンクの遅延時間をメトリックとして、E2E 遅延が最短となる経路を選択する経路制御手法です。遅延最短経路はシビアなリアルタイム性が求められる、例えばライブ配信や遠隔操作などでの活用が期待されます。
以降では、Segment Routing を用いたネットワークにおける Delay-Based TE の実現手法と、遅延の実測方法や Multi-vendor 環境における制約を紹介します。
Delay Measurement
IGP Metric や TE Metric を利用する TE では、それぞれの Metric をインターフェースに静的に設定し、経路計算を行なっていました。 それに対し、Delay-Based TE を行うためにはリンクの遅延に対応する Delay Metric を動的に計測し、経路計算をする必要があります。 本節では遅延の計測方法について紹介します。
一般的な遅延計測プロトコルのユースケースには大きく分けて 2 パターンあります。
- リンク遅延測定
- 接続されている 2 台のルーター間の遅延測定
- Delay-based TE で用いる Delay Metric の算出に利用可能
- IOS XR / Junos で実装済み
- E2E 遅延測定
- E2E パスの遅延測定
- まだ標準化されていないが独自機能により SR Policy 単位で測定可能
- IOS XR にて実装有り
一般的に、遅延計測のためには Two-Way Active Measurement Protocol (TWAMP) と呼ばれる技術が利用されます。 本記事では Multi-vendor における TWAMP を利用したリンク遅延測定の検証と、Delay-Based TE の検証を実施します。
TWAMP の仕組み
TWAMP は、RFC5357 で標準化されている、IP ネットワークにおいてリンクの単方向遅延や双方向遅延を測定できるプロトコルです。 計測用のテストセッションを確立するための Server / Control-Client と、実際に計測用のパケットを交換する Session-Sender / Session-Reflector の 4 つの要素で構成されます。実装上は Server と Session-Reflector の組み合わせで responder として、Control-Client と Session-Sender の組み合わせで controller として扱われることもあります。
TWAMP を用いた遅延計測のおおまかな流れは次の通りです。
- Control-Client が TWAMP の well-known port (もしくは設定されたポート) で TCP コネクションを開始し、Server が greeting message を応答する
- Control-Client が通信モードと、必要に応じて完全性保護と暗号化のための情報を応答する。Server はモード受け入れの応答をする
- Control-Client がテストセッションを要求し、セッションを開始する
- Session-Sender と Session-Reflector の間でテストパケットを交換し計測する
- セッションを終了する
なお、セッション管理を排除し簡略化された TWAMP Light と呼ばれるプロトコルも定義されています。こちらは Server / Control-Client / Session-Sender を持つ controller と、Session-Reflector のみを持つ responder から構成されます。TWAMP Light においては responder はセッション情報を持たず、テストパケットに応答するのみになります。
補足として、TWAMP 検証の中で IOS XR / Junos において確認できた制約を記載します。 なお各バージョン番号は我々が検証に使用したバージョンです。
IOS XR
- NCS55A2 (IOS XR 7.4.1)
- Single-vendor、Multi-vendor 問わず controller / responder として動作確認可能
- ASR9901 (IOS XR 7.4.1)
- Single-vendor、Multi-vendor 問わず controller / responder として動作確認可能
- Cisco 8201 (IOS XR 7.5.1)
- well-known port である 862 が利用不可。利用可能ポートは <1024 ~ 15000>
- XRv9000 (IOS XR 7.4.1)
- responder としては 利用可能だが、controller としては利用不可
Junos
- MX204 (Junos 21.2R1.10)
- Single-vendor、Multi-vendor 問わず controller / responder として動作確認可能。well-known port 以外の利用可能ポートは <49152 ~ 65535>
- MX10003 (Junos 21.2R1.10)
- Single-vendor、Multi-vendor 問わず controlle / responder として動作確認可能。well-known port 以外の利用可能ポートは <49152 ~ 65535>
- PTX10001-36MR (Junos 21.2R1.15-EVO)
- Single-vendor、Multi-vendor 問わず controlle / responder として動作確認可能。well-known port 以外の利用可能ポートは <49152 ~ 65535>
- vMX (Junos 21.3R1.9)
- Single-vendor において controller / responder として動作確認可能。Multi-vendor については未検証。
特にポート番号の制約に着目すると Cisco 8201 と Juniper 機器群の間で相互接続できないことが予想されます。そして実際に確認したところ測定できませんでした。
Delay Metric の広告
Delay Metric を TE で利用するためには、SR Policy を管理するコントローラーや ingress PE といった、経路を計算する機器が各リンクの Delay Metric を保持している必要があります。広告方法としては IS-IS や OSPF などの IGP において TLV によってお互いに広告する方法や、BGP-LS を用いて AS を越えて広告する方法が挙げられます。 IGP では TE 向け拡張が RFC で定義され1 2、その中に Delay Metric の広告用 TLV も含まれています。
本連載では一貫して IGP に IS-IS を用いた AS 内の経路学習を行なってるため、本検証での Delay Metric の広告も IS-IS で行います。
Delay Metric を用いた TE の実装パターン
Delay Metric を用いた TE の実装方法は次の 2 種類があります。
- SR Policy の dynamic path による TE
- Delay Metric をリンクコストの制約として計算した Flex-Algorithm による TE
SR Policy の dynamic path とは第 5 回記事の検証でも利用した、SR Policy で指定したメトリックを用いて Segment List を計算する方法です。 Flex-Algorithm に関する説明と検証例は第 6 回記事にて行なったので、実装方法などはそちらを参照ください。
以降の検証章ではリンク遅延の計測から IGP での広告、Delay Metric を用いた SR Policy の作成と動作確認を行います。
TWAMP 動作検証
本記事での検証は、遅延の計測・広告と TE 実装で章を分けて説明します。 まず本章では TWAMP を用いたリンク遅延測定と IS-IS で測定値を広告する設定例を紹介します。 動作検証環境は下図の通りです。各ルーター間のリンクは直結です。
なお、IGP にて広告するリンク間遅延の測定手法として Cisco / Juniper ともに TWAMP Light3 形式で実装されているため、TWAMP Light の設定方法について紹介します。
設定と確認
TWAMP のサーバー、クライアント、IS-IS で広告するための設定を追加します。 なお IS-IS の基本設定の記載は省略します。基本設定は第 1 回記事を参照ください。
rt01 (IOS XR)
ipsla responder twamp-light test-session 1 local-ip 10.1.2.1 local-port 862 remote-ip 10.1.2.2 remote-port any vrf default ! ! ! performance-measurement interface TenGigE0/0/0/8 next-hop ipv4 10.1.2.2 delay-measurement ! ! !
rt02 (Junos)
set services rpm twamp server light port 862 set protocols isis interface xe-0/1/0.0 delay-measurement
上記設定を全て投入後、各ルーターにて計測が行われていること、IS-IS で広告していることを確認します。
rt01 (IOS XR)
RP/0/RSP0/CPU0:rt01#show performance-measurement interfaces tenGigE 0/0/0/8 brief
Tue Aug 16 20:05:55.144 JST
----------------------------------------------------------------------------------------------------------------------------------------------------------------
0/0/CPU0
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Interface Name Tx/Rx Avg/Min/Max/Variance (uSec)
--------------------------------------------------------------------------------------------------------------------------------------------------------------
TenGigE0/0/0/8 9/9 85/75/102/10
RP/0/RSP0/CPU0:rt01#show isis database rt01.00-00 verbose
Wed Aug 24 17:27:37.673 JST
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
rt01.00-00 * 0x000097b7 0x4c8f 991 /* 0/0/0
(snip)
Metric: 10 IS-Extended rt02.00
Local Interface ID: 26, Remote Interface ID: 349
Interface IP Address: 10.1.2.1
Neighbor IP Address: 10.1.2.2
Affinity: 0x00000000
Physical BW: 10000000 kbits/sec
Reservable Global pool BW: 0 kbits/sec
Global Pool BW Unreserved:
[0]: 0 kbits/sec [1]: 0 kbits/sec
[2]: 0 kbits/sec [3]: 0 kbits/sec
[4]: 0 kbits/sec [5]: 0 kbits/sec
[6]: 0 kbits/sec [7]: 0 kbits/sec
Admin. Weight: 10
Ext Admin Group: Length: 32
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
Physical BW: 10000000 kbits/sec
Link Average Delay: 79 us
Link Min/Max Delay: 52/114 us
Link Delay Variation: 18 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24009
rt02 (Junos)
user@rt02> show services rpm twamp client
Connection Session Sender Sender Reflector Reflector
Name Name address port address port
__r__2 __r__3 10.1.2.2 59823 10.1.2.1 862
user@rt02> show services rpm twamp client probe-results control-connection __r__2
Owner: __r__2, Test: __r__3
TWAMP-Server-Status: Light, Number-Of-Retries-With-TWAMP-Server: 0
Reflector address: 10.1.2.1, Reflector port: 862, Sender address: 10.1.2.2, sender-port: 52980
Test size: 10 probes
Probe results:
Response received
Probe sent time: Tue Aug 16 20:08:50 2022
Probe rcvd/timeout time: Tue Aug 16 20:08:50 2022
Rtt: 138 usec, Egress jitter: 28 usec, Ingress jitter: -44 usec, Round trip jitter: -137 usec
Egress interarrival jitter: 99 usec, Ingress interarrival jitter: 105 usec,
Round trip interarrival jitter: 137 usec
(snip)
user@rt02> show isis database rt02.00-00 extensive
IS-IS level 1 link-state database:
IS-IS level 2 link-state database:
rt02.00-00 Sequence: 0x1d6ea, Checksum: 0xf3cb, Lifetime: 1146 secs
(snip)
TLVs:
(snip)
IS extended neighbor: rt01.00, Metric: default 10 SubTLV len: 51
IP address: 10.1.2.2
Neighbor's IP address: 10.1.2.1
Local interface index: 349, Remote interface index: 26
Unidirectional link delay: 76
Min unidirectional link delay: 53
Max unidirectional link delay: 91
Unidirectional delay variation: 104
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 45
P2P IPv4 Adj-SID: 45, Weight: 0, Flags: --VL--
また、各ルーターにて対向から IS-IS でリンク遅延の広告が行われていることを確認します。
rt01 (IOS XR)
RP/0/RSP0/CPU0:rt01#show isis database rt02.00-00 verbose
Tue Aug 16 20:14:16.022 JST
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
rt02.00-00 0x0001b8fc 0xf246 1049 /1198 0/0/0
(snip)
Metric: 10 IS-Extended rt01.00
Interface IP Address: 10.1.2.2
Neighbor IP Address: 10.1.2.1
Local Interface ID: 349, Remote Interface ID: 26
Link Average Delay: 76 us
Link Min/Max Delay: 60/107 us
Link Delay Variation: 119 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:45
(snip)
rt02 (Junos)
user@rt02> show isis database rt01.00-00 extensive
IS-IS level 1 link-state database:
IS-IS level 2 link-state database:
rt01.00-00 Sequence: 0x9455, Checksum: 0x1a27, Lifetime: 630 secs
(snip)
TLVs:
(snip)
Extended IS Reachability TLV, Type: 22, Length: 159
IS extended neighbor: rt02.00, Metric: default 10 SubTLV len: 148
Local interface index: 26, Remote interface index: 349
IP address: 10.1.2.1
Neighbor's IP address: 10.1.2.2
Administrative groups: 0 <none>
Maximum bandwidth: 10Gbps
Maximum reservable bandwidth: 0bps
Current reservable bandwidth:
Priority 0 : 0bps
Priority 1 : 0bps
Priority 2 : 0bps
Priority 3 : 0bps
Priority 4 : 0bps
Priority 5 : 0bps
Priority 6 : 0bps
Priority 7 : 0bps
Traffic engineering metric: 10
Unknown sub-TLV type 252, length 32
Maximum bandwidth: 10Gbps
Unidirectional link delay: 79
Min unidirectional link delay: 52
Max unidirectional link delay: 114
Unidirectional delay variation: 18
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 24009
P2P IPv4 Adj-SID: 24009, Weight: 0, Flags: --VL--
(snip)
考察
Cisco ルーター同士（rt01-rt03 間）、Juniper ルーター同士（rt02-rt04 間）で TWAMP を用いてリンク遅延計測をしたところ、下記の計測結果に表示されているとおり遅延値に大きく差がありました。これは推測ですが、TWAMP の Session-Reflector が動作する場所の違いによるものだと考えられます。
※ このため、現状 Multi-vendor 環境において TWAMP によるリンク遅延実測値を用いた Delay-Based TE は必ずしも実態としての最短遅延パスを通るとは限らないと思われます。
Cisco ルーター間のリンク遅延計測結果
RP/0/RSP0/CPU0:rt01#show performance-measurement interfaces hundredGigE 0/0/0/20 brief Thu Aug 18 16:24:37.574 JST ---------------------------------------------------------------------------------------------------------------------------------------------------------------- 0/0/CPU0 ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Interface Name Tx/Rx Avg/Min/Max/Variance (uSec) -------------------------------------------------------------------------------------------------------------------------------------------------------------- HundredGigE0/0/0/20 6/6 3/3/4/0
Juniper ルーター間のリンク遅延計測結果
user@rt02> show services rpm twamp client
Connection Session Sender Sender Reflector Reflector
Name Name address port address port
__r__0 __r__1 10.1.8.1 58574 10.1.8.2 862
__r__2 __r__3 10.1.2.2 50830 10.1.2.1 862
user@rt02> show services rpm twamp client probe-results control-connection __r__0
Owner: __r__0, Test: __r__1
TWAMP-Server-Status: Light, Number-Of-Retries-With-TWAMP-Server: 0
Reflector address: 10.1.8.2, Reflector port: 862, Sender address: 10.1.8.1, sender-port: 58042
Test size: 10 probes
Probe results:
Response received
Probe sent time: Thu Aug 18 16:25:39 2022
Probe rcvd/timeout time: Thu Aug 18 16:25:39 2022
Rtt: 449 usec, Egress jitter: 97 usec, Ingress jitter: 29 usec, Round trip jitter: 169 usec
Egress interarrival jitter: 102 usec, Ingress interarrival jitter: 91 usec, Round trip interarrival jitter: 92 usec
(snip)
次章では広告されたリンク遅延の値を利用して Delay-Based TE を実装します。
Delay-Based TE 動作検証
本章では IS-IS によって広告されたリンク遅延を用いて TE を実装するための設定例を紹介します。
なお、本記事では SR Policy の作成に On-Demand Next-Hop（ODN）と呼ばれる手法を利用します。 ODN は SR Policy を動的に生成可能な仕組みです。SR Policy の生成条件となる color と、パラメータである Segment List（explicit or dynamic）を定義しておくことで、 IBGP で対象となる経路を受け取った際に BGP nexthop を endpoint とした SR Policy を自動で生成できます。 ODN を利用することで、複数の egress PE がある場合でも endpoint ごとの SR Policy の設定が不要となります。
トポロジー
下記のようなトポロジーで検証します。本章においては、リンク遅延（Delay Metric）は TE のわかりやすさのため図の通りに手動で設定します。 リンク遅延は実測値ベースのため往路と復路で非対称になり得ます。本検証では PE1 -> P1、P2 -> PE2 の片方向のみ値を 100 とし、他の Delay Metric は 10 とします。 非対称な Metric によって E2E の経路も非対称となることを確認します。
このように Delay Metric を設定したネットワークにおいて Delay-Based TE を実装した場合、次の図のような経路となることが想定されます。PE1 -> PE2 への転送時には Delay Metric の大きいリンクを避ける経路となり、PE2 -> PE1 への転送時にはリンクの Delay Metric が全て等しく最短経路となるためです。
物理構成や基本的な interface、IGP、BGP の設定は第 1 回記事をご参照ください。 検証において利用する機器は下記の通りです。
- PE1、P1: Cisco IOS XR 7.4.1
- PE2、P2: Junos 21.3R1.9
Delay Metric の手動設定と確認
リンク遅延の実測値を利用した場合 TE の様子が分かりにくくなるため、各ルーターにて手動で Delay Metric を付与します。
PE1 (IOS XR)
performance-measurement interface GigabitEthernet0/0/0/0 delay-measurement advertise-delay 100 ! ! interface GigabitEthernet0/0/0/1 delay-measurement advertise-delay 10 ! ! !
P1 (IOS XR)
performance-measurement interface GigabitEthernet0/0/0/0 delay-measurement advertise-delay 10 ! ! interface GigabitEthernet0/0/0/1 delay-measurement advertise-delay 10 ! ! interface GigabitEthernet0/0/0/2 delay-measurement advertise-delay 10 ! ! !
P2 (Junos)
set protocols isis interface ge-0/0/0.0 delay-metric 10 set protocols isis interface ge-0/0/1.0 delay-metric 100 set protocols isis interface ge-0/0/2.0 delay-metric 10
PE2 (Junos)
set protocols isis interface ge-0/0/0.0 delay-metric 10 set protocols isis interface ge-0/0/1.0 delay-metric 10
Delay Metric が IS-IS にて広告されていることを PE1 にて確認します。
RP/0/RP0/CPU0:PE1#show isis database verbose
Wed Aug 17 19:34:32.686 JST
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
PE1.00-00 * 0x0000068a 0xcd94 1016 /* 0/0/0
(snip)
Metric: 10 IS-Extended P1.00
Local Interface ID: 7, Remote Interface ID: 7
Interface IP Address: 10.0.0.1
Neighbor IP Address: 10.0.0.2
Physical BW: 1000000 kbits/sec
Link Average Delay: 100 us
Link Min/Max Delay: 100/100 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24003
Metric: 10 IS-Extended P2.00
Local Interface ID: 8, Remote Interface ID: 333
Interface IP Address: 10.0.1.1
Neighbor IP Address: 10.0.1.2
Physical BW: 1000000 kbits/sec
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24001
Hostname: PE1
P1.00-00 0x00000680 0x67b0 1197 /1200 0/0/0
(snip)
Metric: 10 IS-Extended PE1.00
Local Interface ID: 7, Remote Interface ID: 7
Interface IP Address: 10.0.0.2
Neighbor IP Address: 10.0.0.1
Physical BW: 1000000 kbits/sec
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24005
Metric: 10 IS-Extended PE2.00
Local Interface ID: 8, Remote Interface ID: 333
Interface IP Address: 10.0.2.1
Neighbor IP Address: 10.0.2.2
Physical BW: 1000000 kbits/sec
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24003
Metric: 10 IS-Extended P2.00
Local Interface ID: 9, Remote Interface ID: 335
Interface IP Address: 10.0.4.1
Neighbor IP Address: 10.0.4.2
Physical BW: 1000000 kbits/sec
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24001
PE2.00-00 0x000006a3 0x86aa 1050 /1200 0/0/0
(snip)
Metric: 10 IS-Extended P1.00
Interface IP Address: 10.0.2.2
Neighbor IP Address: 10.0.2.1
Local Interface ID: 333, Remote Interface ID: 8
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:17
Metric: 10 IS-Extended P2.00
Interface IP Address: 10.0.3.1
Neighbor IP Address: 10.0.3.2
Local Interface ID: 334, Remote Interface ID: 334
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:16
(snip)
P2.00-00 0x000006aa 0xca39 1066 /1198 0/0/0
(snip)
Metric: 10 IS-Extended PE1.00
Interface IP Address: 10.0.1.2
Neighbor IP Address: 10.0.1.1
Local Interface ID: 333, Remote Interface ID: 8
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:17
Metric: 10 IS-Extended PE2.00
Interface IP Address: 10.0.3.2
Neighbor IP Address: 10.0.3.1
Local Interface ID: 334, Remote Interface ID: 334
Link Average Delay: 100 us
Link Min/Max Delay: 100/100 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:16
Metric: 10 IS-Extended P1.00
Interface IP Address: 10.0.4.2
Neighbor IP Address: 10.0.4.1
Local Interface ID: 335, Remote Interface ID: 9
Link Average Delay: 10 us
Link Min/Max Delay: 10/10 us
Link Delay Variation: 0 us
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:18
(snip)
ODN による SR Policy の定義
各 PE にて ODN を設定します。
PE1 (IOS XR)
segment-routing
traffic-eng
on-demand color 100
dynamic
metric
type latency
!
!
!
!
!
PE2 (Junos)
set routing-options dynamic-tunnels ODN-100 spring-te source-routing-path-template ODN-100-TMP color 100 set routing-options dynamic-tunnels ODN-100 spring-te destination-networks 0.0.0.0/0 set protocols source-packet-routing compute-profile DYNAMIC-DELAY metric-type delay set protocols source-packet-routing source-routing-path-template ODN-100-TMP primary odn_path compute DYNAMIC-DELAY
BGP 経路に color 100 を付加することで動的に SR Policy が作成されます。 color の付加方法は第4回記事を参照ください。
color 付加後、Delay-Based TE のための SR Policy が作成されていることが確認できます。
PE1 (IOS XR)
RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy
Wed Aug 17 21:02:43.435 JST
SR-TE policy database
---------------------
Color: 100, End-point: 10.255.0.3
Name: srte_c_100_ep_10.255.0.3
Status:
Admin: up Operational: up for 00:00:49 (since Aug 17 21:01:53.919)
Candidate-paths:
Preference: 200 (BGP ODN) (active)
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (valid)
Metric Type: LATENCY, Path Accumulated Metric: 30
16003 [Prefix-SID, 10.255.0.4]
16001 [Prefix-SID, 10.255.0.2]
16002 [Prefix-SID, 10.255.0.3]
Preference: 100 (BGP ODN)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_100_ep_10.255.0.3_discr_100
PLSP-ID: 1
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (pce) (invalid)
Metric Type: NONE, Path Accumulated Metric: 0
Attributes:
Binding SID: 24007
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
PE2 (Junos)
user@PE2> show spring-traffic-engineering lsp detail
Name: 10.255.0.1:64:dt-srte-ODN-100
Tunnel-source: Dynamic Tunnel Module(DTM)
Tunnel Forward Type: SRMPLS
Tunnel-template: ODN-100-TMP
To: 10.255.0.1-100<c>
State: Up
Path: odn_path
Path Status: NA
Outgoing interface: NA
Auto-translate status: Disabled Auto-translate result: N/A
Compute Status:Enabled , Compute Result:success , Compute-Profile Name:DYNAMIC-DELAY
Total number of computed paths: 1
Computed-path-index: 1
BFD status: N/A BFD name: N/A
TE metric: 110, IGP metric: 20
Delay metrics: Min: 20, Max: 20, Avg: 20
Metric optimized by type: Minimum-Delay
computed segments count: 1
computed segment : 1 (computed-node-segment):
node segment label: 16001
router-id: 10.255.0.1
疎通確認
traceroute を用いて TE によるパケットの往復の転送経路を確認します。 リンク遅延は実測値ベースのため往路と復路で非対称になり得ます。本検証では PE1 -> P1、P2 -> PE2 の片方向のみ値を 100 としたので PE1 -> PE2 の経路のみ PE1 - P1 と P2 - PE2 のリンクを避ける経路となるはずです。
PE1 -> PE2
RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 100 Thu Aug 18 14:48:00.861 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.0.1.2 [MPLS: Labels 16002/16003/16 Exp 0] 18 msec 3 msec 7 msec 2 10.0.4.1 [MPLS: Labels 16003/16 Exp 0] 23 msec 20 msec 19 msec 3 192.168.1.254 12 msec 2 msec 8 msec
PE2 -> PE1
user@PE2> traceroute 192.168.0.254 routing-instance 100
traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets
1 10.0.3.2 (10.0.3.2) 2.729 ms 1.820 ms 1.731 ms
MPLS Label=16001 CoS=0 TTL=1 S=0
MPLS Label=24004 CoS=0 TTL=1 S=1
2 10.0.1.1 (10.0.1.1) 14.716 ms * 11.153 ms
次の図のように、P1 -> PE1、PE2 -> P2 のリンク遅延を大きくすることで PE2 -> PE1 の経路も PE1 -> PE2 と同じ経路を通ることを確認します。
PE2
[edit] user@PE2# set protocols isis interface ge-0/0/1.0 delay-metric 100 [edit] user@PE2# show | compare [edit protocols isis interface ge-0/0/1.0] - delay-metric 10; + delay-metric 100;
P1
performance-measurement
interface GigabitEthernet0/0/0/0
delay-measurement
<- advertise-delay 10
+> advertise-delay 100
!
!
!
end
再度 PE2 -> PE1 で traceroute を行うと経路が変わっていることが確認できます。
PE2 -> PE1
user@PE2> traceroute 192.168.0.254 routing-instance 100
traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets
1 10.0.2.1 (10.0.2.1) 8.389 ms 8.118 ms 10.108 ms
MPLS Label=16004 CoS=0 TTL=1 S=0
MPLS Label=16001 CoS=0 TTL=1 S=0
MPLS Label=24004 CoS=0 TTL=1 S=1
2 10.0.4.2 (10.0.4.2) 2.344 ms 2.011 ms 1.516 ms
MPLS Label=16001 CoS=0 TTL=1 S=0
MPLS Label=24004 CoS=0 TTL=2 S=1
3 10.0.1.1 (10.0.1.1) 13.928 ms * 13.418 ms
まとめ
本記事では、遅延計測技術である TWAMP と Delay Metric を用いて経路制御をする Delay-Based TE について紹介しました。 また Multi-vendor での TWAMP Light による遅延計測や計測結果の広告と、TE の実装について動作検証しました。 特に現状では遅延計測に対応できない機器の組み合わせがありました。
次回の記事では宛先 prefix 以外をトリガにした SR Policy の適用方法について紹介予定です。
（2022/09/16 追記） 公開しました：[Multi-AS Segment Routing 検証連載 #8] SR Policy の適用方法と活用
- IS-IS TE Metric Extensions: https://tex2e.github.io/rfc-translater/html/rfc8570.html↩
- OSPF TE Metric Extensions: https://tex2e.github.io/rfc-translater/html/rfc7471.html↩
- TWAMP Light: https://www.rfc-editor.org/rfc/rfc5357.html#appendix-I↩
