NTTドコモビジネスの技術ブログ

全632件

2022/12/20

はじめにこんにちは、イノベーションセンターの竹中です。本記事では、SR-TE を一元的に管理するためのソフトウェア実装である Pola PCE の概要や利用方法について紹介します。 Pola PCE は私と三島で実装し、現在 NTT Com より OSS 公開中です。 [Multi-AS Segment Routing 検証連載 #11] PCE 実装の検証記事でも一部機能を紹介しましたが、本記事では Example を用いた試用環境の準備、ベンダールーターを用いての環境準備、また各機能について紹介します。また、Go で開発したツールを OSS として公開する中で得た知見を NTT Communications Advent Calendar 2022 8日目で紹介しているので、こちらも是非ご覧ください。目次 Pola PCE 概要 Pola PCE とはどのような特徴を持つ PCE であるか、またその活用方法について記載 Docker 環境を用いた Explicit Path 機能の検証手元の Docker 環境のみで Pola PCE を検証する手順を紹介 Multi-vendor で構成されるネットワークを用いた Dynamic Path 機能の検証 Multi-vendor 機器を用いて構築された SR-MPLS 環境において Pola PCE を利用する手順を紹介 SR-TE や PCE に興味を持ち、簡潔な構成で Pola PCE の機能を試してみたい方は、まずは Docker 環境を用いた検証をお勧めします。なお PCE とは何か、については下記記事にて紹介しているためこちらも併せて参考にしてください。 engineers.ntt.com 開発へのモチベーション Pola PCE の紹介の前段として、開発に至ったモチベーションについて話します。開発のモチベーションは大きく分けて 3 つあります。 1 つ目は、最新 RFC や Internet-Draft で議論中の PCE に関する機能を先行して実装し、検証したいという要求です。自作の PCE を準備することで、RFC や Internet-Draft の更新に合わせてリアルタイムに実装状況を更新し、自作 PCE - 各社ベンダー製 PCC の相互接続検証を行いたいです。 2 つ目は、Multi-vendor 対応な PCE を利用したいという要求です。 Multi-AS Segment Routing 検証連載で公開していますが、私たちは Multi-vendor 機器環境で Segment Routing の検証を行なっています。そのため、PCE についても Multi-vendor 対応な製品を利用したいです。 PCE の技術仕様に関しては RFC や Internet-Draft で未提案な部分もあり、PCC 機能にはベンダーごとに独自実装の部分も存在します。そのため、現状 Multi-vendor 環境において Color や Preference の情報などを含む PCEP の相互接続はまだできません。自作 PCE によってそのような問題の解決したいです。 3 つ目は、外部連携用の API を提供する軽量なツールが欲しいという要求です。必要に応じて機能の分割や拡張などが行えるようにマイクロサービスアーキテクチャを目指し、機能ごとに分かれたコンポーネントを API で連携する仕組みを利用したいです。例えば SR Policy 投入機能は独立して動作させたり、トポロジーを描写するツールと連携させて利用したいです。以上のモチベーションから Pola PCE を実装しました。 Pola PCE 概要できること Pola PCE では現在（v1.1.2） SR-MPLS で構成されるネットワークにおいて以下の機能が利用可能です。 PCC へ SR Policy の追加・更新 PCC で利用中の SR Policy の確認 GoBGP との連携による TED の取得 TED を保持することで経路計算が可能になり、Dynamic Path が利用可能 Multi-vendor 環境での利用 IOS XR、Junos、FRRouting を PCC として利用可能マイクロサービスアーキテクチャに基づいた実装 Pola PCE はマイクロサービスアーキテクチャに基づいた実装となっており、それぞれのプロセス間の連携を gRPC が担っています。そのため、各利用者の用途に応じて必要な機能のみを組み合わせて利用できます。最小構成であれば Pola PCE 単体で SR Policy の管理や Explicit Path の追加や更新ができる簡素な SR Policy 管理ツールとして利用できます。また Pola PCE のデーモンが gRPC インターフェースを提供しているため、デーモンを中核として、例えば以下のような高機能なネットワークコントローラを構築することも可能です。構成 Pola PCE の構成は以下の通りです。ツール単体は polad / pola CLI tool からなります。 polad は PCE デーモンであり、PCEP Session の管理や必要に応じたトポロジー情報の取得・管理、また、保持している情報を出力するための gRPC インターフェースを提供します。 pola CLI tool は polad の gRPC クライアントとなっており、入力したコマンドに応じて適切な gRPC リクエストを送信し polad の保持する情報を取得・更新します。トポロジー情報の取得の必要があれば GoBGP と連携させたり、gRPC インターフェースを提供しているためユーザーが polad の gRPC クライアント機能をもつツールを用意することで Pola PCE を制御することも可能です。実装予定の新機能私たちはチームの取り組みとして SR-MPLS だけでなく SRv6 環境での検証も行っております。 SRv6 環境での利用も想定しているため、今後の直近のアップデート予定として PCEP の SRv6 対応を開発中です。プロトコル拡張自体がまだ Internet-Draft で議論中のため、各ベンダーの SRv6 PCC 機能の実装状況や独自実装の内容を把握しつつ、Multi-vendor で動作する SRv6 PCE へと拡張する予定です。 Docker 環境を用いた Explicit Path 機能の検証公開中の example を用いて動作検証をします。検証環境の構築には OSS の Docker ベースなネットワークエミュレータである tinet を利用しているため、Docker が利用できる x86_64 CPU 機器が1台あれば手元で試せます。検証環境公開中の spec.yaml を用いて、tinet により以下のトポロジーを作成します。 SR-MPLS ドメインは FRRouting version:latest (2022年12月5日現在では v8.4.1) を用いて構築されます。手順 Docker、tinet のインストールについては手順を省略します。 pola リポジトリの取得 GitHub から pola リポジトリを clone します。 user@server:~$ git clone https://github.com/nttcom/pola トポロジーの構築・機器への config 投入ディレクトリを sr-mpls_l3vpn へ変更したのちに tinet コマンドを 1 つ実行すると全環境構築が完了します。 user@server:~$ cd pola/examples/sr-mpls_l3vpn/ user@server:~/pola/examples/sr-mpls_l3vpn$ tinet upconf | sudo sh -x docker ps でトポロジー図に記載してある、各機器名称に従ったコンテナが作成・起動していることが確認できます。 user@server:~/pola/examples/sr-mpls_l3vpn$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES fe439ecd0a78 host_ubuntu:latest "bash" 25 minutes ago Up 25 minutes host02 0b17cd9386aa host_ubuntu:latest "bash" 25 minutes ago Up 25 minutes host01 f92da0d39aea frr:latest "/sbin/tini -- /usr/…" 25 minutes ago Up 25 minutes p02 d5093e6fa5c1 frr:latest "/sbin/tini -- /usr/…" 25 minutes ago Up 25 minutes p01 8341a6836618 frr:latest "/sbin/tini -- /usr/…" 25 minutes ago Up 25 minutes pe02 a24a70528e1a frr:latest "/sbin/tini -- /usr/…" 26 minutes ago Up 25 minutes pe01 25c3666b6f17 pola:latest "bash" 26 minutes ago Up 26 minutes pola なお、Pola PCE や FRRouting の初期設定は example の spec.yaml に記載しているため、気になる方はご確認ください。 PCEP Session の確認 pola session コマンドによって PCEP Session を確認します。 docker exec で pola コンテナに入り、コマンドを実行します。 user@server:~/pola/examples/sr-mpls_l3vpn$ docker exec -it pola /bin/bash root@pola:/# pola session sessionAddr(0): 10.0.255.1 SR Policy の発行 SR Policy のパラメータ指定する yaml ファイルを作成し、 pola sr-policy add コマンドで SR Policy を PCC に発行します。本検証では、pe01 から pe02 への VPN 経路（color 1）に対して、pe01 -> p01 -> p02 -> pe02 を通るようにするための SR Policy を発行します。作成する yaml ファイル # policy1.yaml srPolicy : name : "policy1" pcepSessionAddr : "10.0.255.1" srcAddr : "10.255.0.1" dstAddr : "10.255.0.3" color : 1 segmentList : - sid : 16002 nai : "10.255.0.2" - sid : 16004 nai : "10.255.0.4" - sid : 16003 nai : "10.255.0.3" コマンド実行 root@pola:/# pola sr-policy add -f policy1.yaml --no-link-state success! 作成した SR Policy は pola sr-policy list コマンドで確認ができます。 ※ 現在 FRRouting で利用されている SR Policy の Color、Preference 項目は pola sr-policy list から確認できない状態です。FRRouting の PCEP RFC 対応が進むと確認できるようになります。 root@pola:/# pola sr-policy list LSP(0): PcepSessionAddr: 10.0.255.1 PolicyName: policy1 SrcAddr: 10.0.255.1 DstAddr: 10.255.0.3 Color: 0 Preference: 0 DstAddr: 10.255.0.3 SegmentList: 16002 -> 16004 -> 16003 経路と SR Policy の紐付け FRRouting の route-map を用いて、SR Policy と BGP で広告される経路とを紐付けます。 pe01　コンテナに入り、route-map を適用する config を投入します。 user@server:~/pola/examples/sr-mpls_l3vpn$ docker exec -it pe01 /bin/bash bash-5.1# vtysh -c 'conf t' -c 'router bgp 65000' -c 'address-family ipv4 vpn' -c 'neighbor 10.255.0.3 route-map color1 in' 疎通確認疎通確認を行います。まずは host01 から host02 へ ping が通ることを確認します。 user@server:~$ docker exec -it host01 ping -c 5 192.168.1.2 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=62 time=0.198 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=62 time=0.126 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=62 time=0.122 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=62 time=0.110 ms 64 bytes from 192.168.1.2: icmp_seq=5 ttl=62 time=0.112 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4098ms rtt min/avg/max/mdev = 0.110/0.133/0.198/0.032 ms また、host01 から host02 へ ping を打っている状態で pe01 の net0 interface を通るパケットをキャプチャします。 net0 interface から ping のパケットが出ていることと、SR Policy で指定した MPLS ラベルが積まれていることを確認できます。 host01 user@server:~$ docker exec -it host01 ping 192.168.1.2 pe01 user@server:~/pola/examples/sr-mpls_l3vpn$ docker exec -it pe01 tcpdump -i net0 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on net0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 11:24:48.358826 MPLS (label 16004, exp 0, ttl 63) (label 16003, exp 0, ttl 63) (label 80, exp 0, [S], ttl 63) IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1067, seq 12, length 64 11:24:49.382800 MPLS (label 16004, exp 0, ttl 63) (label 16003, exp 0, ttl 63) (label 80, exp 0, [S], ttl 63) IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1067, seq 13, length 64 11:24:49.957688 IP 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 48 11:24:50.406778 MPLS (label 16004, exp 0, ttl 63) (label 16003, exp 0, ttl 63) (label 80, exp 0, [S], ttl 63) IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1067, seq 14, length 64 11:24:51.430769 MPLS (label 16004, exp 0, ttl 63) (label 16003, exp 0, ttl 63) (label 80, exp 0, [S], ttl 63) IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1067, seq 15, length 64 11:24:52.454779 MPLS (label 16004, exp 0, ttl 63) (label 16003, exp 0, ttl 63) (label 80, exp 0, [S], ttl 63) IP 192.168.0.2 > 192.168.1.2: ICMP echo request, id 1067, seq 16, length 64 Multi-vendor で構成されるネットワークを用いた Dynamic Path 機能の検証 GitHub から Pola PCE のバイナリファイルをダウンロードし、SR-MPLS を用いた Multi-vendor L3VPN 環境で検証します。検証環境以下のトポロジーを用いて検証します。各ルーターの製品とバージョンは以下の通りです。 rt01: ASR9901（IOS XR 7.6.1） rt02: MX204（Junos 22.1R1.10） rt03: ASR9901（IOS XR 7.5.1） rt04: MX204（Junos 21.4R1.12） rt05: Cisco 8201（IOS XR 7.5.1） rt06: PTX10001-36MR（Junos 21.2R1.15-EVO） rt07: ASR9902（IOS XR 7.6.1） rt08: MX204（Junos 21.4R1.12）手順本検証では Dynamic Path 機能を検証します。 Dynamic Path 検証にあたって、Pola PCE が経路計算に利用するトポロジー情報を取得する手段として GoBGP を利用します。SR-MPLS ドメインの任意のルーターと GoBGP で BGP-LS Session を確立し、かつ Pola PCE と連携することで Pola PCE が Traffic Engineering Database (TED) としてトポロジー情報を保持します。そのため、本章では GoBGP を Pola PCE で扱うための方法についても説明します。 Pola PCE / GoBGP のバイナリダウンロード Pola PCE と GoBGP のバイナリファイルをダウンロードします。 Pola PCE ダウンロード user@pce:~$ wget https://github.com/nttcom/pola/releases/download/v1.1.2/pola_1.1.2_linux_amd64.tar.gz user@pce:~$ tar -zxvf pola_1.1.2_linux_amd64.tar.gz user@pce:~$ sudo install -t <path が通っているディレクトリ> polad user@pce:~$ sudo install -t <path が通っているディレクトリ> pola GoBGP ダウンロード GoBGP は daemon (gobgpd) と CLI ツール (gobgp) の 2 つの実行ファイルから構成されますが、今回利用する実行ファイルは gobgpd のみになります。 user@pce:~$ wget https://github.com/osrg/gobgp/releases/download/v3.9.0/gobgp_3.9.0_linux_amd64.tar.gz user@pce:~$ tar -zxvf gobgp_3.9.0_linux_amd64.tar.gz user@pce:~$ sudo install -t <path が通っているディレクトリ> gobgpd gobgpd の起動 gobgpd は toml (または yaml、json) 形式のファイルに config を記載し、実行します。トポロジー情報を取得するため、gobgpd を起動して RR である rt03 / rt04 と BGP-LS の Session を確立します。作成する toml ファイル # gobgpd_cfg.toml [global.config] as = 65001 router-id = "10.99.0.254" [[neighbors]] [neighbors.config] neighbor-address = "10.255.1.3" peer-as = 65001 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ls" [[neighbors]] [neighbors.config] neighbor-address = "10.255.1.4" peer-as = 65001 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ls" gobgpd 起動 user@pce:~$ sudo gobgpd -f gobgpd_cfg.toml -l debug {"level":"info","msg":"gobgpd started","time":"2022-12-08T10:53:05Z"} {"Topic":"Config","level":"info","msg":"Finished reading the config file","time":"2022-12-08T10:53:05Z"} {"Key":"10.255.1.3","Topic":"config","level":"info","msg":"Add Peer","time":"2022-12-08T10:53:05Z"} {"Key":"10.255.1.3","Topic":"Peer","level":"info","msg":"Add a peer configuration","time":"2022-12-08T10:53:05Z"} {"Key":"10.255.1.4","Topic":"config","level":"info","msg":"Add Peer","time":"2022-12-08T10:53:05Z"} {"Key":"10.255.1.4","Topic":"Peer","level":"info","msg":"Add a peer configuration","time":"2022-12-08T10:53:05Z"} {"Duration":0,"Key":"10.255.1.3","Topic":"Peer","level":"debug","msg":"IdleHoldTimer expired","time":"2022-12-08T10:53:05Z"} {"Duration":0,"Key":"10.255.1.4","Topic":"Peer","level":"debug","msg":"IdleHoldTimer expired","time":"2022-12-08T10:53:05Z"} {"Key":"10.255.1.3","Topic":"Peer","level":"debug","msg":"state changed","new":"BGP_FSM_ACTIVE","old":"BGP_FSM_IDLE","reason":{"Type":7,"BGPNotification":null,"Data":null},"time":"2022-12-08T10:53:05Z"} {"Key":"10.255.1.4","Topic":"Peer","level":"debug","msg":"state changed","new":"BGP_FSM_ACTIVE","old":"BGP_FSM_IDLE","reason":{"Type":7,"BGPNotification":null,"Data":null},"time":"2022-12-08T10:53:05Z"} 現時点では対向の rt03 / rt04 に BGP-LS Session を確立するための config が投入されていないため、BGP Session はまだ確立しません。 BGP-LS Session の確立 rt03 / rt04 に BGP-LS Session を確立するための config を投入します。 IOS XR / Junos 共に、BGP-LS Session を確立するための config を記載します。 IOS XR router isis 1 distribute link-state instance-id 32 ! ! router bgp 65001 address-family link-state link-state ! neighbor-group pola remote-as 65001 timers 10 30 update-source Loopback0 address-family link-state link-state ! ! neighbor 10.99.0.254 use neighbor-group pola BGP-LS Session の UP を確認します。 RP/0/RSP0/CPU0:rt03#show bgp link-state link-state summary Thu Dec 8 20:25:17.394 JST BGP router identifier 10.255.1.3, local AS number 65001 BGP generic scan interval 60 secs Non-stop routing is enabled BGP table state: Active Table ID: 0x0 RD version: 221 BGP main routing table version 221 BGP NSR Initial initsync version 65 (Reached) BGP NSR/ISSU Sync-Group versions 0/0 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer Speaker 221 221 221 221 221 0 Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.99.0.254 0 65001 7 51 221 0 0 00:00:59 0 Junos set policy-options policy-statement TE term 1 from family traffic-engineering set policy-options policy-statement TE term 1 then accept set protocols bgp group pola type internal set protocols bgp group pola local-address 10.255.1.4 set protocols bgp group pola family traffic-engineering unicast set protocols bgp group pola export TE set protocols bgp group pola neighbor 10.99.0.254 set protocols mpls traffic-engineering database import policy TE BGP-LS Session の UP を確認します。 user@rt04> show bgp group pola Group Type: Internal AS: 65001 Local AS: 65001 Name: pola Index: 2 Flags: <Export Eval> Export: [ TE ] Options: <GracefulShutdownRcv> Holdtime: 90 Preference: 0 Graceful Shutdown Receiver local-preference: 0 Total peers: 1 Established: 1 10.99.0.254+42121 lsdist.0: 0/0/0/0 polad の起動 polad は yaml 形式のファイルに config を記載し、実行します。トポロジー情報の利用を有効化して GoBGP からトポロジー情報を取得するための config を記載します。 PCEP に関しては、PCC と疎通性のあるアドレス、PCEP のデフォルトポートである 4189 を設定しています。また、GoBGP は gRPC のデフォルトポートである 50051 で gRPC リクエストを待ち受けています。そのため以下の config では GoBGP の gRPC クライアントの接続先ポートを 50051 とし、Pola PCE が提供する gRPC サーバは 50052 で待ち受けるように設定しています。作成する yaml ファイル # polad_cfg.yaml global : pcep : address : "10.99.0.254" port : 4189 grpc-server : address : "127.0.0.1" port : 50052 log : path : "./pola_log/" name : "polad.log" ted : enable : true source : "gobgp" gobgp : grpc-client : address : "127.0.0.1" port : 50051 polad 起動 user@pce:~$ mkdir pola_log user@pce:~$ polad -f polad_cfg.yaml 2022-12-11T08:06:23.233Z info gRPC listen {"listenInfo": "127.0.0.1:50052", "server": "grpc"} 2022-12-11T08:06:23.233Z info PCEP listen {"listenInfo": "10.99.0.254:4189"} 2022-12-11T08:06:23.249Z info Request TED update {"source": "GoBGP", "session": "127.0.0.1:50051"} 2022-12-11T08:06:23.249Z info Update TED Update TED のログが出力されていれば、gobgpd との接続が完了し TED の更新が完了しています。 PCEP Session の確立 PCC とする rt01 / rt02 へ PCEP Session を確立するための config を投入します。 IOS XR / Junos 共に、PCEP Session を確立するための config を記載します。 IOS XR segment-routing traffic-eng pcc source-address ipv4 10.255.1.1 pce address ipv4 10.99.0.254 ! ! ! ! PCEP Session が確立していることを rt01 で確認します。 RP/0/RSP0/CPU0:rt01#show segment-routing traffic-eng pcc ipv4 peer Sun Dec 11 17:41:06.157 JST PCC's peer database: -------------------- Peer address: 10.99.0.254, Precedence: 255, (best PCE) State up Capabilities: Stateful, Update, Segment-Routing, Instantiation Junos set protocols mpls lsp-external-controller pccd set protocols source-packet-routing lsp-external-controller pccd set protocols pcep pce pola local-address 10.255.1.2 set protocols pcep pce pola destination-ipv4-address 10.99.0.254 set protocols pcep pce pola pce-type active set protocols pcep pce pola pce-type stateful set protocols pcep pce pola lsp-provisioning set protocols pcep pce pola spring-capability PCEP Session が　確立していることを rt02 で確認します。 user@rt02> show path-computation-client status Session Type Provisioning Status Uptime pola Stateful Active On Up 102 LSP Summary Total number of LSPs : 0 Static LSPs : 0 Externally controlled LSPs : 0 Externally provisioned LSPs : 0/16000 (current/limit) Orphaned LSPs : 0 pola (main) Delegated : 0 Externally provisioned : 0 Pola PCE 各種情報の確認 PCC と PCEP Sessoin が確立できたため、Pola PCE の持つ各種情報を確認します。 Pola PCE の操作は pola CLI コマンドを用いて行います。 PCEP Session の確認 PCEP Session を確認します。 user@pce:~$ pola session -p 50052 sessionAddr(0): 10.255.1.1 sessionAddr(1): 10.255.1.2 TED の確認 gobgpd から取得したトポロジー情報を確認します。 user@pce:~$ pola ted -p 50052 Node: 1 0000.0aff.0107 Hostname: rt07 ISIS Area ID: 49.0000 SRGB: 16000 - 24000 Prefixes: 10.255.1.7/32 index: 7 Links: Local: 10.1.4.2 Remote: 10.1.4.1 RemoteNode: 0000.0aff.0106 Metrics: IGP: 10 TE: 10 Adj-SID: 24008 Local: 10.1.12.2 Remote: 10.1.12.1 RemoteNode: 0000.0aff.0105 Metrics: IGP: 10 TE: 10 Adj-SID: 24002 <snip> SR Policy の発行 SR Policy を表す yaml ファイルを作成し、pola sr-policy add コマンドで SR Policy を PCC に発行します。本検証では、color 100 が付与されている rt01 から rt02 への VPN 経路・ rt02 から rt01 への VPN 経路それぞれに対して、TE メトリックに従った経路を通るための SR Policy を発行します。TE メトリックはトポロジー図に記載した設定をしているため、パケットはトポロジー図中青線の通りの経路を通ります。作成する yaml ファイル # policy_dynamic_rt01.yaml asn : 65001 srPolicy : pcepSessionAddr : "10.255.1.1" name : "dynamic_rt01" srcRouterId : "0000.0aff.0101" dstRouterId : "0000.0aff.0102" color : 100 type : "dynamic" metric : "te" # policy_dynamic_rt02.yaml asn : 65001 srPolicy : pcepSessionAddr : "10.255.1.2" name : "dynamic_rt02" srcRouterId : "0000.0aff.0102" dstRouterId : "0000.0aff.0101" color : 100 type : "dynamic" metric : "te" コマンド実行 user@pce:~$ pola sr-policy add -f policy_dynamic_rt01.yaml -p 50052 success! user@pce:~$ pola sr-policy add -f policy_dynamic_rt02.yaml -p 50052 success! 作成した SR Policy は pola sr-policy list コマンドで確認ができます。 user@pce:~$ pola sr-policy list -p 50052 LSP(0): PcepSessionAddr: 10.255.1.1 PolicyName: dynamic_rt01 SrcAddr: 10.255.1.1 DstAddr: 10.255.1.2 Color: 100 Preference: 100 DstAddr: 10.255.1.2 SegmentList: 16005 -> 16008 -> 16006 -> 16002 LSP(1): PcepSessionAddr: 10.255.1.2 PolicyName: dynamic_rt02 SrcAddr: 10.255.1.2 DstAddr: 10.255.1.1 Color: 100 Preference: 100 DstAddr: 10.255.1.1 SegmentList: 16006 -> 16008 -> 16005 -> 16001 PCC で受けとった SR Policy の確認各 PCC で受け取った経路が有効化されていることを確認します。 IOS XR RP/0/RSP0/CPU0:rt01#show segment-routing traffic-eng policy Mon Dec 12 07:41:10.566 JST SR-TE policy database --------------------- Color: 100, End-point: 10.255.1.2 Name: srte_c_100_ep_10.255.1.2 Status: Admin: up Operational: up for 00:03:14 (since Dec 12 07:37:56.127) Candidate-paths: Preference: 100 (PCEP) (active) Name: dynamic_rt01 Requested BSID: dynamic PCC info: Symbolic name: dynamic_rt01 PLSP-ID: 3 Protection Type: unprotected-preferred Maximum SID Depth: 10 Dynamic (pce 10.99.0.254) (valid) Metric Type: TE, Path Accumulated Metric: 0 16005 [Prefix-SID, 10.255.1.5] 16008 [Prefix-SID, 10.255.1.8] 16006 [Prefix-SID, 10.255.1.6] 16002 [Prefix-SID, 10.255.1.2] Attributes: Binding SID: 24012 Forward Class: Not Configured Steering labeled-services disabled: no Steering BGP disabled: no IPv6 caps enable: yes Invalidation drop enabled: no Max Install Standby Candidate Paths: 0 Junos user@rt02> show spring-traffic-engineering lsp detail Name: dynamic_rt02 Tunnel-source: Path computation element protocol(PCEP) Tunnel Forward Type: SRMPLS To: 10.255.1.1-100<c> State: Up Path Status: NA Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A BFD status: N/A BFD name: N/A Segment ID : 128 ERO Valid: true SR-ERO hop count: 4 Hop 1 (Strict): NAI: IPv4 Node ID, Node address: 10.255.1.6 SID type: 20-bit label, Value: 16006 Hop 2 (Strict): NAI: IPv4 Node ID, Node address: 10.255.1.8 SID type: 20-bit label, Value: 16008 Hop 3 (Strict): NAI: IPv4 Node ID, Node address: 10.255.1.5 SID type: 20-bit label, Value: 16005 Hop 4 (Strict): NAI: IPv4 Node ID, Node address: 10.255.1.1 SID type: 20-bit label, Value: 16001 Total displayed LSPs: 1 (Up: 1, Down: 0) 本検証で発行した SR Policy は、BGP Color Extended Community の 100 が付加されている VPN 経路に対して適用されます。Color の付加方法は [Multi-AS Segment Routing 検証連載 #4] Color-Based Steering in Single-AS で紹介しているため、こちらの記事を参考にしてください。疎通確認疎通確認を行います。 rt01 の Customer ネットワークと rt02 の Customer ネットワークで相互に traceroute を行い、経路を確認します。事情により rt06 を通る経路の traceroute は当該ホップの結果で * * * と表示されています。 rt01 -> rt02 RP/0/RSP0/CPU0:rt01#traceroute 192.168.1.254 vrf Customer Mon Dec 12 08:30:46.261 JST Type escape sequence to abort. Tracing the route to 192.168.1.254 1 10.1.1.2 [MPLS: Labels 16008/16006/16002/130 Exp 0] 26 msec 4 msec 4 msec 2 10.1.5.2 [MPLS: Labels 16006/16002/130 Exp 0] 1 msec 1 msec 2 msec 3 * * * 4 192.168.1.254 1 msec 1 msec 1 msec rt02 -> rt01 user@rt02> traceroute 192.168.0.254 routing-instance Customer no-resolve traceroute to 192.168.0.254 (192.168.0.254), 30 hops max, 52 byte packets 1 * * * 2 10.1.11.2 0.906 ms 0.837 ms 1.177 ms MPLS Label=16005 CoS=0 TTL=1 S=0 MPLS Label=16001 CoS=0 TTL=2 S=0 MPLS Label=24013 CoS=0 TTL=2 S=1 3 10.1.5.1 2.108 ms 2.132 ms 3.897 ms MPLS Label=16001 CoS=0 TTL=1 S=0 MPLS Label=24013 CoS=0 TTL=3 S=1 4 10.1.1.1 3.844 ms * 3.963 ms トポロジー図に記載の通りの経路となっていることが確認できます。まとめ本記事では　Pola PCE の概要と手元の Docker 環境・ Multi-vendor ネットワーク環境での利用方法について紹介しました。気軽に試験環境を作成できるため是非お手元で試してみてください！質問や気になった点、機能追加も大歓迎です。ブログコメントや GitHub Issues/PRs を是非お願いします！ GitHub - nttcom/pola: PCEP Library and Stateful PCE Implementation with Go

bash, Docker, GitHub, Go, Ubuntu, Cisco, ネットワーク, API, アーキテクチャ, Microservices

NTTドコモビジネス の技術ブログ

コンテンツ

NTTドコモビジネスの技術ブログ