[Multi-AS Segment Routing 検証連載 #5] Traffic Engineering in Multi-AS

サマリ

Multi-AS で構成されるネットワークにおける Traffic Engineering (TE) の実現
IOS XR の機能を用いて、 TE metric に基づき AS Border Router（ASBR）を選択する TE の動作検証に成功

この記事は Multi-AS Segment Routing 検証連載の第 5 回です。目次はこちら

概要

イノベーションセンターの岩田です。本記事では、Multi-AS での Segment Routing（SR）での Traffic Engineering（TE）の実現手法についてご紹介します。

Multi-AS において SR-TE で実現したい要求としては大きく以下の 2 つに分けられます。

(a) AS 内で意図した経路を選択したい（AS 内での TE）
(b) 他 AS との接続トポロジーを考慮した経路を選択したい（AS 間での TE）

本記事ではこの 2 つの TE を SR でどう実現するかについてご紹介します。特に (a) では出口となる ASBR の選択を AS 内で行う必要があります。そのために SR-TE の metric に基づいた egress node（ASBR）選択の実現例について検証パートでご紹介します。

(a) AS 内での TE

Multi-AS で AS 内での TE を実現する上での考慮点として、ある 1 つの宛先に対し egress node（ASBR）となる node 候補が複数存在する際にどう TE を実現するか、という点があります。

1 つの宛先に対し、1 つの ASBR のみが egress node となる場合の TE は endpoint の選択余地がないので Single-AS と同様に考えることができます。これに関しては第 4 回の記事で紹介したのでそちらをご参照ください。

ここでは、以下の図のような 1 つの ingress node に対し複数の ASBR が egress node になれる構成時の TE について考えます。

SR-TE を用いた経路制御をする場合には、SR Policy で定義した metric に基づいて、より優位な ASBR を選択するような経路を選択したいという要求が考えられます。通常は、各 BGP 経路の egress node となる ASBR は BGP ベストパス決定アルゴリズムにより決定されてしまいます ¹ 。 SR-TE で ASBR の選択をする場合には、 ingress node において何らかの方法で SR Policy の評価結果を BGP のベストパスに反映させる必要があります。

この要求を実現する機能として、 BGP ベストパス決定アルゴリズム時に SR Policy を評価するための機能が、IOS XR 7.3.2 以降で提供されています²。本記事の検証パートでは、この機能を用いて ASBR 選択を含めた Color-Based Steering を行うための設定例をご紹介します。

(b) AS 間での TE

AS 間での TE の実現手法としては BGP Egress Peer Engineering（EPE）があります。EPE は ASBR において Inter-AS 情報から BGP Peering Segments、もしくは BGP Peering SIDs と呼ばれる segment を作成し IGP へ広告することで、AS 内の ingress node から EBGP Peer の選択を可能とします。これにより、接続した AS も含めた TE が実現されます。

本連載で我々が取り組んでいる Inter-AS Option-B において EPE を用いた TE を実現するためには、 ASBR において VPN SID と BGP Peering SID の 2 つを同時に処理する必要がありますが、2022 年 8 月時点ではどの機器にも実装されていないため本記事では扱いません。

検証

本章では、ある宛先に対し複数の egress node（ASBR）が選択可能な Multi-AS/Multi-domain SR-MPLS 上での L3VPN において、ASBR 選択を含めた Color-Based Steering を行うための設定例をご紹介します。

トポロジー

下記のようなトポロジーを作成します。

3 つのルーターによる AS を 2 つ接続したコア網で、顧客 A を収容します。検証環境は Multi-vendor に構成します。使用する機器は下記の通りです。

SR Domain 1
- PE1、ASBR1: Cisco IOS XR 7.4.1
- ASBR2: Junos OS 21.3R1.9
SR Domain 2
- ASBR3: Cisco IOS XR 7.4.1
- PE2、ASBR4: Junos OS 21.3R1.9

検証の流れ

本検証では、下図に示す AS65000 の各リンクの TE metric を設定し変更することにより ASBR の選択が変わることを示します。具体的には ingress node（PE）において定義された、 TE metric を指標とした dynamic path を計算する SR Policy が、より小さい metric の経路を選択することを確認します。

また設定は、以下の手順で実施していきます。

TE metric に基づく経路制御をする SR Policy を作成する
PE1 から ASBR1 への経路の metric が最小となるように TE metric を設定し、意図通り ASBR1 が egress node として選択される事を確認する
PE1 から ASBR2 への経路の metric が最小となるように TE metric を設定変更し、意図通り egress node が ASBR2 に変更される事を確認する

アンダーレイの構築に関しては、第 2 回の検証例のアンダーレイと同様のため省略いたします。

1. TE metric に基づく経路制御のための SR Policy を作成する

各リンクで設定した TE metric を広告するための設定

本検証では、dynamic path を用いた TE により経路制御します。各リンクへ設定した TE metric 情報を Traffic Engineering Database (TED) に反映し、経路制御を行えるように Cisco ルーターへ以下の設定を追加します。

router isis 1
 distribute link-state
 address-family ipv4 unicast
  mpls traffic-eng level-2-only
 !
!

TE metric に基づく経路を選択するための SR Policy の設定

各 egress node（ASBR）を endpoint とする、 color が 100 に対応する SR Policy を作成します。以下の設定を PE1（XR）へすることにより PE と endpoint 間の各リンクの TE metric の合計値が最小となるような経路を表す segment list を生成します。

segment-routing
 traffic-eng
  policy path-based-te-metric-to-asbr1
   color 100 end-point ipv4 10.255.0.2
   candidate-paths
    preference 10
     dynamic
      metric
       type te
      !
     !
    !
   !
  !
 !
!

segment-routing
 traffic-eng
  policy path-based-te-metric-to-asbr2
   color 100 end-point ipv4 10.255.0.3
   candidate-paths
    preference 10
     dynamic
      metric
       type te
      !
     !
    !
   !
  !
 !
!

BGP color と SR Policy を関連付けを行う設定

本検証では Color-Based Steering を行うため、以下のように BGP 経路に紐付ける color を設定します。

PE1（XR）

vrf 100
 address-family ipv4 unicast
  export route-policy add-color-100
 !
!
extcommunity-set opaque color-100
  100
end-set
!
route-policy add-color-100
  set extcommunity color color-100
end-policy
!

PE2（Junos）

set policy-options community COLOR-100 members color:0:100
delete policy-options policy-statement EXPORT-POLICY-100
set policy-options policy-statement EXPORT-POLICY-100 term ROUTE-TARGET then community add VRF100-65001-RT
set policy-options policy-statement EXPORT-POLICY-100 term ADD-COLOR-100 then community add COLOR-100
set policy-options policy-statement EXPORT-POLICY-100 term ROUTE-TARGET then community add VRF100-SHARED-RT
set policy-options policy-statement EXPORT-POLICY-100 term REDIST-DIRECT from protocol direct
set policy-options policy-statement EXPORT-POLICY-100 term REDIST-DIRECT then accept

PE1 が PE2 から受け取った経路に color がついていることを確認します。

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24
Wed Jul 20 13:54:17.734 JST
BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 33          33
Last Modified: Jul 20 13:37:04.989 for 00:17:12
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001
    10.255.0.3 C:100 (bsid:24009) (metric 10) from 10.255.0.3 (10.255.0.3)
      Received Label 16
      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 33
      Extended community: Color:100 RT:64999:100 RT:65001:100
      SR policy color 100, up, not-registered, bsid 24009

      Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100

PE2 が PE1 から受け取った経路に color がついていることを確認します。

user@ASBR2> show route table bgp.l3vpn.0 detail
bgp.l3vpn.0: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden)
65000:100:192.168.0.0/24 (2 entries, 0 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 65000:100
                Next hop type: Indirect, Next hop index: 0
                Address: 0x704e3d4
                Next-hop reference count: 3
                Source: 10.255.0.3
                Next hop type: Router, Next hop index: 644
                Next hop: 10.0.1.2 via ge-0/0/1.0, selected
                Label operation: Push 16
                Label TTL action: prop-ttl
                Load balance label: Label 16: None;
                Label element ptr: 0x782ed48
                Label parent element ptr: 0x782ea50
                Label element references: 1
                Label element child references: 0
                Label element lsp id: 0
                Session Id: 0x142
                Protocol next hop: 10.255.0.3
                Label operation: Push 16
                Label TTL action: prop-ttl
                Load balance label: Label 16: None;
                Indirect next hop: 0x7199084 1048575 INH Session ID: 0x143
                State: <Active Int Ext ProtectionPath ProtectionCand>
                Local AS: 65001 Peer AS: 65001
                Age: 23:07      Metric2: 10
                Validation State: unverified
                ORR Generation-ID: 0
                Task: BGP_65001.10.255.0.3
                AS path: 65000 ?
                Communities: target:64999:100 target:65000:100 color:0:100
                Import Accepted
                VPN Label: 16
                Localpref: 100
                Router ID: 10.255.0.3
                Secondary Tables: 100.inet.0
                Thread: junos-main
         BGP    Preference: 170/-101
                Route Distinguisher: 65000:100
                Next hop type: Indirect, Next hop index: 0
                Address: 0x704e8b4
                Next-hop reference count: 2
                Source: 10.255.0.2
                Next hop type: Router, Next hop index: 0
                Next hop: 10.0.0.2 via ge-0/0/0.0, selected
                Label operation: Push 24005
                Label TTL action: prop-ttl
                Load balance label: Label 24005: None;
                Label element ptr: 0x782ee60
                Label parent element ptr: 0x782ea50
                Label element references: 1
                Label element child references: 0
                Label element lsp id: 0
                Session Id: 0x0
                Protocol next hop: 10.255.0.2
                Label operation: Push 24005
                Label TTL action: prop-ttl
                Load balance label: Label 24005: None;
                Indirect next hop: 0x71ac104 - INH Session ID: 0x0
                State: <NotBest Int Ext Changed ProtectionPath ProtectionCand>
                Inactive reason: Not Best in its group - IGP metric
                Local AS: 65001 Peer AS: 65001
                Age: 22:12      Metric2: 20
                Validation State: unverified
                ORR Generation-ID: 0
                Task: BGP_65001.10.255.0.2
                AS path: 65000 ?
                Communities: target:64999:100 target:65000:100 color:0:100
                Import Accepted
                VPN Label: 24005
                Localpref: 100
                Router ID: 10.255.0.2
                Secondary Tables: 100.inet.0
                Thread: junos-main

SR Policy の評価結果を BGP ベストパスに反映するための設定

BGP ベストパス選択アルゴリズムの評価時に SR Policy が評価されるように、 PE1 に以下のような設定を追加します。

router bgp 65000
 nexthop validation color-extcomm sr-policy
 bgp bestpath igp-metric sr-policy
!

この設定を追加すると Cisco ルーターの BGP ベストパス選択アルゴリズム³ の Step 8 において、 IGP metric の代わりに SR Policy path metric が評価されるようになります。Step 8 よりも優先度の高い評価項目である local preference や MED が設定されている場合は SR Policy の評価前にベストパスが決定し、経路へ反映されない事がある点にご注意ください。

また、SR Policy で定義できる metric type は以下の 5 つがあり、この機能において SR Policy の優先度は administrative distance values（admin values）として表されます。SR Policy の metric type と対応する admin values は以下の通りで、値が小さいほど優先されます。

latency（admin values: 10）
TE（admin values: 20）
IGP（admin values: 30）
hopcount（admin values: 40）
NONE/UNKNOWN metric type (for explicit segment list policies) （admin values: 100）

作成した SR Policy の確認

定義した SR Policy の評価結果を確認します。まだ各リンクへ TE metric を設定していないため、両 SR Policy 共に path accumulated metric が 10（1リンク当たりのデフォルト値）と計算されている事が分かります。

RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy
Sat Jul 16 16:20:32.590 JST

SR-TE policy database
---------------------

Color: 100, End-point: 10.255.0.2
  Name: srte_c_100_ep_10.255.0.2
  Status:
    Admin: up  Operational: up for 1d02h (since Jul 15 13:39:47.290)
  Candidate-paths:
    Preference: 10 (configuration) (active)
      Name: path-based-te-metric-to-asbr1
      Requested BSID: dynamic
        Protection Type: protected-preferred
        Maximum SID Depth: 10
      Dynamic (valid)
        metric Type: TE,   Path Accumulated metric: 10
          16001 [Prefix-SID, 10.255.0.2]
  Attributes:
    Binding SID: 24008
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no

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:05 (since Jul 16 16:20:26.833)
  Candidate-paths:
    Preference: 10 (configuration) (active)
      Name: path-based-te-metric-to-asbr2
      Requested BSID: dynamic
        Protection Type: protected-preferred
        Maximum SID Depth: 10
      Dynamic (valid)
        metric Type: TE,   Path Accumulated metric: 10
          16002 [Prefix-SID, 10.255.0.3]
  Attributes:
    Binding SID: 24009
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no

path accumulated metric が等しい場合、この時点では ASBR1（10.255.0.2）が egress node として選択されていることが確認できました。

RP/0/RP0/CPU0:PE1#show route vrf 100
Sat Jul 16 16:51:50.976 JST

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP
       A - access/subscriber, a - Application route
       M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path

Gateway of last resort is not set

C    192.168.0.0/24 is directly connected, 00:05:33, GigabitEthernet0/0/0/2
L    192.168.0.254/32 is directly connected, 00:05:33, GigabitEthernet0/0/0/2
B    192.168.1.0/24 [200/0] via 10.255.0.2 (nexthop in vrf default), 00:04:17

以下のように VPN 経路を確認すると (admin 20) と出力され、admin values が 20 である TE metric に基づいた SR Policy が適用されていることも確認できました。

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24
Wed Jul 20 14:00:12.294 JST
BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 42          42
Last Modified: Jul 20 13:59:56.989 for 00:00:15
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001
    10.255.0.2 C:100 (bsid:24008) (admin 20) (metric 10) from 10.255.0.2 (10.255.0.2)
      Received Label 24005
      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 42
      Extended community: Color:100 RT:64999:100 RT:65001:100
      SR policy color 100, up, not-registered, bsid 24008

      Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100

これで準備は完了です。次の節から各リンクへ TE metric を設定することでより metric 値が小さい経路となる ASBR が選択できることを確認していきます。

2. PE1、ASBR1 間経路の metric が最小となるように設定し、ASBR1 が egress node として選択される事を確認する

上図のように、TE metric を設定し、ASBR1 が egress node として選択される事を確認していきます。

TE metric の設定

PE1 と ASBR1 間に metric を設定（PE1）

segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/0
   metric 50
  !
 !
!

PE1 と ASBR2 間に metric を設定（PE1）

segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/1
   metric 100
  !
 !
!

ASBR1 と ASBR2 間に metric を設定（ASBR1）

segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/1
   metric 100
  !
 !
!

SR Policy の評価結果

以下のように、PE1 と ASBR1 間の metric が 50、PE1 と ASBR2 間の metric が 100 とそれぞれ計算されていることが確認できました。

RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy
Wed Jul 20 14:09:55.662 JST

SR-TE policy database
---------------------

Color: 100, End-point: 10.255.0.2
  Name: srte_c_100_ep_10.255.0.2
  Status:
    Admin: up  Operational: up for 00:37:58 (since Jul 20 13:31:57.085)
  Candidate-paths:
    Preference: 10 (configuration) (active)
      Name: path-based-te-metric-to-asbr1
      Requested BSID: dynamic
        Protection Type: protected-preferred
        Maximum SID Depth: 10
      Dynamic (valid)
        Metric Type: TE,   Path Accumulated Metric: 50
          16002 [Prefix-SID, 10.255.0.2]
  Attributes:
    Binding SID: 24008
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no

Color: 100, End-point: 10.255.0.3
  Name: srte_c_100_ep_10.255.0.3
  Status:
    Admin: up  Operational: up for 00:37:58 (since Jul 20 13:31:57.087)
  Candidate-paths:
    Preference: 10 (configuration) (active)
      Name: path-based-te-metric-to-asbr2
      Requested BSID: dynamic
        Protection Type: protected-preferred
        Maximum SID Depth: 10
      Dynamic (valid)
        Metric Type: TE,   Path Accumulated Metric: 100
          16003 [Prefix-SID, 10.255.0.3]
  Attributes:
    Binding SID: 24009
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no

egress node として、ASBR1 が採用されていることも確認できました。

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24 detail
Wed Jul 20 14:10:37.611 JST
BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 43          43
    Flags: 0x00003001+0x00000000;
Last Modified: Jul 20 14:09:45.989 for 00:00:51
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0xa000000005060005, import: 0x80
  Not advertised to any peer
  65001
    10.255.0.2 C:100 (bsid:24008) (admin 20) (metric 50) from 10.255.0.2 (10.255.0.2), if-handle 0x00000000
      Received Label 24005
      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 42
      Extended community: Color:100 RT:64999:100 RT:65001:100
      SR policy color 100, up, not-registered, bsid 24008

      Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100

traceroute による経路確認

traceroute により、ASBR1 経由で転送されていることが確認できました。

RP/0/RP0/CPU0:PE1#traceroute 192.168.1.254 vrf 100
Wed Jul 20 14:11:09.185 JST

Type escape sequence to abort.
Tracing the route to 192.168.1.254

 1  10.0.0.2 [MPLS: Label 24005 Exp 0] 56 msec  12 msec  7 msec
 2  10.100.0.2 [MPLS: Label 24007 Exp 0] 29 msec  5 msec  15 msec
 3  192.168.1.254 15 msec  3 msec  7 msec

3. PE1、ASBR2 間経路の metric が最小となるように設定し、ASBR2 が egress node として選択される事を確認する

上図のように、TE metric を設定し、ASBR1 が egress node として選択される事を確認していきます。

TE metric の設定

PE1 と ASBR1 間に metric を設定（PE1）

segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/0
   metric 100
  !
 !
!

PE1 と ASBR2 間に metric を設定（PE1）

segment-routing
 traffic-eng
  interface GigabitEthernet0/0/0/1
   metric 50
  !
 !
!

ASBR2 と ASBR1 間に metric を設定（ASBR2）

set protocols isis interface ge-0/0/1.0 level 2 te-metric 100

SR Policy の評価結果

以下のように、PE1 と ASBR1 間の metric が 100、PE1 と ASBR2 間の metric が 50 とそれぞれ計算されていることが確認できました。

RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy
Wed Jul 20 14:11:44.058 JST

SR-TE policy database
---------------------

Color: 100, End-point: 10.255.0.2
  Name: srte_c_100_ep_10.255.0.2
  Status:
    Admin: up  Operational: up for 00:39:47 (since Jul 20 13:31:57.085)
  Candidate-paths:
    Preference: 10 (configuration) (active)
      Name: path-based-te-metric-to-asbr1
      Requested BSID: dynamic
        Protection Type: protected-preferred
        Maximum SID Depth: 10
      Dynamic (valid)
        Metric Type: TE,   Path Accumulated Metric: 100
          16002 [Prefix-SID, 10.255.0.2]
  Attributes:
    Binding SID: 24008
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no

Color: 100, End-point: 10.255.0.3
  Name: srte_c_100_ep_10.255.0.3
  Status:
    Admin: up  Operational: up for 00:39:47 (since Jul 20 13:31:57.087)
  Candidate-paths:
    Preference: 10 (configuration) (active)
      Name: path-based-te-metric-to-asbr2
      Requested BSID: dynamic
        Protection Type: protected-preferred
        Maximum SID Depth: 10
      Dynamic (valid)
        Metric Type: TE,   Path Accumulated Metric: 50
          16003 [Prefix-SID, 10.255.0.3]
  Attributes:
    Binding SID: 24009
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no

egress node として、ASBR2 が採用されていることも確認できました。

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf 100 192.168.1.0/24 detail
Wed Jul 20 14:12:06.724 JST
BGP routing table entry for 192.168.1.0/24, Route Distinguisher: 65000:100
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 49          49
    Flags: 0x00003001+0x00000000;
Last Modified: Jul 20 14:11:34.989 for 00:00:31
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0xa000000005060005, import: 0x80
  Not advertised to any peer
  65001
    10.255.0.3 C:100 (bsid:24009) (admin 20) (metric 50) from 10.255.0.3 (10.255.0.3), if-handle 0x00000000
      Received Label 16
      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 0, Local Path ID 1, version 49
      Extended community: Color:100 RT:64999:100 RT:65001:100
      SR policy color 100, up, not-registered, bsid 24009

      Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:100

パケットカウンタによる経路確認

我々の環境では IOS XR の PE から Junos の ASBR を経由する経路に対し traceroute を実行すると Junos ルーターが応答せず経路確認できないため、ASBR2 と ASBR4 間リンクの ASBR2 側のインタフェース（ge-0/0/2）の Output packets を計測することにより、パケットが ASBR2 を経由したと確認していきます。

以下のように該当インタフェースの統計情報をクリアします。

user@ASBR2> clear interfaces statistics ge-0/0/2

user@ASBR2> show interfaces ge-0/0/2 statistics | match "Output packets"
    Output packets: 0

次に対向へパケットを一定数送ります。これで疎通できていることは確認できました。

RP/0/RP0/CPU0:PE1#ping 192.168.1.254 vrf 100 count 1000 size 100 interval 1
Wed Jul 20 14:23:45.959 JST
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/4/21 ms

インタフェースの Output packets を確認すると以下のようにパケットカウンタが増え、ASBR2 を経由して通信できていることが確認できました。

user@ASBR2> show interfaces ge-0/0/2 statistics | match "Output packets"
    Output packets: 1004

まとめ

本記事では、Multi-AS での SR-TE を実現する上での考慮点を紹介し、Multi-AS/Multi-domain SR-MPLS 上での L3VPN において、TE metric に基づいた ASBR 選択を含む Color-Based Steering による経路制御の検証結果を紹介しました。次回の記事では、Flexible Algorithm を用いた TE について紹介予定です。

（2022/08/22 追記）公開しました：[Multi-AS Segment Routing 検証連載 #6] IGP Flexible Algorithm