横浜539のブログ

技術ブログっぽい雑記。

JNCIE-SP (2回目) 受験記

2026年7月某日に2回目となる、JNCIE-SP(JPR-962)の資格試験を受けました。
受験記を残したいと思います。
※公開されている情報のみ記載してます。

1回目はこちらです。2つに分けてます。
yokohama539.hatenablog.com
yokohama539.hatenablog.com

1. 2回目への対策と試験予約

1回目はFailとなったため、2回目を受験するにあたって以下の対策を行いました。

①出題範囲の反復練習
出題される技術の基本的な設定方法を今一度確認し、極力Documentを見ずともコマンドが打てるようにトレーニングしました。

②showコマンドによる確認の強化
detailやextensiveオプションで詳細情報を表示し、意味を理解するようにしました。
また、エントリ数の多いルーティングテーブルに対し、見たい経路情報を正規表現によるフィルターでピンポイントで表示するオプションを使うトレーニングをしました。
例を挙げるとshow route table inet.0にて、「match-prefix */32$」を付けてIPv4 ホストルートのみ表示させ、各デバイスのlo0.0の経路情報を学習してるかの確認時間の短縮化を図る…と言ったトレーニングなどです。

lab@PE-01# run show route table inet.0 match-prefix */32$ protocol isis

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.2/32      *[IS-IS/15] 00:07:06, metric 10
                    >  to 10.1.12.1 via ge-0/0/0.0
172.16.1.3/32      *[IS-IS/15] 00:06:57, metric 20
                    >  to 10.1.12.1 via ge-0/0/0.0
172.16.1.4/32      *[IS-IS/15] 00:06:57, metric 20
                    >  to 10.1.12.1 via ge-0/0/0.0


③出題される技術についてDocumentでの調査強化
①でDocumentを見ずとも設定するトレーニングをしてますが、それでも試験ではどんな条件の設問が出るのか、わかりません。
なので、出題される技術について、どのDocumentファイルを参照すれば良いか、どんなオプションが存在するのか可能な限り調査しました。

④help aproposの活用
Junosには「help apropos」という、コマンド検索機能があります。この機能を使って、出題される技術のコマンドを素早く調べられるようにトレーニングしました。
例を挙げると、Telemetryは「grpc」というキーワードで覚えておいて、細かなコマンドはhelp aproposでアドリブで調べる…といった流れです。

lab@PE-01# help apropos grpc
set system login class <class-name> allow-grpc-rpc-regexps
    Regular expressions of gRPC rpcs to be allowed
set system login class <class-name> deny-grpc-rpc-regexps
    Regular expressions of gRPC rpcs to be denied
set system services extension-service request-response grpc
    Grpc server configuration
set system services extension-service request-response grpc ssl hot-reloading
    Enable certificate reload without terminating existing gRPC sessions
:
:
lab@PE-01# help apropos grpc | grep extension-service
set system services extension-service request-response grpc
set system services extension-service request-response grpc ssl hot-reloading
set system services extension-service request-response grpc routing-instance <routing-instance>
set system services extension-service request-response grpc grpc-keep-alive <grpc-keep-alive>
set system services extension-service traceoptions flag grpc
set system services extension-service traceoptions flag libgrpc-debug
set system services extension-service traceoptions flag libgrpc-errors
set system services extension-service traceoptions flag libgrpc-info

また、③との併せ技で、全く知らない条件での設定が出題されても、 help aproposでコマンドをある程度調べて、コマンド文字列でDocumentを検索して必要なオプションを割り出す…という方法が可能になります。

⑤コピペ活用の強化
1回目でもコピペは使ってましたが、それでも時間が足りなかったためコピペをもっと多く使うようトレーニングしました。
Firewall Filterやpolicy-statementの設定は全てコピペにて設定するくらいトレーニングしました。
直打ちの方が設定してる感あるんですけどね!

そして、2回目の試験日ですが、「5月以降で、なる早でAPACゾーンで予約できれば」と考えてましたが、あいにく8月までFullとなっており予約ができない状況でした。
なので、ちょいちょい予約状況を確認してキャンセルが出ればAPAC or EMEAゾーンで予約してしまおう、という方針で受験を考えてました。
…それでもなかなか空きが出ずヤキモキした日々が続きました。
で、ある日、7月某日にEMEAゾーンで空きが出たため、えいやっと予約を取りましたw とりあえず早めに受けたかったですw

試験日まで、上記の対策を習熟しつつ1回目の試験問題の復習と、想定される類似問題でトレーニングなど行いました。

2. 試験前々日〜前日

試験前日は出社する予定だったので、前々日から1回目の受験時と同様に、部屋の整理と家具の目隠しを行いました。
試験前日は、職場から帰宅後にPCの動作確認を行いました(Juniper Portalサイトへアクセスできるか、マイクとWebカメラは機能するかなど)
ネット接続はできる限り確実にすべく、もちろん今回も有線接続です。
LANケーブルにお守りをモリモリつけて願掛けました!(とても重要な行為だと思っている)

復習もそこそこにして、明日に備えて寝ます!おやすみなさい!!

3-1. 試験当日 チェックイン前まで

試験当日になりました。
今回はEMEA(CEST)のAM 9:00スタートなので、日本時間ではPM 4:00スタートになります。
(案内メールでは「CET AM 9:00」スタートと書いてありましたが、実際は夏時間なCESTでした。まあ7月なので予想できてましたが)
14:30くらいまでは会社のPCを立ち上げてメールチェックなどしつつ、試験で必要な物を用意します。

部屋も準備OK!

14:45頃にRemote Lab用のアクセスプロファイルが添付されたメールがプロクターより送られてきました。
また、(前回同様)このメールには事前ブリーフィング(Zoom)のミーティングIDが記載されており、試験開始30分前くらいに参加するよう指示があります。
15:20くらいまで勉強ノート(OneNote)を読み返したり、PCの設定確認をしてました。
そして試験開始30分前(15:30)になり、Safe Exam Browserを立ち上げてRemote Lab環境にアクセスし、届いたメール記載のミーティングIDへ参加します。

3-2. 試験当日 チェックイン〜ブリーフィング

ミーティング参加後、少し待ってからブレイクアウトルームに誘導されます。
そしてプロクターの顔が映り「Hi, YOKOHAMA! How are you?」と挨拶されました(もちろん本名で呼ばれてますが、Blog上ではYOKOHAMAとします)
なお、プロクターは前回とは違う方です(前回はAPACゾーンでの受験で今回はEMEAゾーンの受験なので、違うプロクターになったようです)
まず「How many times you taken exam?(試験は何回目だ?)」と聞かれ「2nd try」と回答しました。
その後「All right. So, I explain the lab exam(よしわかった、Lab試験について説明するぞ)」と言い、ブリーフィングが始まりました。
とは言っても、試験時間や諸注意などすでにわかっていることなので、そこまで気をつけることはありませんでした。
試験の諸注意をしながら、前回と同様に身分証明書のチェックやルームスキャンも行われました。
一通り説明が終わり、「Any question?」と聞かれましたが「No」と返してブリーフィングは終了しました。

そして、プロクターへRemote Lab環境の操作権限を与え、遠隔操作にて用意されているLab問題、トポロジーの画、ターミナルソフトのSecureCRTが置いてあるRemote DesktopなWindows画面を出してくれます。
当然、この時間はお祈りポイントでした。知ってる技術たくさん出題されろ…!
そしてプロクターより「Let's get started exam. Lunch is after ◯ hours(じゃあ試験を開始しよう。ランチは◯時間後だ)」と言われ、操作可能になりました。
※時間配分は公の記載がないので、秘密です…。

6時間のLab試験が始まりました。

3-3. 試験当日 Lab試験(前半)

まずトポロジーを見ます。第一印象は「ふむふむなるほど…。今回もまあ理解できる構成やね…」と言ったところでした。
そして前回よりもしっかり設問を一通り最後まで読みます。
今回も英語力皆無な自分でも大体は理解できる内容でした。
10分くらいトポロジーと問題文を眺めて、どのRouterにどんな設定を入れるか見当をつけた後、SecureCRTを立ち上げて設定を入れていきます。
設問の詳細はもちろん書けませんが、ココココの内容が問われます。

前回よりも迷いなく設定を入れていきます。
とは言っても当然詰まるところはあるので、用意されたDocumentを読んで設定を入れていきます。しっかり設定確認もします。
曖昧な設問に対しては稚拙な中学英語でプロクターに質問もしました。
意図しない動作となった場面もありましたが、なんとか題意が満たされるような設定を入れていきます。

そして、ランチの15分前になったらプロクターではないアシスタント役の方?から
「Hi YOKOHAMA, there are 15 minutes until lunch(ランチの時間まで15分前です)」とアナウンスがありました。
今回は時間のアナウンスをしてくれるようです。この辺はプロクターによって采配が違うのかな?
この15分でキリのいいところまで進めて、ランチの時間となりました。

今回は、(前回のような)試験進行上のトラブルもなかったです。
前半の進捗は、前回よりかなり早く設問数的に6〜7割を終えてました。この時点でホワイトボードはほぼ使わなかったです。
まあ問題は後半(Edge Servicesの範囲)なのですが…。

3-4. 試験当日 昼休憩

ランチ時は一旦、プロクターにてRemote Lab環境をログアウトされました。
そして試験をしている部屋から出て、ランチを食べます(日本時間では夕方以降なのでランチではなく夕食ですが)
内容は今回も前回同様おにぎり2個+チョコ+キレートレモンにしました。
10分程度でご飯を済ませ、残りの時間で作戦を立てます。
とは言っても、今回は主に設定内容ではなく、この後の時間配分をどうするか考えました。

あっという間に試験再開の時間になり、部屋へ戻ります。

3-4. 試験当日 Lab試験(後半)

席に戻るとプロクターから「OK, let's back exam. End in ◯ hours. I'll announcement when nearly end time, too
(よし、じゃ再開しよう。試験はあと◯時間だ。終了時間近くなったら、またアナウンスするね)」と周知があり、遠隔操作でRemote Lab環境へ再ログインしてくれました。
後半の開始です。

後半もガシガシ設定していきます。
特に後半は時間との戦いなので、設定→showコマンド確認→疎通確認のサイクルをなるべく早く行うようにしました。
前回より落ち着いて試験に集中できていたのか、前回と比べて細かな指定や条件を理解できてるように感じました。
「ああ、前回はここが原因で得点できてなかったかもな…」と思う箇所もいくつかありました。
複雑な条件がある設問は、ホワイトボードを使って頭の整理をしました。
うまく動作しない箇所は、なんとか意図通りの挙動となるよう色々設定をして題意を満たすように心がけました。

そして、試験終了45分前に「Hi YOKOHAMA, 45 minutes until the end」とアナウンスがありました。
この時点では、途中2問ほど飛ばして最後の2、3問の設定をしていました。
残り時間40分を切ろうかと言うところで、一通り全ての設問を終えました。

途中飛ばした2問をどうするか、少し考えます。
「うーん…この2問の設定をすることによって、今疎通できてる箇所が万一、不通になったら減点になるな…どうするか」と、しばらく考えました。
悩んだ末、この2問は手付かずにしておき、残りの時間で見直しを行いました。
見直しをしてて、1問だけ誤っていた設定があったので修正しました。あぶねー…。
見直しが終わった時点で残り5分を切っていたので共通設定や疎通を再々確認し、タイムアップとなりました。

プロクターから「Exam is over(試験は終了だ)」とアナウンスがあり、遠隔操作でRemote Lab環境からログアウトされました。
最後に「See you!」と挨拶し、ミーティングは終了となりました。

3-5. 試験当日 Lab試験後

試験後はお約束のトポロジーと問題をメモしました。今回はA4コピー用紙2枚ほどメモしました。
そして業務PCを立ち上げて、上司にLab試験終了の報告とメールチェックをして業務終了。
既に買ってあるお弁当を食べながら、試験を振り返ります。
頭に浮かぶのは2問飛ばしたことばかりでした。果たしてあの選択が吉と出るか凶と出るか…。

4. 試験結果

試験結果は「試験日から5営業日以内に通知」との決まりなので、(土日も考慮して)早くて3〜4日後かなあと想定してました。
で、試験からあまり経ってない時間に「いつでも結果見られるようにCertMetricsのページをブックマークしておくかな」
とふと思い、CertMetricsにアクセスしてみると

……………………………………え?これ合格?もう出てるの?マジ?
某所で酒を飲んだ帰りだったので酔いが一気に醒め、ログアウト→ログインなどして五度見くらいしました。
Download欄からファイルをダウンロードして中身をみると

わーーPASSだーーやったーああああ

それにしても結果早いな!!ビックリしたっぜ!!!

すぐに上司とお世話になった同僚にPassした旨の報告をしました。

そして翌日、メールにて正式なPass通知がありました。


今回の試験は運良く2回目で合格することができました!!!!!
本当に運が良かった…。もう今年の運すべて使い切ったね。

という訳でJNCIE-SP 受験記は以上になります!
ここまでお読みいただき、ありがとうございました!!!!
去年から続けてた試験勉強からようやく解放されて嬉しいです!!!!! (本音)

…試験のテクニックTipsや参考にしたサイト集など、別の記事でやりたいですね〜。

vJunosでInter-AS Option CのL3VPNをしてみた。

今回は、vJunos-routerを使ってInter-AS Option CによるL3VPNの検証をしたいと思います。
「Inter-AS Option C」とは、ASを跨いでVPNを実現するソリューションの一つです。
(Option 「C」なので、AやBもあります)
複数の異なるSP(Service Provider)を経由してL2VPNやL3VPNを行うようなイメージです。

IOSでの設定例は数あれど、Junosの設定例はほぼ無いので、書き記します。
公式ドキュメントの設定例はRR(Route Reflector)がなく微妙な構成なので、RR有りな現実的なトポロジーで構築します。
例によって用語の詳しい説明は行いません。わからない用語は各自でググってください。
今回行うOption Cは、C-Plane(経路情報の広告)とD-Plane(実際のトラフィック)のパケットフローやLabel構造がとてもややこしいです。
特にD-Planeについては3重ものLabelが付与され転送処理が行われます。
概要を知りたい方は、ChrisさんのBlog記事の前半部分を一読するのをオススメします。
また、D-PlaneのLabel構造については同じくChrisさんのBlogの絵がわかりやすいです。

では、いつもの通り構成より詳しく書いていきます。

1. Inter-AS Option C L3VPN 構成

トポロジーは以下のとおりです。

前述した通り、異なるSPを経由するので、2つSP網を用意しそれぞれCEをつなげています。
今回はSP Aを自AS、SP Bを相手方の対向ASとして見立てます。
Routing Protocolとしては、SP網のUnderlayにてIS-ISを使用し、PEとCE間ではOSPFを使います。AS内とAS間で当然BGPも使います。
Label配布ProtocolはRSVPを使用します。
そしてOption Cの特徴として、ASBR間ではBGP-LU(Labeled-Unicast)によるPeeringを行い、かつRR間でPeeringを行いVPNv4 Prefixを交換します。
ゴールとしては、VPN-01のSite-AとSite-BのVPC間(vPC-01とvPC-02間)でL3VPNによる通信ができることです。

追記: 構成図の解像度が低いので、Xに高解像度の構成図をアップしました。

2. Inter-AS Option C L3VPN 設定

それでは設定していきます。
今回は尺の都合でSP A側の設定のみ記載しています。
IP Addressの設定は完了していることとします。
まず、SP網内でUnderlayとなるIS-ISを設定し、AS内のLoopback Addressをお互い広報します。
例としてP-01のみconfigを記載します。

//P-01
set interfaces ge-0/0/0 unit 0 family iso
set interfaces ge-0/0/1 unit 0 family iso
set interfaces ge-0/0/2 unit 0 family iso
set interfaces lo0 unit 0 family iso address 49.0001.0000.0000.0002.00
set protocols isis interface ge-0/0/0.0 level 2 disable
set protocols isis interface ge-0/0/1.0 level 2 disable
set protocols isis interface ge-0/0/2.0 level 2 disable
set protocols isis interface lo0.0 passive

他の機器はIS-ISを有効にするインターフェイスやLo0.0のNSAP Addressが異なる程度なので、ほぼコピペとなります。
参考に、今回は下記のパラメーターにて設定してます。

機器名 Lo0.0 NSAP Address IS-ISを有効にするインターフェイス
PE-01 49.0001.0000.0000.0001.00 ge-0/0/0.0, lo0.0
P-01 49.0001.0000.0000.0002.00 ge-0/0/0.0, ge-0/0/1.0, ge-0/0/2.0, lo0.0
ASBR-01 49.0001.0000.0000.0003.00 ge-0/0/0.0, lo0.0
RR-01 49.0001.0000.0000.0004.00 ge-0/0/0.0, lo0.0


続いてMPLSとRSVPを設定します。
Labeled-Unicatをするので、RRもMPLSを動作させます。
RSVPについては、PE-01、ASBR-01、RR-01は他の2つのデバイス宛のPathを定義します。

//PE-01
set protocols mpls label-switched-path TO_ASBR-01 to 172.16.1.3
set protocols mpls label-switched-path TO_RR-01 to 172.16.1.4
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface lo0.0
set protocols rsvp interface ge-0/0/0.0
//P-01
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface lo0.0
set protocols mpls interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
//ASBR-01
set interfaces ge-0/0/0 unit 0 family mpls
set protocols mpls label-switched-path TO_PE-01 to 172.16.1.1
set protocols mpls label-switched-path TO_RR-01 to 172.16.1.4
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface lo0.0
set protocols rsvp interface ge-0/0/0.0
//RR-01
set interfaces ge-0/0/0 unit 0 family mpls
set protocols mpls label-switched-path TO_ASBR-01 to 172.16.1.3
set protocols mpls label-switched-path TO_PE-01 to 172.16.1.1
set protocols mpls interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/0.0


続いて、InternalなBGP部分を設定します。
今回はL3VPNでの通信だけなので、family inet-vpn (VPNv4)のみを有効にします。
RRについては「cluster」を設定します。
cluster設定されているBGP groupでのPeerは全てRoute Reflector Clientになります。
なお、P-01に設定は必要ありません。
また、一部の設定については後ほど追加します。

//PE-01
set routing-options autonomous-system 65001
set protocols bgp group INT type internal
set protocols bgp group INT local-address 172.16.1.1
set protocols bgp group INT family inet-vpn unicast
set protocols bgp group INT neighbor 172.16.1.4
//ASBR-01
set routing-options autonomous-system 65001
set protocols bgp group INT type internal
set protocols bgp group INT local-address 172.16.1.3
set protocols bgp group INT neighbor 172.16.1.4
//RR-01
set routing-options autonomous-system 65001
set protocols bgp group INT type internal
set protocols bgp group INT local-address 172.16.1.4
set protocols bgp group INT family inet-vpn unicast
set protocols bgp group INT cluster 172.16.1.4
set protocols bgp group INT neighbor 172.16.1.1
set protocols bgp group INT neighbor 172.16.1.3


続いて、L3VPNの設定をします。
前述の通り、PEとCE間はOSPFにて経路広報を行います。
今回はSP毎にRT(Route Target)を変えてるので、vrf-importとvrf-exportを個別に設定します。
SP Aは「target:65001:1」を付与してVPNv4 Prefixを送信し、SP Bは「target:65002:1」を付与してVPNv4 Prefixを送信するテイとします。
なので、SP AのPE-01において受信時は「target:65002:1」のRTを持つVPNv4 Prefixを受け入れる設定をします。
(SP BのPE-02は「target:65001:1」のRTを持つVPNv4 Prefixを受け入れる設定となります)
あと、BGPで受信したVPNv4 PrefixをVRFのOSPFドメインに広報する際はexportの設定が必要になります。意外と忘れがちな設定です。

//PE-01
set policy-options community AS65001_VPN01 members target:65001:1
set policy-options community AS65002_VPN01 members target:65002:1
set policy-options policy-statement VRF_BGP_to_OSPF term 0011 from protocol bgp
set policy-options policy-statement VRF_BGP_to_OSPF term 0011 then accept
set policy-options policy-statement VPN01_VRF_EXPORT term 0011 from protocol ospf
set policy-options policy-statement VPN01_VRF_EXPORT term 0011 then community set AS65001_VPN01
set policy-options policy-statement VPN01_VRF_EXPORT term 0011 then accept
set policy-options policy-statement VPN01_VRF_EXPORT term 9991 then reject
set policy-options policy-statement VPN01_VRF_IMPORT term 0011 from community AS65002_VPN01
set policy-options policy-statement VPN01_VRF_IMPORT term 0011 then accept
set policy-options policy-statement VPN01_VRF_IMPORT term 9991 then reject
set routing-instances VPN_01 instance-type vrf
set routing-instances VPN_01 protocols ospf area 0.0.0.0 interface ge-0/0/6.0
set routing-instances VPN_01 protocols ospf export VRF_BGP_to_OSPF
set routing-instances VPN_01 interface ge-0/0/6.0
set routing-instances VPN_01 route-distinguisher 172.16.1.1:65001
set routing-instances VPN_01 vrf-import VPN01_VRF_IMPORT
set routing-instances VPN_01 vrf-export VPN01_VRF_EXPORT
//CE-01
set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0


最後に、Inter-AS Option Cに関わる設定を追加します。
具体的には以下3点の設定をします。

1. ASBR-01にて、External BGP-LU Peeringの設定
2. RR-01にて、External BGP Peeringの設定
3. PE-01、ASBR-01、RR-01にて、Internal BGP(AS65001内)におけるBGP-LUの設定

まず、1. ですが、ASBR間でeBGP-LUでPeeringをします。
その際、自ASのRRおよびPEのLoopback Address((BGP) Protocol Next-hopとなり得るIP Address)を広報します。
広報されてきた対向のRRのLoopback Addressの学習によって2. のPeeringが可能となります。
次に、2. について、RR間にてPEから学習したVPNv4アドレスを広報します。よってfamilyはinet-vpnを定義します。
また、RRで対向PEのProtocol Next-hopの解決はinet.3で解決する必要があります。
RRに「family inet labeled-unicast」といった設定をするのですが、この設定だとinet.0のみでのlookupとなりRR間での通信は実現できるものの、対向PE宛のMPLS Pathを自ASのPEへ広報できない状態となります。なので、inet.3にてlookupを行う必要があります。
方法はいくつかあるのですが、今回は一番簡単なinet.3へstatic routeを設定してゴリ押しでNext-hop解決させます。
さらに、PEへ対向のVPNv4 Prefixを広報する際、Defaultでは通常のIPv4 Unicast(SAFI=1)ルートと同様にProtocol Next-hopを自身のLoopbackに書き換えます。
そうなった場合、実トラフィックはRRを経由する形となり効率的ではありません。そのため、multihop設定にて"no-nexthop-change"というオプションを追加することにより、Protocol Next-hopを自身のLoopbackに書き換えず対向のPEのままで広報します。
最後に、3. については、AS内でLabeled-Unicastを広報できるように「set protocols bgp group INT 〜」配下に追加します。
PE、ASBR、RRによって微妙にコマンドが異なります。

なお、全てBGPに関わる設定なのでP-01については設定は必要ありません。

//PE-01
set protocols bgp group INT family inet labeled-unicast resolve-vpn
//ASBR-01
set interfaces ge-0/0/2 unit 0 family mpls
set protocols mpls interface ge-0/0/2.0
set policy-options policy-statement BGP_ASBR_EXPORT term 0011 from route-filter 172.16.1.4/32 exact
set policy-options policy-statement BGP_ASBR_EXPORT term 0011 from route-filter 172.16.1.1/32 exact
set policy-options policy-statement BGP_ASBR_EXPORT term 0011 then accept
set policy-options policy-statement BGP_ASBR_EXPORT term 9991 then reject
set protocols bgp group INT family inet labeled-unicast rib inet.3
set protocols bgp group ASBR type external
set protocols bgp group ASBR family inet labeled-unicast rib inet.3
set protocols bgp group ASBR neighbor 10.1.35.1 export BGP_ASBR_EXPORT
set protocols bgp group ASBR neighbor 10.1.35.1 peer-as 65002
//RR-01
set routing-options rib inet.3 static route 0.0.0.0/0 receive
set protocols bgp group INT family inet labeled-unicast
set protocols bgp group RR_PEER type external
set protocols bgp group RR_PEER multihop ttl 10
set protocols bgp group RR_PEER multihop no-nexthop-change
set protocols bgp group RR_PEER local-address 172.16.1.4
set protocols bgp group RR_PEER family inet-vpn unicast
set protocols bgp group RR_PEER neighbor 172.16.1.8 peer-as 65002

設定は以上となります。

3. Inter-AS Option C L3VPN 確認

それでは設定の確認をします。
まずはサクッとIS-ISとMPLS(RSVP)を確認します。

//PE-01
lab@PE-01# run show route table inet.0 protocol isis 172.16.1/24

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.2/32      *[IS-IS/15] 01:30:02, metric 10
                    >  to 10.1.12.1 via ge-0/0/0.0
172.16.1.3/32      *[IS-IS/15] 01:29:34, metric 20
                    >  to 10.1.12.1 via ge-0/0/0.0
172.16.1.4/32      *[IS-IS/15] 01:29:37, metric 20
                    >  to 10.1.12.1 via ge-0/0/0.0
lab@PE-01# run show route table inet.3 protocol rsvp

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.3/32      *[RSVP/7/1] 01:32:17, metric 20
                    >  to 10.1.12.1 via ge-0/0/0.0, label-switched-path TO_ASBR-01
172.16.1.4/32      *[RSVP/7/1] 01:32:17, metric 20
                    >  to 10.1.12.1 via ge-0/0/0.0, label-switched-path TO_RR-01
//P-01
lab@P-01# run show route table inet.0 protocol isis 172.16.1/24

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[IS-IS/15] 01:30:37, metric 10
                    >  to 10.1.12.0 via ge-0/0/0.0
172.16.1.3/32      *[IS-IS/15] 01:30:09, metric 10
                    >  to 10.1.23.1 via ge-0/0/1.0
172.16.1.4/32      *[IS-IS/15] 01:30:12, metric 10
                    >  to 10.1.24.1 via ge-0/0/2.0
//ASBR-01
lab@ASBR-01# run show route table inet.0 protocol isis 172.16.1/24

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[IS-IS/15] 01:30:32, metric 20
                    >  to 10.1.23.0 via ge-0/0/0.0
172.16.1.2/32      *[IS-IS/15] 01:30:41, metric 10
                    >  to 10.1.23.0 via ge-0/0/0.0
172.16.1.4/32      *[IS-IS/15] 01:30:32, metric 20
                    >  to 10.1.23.0 via ge-0/0/0.0
lab@ASBR-01# run show route table inet.3 protocol rsvp

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[RSVP/7/1] 01:32:32, metric 20
                    >  to 10.1.23.0 via ge-0/0/0.0, label-switched-path TO_PE-01
172.16.1.4/32      *[RSVP/7/1] 01:32:32, metric 20
                    >  to 10.1.23.0 via ge-0/0/0.0, label-switched-path TO_RR-01
//RR-01
lab@RR-01# run show route table inet.0 protocol isis 172.16.1/24

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[IS-IS/15] 01:31:04, metric 20
                    >  to 10.1.24.0 via ge-0/0/0.0
172.16.1.2/32      *[IS-IS/15] 01:31:13, metric 10
                    >  to 10.1.24.0 via ge-0/0/0.0
172.16.1.3/32      *[IS-IS/15] 01:31:10, metric 20
                    >  to 10.1.24.0 via ge-0/0/0.0
lab@RR-01# run show route table inet.3 protocol rsvp

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[RSVP/7/1] 01:32:28, metric 20
                    >  to 10.1.24.0 via ge-0/0/0.0, label-switched-path TO_PE-01
172.16.1.3/32      *[RSVP/7/1] 01:32:28, metric 20
                    >  to 10.1.24.0 via ge-0/0/0.0, label-switched-path TO_ASBR-01

各機器にて、互いのLoopback Addressを学習し、かつRSVP PathがActive Routeになっています。

続いて、CE-PE間のOSPFのネイバー状況を確認します。
ついでにCEネットワークの経路情報(203.0.113.0/29)を受信できているか確認します。

//PE-01
lab@PE-01# run show ospf neighbor instance VPN_01
Address          Interface              State           ID               Pri  Dead
192.168.1.1      ge-0/0/6.0             Full            192.168.1.1      128    34
lab@PE-01# run show route table VPN_01.inet.0 protocol ospf

VPN_01.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

203.0.113.0/29     *[OSPF/10] 01:38:40, metric 2
                    >  to 192.168.1.1 via ge-0/0/6.0
224.0.0.5/32       *[OSPF/10] 01:43:39, metric 1
                       MultiRecv
//CE-01
lab@CE-01# run show ospf neighbor
Address          Interface              State           ID               Pri  Dead
192.168.1.0      ge-0/0/0.0             Full            192.168.1.0      128    33

問題なくネイバー確立され、CEネットワークの経路情報を学習できてます。

続いて、RR-01にてCEネットワークのVPNv4 Prefixを受信できているか確認します。

//RR-01
lab@RR-01# run show route receive-protocol bgp 172.16.1.1 table bgp.l3vpn.0

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  172.16.1.1:65001:203.0.113.0/29
*                         172.16.1.1           2       100        I

[edit]
lab@RR-01# run show route table bgp.l3vpn.0 match-prefix "*203.0.113.0*"

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1:65001:203.0.113.0/29
                   *[BGP/170] 01:03:56, MED 2, localpref 100, from 172.16.1.1
                      AS path: I, validation-state: unverified
                    >  to 10.1.24.0 via ge-0/0/0.0, label-switched-path TO_PE-01

VPNv4 Prefix(172.16.1.1:65001:203.0.113.0/29)を受信して、ルーティングテーブルに反映されています。

続いて、RR-01がRR-02にVPNv4 Prefixを送信してるか確認…をする前に、そもそもRR間でネイバーが張れてるか確認します。
丁寧に見ていきたいので、まずASBR-01で、RR-02とPE-02のLo0.0の経路情報を受信できているか確認します。

//ASBR-01
lab@ASBR-01# run show bgp summary group ASBR
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.3
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.1.35.1             65002         65         63       0       0       27:26 Establ
  inet.3: 2/2/2/0

[edit]
lab@ASBR-01# run show route receive-protocol bgp 10.1.35.1

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.7/32           10.1.35.1            20                 65002 I
* 172.16.1.8/32           10.1.35.1            20                 65002 I

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)

ASBR-02(10.1.35.1)間にて、StateがEstablishedでネイバー確立しており、かつRR-02とPE-02のLo0.0の経路情報(172.16.1.8/32と172.16.1.7/32)を受信しています。
なおASBR-01において、RR-02とPE-02の経路情報はinet.3にエントリーさせる必要があります。

続いて、RR-01にてASBR-01よりRR-02とPE-02の経路情報を受信しているか確認します。

//RR-01
lab@RR-01# run show route receive-protocol bgp 172.16.1.3

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.7/32           172.16.1.3           20      100        65002 I
* 172.16.1.8/32           172.16.1.3           20      100        65002 I

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

ASBR-01(172.16.1.3)よりRR-02とPE-02の経路情報を受信しています。
なおRR-01においては(ASBR-01と違って)RR-02の経路情報はinet.0にエントリーさせる必要があります。この辺の細かな違いが難しい…。
ちなみに、Labeled-Unicastの場合はNext-hopが自動で書き替わります(ASBR-01にてNext-hop Selfの設定はいりません)

RR-01にてRR-02の経路情報がエントリーされているので、RR間でPeeringできそうです。
(逆もしかりでASBR-01よりASBR-02へRR-01とPE-01のLo0.0の経路情報を送信している必要があります。ASBR-01から送信できてるかの確認は今回は省略します)

では、RR-01にてRR-02とのネイバー状態を確認します。

//RR-01
lab@RR-01# run show bgp summary group RR_PEER
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 3 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       2          2          0          0          0          0
bgp.l3vpn.0
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.8            65002        202        201       0       0     1:30:03 Establ
  bgp.l3vpn.0: 1/1/1/0

StateがEstablishedとなっており、RR間でネイバーが張れています!

続いて経路の送受信状況を確認します。

//RR-01
lab@RR-01# run show route advertising-protocol bgp 172.16.1.8

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  172.16.1.1:65001:203.0.113.0/29
*                         172.16.1.1                              I

[edit]
lab@RR-01# run show route receive-protocol bgp 172.16.1.8

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  172.16.1.7:1:203.0.113.8/29
*                         172.16.1.7                              65002 I

自ASのCEネットワークのVPNv4 Prefix(172.16.1.1:65001:203.0.113.0/29)を送信しています。
また、対向のCEネットワークのVPNv4 Prefix(172.16.1.7:1:203.0.113.8/29)を受信しています。
L3VPN通信のための経路情報を送り合っているので、問題なさそうです。

RR-01にて受信した対向のCEネットワークのVPNv4 PrefixがPE-01でも受信しているか確認します。

//PE-01
lab@PE-01# run show route table bgp.l3vpn.0

bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.7:1:203.0.113.8/29
                   *[BGP/170] 00:12:49, localpref 100, from 172.16.1.4
                      AS path: 65002 I, validation-state: unverified
                    >  to 10.1.12.1 via ge-0/0/0.0, label-switched-path TO_ASBR-01

[edit]
lab@PE-01# run show route table VPN_01.inet.0 203.0.113.08/29

VPN_01.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

203.0.113.8/29     *[BGP/170] 00:13:23, localpref 100, from 172.16.1.4
                      AS path: 65002 I, validation-state: unverified
                    >  to 10.1.12.1 via ge-0/0/0.0, label-switched-path TO_ASBR-01

VPNv4 PrefixをRR-01から受信していますね。
また、VRFのルーティングテーブルである「VPN_01.inet.0」に対向のCEネットワーク(203.0.113.8/29)がエントリーされています。
正しく経路情報を学習しています!!

最後にCE-01において、OSPFにて対向のCEネットワークを学習しているか確認します。

//CE-01
lab@CE-01# run show route protocol ospf 203.0.113.8/29

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

203.0.113.8/29     *[OSPF/150] 00:19:34, metric 0, tag 3489725929
                    >  to 192.168.1.0 via ge-0/0/0.0

CE-01にて対向CEネットワークの経路情報を学習できています!
PE-01についても対向CEネットワーク宛はASBR-01へLabel Switchingされる様になっているので、少なくとも自ASにて対向のCEネットワーク宛のパケットはお相手のASに転送されそうです!!
(ルーティングテーブルの詳細確認はこの後行います)

では、PingにてvPC間で通信できるか確認します。

//VPC-01
VPC-01> ping 203.0.113.9

84 bytes from 203.0.113.9 icmp_seq=1 ttl=56 time=5.601 ms
84 bytes from 203.0.113.9 icmp_seq=2 ttl=56 time=5.144 ms
84 bytes from 203.0.113.9 icmp_seq=3 ttl=56 time=5.285 ms
84 bytes from 203.0.113.9 icmp_seq=4 ttl=56 time=5.214 ms
84 bytes from 203.0.113.9 icmp_seq=5 ttl=56 time=6.441 ms

対向のVPC(vPC-02)へPing疎通できました!!やったー!

という訳で一旦、ゴールであるL3VPNによるVPC間の疎通は無事できました。
とは言え、せっかくなのでパケットが各機器に届いた際、どんな処理を行なってるか詳しく見ていきましょう。

4. Inter-AS Option C L3VPN 詳細確認

ここから各機器の詳細な経路情報と実際のパケットを見ていきます。
最初に書いた、ChrisさんのBlogの絵と比較しながら読むとわかりやすいと思います。

まず、vPC-01(203.0.113.1)からvPC-02(203.0.113.9)宛のICMP Echo Request(以下、Echo Req)を送信します。
Echo Reqが届いたCE-01は、OSPFにて学習した経路情報に沿ってPE-01(192.168.1.0)へ転送します。

//CE-01
lab@CE-01# run show route protocol ospf 203.0.113.8/29

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

203.0.113.8/29     *[OSPF/150] 00:19:34, metric 0, tag 3489725929
                    >  to 192.168.1.0 via ge-0/0/0.0

CE-01〜PE-01間のパケットキャプチャーを見ます。

EthernetヘッダーがあってIPヘッダーが付いてる、まあ普通のパケット構造ですね。

続いて、PE-01の詳細な経路情報を見ます。
VRFなインターフェイスにて受信しているので、作成したRouting-Instanceのテーブル(VPN_01.inet.0)にて確認します。

//PE-01
lab@PE-01# run show route 203.0.113.8/29 table VPN_01.inet.0 extensive

VPN_01.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
203.0.113.8/29 (1 entry, 1 announced)
<snip>
                Next hop: 10.1.12.1 via ge-0/0/0.0, selected
                Label-switched-path TO_ASBR-01
                Label operation: Push 299776, Push 299808, Push 299856(top)
<snip>

出力結果より、Label-switched-pathの項目より「TO_ASBR-01」のPathを使ってパケット転送する様になっています。
また、Label operationの項目より「Push 299776, Push 299808, Push 299856」と3重でLabelが付くようになっています。
そして、Next hopの項目より「10.1.12.1」へ、つまりP-01に転送しています。

実際にPE-01〜P-01間のパケットキャプチャーを見て、確認します。

EthernetヘッダーとIPヘッダーの間に、経路情報の通り、上から299856、299808、299776のLabelが挿入されてますね。

続いて、P-01の詳細な経路情報を見ます。
TopなLabel 299856をlookupして処理するため、Labelを指定して確認します。

//P-01
lab@P-01# run show route label 299856

mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299856             *[RSVP/7/1] 00:27:39, metric 1
                    >  to 10.1.23.1 via ge-0/0/1.0, label-switched-path TO_ASBR-01
299856(S=0)        *[RSVP/7/1] 00:27:39, metric 1
                    >  to 10.1.23.1 via ge-0/0/1.0, label-switched-path TO_ASBR-01

[edit]
lab@P-01# run show route label 299856 extensive

mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
<snip>
299856(S=0) (1 entry, 1 announced)
<snip>
                Next hop: 10.1.23.1 via ge-0/0/1.0, selected
                Label-switched-path TO_ASBR-01
                Label operation: Pop
<snip>

299856について、「299856」と「299856(S=0) 」がありますが、パケットにLabelが3つスタックされているため、「299856(S=0)」のエントリーをlookupします。
出力結果より、Top LebelがPop(削除)され、 10.1.23.1(ASBR-01)へ転送される様になっています。
なので、3重となっているLabelが1つ削除され、2重になってASBR-01へ転送されることとなります。

実際にP-01〜 ASBR-01間のパケットキャプチャーを見て、確認します。

経路情報の通り、299856のLabelが削除され、299808、299776のLabelが残ってますね。

続いて、ASBR-01の詳細な経路情報を見ます。
TopなLabel 299808をlookupして処理するため、Labelを指定して確認します。

//ASBR-01
lab@ASBR-01# run show route label 299808 extensive

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
299808 (1 entry, 1 announced)
<snip>
                Next hop: 10.1.35.1 via ge-0/0/2.0, selected
                Label operation: Swap 299776
<snip>

出力結果より、Top Lebelが299776にSwap(付け替え)され、 10.1.35.1(ASBR-02)へ転送される様になっています。
なのでAS間にてLabel Switchingによってパケット転送されることとなります。

実際にASBR-01〜ASBR-02間のパケットキャプチャーを見て、確認します。

経路情報の通り、299808が299776に替わり、かつ(元々あった)299776のLabelが残ってますね。

少なくとも自ASについては、正しくOption Cとしてのパケット転送が動作してそうです。
せっかくなので、対向ASのASBR-02に届いた後のパケットの処理も見ていきましょう。
対向ASも自ASと同じく、RSVP PathによるLabel switchingを行なっています。

ASBR-02の詳細な経路情報を見ます。
TopなLabel 299776をlookupして処理するため、Labelを指定して確認します。

//ASBR-02
lab@ASBR-02# run show route label 299776 extensive

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
299776 (1 entry, 1 announced)
<snip>
                Next hop: 10.1.56.1 via ge-0/0/0.0, selected
                Label-switched-path TO_PE-02
                Label operation: Swap 299808
<snip>

出力結果より、Label-switched-pathの項目より「TO_PE-02」のPathを使ってパケット転送する様になっています。
また、Label operationの項目より、299776が299808にSwapする様になっています。
そして、Next hopの項目より10.1.56.1(P-02)に転送しています。

実際にASBR-02〜P-02間のパケットキャプチャーを見て、確認します。

経路情報の通り、299776が299808に替わり、かつ(元々あった)299776のLabelが残ってますね。

続いて、P-02の詳細な経路情報を見ます。
TopなLabel 299808をlookupして処理するため、Labelを指定して確認します。

//P-02
lab@P-02# run show route label 299808

mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299808             *[RSVP/7/1] 01:02:19, metric 1
                    >  to 10.1.67.1 via ge-0/0/0.0, label-switched-path TO_PE-02
299808(S=0)        *[RSVP/7/1] 01:02:19, metric 1
                    >  to 10.1.67.1 via ge-0/0/0.0, label-switched-path TO_PE-02

[edit]
lab@P-02# run show route label 299808 extensive

mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
299808(S=0) (1 entry, 1 announced)
<snip>
                Next hop: 10.1.67.1 via ge-0/0/0.0, selected
                Label-switched-path TO_PE-02
                Label operation: Pop
<snip>

299808について、「299808」と「299808(S=0) 」がありますが、パケットにLabelが2つスタックされているため、「299808(S=0)」のエントリーをlookupします。
出力結果より、Top LebelがPopされ、 10.1.67.1(PE-02)へ転送される様になっています。
なので、2重となっているLabelが1つ削除され、1つのみとなってPE-02へ転送されることとなります。

実際にP-02〜 PE-02間のパケットキャプチャーを見て、確認します。

経路情報の通り、299808のLabelが削除され、299776のLabelのみ残ってますね。

続いてPE-02の詳細な経路情報を見ます。
Label 299776をlookupして処理するため、Labelを指定して確認します。

//PE-02
lab@PE-02# run show route label 299776 extensive

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
299776 (1 entry, 1 announced)
<snip>
                Next hop: 192.168.11.1 via ge-0/0/6.0, selected
                Label operation: Pop
<snip>

出力結果より、LabelがPopされ192.168.11.1(CE-02)へ転送される様になっています。
最後のLabelがPopされるため、Ethernetヘッダーの上にIPヘッダーが付いた普通のパケット構造になります。

PE-02〜CE-02間のパケットキャプチャーを見ます。

経路情報の通り、Labelが無くなっていますね。

最後に、おまけでCE-02のルーティングテーブルも見ます。

//CE-02
lab@CE-02# run show route 203.0.113/24

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

203.0.113.0/29     *[OSPF/150] 07:47:29, metric 0, tag 3489725930
                    >  to 192.168.11.0 via ge-0/0/0.0
203.0.113.8/29     *[Direct/0] 07:47:34
                    >  via ge-0/0/6.0
203.0.113.14/32    *[Local/0] 07:47:34
                       Local via ge-0/0/6.0

(当たり前ですが)直接接続な203.0.113.8/29のネットワークが存在してます。
Echo Reqパケットはge-0/0/6から送出され、vPC-02に届いてることでしょう。
また、CE-02から見た対向のCEネットワーク情報(203.0.113.0/29)をOSPFで学習しています。
Echo Replayパケットは、このルーティングテーブルに沿ってパケット転送されてることでしょう。
無事、複数のASを跨いでL3VPNな通信ができていることが証明できました。

という訳でInter-AS Option Cの構築が無事できました!
今回は以上になります!!
ここまでお読みいただき、ありがとうございました!!!!!

… 尺の都合で対向AS側(PE-02、P-02、ASBR-02、RR-02)の機器の設定例は載せてませんが、要望多ければ載せます。
ぜひ参考にしたい!という方はご連絡をw

5. 参考資料

書籍 O'Reilly 「MPLS in the SDN Era: Interoperable Scenarios to Make Networks Scale to New Services」
Juniper Documentation - Layer 3 VPNs User Guide for Routing Devices - Interprovider VPNswww.juniper.net
NETWORK FUNTIME - INTERPROVIDER OPTION C, ON JUNIPER JUNOS ROUTERS – PART 1www.networkfuntimes.com

JNCIE-SP (1回目) 受験記 試験当日~

2026年3月某日にJNCIE-SP(JPR-962)の資格試験を受けました。
せっかくなので、受験記を残したいと思います。
今回は後半になります。前半のBlogはこちらです。
yokohama539.hatenablog.com

1. 試験当日 チェックイン前まで

ついに試験当日となりました。試験開始時刻はIST(インド標準時) 9:00なので、日本時間 12:30から開始になります。
何回か事前案内メールが来てOutlookにスケジュール登録できるので、間違えはしないでしょう。
(私はGoogleカレンダーにエクスポートしました)

朝はいつも通りテレワーク出勤しメールチェックした後、勉強したOneNoteを読み返してました。
11:00少し前にRemote Lab用のアクセスプロファイルが添付されたメールがプロクターより送られてきました。
また、このメールには事前ブリーフィング(Zoom)のミーティングIDが記載されており、試験開始30分前くらいに参加するよう指示があります。

事前ブリーフィングの直前まで若干緊張しながら最後のOneNote確認をします。
机の上に(キーボードとマウスと)ミネラルウォーターとホワイトボード用具一式と身分証明書のパスポートを準備します。

試験開始30分前になったので、Safe Exam Browserを立ち上げてRemote Lab環境にアクセスし、届いたメール記載のミーティングIDへ参加します。

2. 試験当日 チェックイン~事前ブリーフィング

ミーティングに参加すると既にプロクターがいました。
「Hi, YOKOHAMA!」と元気に呼ばれます(もちろん本名で呼ばれてますが、Blog上ではYOKOHAMAとします)
さっそくチェックイン開始です。公開されている情報のとおり、身分証明書の確認と「ルームスキャン」という部屋のチェックが行われます。
プロクターよりWebカメラを使ってパスポートと併せて、机の上と部屋を映すよう促されます。なのでWebカメラを持って一通り映しました。
しっかり本棚など目隠ししていたので予想よりスムーズにOKが出ました。
その後、自分が受験するトラックの確認があり「Service Provider」と答えました。
トラックの確認後にプロクターから
「OK. SP track is very difficulty, are you preparing until today?
(よし、いいな。Service Providerトラックはとても難しい、ちゃんと今日まで準備してきたか?)」
とのお言葉が。おお…煽ってくれるやん。とりあえず「Yes.I'll do best.」と無難な回答をしました。
その後、昼休憩の時間と終了時間のアナウンスがありました(時間配分は公開されてない様なので具体的な時刻は内緒)

話はその程度で「End the briefing. Let's start exam!(ブリーフィングは以上だ。試験を始めるぞ!)」と言い、試験の準備が行われます。
2007年に受けたCCIE R&S Lab試験では、ブリーフィング時に試験の注意事項の説明がありましたが、この試験ではブリーフィング時に説明はないようです。
プロクターの遠隔操作にてRemote Lab環境に用意されているLab問題、トポロジーの画、ターミナルソフトのSecureCRTが置いてあるRemote DesktopなWindows画面を出してくれます。
この時は「19年ぶりのLab試験…!頼む、理解している技術わんさか出てくれ!!」とお祈りタイムでした。

そしてプロクターより「Let's get started! Let me know any questions. Good luck! GANBATTE!
(試験開始だ!何か質問あれば聞いてくれ。グッドラック!がんばって!)」と言われ、操作可能になります。GANBATTEは本当に言われましたw
なお、試験中は常時WebカメラとマイクはONにしたままとなります。

6時間のLab試験が始まりました。

3. 試験当日 Lab試験 (前半)

まずザッとトポロジーを見ます。
第一印象としては「な、なるほど…そんなに理解に苦しむ構成じゃないかも」でした。
2007年に受けたCCIE R&S Lab試験はキテレツな謎トポロジーだったので少し安心しました。
また、思ってたよりも親切だなあというのが最初の感想です。最初はね。

続いてLab問題を見ます。
第一印象としては「……こういうテイストの設問ですかあ。これはなかなか厄介ですなあ」でした。
各設問自体は英語力が皆無な私でもだいたい理解できました。
設問全体の流れを把握してSecureCRTよりLabデバイスへアクセスして設定を始めます。これはしんどい試験になりそうだ…!
作戦としては「IPリーチャビリティに直結する設問以外はメモっておいて後に回そう作戦」で行きました。

設問の詳細はもちろん書けませんが、ココココの内容が問われます。
とても色々な形で知識を問われます。設計、構築、運用面でのノウハウが必要だなあと感じました。
設問とトポロジーの画を見ながら設定投入をしていきます。
微妙にわからない箇所は用意されたDocumentを見ながら設定していきます。

そして中盤に差し掛かろうとした矢先に、(試験範囲のトラブルシューティングとは別で)進行上で、あるトラブルに見舞われました。
このトラブルでしばらく試験が中断されました(トラブル内容は試験内容に関係ないですが、念のため秘密です)
中断された時間は計測され、「Lost time is will be additional time.(中断時間分はアディショナルタイムとして補完する)」との説明がありました。
大変ありがてえ…!

前半の進捗は、想定よりやや遅かったです。
まあ土台なIGP/BGPだし中断時間あったし、焦らず進めようという気持ちでやってました。
幸い、ここまででリーチャビリティに問題はなさそう(=題意は満たせている認識)でした。

そうこうしてる内に前半終了の時刻になり、プロクターより
「Hi,YOKOHAMA. It's lunchtime! Come back in 1 hour!(昼休憩だ。1時間後に戻るように)」と言われました。
うおお…あっという間だったな…時間配分やべえかも…と思いつつ休憩に入ります。
前半はホワイトボードは、ほぼ使わなかったです。

4, 試験当日 昼休憩

休憩は試験の部屋から一旦出ます。いつ呼ばれてもいいように隣の部屋のドア越しで食べました。
お昼は短縮されることも加味してササッと食べれるように、おにぎり2個+チョコ+キレートレモンにしました。
結局、休憩はきっちり1時間で、10分程度で食べ終わったので残りの50分は午後の作戦を立ててました。
(始まったらRouter Xの〇〇を確認して、出力次第でRouter Yに××の設定入れて挙動を確かめるか…的な感じ)

思ったよりあっという間に50分経ち、席に戻ります。

5. 試験当日 Lab試験 (後半)

部屋に戻るとプロクターは既にPC前に待機しており「OK,keep exam(よし、再開だ)」と言われ試験が再開されます。

後半も様々な設問を解いていきます。
「ファー…こんなんアリですかー…」と言いたくなるような、意表を突く設問もありました。
とある設問でホワイトボードを使って頭の整理をしたりもしました。
全く意図がわからない設問も数問ありました。ぐぬぬ悔しい…。

最後の最後でトンデモない設問がありました。
幸い知っている技術だったので意地でもこれは完了させたく、しばらく奮闘しました。
想定外な動作もありましたが色々設定を入れ、何とか題意に沿った挙動となりました。
この設問にかなり時間を使ったため、残り時間で見直しや後回しにした問題全ての着手は難しくなりました。ぐぬぬとても悔しい…。

見直しをし、残りわずかな時間で後回しの設問を解いてる時にタイムアップ!うーん、不完全燃焼!

操作をやめ、プロクターが遠隔操作で開始時に広げたウィンドウを閉じます。
その後プロクターより「End the exam. Will notify you of the results at a later date.
(試験はこれで終了だ。結果は後日通知する)」との連絡がありました。

そして最後に「Bye-Bye!」と挨拶をしてミーティングは終了しました。

6. 試験当日 Lab試験後

まずLab試験後お約束の(?)トポロジーと問題をメモしました。今回はA4コピー用紙3枚ほどメモしました。
そして業務PCを立ち上げて、上司にLab試験終了の報告とメールチェックをして業務終了。
ファミレスで晩御飯を食べつつ問題と回答内容を振り返ります。

所感としては「回答できてない箇所もあったけど、回答した設問のリーチャビリティは完璧だったから、上振れればTotal xx%いけるか…?」でした。
特に、あのトンデモ設問は合っててほしい気持ちでした。

7. 試験結果

正式な結果はまだ来てません。来たら追記します。
振り返りも追記します。

7-EX. 試験結果 (2026/3/28 追記)

結果が来ました。
結果通知はCertMetricsのUpdateをもって行われます。

気になる合否は…………………………fail!ぐへー。

まあ未回答の設問があった時点で悟ってましたが、いざ結果を突き付けられると凹む…。

Downloadから「Lab Exam Results Card」というスコアシートがダウンロードできます。


気になるスコアですが、予想よりも若干低い…。
題意を満たしているつもりだったけど、NGな箇所がありそう。
単にリーチャビリティが取れればOK、という訳ではないのはわかってたけど厳しい…。
JNCP Lab試験の手痛い洗礼を受けましたねえ。

ただ、そこまで酷いスコアではなく、トンデモ設問は正解していたようなので、そこはホッとしましたw
どこを補強すれば良いかわかったので、もう少しスコアは伸ばせるはず…。

試験の所感としては
・Service Providerトラックの特性上、「Pingが飛べばOK」でもないので確認が大変
・「設定」だけをトレーニングしてもダメ
・試験範囲の技術について、どのDocumentのどの辺に書いてあるか把握しておく必要がある
・2007年のCCIE R&S Lab試験に比べ、かなり難しい(難しいというより自分と相性が悪い)
あたりでしょうか。あとは体力と精神力…w

という訳でJNCIE-SP 受験記は以上になります。
今後、受けられる方の参考になれば幸いです。

ここまでお読みいただき、ありがとうございました!!!


…だいたい試験の流れ&問題の雰囲気はわかったので次回はいつ受けよう?? そもそも受けられるのだろうかw

JNCIE-SP (1回目) 受験記 ~試験前日まで

2026年3月某日にJNCIE-SP(JPR-962)の資格試験を受けました。
せっかくなので、受験記を残したいと思います。
※公開されている情報のみ記載してます。

1. JNCIE-SP 試験概要

JNCIE-SPとは、HPE Juniper Networkingが主催するJNCP(Juniper Networks Certification Program)の認定試験の一つとなります。
公式の記載のとおりService Provider領域の最上位の資格です。
…まあCCIEがあまりにも有名なのでCCIE SPのJuniper版、と捉えれば間違いありません。
受験料は2026年3月現在、CCIEと同額の1600 USD(約25万円)になります。

試験方法は提示されたTaskに従って6時間(+休憩1時間)に渡り複数台のRouterやSwitchに設定を行うHands-on Labとなります。
使用言語はもちろん英語Onlyです。
現時点では日本国内はRemote Lab形式のみで受験ができます。

試験範囲はService Providerの名のとおり(CoPPやSNMPなどの)デバイス FeatureやIGP/BGPに加えMPLSやVPNサービスが対象となります。
具体的にはLDP、RSVP、L3VPN、L2VPN(VPLS)、EVPNなどの知識が問われます。
さらに昨年7月に試験バージョンが(JPR-961からJPR-962へと)改訂され、TelemetryやSegment Routingも試験対象となりました。増える一方で嬉しくない…。
なお、公式のBlueprintにて必要なスキルセットが記載されてます。
受験した身としては、日本の公式の説明はあんまりイケてなく英語のFlyerの説明の方が要求スキルセットは正確かな…という印象です。

そしてRemote Labについての説明です。前述のとおり、日本国内で受験する際はRemote Lab形式となります。
自分のPCよりSafe Exam Browserというソフトウェア経由でJuniperの試験専用インターフェイス(ポータルサイト)にアクセスし、Remote DesktopでRouterやSwitchが操作できる試験端末にアクセスします。
Lab問題やトポロジー、参照可能なTech Documentもそれらからアクセスします。
自部屋で自分のキーボードやマウスで試験が受けられるのでとてもイイ!
(…ただ、準備もそれなりに必要で結構大変でした)

自分のPCにソフトウェアをインストールするため、Windows PCが必須となります。Macは使えません。
また、試験時に自部屋に持ち込める物はホワイトボードとマーカーと水のみとなっています。
紙とペンといった筆記用具や腕時計は持ち込み禁止です。
公開されている情報のとおり、各デバイスへの設定投入は「SecureCRT」というターミナルソフトを使って行います。

2. 試験前日まで

トレーニングは推奨されている「JNCIE-SP Certification Self-Study Bundle」を受講しました。

この教材はJNCIE-SPの範囲における技術を非常に丁寧に説明している、とても良い教材です。
また、メーカーによらない各プロトコルの動作原理も詳しく解説しており、大変ためになりました。
さらに勉強用Labも最大500時間分使えます!全く足りませんが!!w
試験の9ヶ月前から着手し試験の2ヶ月前までは、この教材の各セクションのTaskを自宅のLab(EVE-NG)にて環境構築&検証→わからんところを調べたりしてました。
EVE-NG(というか多分vJunos-routerの性能制限)で環境を再現できない場合は教材の勉強用Labを使って検証してました。

そして試験2ヶ月前からトラブルシューティングやconfigスピードを意識したトレーニングをしてました。
トラブルシューティングは、configを比較してトラブル原因を特定する方法ではなく、showコマンドとdebug log(traceoptionやmonitor traffic)より原因を特定できるような検証を行いました。
具体的には、OSPFを例に挙げると各パラメーター(NWアドレス、サブネットマスク長、エリアID、MTUなど)不一致によってネイバーが張れない場合、どんなshowコマンドで確認できて、どんなflagのTraceoptionが必要で、どの様なlogが出て、どんな設定をすれば良いか…などの検証をしてました。
また、2つ以上のパラメーター(例: サブネットマスク長とエリアID)が不一致の場合のlogの出力も可能な範囲で確認してました。

configスピードを上げる練習は、単に「タイピング速度を上げる」や「調べなくともコマンドを打てるようにする」だけでなく「他のデバイスのconfigを流用して、いかに効率的に設定投入できるか」も自分なりにノウハウを溜めました。
自分でイチから設定投入するより、実績のある既存のconfigを編集して投入した方が早いしミスは少ないので良いことずくめです。
なので、「run show configuration | display set | grep ~」で何をgrepの対象とすればコピペしやすい出力がされるか、の検証をしました。
具体例を挙げれば、EVPNが動作済みのRouterがあり、他のRouterでもEVPNを動作させたい場合は、
「run show configuration | display set | grep "IF名|Instance名|disti|evpn"」を実行すれば、ほぼコピペでOKなconfigが出力されます。
EVPNに限らず他の設定でも、この辺を意識してconfig作成~投入~確認の一連のスピードを早くするトレーニングをしました。

あと、設定済みのconfigの修正として、replace patternコマンドやinsertコマンドの習熟も有効かなと思います。
(この辺は実務で使ってるので特別に練習とかはしてませんでしたが)

検証した内容は全てOneNoteに記入し、読み返せるようにしました。
1ページに技術概要やトポロジーや設定、logをまとめて見れるようにしました。

↓OneNoteの記入例

教材は約1400ページあるので相応のページになりました(しかも英語)
読み返すのも一苦労…。

こんな感じで勉強を進めました。
また、SecureCRTに慣れておくため会社でのコンソール作業はこれを使うようにしました。
(有料ソフトですが所属部署でライセンス買ってくれました。感謝!!!)

技術的なこと以外としては、公開されている情報のとおり試験日の1ヵ月前に
「Remote Lab Exam Application Verification Guide」というRemote Labに関する資料が添付されたメールが届きます。
内容としては前述したSafe Exam Browserのインストール方法や、RouterとSwitchの操作方法、Lab問題とTech Documentのアクセス方法のマニュアルになります。
そんなに複雑でないので、英語力が皆無の私でも理解できましたw
また、デモのアクセスプロファイルが添付されており、リハーサルとしてRemote Desktopでログインし、SecureCRTにてJuniperデバイスの操作ができます。
(Lab試験の際は、試験用のアクセスプロファイルが試験前に送付されます。詳しくはまた次回で…)

ここでちょっとトラブルがあり、最初、私のPCではSafe Exam Browserが正常に起動せず若干テンパりました。
(といっても試験2週間前くらいの出来事で時間的に余裕でしたが)
一人では解決できずガイドに記載されている問い合わせ先に連絡したところ、Windowsのとある設定が原因という回答メールが来て、その回答メールの通りに設定を変えたら無事にSafe Exam Browserが起動しました。
まあ今後受験する方がいたら、Remote Labのリハーサルは早めにした方がいいですよということで…。

試験前日の夜は、自部屋とPC環境の整理をしました。
試験の際、部屋の確認が行われ、文字が目に付くと細かくチェックされるらしいので本棚などは全て目隠ししました。

また、通信コンディションは最善を尽くすため有線接続とすべく、LANケーブルを引きました。
なおケーブルに合格祈願のお守りをつけました(とても重要な行為だと思っている)

3. 試験当日(次回の記事)

長くなってきたので、また次回!!続く!!!!!

vJunosでEVPN-MPLS L3VPNをしてみた。 ~その1~

今回から二回に渡り、vJunos-routerを使ってEVPN-MPLSによるL3VPNの検証をしたいと思います。
ネット上はEVPN-VXLANな記事ばかりなので、敢えてEVPN-MPLSの例をやってみます。
今回の「その1」はL2VPNなEVPN-MPLSまで設定して、(同一Network Addressである)拠点間の疎通を確認します。
次回の「その2」は疑似的なインターネットを構築して、各拠点からL3VPNで(疑似の)インターネットと通信できるようにしたいと思います。

主にJunosの設定と確認について書き記します。
例によって用語の詳しい説明は行いません。わからない用語は各自でググってください。

1. EVPN-MPLS L3VPN 構成

トポロジーは以下のとおりです。

EVPN-MPLSを動かす疑似Service-Provider(疑似SP)網を中心に、Customer Siteを3つ用意します。
それぞれ同じNetwork(192.168.12.0/24)です。
Customer Site1はMultihomig構成としてます。
Customer SiteのPCとPE間はVlan Taggingは無しとしてます((ネット上にはVlan Taggingありの設定例ばかりで)あまり実例がない無しでやります)
また、疑似SP網内はRoute-Reflector(RR)によって(BGPによる)経路を広報します。
MPLSでのLabel配布Protocolは今回はRSVPを使用します。
(次回の話ですが)R4にて他ASなR8とeBGP Peeringし、疑似Internetから経路を受け取る設定をします。
各Customer SiteのPC1~3から疑似Internet上のHostであるPC10と通信できることをゴールとします。

上述のとおり、今回はCustomer SiteにあるPC1~3間のL2VPN通信まで検証したいと思います。

2-1. OSPF 設定・確認

それでは設定していきます。
R4のge-0/0/9以外のIP Addressの設定まで完了していることとします。
まず、疑似SP網内でUnderlayとなるOSPFを設定し、R1~R7のLoopback Addressをお互い広報します。

//R1
set routing-options router-id 172.16.1.1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R2
set routing-options router-id 172.16.1.2
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R3
set routing-options router-id 172.16.1.3
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R4
set routing-options router-id 172.16.1.4
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R5
set routing-options router-id 172.16.1.5
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
set protocols ospf area 0.0.0.0 interface ge-0/0/6.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R6
set routing-options router-id 172.16.1.6
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
set protocols ospf area 0.0.0.0 interface ge-0/0/6.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R7
set routing-options router-id 172.16.1.7
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

OSPF設定で特筆すべき点としては、lo0.0はパッシブインターフェイスでよいのでpassive入れてます。以上!

R1~R7でお互いのLoopback Addressを学習できてるか確認します。
念のため、OSPFを動かしているインターフェイスでAdjacencyが確立してるかも見ましょう。
BlogではR7のみ確認します(実際はR1~R6でも確認してます)

//R7
lab@R7# run show route 172.16.1/24

inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[OSPF/10] 00:47:17, metric 2
                    >  to 10.1.57.5 via ge-0/0/0.0
172.16.1.2/32      *[OSPF/10] 00:19:36, metric 2
                    >  to 10.1.57.5 via ge-0/0/0.0
172.16.1.3/32      *[OSPF/10] 00:26:20, metric 2
                    >  to 10.1.67.6 via ge-0/0/1.0
172.16.1.4/32      *[OSPF/10] 00:21:25, metric 2
                    >  to 10.1.67.6 via ge-0/0/1.0
172.16.1.5/32      *[OSPF/10] 00:47:17, metric 1
                    >  to 10.1.57.5 via ge-0/0/0.0
172.16.1.6/32      *[OSPF/10] 00:26:59, metric 1
                    >  to 10.1.67.6 via ge-0/0/1.0
172.16.1.7/32      *[Direct/0] 00:47:57
                    >  via lo0.0

[edit]
lab@R7# run show ospf neighbor
Address          Interface              State           ID               Pri  Dead
10.1.57.5        ge-0/0/0.0             Full            172.16.1.5       128    32
10.1.67.6        ge-0/0/1.0             Full            172.16.1.6       128    35

neighbor Stateが「Full」となっており、かつR1~R6のLoopback Addressを学習していますね。
問題なさそうです。
OSPFの設定は以上です。

2-2. BGP 設定・確認

続いて、BGPの設定をしていきます。
R1~R6とR7とiBGP Peering、R7は文字通りRRの設定をします。
「cluster」をつけてるBGP groupでのPeerは全てRoute Reflector Clientになります。

//R1
set routing-options autonomous-system 65001
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.1
set protocols bgp group INTERNAL neighbor 172.16.1.7 
//R2
set routing-options autonomous-system 65001
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.2
set protocols bgp group INTERNAL neighbor 172.16.1.7
//R3
set routing-options autonomous-system 65001
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.3
set protocols bgp group INTERNAL neighbor 172.16.1.7
//R4
set routing-options autonomous-system 65001
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.4
set protocols bgp group INTERNAL neighbor 172.16.1.7
//R5
set routing-options autonomous-system 65001
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.5
set protocols bgp group INTERNAL neighbor 172.16.1.7
//R6
set routing-options autonomous-system 65001
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.6
set protocols bgp group INTERNAL neighbor 172.16.1.7
//R7
set routing-options autonomous-system 65001
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.7
set protocols bgp group INTERNAL cluster 172.16.1.7
set protocols bgp group INTERNAL neighbor 172.16.1.1
set protocols bgp group INTERNAL neighbor 172.16.1.2
set protocols bgp group INTERNAL neighbor 172.16.1.3
set protocols bgp group INTERNAL neighbor 172.16.1.4
set protocols bgp group INTERNAL neighbor 172.16.1.5
set protocols bgp group INTERNAL neighbor 172.16.1.6


確認をします。
RRなR7で確認します。

//R7
lab@R7# run show bgp summary | no-more
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 6 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1            65001         11         10       0       0        4:06 Establ
  inet.0: 0/0/0/0
172.16.1.2            65001         11         10       0       0        4:02 Establ
  inet.0: 0/0/0/0
172.16.1.3            65001         11         10       0       0        3:58 Establ
  inet.0: 0/0/0/0
172.16.1.4            65001         11         10       0       0        3:54 Establ
  inet.0: 0/0/0/0
172.16.1.5            65001         11          9       0       0        3:50 Establ
  inet.0: 0/0/0/0
172.16.1.6            65001         11          9       0       0        3:53 Establ
  inet.0: 0/0/0/0

R1~R6とBGPネイバーが確立していますね。
BGPの設定は以上です。

2-3. MPLS - RSVP 設定・確認

MPLSを設定していきます。今回はRSVPなので各Ingress LERでPathを定義します。
また、Traffic Engineeringはしないのでオプションでno-cspfを付けます。
(no-cspfがないとOSPFにてTraffic Engineeringの設定が必須になります)
なお、R5-R7およびR6-R7間はMPLSを有効にする必要はありません。

//R1
set interfaces ge-0/0/0.0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/0.0
set protocols mpls label-switched-path R1-to-R2 to 172.16.1.2
set protocols mpls label-switched-path R1-to-R2 no-cspf
set protocols mpls label-switched-path R1-to-R3 to 172.16.1.3
set protocols mpls label-switched-path R1-to-R3 no-cspf
set protocols mpls label-switched-path R1-to-R4 to 172.16.1.4
set protocols mpls label-switched-path R1-to-R4 no-cspf
//R2
set interfaces ge-0/0/0.0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/0.0
set protocols mpls label-switched-path R2-to-R1 to 172.16.1.1
set protocols mpls label-switched-path R2-to-R1 no-cspf
set protocols mpls label-switched-path R2-to-R3 to 172.16.1.3
set protocols mpls label-switched-path R2-to-R3 no-cspf
set protocols mpls label-switched-path R2-to-R4 to 172.16.1.4
set protocols mpls label-switched-path R2-to-R4 no-cspf
//R3
set interfaces ge-0/0/0.0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/0.0
set protocols mpls label-switched-path R3-to-R2 to 172.16.1.2
set protocols mpls label-switched-path R3-to-R2 no-cspf
set protocols mpls label-switched-path R3-to-R1 to 172.16.1.1
set protocols mpls label-switched-path R3-to-R1 no-cspf
set protocols mpls label-switched-path R3-to-R4 to 172.16.1.4
set protocols mpls label-switched-path R3-to-R4 no-cspf
//R4
set interfaces ge-0/0/0.0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/0.0
set protocols mpls label-switched-path R4-to-R1 to 172.16.1.1
set protocols mpls label-switched-path R4-to-R1 no-cspf
set protocols mpls label-switched-path R4-to-R2 to 172.16.1.2
set protocols mpls label-switched-path R4-to-R2 no-cspf
set protocols mpls label-switched-path R4-to-R3 to 172.16.1.3
set protocols mpls label-switched-path R4-to-R3 no-cspf
//R5
set interfaces ge-0/0/0.0 family mpls
set interfaces ge-0/0/1.0 family mpls
set interfaces ge-0/0/5.0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/5.0
set protocols rsvp interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/5.0
//R6
set interfaces ge-0/0/0.0 family mpls
set interfaces ge-0/0/1.0 family mpls
set interfaces ge-0/0/5.0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/5.0
set protocols rsvp interface ge-0/0/0.0
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/5.0


確認をします。
まず、MPLSとRSVPのStatusを確認します。
今回は尺の都合でR1のみ確認します。
(実際はR2~R4も確認してます)

//R1
lab@R1# run show mpls interface
Interface        State       Administrative groups (x: extended)
ge-0/0/0.0       Up         <none>

lab@R1# run show rsvp session
Ingress RSVP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname
172.16.1.2      172.16.1.1      Up       0  1 FF       -   299824 R1-to-R2
172.16.1.3      172.16.1.1      Up       0  1 FF       -   299952 R1-to-R3
172.16.1.4      172.16.1.1      Up       0  1 FF       -   299888 R1-to-R4
Total 3 displayed, Up 3, Down 0

Egress RSVP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname
172.16.1.1      172.16.1.3      Up       0  1 FF       3        - R3-to-R1
172.16.1.1      172.16.1.4      Up       0  1 FF       3        - R4-to-R1
172.16.1.1      172.16.1.2      Up       0  1 FF       3        - R2-to-R1
Total 3 displayed, Up 3, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

MPLS、RSVPIngress RSVPともにUp表示されて問題なさそうですね。
併せてR1~R4でルーティングテーブルを確認します。

//R1
lab@R1# run show route protocol rsvp table inet.3

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.2/32      *[RSVP/7/1] 00:14:57, metric 2
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R2
172.16.1.3/32      *[RSVP/7/1] 00:13:50, metric 3
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R3
172.16.1.4/32      *[RSVP/7/1] 00:14:05, metric 3
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R4
//R2
lab@R2# run show route protocol rsvp table inet.3

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[RSVP/7/1] 00:15:33, metric 2
                    >  to 10.1.25.5 via ge-0/0/0.0, label-switched-path R2-to-R1
172.16.1.3/32      *[RSVP/7/1] 00:14:19, metric 3
                    >  to 10.1.25.5 via ge-0/0/0.0, label-switched-path R2-to-R3
172.16.1.4/32      *[RSVP/7/1] 00:14:46, metric 3
                    >  to 10.1.25.5 via ge-0/0/0.0, label-switched-path R2-to-R4
//R3
lab@R3# run show route protocol rsvp table inet.3

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[RSVP/7/1] 00:14:56, metric 3
                    >  to 10.1.35.6 via ge-0/0/0.0, label-switched-path R3-to-R1
172.16.1.2/32      *[RSVP/7/1] 00:14:33, metric 3
                    >  to 10.1.35.6 via ge-0/0/0.0, label-switched-path R3-to-R2
172.16.1.4/32      *[RSVP/7/1] 00:14:29, metric 2
                    >  to 10.1.35.6 via ge-0/0/0.0, label-switched-path R3-to-R4
//R4
lab@R4# run show route protocol rsvp table inet.3

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[RSVP/7/1] 00:14:50, metric 3
                    >  to 10.1.46.6 via ge-0/0/0.0, label-switched-path R4-to-R1
172.16.1.2/32      *[RSVP/7/1] 00:15:18, metric 3
                    >  to 10.1.46.6 via ge-0/0/0.0, label-switched-path R4-to-R2
172.16.1.3/32      *[RSVP/7/1] 00:14:59, metric 2
                    >  to 10.1.46.6 via ge-0/0/0.0, label-switched-path R4-to-R3

Label Switchingするためのinet.3テーブルに、設定した通りのPathがエントリーされてます。
これで各LER(のLoopback Address)間でLabel Switchingされます。

ちなみに、ちゃんとLabel SwitchingされるかはMPLS Pingをすることによって確認できます。

//R1
lab@R1# run ping mpls rsvp R1-to-R3
!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
//「R1-to-R3」のPathを使ってR1からR3へMPLS Pingして疎通できている。

2-4. EVPN 設定・確認

EVPNの設定をします。
R1とR2についてはMultihomingの設定を入れます。
トポロジー上でDesignated ForwarderをR1としているので、preference valueで明示的にR1を高優先にします。

//R1
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family evpn signaling 
set chassis aggregated-devices ethernet device-count 1
set interfaces ae1 encapsulation ethernet-bridge
set interfaces ae1 esi 00:11:22:33:44:55:66:77:88:99
set interfaces ae1 esi single-active df-election-type preference value 100
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 aggregated-ether-options lacp system-id 00:00:00:00:00:12
set interfaces ae1 unit 0 family bridge
set interfaces ge-0/0/6 gigether-options 802.3ad ae1
set routing-instances EVPN-MPLS instance-type evpn
set routing-instances EVPN-MPLS protocols evpn interface ae1.0
set routing-instances EVPN-MPLS vlan-id 12
set routing-instances EVPN-MPLS interface ae1.0
set routing-instances EVPN-MPLS route-distinguisher 172.16.1.1:65001
set routing-instances EVPN-MPLS vrf-target target:65001:1
//R2
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family evpn signaling 
set chassis aggregated-devices ethernet device-count 1
set interfaces ae1 encapsulation ethernet-bridge
set interfaces ae1 esi 00:11:22:33:44:55:66:77:88:99
set interfaces ae1 esi single-active df-election-type preference value 50
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 aggregated-ether-options lacp system-id 00:00:00:00:00:12
set interfaces ae1 unit 0 family bridge
set interfaces ge-0/0/6 gigether-options 802.3ad ae1
set routing-instances EVPN-MPLS instance-type evpn
set routing-instances EVPN-MPLS protocols evpn interface ae1.0
set routing-instances EVPN-MPLS vlan-id 12
set routing-instances EVPN-MPLS interface ae1.0
set routing-instances EVPN-MPLS route-distinguisher 172.16.1.2:65001
set routing-instances EVPN-MPLS vrf-target target:65001:1
//R3
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family evpn signaling 
set interfaces ge-0/0/6 encapsulation ethernet-bridge
set interfaces ge-0/0/6 unit 0 family bridge
set routing-instances EVPN-MPLS instance-type evpn
set routing-instances EVPN-MPLS vlan-id 12
set routing-instances EVPN-MPLS interface ge-0/0/6.0
set routing-instances EVPN-MPLS vrf-target target:65001:1
set routing-instances EVPN-MPLS protocols evpn interface ge-0/0/6.0
set routing-instances EVPN-MPLS route-distinguisher 172.16.1.3:65001
//R4
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family evpn signaling
set interfaces ge-0/0/6 encapsulation ethernet-bridge
set interfaces ge-0/0/6 unit 0 family bridge
set routing-instances EVPN-MPLS instance-type evpn
set routing-instances EVPN-MPLS vlan-id 12
set routing-instances EVPN-MPLS interface ge-0/0/6.0
set routing-instances EVPN-MPLS vrf-target target:65001:1
set routing-instances EVPN-MPLS protocols evpn interface ge-0/0/6.0
set routing-instances EVPN-MPLS route-distinguisher 172.16.1.4:65001
//R7
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family evpn signaling
set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0

R7の最後の「set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0」コマンドですが今回のRRなR7には必須になります。
と言うのもEVPNで学習する経路情報はDefault動作として、inet.3テーブルをlookupしてBGP Protocol next-hopを解決しようとします。
つまりR7でMPLSを動かしてRSVPで各LERへのPathを定義しないとEVPNでの経路情報を学習できません。
そのために数十行もの設定を入れるのもダルいので、このコマンドが用意されてます。
このコマンドを入れることによってlookup対象をinet.3ではなくinet.0にします。
そうすることにより、BGP Protocol next-hopが解決されて経路情報がActiveになります。
Labが用意できる方は、ぜひこのコマンドの有無を試してみてください。

…ちなみに勘の良い方は「じゃあinet.3に直接Static Routeを書けば同様にProtocol next-hop解決されるんじゃないの?」と気づくかもしれません。
そのとおりです。ぜひその方法も試してみてください(わからなければ私にご連絡を…w)

あと、SW1の設定も入れます。単にVlan切ってLAG設定入れてるだけです。

//SW1
set chassis aggregated-devices ethernet device-count 1
set interfaces ge-0/0/0 gigether-options 802.3ad ae1
set interfaces ge-0/0/1 gigether-options 802.3ad ae1
set interfaces ge-0/0/6 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/6 unit 0 family ethernet-switching vlan members VLAN0012
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 unit 0 family ethernet-switching interface-mode access
set interfaces ae1 unit 0 family ethernet-switching vlan members VLAN0012
set vlans VLAN0012 vlan-id 12

設定は以上です。

確認をします。
まず、Customer Site 1のLAG部分を確認します。

//SW1
lab@SW1# run show lacp interfaces
Aggregated interface: ae1
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-0/0/0       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/0     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      ge-0/0/0                  Current   Fast periodic Collecting distributing
      ge-0/0/1                  Current   Fast periodic Collecting distributing
//R1
lab@R1# run show lacp interfaces
Aggregated interface: ae1
    LACP state:           Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-0/0/6           Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/6         Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      ge-0/0/6                  Current   Fast periodic Collecting distributing
//R2
lab@R2# run show lacp interfaces
Aggregated interface: ae1
    LACP state:           Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-0/0/6           Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/6         Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      ge-0/0/6                  Current   Fast periodic Collecting distributing

SW1、R1、R2で「Collecting distributing」となっているので問題なさそうです。

次にMP-BGPの状態を確認します。
尺の都合でR1のみ確認します。

//R1
lab@R1# run show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       0          0          0          0          0          0
bgp.evpn.0
                       9          9          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.7            65001         87         81       0       0       33:01 Establ
  inet.0: 0/0/0/0
  bgp.evpn.0: 9/9/9/0
  EVPN-MPLS.evpn.0: 8/8/8/0
  __default_evpn__.evpn.0: 1/1/1/0

RRなR7と「Establ」となっており、かつbgp.evpn.0テーブルにて経路情報を受信しているので問題なさそうです。
bgp.evpn.0テーブルにて受信した経路情報を確認します。
各LERなRouterからEVPN Route Type 3情報を受信してるか確認します。

//R1
lab@R1# run show route match-prefix "3:172.16.1.*" table bgp.evpn.0

bgp.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3:172.16.1.1:65001::12::172.16.1.1/248 IM
                   *[EVPN/170] 00:05:09
                       Indirect
3:172.16.1.2:65001::12::172.16.1.2/248 IM
                   *[BGP/170] 00:04:55, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R2
3:172.16.1.3:65001::12::172.16.1.3/248 IM
                   *[BGP/170] 00:05:12, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R3
3:172.16.1.4:65001::12::172.16.1.4/248 IM
                   *[BGP/170] 00:05:12, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R4

(RRを経由して)R2~R4からのEVPN Route Type 3情報を受信してますね。
EVPN-MPLSによる経路情報の広報は問題なさそうです。

次に、Multihoming構成が問題ないか確認します。
まず、R1の状態を見ます。

//R1
lab@R1# run show evpn instance esi 00:11:22:33:44:55:66:77:88:99 extensive | no-more
Instance: EVPN-MPLS
<snip>
  Number of ethernet segments: 1
<snip>
      Local interface: ae1.0, Status: Up/Forwarding
      Number of remote PEs connected: 1
        Remote-PE        MAC-label  Aliasing-label  Mode
        172.16.1.2       0          0               single-active
      DF Election Algorithm: Preference based
      Designated forwarder: 172.16.1.1, Preference: 100
      Backup forwarder: 172.16.1.2, Preference: 50
<snip>

トポロジー上の指定通り、single-active Modeとなっており、Designated forwarderがR1(172.16.1.1)となっています。
また、Statusが「Up/Forwarding」となっており、R1が高優先で動作してます。

R2も見ます。

//R2
lab@R2# run show evpn instance esi 00:11:22:33:44:55:66:77:88:99 extensive | no-more
Instance: EVPN-MPLS
<snip>
  Number of ethernet segments: 1
<snip>
      Local interface: ae1.0, Status: Up/Blocking
      Number of remote PEs connected: 1
        Remote-PE        MAC-label  Aliasing-label  Mode
        172.16.1.1       0          300000          single-active
      DF Election Algorithm: Preference based
      Designated forwarder: 172.16.1.1, Preference: 100
      Backup forwarder: 172.16.1.2, Preference: 50
<snip>

こちらもsingle-active Modeとなっており、Designated forwarderがR1(172.16.1.1)となっています。
また、Statusが「Up/Blocking」となっており、R1が高優先で動作してます。

Customer Site配下のPC間で通信してみます。

//PC1
VPC1> ping 192.168.12.2

84 bytes from 192.168.12.2 icmp_seq=1 ttl=64 time=4.805 ms
84 bytes from 192.168.12.2 icmp_seq=2 ttl=64 time=3.597 ms
84 bytes from 192.168.12.2 icmp_seq=3 ttl=64 time=3.700 ms
84 bytes from 192.168.12.2 icmp_seq=4 ttl=64 time=3.766 ms
84 bytes from 192.168.12.2 icmp_seq=5 ttl=64 time=5.345 ms

VPC1> ping 192.168.12.3

84 bytes from 192.168.12.3 icmp_seq=1 ttl=64 time=4.497 ms
84 bytes from 192.168.12.3 icmp_seq=2 ttl=64 time=7.456 ms
84 bytes from 192.168.12.3 icmp_seq=3 ttl=64 time=4.497 ms
84 bytes from 192.168.12.3 icmp_seq=4 ttl=64 time=3.491 ms
84 bytes from 192.168.12.3 icmp_seq=5 ttl=64 time=3.164 ms

今回のゴールである、拠点間でのPing疎通が無事できました!やったー!!

もうちょっと詳しく見ていきます。
まず、各PCのMAC Address情報は以下の通りです。

ホスト名 IP Address MAC Address
PC 1 192.168.12.1 00:50:79:66:68:09
PC 2 192.168.12.2 00:50:79:66:68:0c
PC 3 192.168.12.3 00:50:79:66:68:0b


上記のMAC Address情報を踏まえて、R1のMAC Addressの学習情報を見ます。

//R1
lab@R1# run show evpn database
Instance: EVPN-MPLS
VLAN  DomainId  MAC address        Active source                  Timestamp        IP address
12              00:50:79:66:68:09  00:11:22:33:44:55:66:77:88:99  Feb 05 01:07:27  192.168.12.1
12              00:50:79:66:68:0b  172.16.1.4                     Feb 05 01:07:31  192.168.12.3
12              00:50:79:66:68:0c  172.16.1.3                     Feb 05 01:07:27  192.168.12.2

R1にて各PCのMAC Addressを学習していますね。
各エントリーにActive sourceにESIやPE情報が紐づいています。

また、bgp.evpn.0テーブル上には、EVPN Route Type 2にてPCのMAC/IP情報が広報されています。

//R1
lab@R1# run show route match-prefix "2:172.16.1.*" table bgp.evpn.0 | no-more

bgp.evpn.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:172.16.1.1:65001::12::00:50:79:66:68:09/304 MAC/IP
                   *[EVPN/170] 00:03:59
                       Indirect
2:172.16.1.3:65001::12::00:50:79:66:68:0c/304 MAC/IP
                   *[BGP/170] 00:03:59, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R3
2:172.16.1.4:65001::12::00:50:79:66:68:0b/304 MAC/IP
                   *[BGP/170] 00:03:55, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R4
2:172.16.1.1:65001::12::00:50:79:66:68:09::192.168.12.1/304 MAC/IP
                   *[EVPN/170] 00:03:59
                       Indirect
2:172.16.1.3:65001::12::00:50:79:66:68:0c::192.168.12.2/304 MAC/IP
                   *[BGP/170] 00:03:59, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R3
2:172.16.1.4:65001::12::00:50:79:66:68:0b::192.168.12.3/304 MAC/IP
                   *[BGP/170] 00:03:55, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R4


Customer Site間の疎通は無事できました。が、パケットは一体どうIPルーティングとLabel Switchingされて届いてるのでしょう?
せっかくなので、ルーティングテーブルとキャプチャーしたICMP Echo Requestパケットを詳しく見ていきます。

まずはPC1~R1間のパケットを見ます。

普通のL2ヘッダー+L3ヘッダーなパケットですね。

このパケットがR1に届いた際のパケット転送動作を見ます。
まず、EVPN-MPLSなので転送はMPLS、つまりLabel Switchingで転送されます(転送用のLabelをTransport Labelと言います)
該当するルーティングエントリーを見ます。

//R1
lab@R1# run show route table EVPN-MPLS.evpn.0 match-prefix "2:*192.168.12.2"

EVPN-MPLS.evpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:172.16.1.3:65001::12::00:50:79:66:68:0c::192.168.12.2/304 MAC/IP
                   *[BGP/170] 00:05:35, localpref 100, from 172.16.1.7
                      AS path: I, validation-state: unverified
                    >  to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R3

「to 10.1.15.5 via ge-0/0/0.0, label-switched-path R1-to-R3」なので、RSVPのPathを使ってR5へ転送します。
具体的なLabelを確認します。

//R1
lab@R1# run show route table inet.3 label-switched-path R1-to-R3 extensive | grep "Label operation"
                Label operation: Push 299888

「299888」がStackされる動作となってますね。

また、EVPNはVPN Labelが付与されます。
上述の「Transport Label」「VPN Label(Service Label)」の関係性は、EVPN-MPLS(やL2VPNやL3VPN)を理解する上でかなり重要です。
この辺の説明を見るとわかりやすいです。

具体的なLabelを確認します。
該当エントリーの「Route Label」の値がStackされます。

//R1
lab@R1# run show route table EVPN-MPLS.evpn.0 match-prefix "2:*192.168.12.2" extensive | grep "Route Label"
                Route Label: 299776

以上より、R1にてTransport Labelは「299888」、VPN Labelは「299776」がStackされる動作となっています。

実際にR1の送出パケットを確認します。

ルーティングテーブルのとおり、L2フレームにLabel「299888」「299776」がStackされてパケットを送出しています。

続いてR5のパケット転送動作を見ます。
Lebel「299888」をlookupするので、該当エントリーを確認します。

//R5
lab@R5# run show route label 299888

mpls.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299888             *[RSVP/7/1] 01:24:25, metric 1
                    >  to 10.1.56.6 via ge-0/0/5.0, label-switched-path R1-to-R3

[edit]
lab@R5# run show route label 299888 extensive | grep "Label operation"
                Label operation: Swap 299888

Label「299888」から「299888」へSwapして10.1.56.6(R6)へ転送する動作となっています。
ようするにほぼ変わらんですね(OuterなSrc/Dst MAC AddressとMPLS TTLだけ変わる)

実際にR5の送出パケットを確認します。

引き続き、Label「299888」「299776」がStackされてパケットを送出しています。

続いてR6のパケット転送動作を見ます。
Lebel「299888」をlookupするので、該当エントリーを確認します。

//R6
lab@R6# run show route label 299888

mpls.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299888             *[RSVP/7/1] 01:27:08, metric 1
                    >  to 10.1.35.3 via ge-0/0/0.0, label-switched-path R1-to-R3
299888(S=0)        *[RSVP/7/1] 01:27:08, metric 1
                    >  to 10.1.35.3 via ge-0/0/0.0, label-switched-path R1-to-R3

[edit]
lab@R6# run show route label 299888 extensive | grep "Label operation"
                Label operation: Pop
                Label operation: Pop

エントリーが二つありますね。「299888」はOuter(一番上)なLabelなのでS=0の方になります。つまり下のエントリーです。
(どっちも同じですが)Popとなりますので、「299888」は外されて10.1.35.3(R3)へ転送する動作となります。
ちなみにこれはPHPの動作となります。詳しくはググってください。

実際にR6の送出パケットを確認します。

ちゃんとLabel「299888」が外されていますね。

そしてR3のパケット転送動作を見ます。
Label「299776」をLookupするので、該当エントリーを確認します。

//R3
lab@R3# run show route label 299776

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299776             *[EVPN/7] 00:25:16, routing-instance EVPN-MPLS, route-type Ingress-MAC, vlan-id 12
                       to table EVPN-MPLS.evpn-mac.0

「EVPN-MPLS.evpn-mac.0」を参照するような動作になっています。これは自身の対象のrouting-instanceを見るようです。
おそらく設定したrouting-instanceに紐づいてるインターフェイスからパケットが送出される動作となるでしょう(適当な推測)

R3~PC2間のパケットを確認します。

ちゃんとPC1からのICMP Echo Requestパケットが確認できました!
Lebelが外されて、PC1とPC2的には同一Networkな感じで通信できそうですね!!

という訳で今回はEVPN-MPLSによるSite間の通信までできました!!!
次回は異なるNetworkとの通信をしてみたいと思います!!!

ここまでお読みくださり、ありがとうございました!!!

3. 参考資料

Juniper Documentation - EVPN User Guide - EVPN-MPLS セクションwww.juniper.net

vJunosでLDPを動かしてみた。 ~その2~

前回に引き続き、vJunosでMPLS周りを検証したいと思います。
今回は、前回のトポロジーと設定を引き継ぎ、6PEによるIPv6 over IPv4を試してみます。
6PEとは、IPv6が動いていないMPLSネットワークを経由してIPv6ネットワーク同士の通信を実現する技術です。
この説明がメッチャわかりやすいです。
今回のトポロジーでは、CE Site1(R1)およびSite2(R7)にはIPv6のLoopback Addressが付与されてますが、疑似SP網(R2~R6)にはIPv6 Addressが付与されてません。そんな条件下でもCE Site間でIPv6が通信できる技術になります。
ネット上に例がないので、書き記します(果たしてテレコム/ISPIPv4/IPv6 Dual Stackになっている今、需要はあるのか…)

1. MPLS LDP - 6PE 構成

前回と同様なので割愛します。前回の説明を見てください。
トポロジー再掲しときます。

キモとしては疑似SP網内ではIPv6 Addressは付与していない点でしょうか。

2. MPLS LDP - 6PE 設定

それでは設定していきます。
疑似SP網内で6PEを有効にするため、設定するRouterはR2~R6になります。
順を追って説明した方がわかりやすいので、少しずつ設定と確認をしたいと思います。
(最後に、機器ごとのconfigをまとめて記載します)

まず、CE Site1の経路情報(R1のIPv6 Loopback Address(3fff::1/128))を考えます。
R2は既にR1から3fff::1/128の経路情報を受信しているため、この経路情報のProtocol next hopを自身にしてRoute-Reflector(RR)なR6に広報する必要があります。
そのため、まず「family inet6 labeled-unicast」コマンドでMP-BGPにてIPv6 Prefixを送受信できるようにします。

//R2
set protocols bgp group INTERNAL family inet6 labeled-unicast explicit-null
//R6
set protocols bgp group INTERNAL family inet6 labeled-unicast explicit-null

explicit-nullオプションは、IPv6通信を行う際に必須となるLabel 2を強制的に付与させる設定となります。
(後ほど詳しく説明します)

R2にてR6へ広報しているか確認します。

//R2
lab@R2# run show route advertising-protocol bgp 172.16.1.6    

inet6.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             Self                         100        65001 I

R6へ3fff::1/128を広報できました。

R6で受信しているか確認します。

//R6
lab@R6# run show route receive-protocol bgp 172.16.1.2    

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)

inet6.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

おや、経路情報が出てきません…。

詳しく見ていきます。

//R6
lab@R6# run show route receive-protocol bgp 172.16.1.2 hidden    

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)

inet6.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  3fff::1/128             ::ffff:172.16.1.2            100        65001 I

[edit]
lab@R6# run show route 3fff::1/128 hidden extensive    

inet6.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)
3fff::1/128 (1 entry, 0 announced)
         BGP    Preference: 170/-101
                Next hop type: Unusable, Next hop index: 0
<snip>
                        Protocol next hop: ::ffff:172.16.1.2 ResolvState: PnhUnresolv
<snip>

3fff::1/128のProtocol next hopは(RFC4291で定めてる)IPv4-Mapped IPv6 Addressな「::ffff:172.16.1.2」として広報しており、このAddressの解決ができていないようです。
なので何らかの形でルーティングテーブルにこの「::ffff:172.16.1.2」をエントリーする必要があります。
そして、この「::ffff:172.16.1.2」はMPLSによるパケット転送対象なnext-hopとするため、inet.3のIPv6版なinet6.3テーブルにエントリーする必要があります。

これらを実現する設定が「set protocols mpls ipv6-tunneling」コマンドになります。
このコマンドによって、inet.3テーブルにエントリーされているIPv4 AddressをMappedしたIPv6 Addressとしてinet6.3テーブルにインストールします。
ですが今はR6はMPLSを有効にしていないため、そもそもinet.3テーブルがありません。
なので、併せてMPLS(LDP)を有効にします。(R6の物理接続)対向のR3のIFでもMPLSとLDPを有効にします。

//R3
set interfaces ge-0/0/6 unit 0 family mpls
set protocols mpls interface ge-0/0/6.0
set protocols ldp interface ge-0/0/6.0
//R6
set interfaces ge-0/0/1 unit 0 family mpls
set protocols mpls interface ge-0/0/1.0
set protocols ldp interface ge-0/0/1.0
set protocols mpls ipv6-tunneling


再度、R6にて確認します。

//R6
lab@R6# run show route receive-protocol bgp 172.16.1.2    

inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             ::ffff:172.16.1.2            100        65001 I

inet6.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

Protocol next hop解決され、有効な経路情報として受信できました!

詳しく確認します。

//R6
lab@R6# run show route 3fff::1/128 extensive              

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
3fff::1/128 (1 entry, 1 announced)
TSI:
KRT in-kernel 3fff::1/128 -> {indirect(1048574)}
        *BGP    Preference: 170/-101
<snip>
                Protocol next hop: ::ffff:172.16.1.2
<snip>

lab@R6# run show route ::ffff:172.16.1.2 

inet6.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::ffff:172.16.1.2/128
                   *[LDP/9] 00:06:33, metric 1
                    >  to 10.1.36.3 via ge-0/0/1.0, Push 299776

lab@R6# run show route 3fff::1/128                        

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3fff::1/128        *[BGP/170] 00:05:26, localpref 100, from 172.16.1.2
                      AS path: 65001 I, validation-state: unverified
                    >  to 10.1.36.3 via ge-0/0/1.0, Push 2, Push 299776(top)

まず「run show route 3fff::1/128 extensive」コマンド結果より、Protocol next hopは「::ffff:172.16.1.2」となっていることが確認できます。
そして「run show route ::ffff:172.16.1.2」コマンド結果より、::ffff:172.16.1.2はinet6.3にエントリーされています。
その結果「run show route 3fff::1/128 」コマンドの結果のとおり、このAddres宛は「Push 2, Push 299776(top)」として、MPLSにてパケット転送されるようになりました。

次に、この経路情報をR5に広報する必要があります。
先ほどと同様の考えで、R5にて「family inet6 labeled-unicast」と「set protocols mpls ipv6-tunneling」を設定する必要があります。

//R5
set protocols mpls ipv6-tunneling
set protocols bgp group INTERNAL family inet6 labeled-unicast explicit-null


R5で確認します。

//R5
lab@R5# run show route receive-protocol bgp 172.16.1.6 

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)

inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             ::ffff:172.16.1.2            100        65001 I

lab@R5# run show route ::ffff:172.16.1.2 

inet6.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::ffff:172.16.1.2/128
                   *[LDP/9] 00:03:34, metric 1
                    >  to 10.1.45.4 via ge-0/0/0.0, Push 299776

inet6.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

lab@R5# run show route 3fff::1/128 

inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3fff::1/128        *[BGP/170] 00:02:23, localpref 100, from 172.16.1.6
                      AS path: 65001 I, validation-state: unverified
                    >  to 10.1.45.4 via ge-0/0/0.0, Push 2, Push 299776(top)

「run show route receive-protocol bgp 172.16.1.6 」コマンド結果より、3fff::1/128の経路情報をR6から受信し、
「run show route ::ffff:172.16.1.2」コマンド結果より、::ffff:172.16.1.2がinet6.3にエントリーされており、
「run show route 3fff::1/128 」コマンド結果より、3fff::1宛のパケットについて、MPLSによって(LabelがPushされて)転送されるのが確認できます。

最後にR5よりR7へ3fff::1/128の経路情報を広報し、R7にエントリーがあるか確認します。

//R5
lab@R5# run show route advertising-protocol bgp 2001:db8:1:57::7    

inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             Self                                    65001 I
//R7
lab@R7# run show route receive-protocol bgp 2001:db8:1:57::5 

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             2001:db8:1:57::5                        65002 65001 I

[edit]
lab@R7# run show route 3fff::1/128 

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3fff::1/128        *[BGP/170] 00:11:09, localpref 100
                      AS path: 65002 65001 I, validation-state: unverified
                    >  to 2001:db8:1:57::5 via ge-0/0/0.0

R7に3fff::1/128の経路情報が載ってます!
CE Site2からCE site1へのIPv6通信はできそうです。
…と言いたいところですが、実はこれではまだR7から3fff::1宛のパケットはR1に届きません。
具体的には、R2より3fff::1宛のパケットをR1へルーティングしてくれません。
これは、Label 2が付与されている場合はIPv6パケットして扱っており、MPLSを動かしている物理IFにてinet6を有効にする必要があるためです。
Web Documentにも以下の記載があります。

In addition to configuring the family inet6 statement on all the CE router–facing interfaces, you must also configure the statement on all the core-facing interfaces running MPLS. Both configurations are necessary because the router must be able to process any IPv6 packets it receives on these interfaces. You should not see any regular IPv6 traffic arrive on these interfaces, but you will receive MPLS packets tagged with Label 2. Even though Label 2 MPLS packets are sent in IPv4, these packets are treated as native IPv6 packets.

これはとんだ罠っすね…。
なので、R2のge-0/0/1でinet6を有効にします。

//R2
set interfaces ge-0/0/1 unit 0 family inet6

これでCE Site1の経路情報の広報に関わる設定は完了です。

CE Site2(R7のIPv6 Loopback Address(3fff::7/128))の経路情報の広報に関わる設定についても、同様の考えで設定を追加します。

//R2
set protocols mpls ipv6-tunneling
//R4
set interfaces ge-0/0/6 unit 0 family mpls
set protocols mpls interface ge-0/0/6.0
set protocols ldp interface ge-0/0/6.0
//R5
set interfaces ge-0/0/0 unit 0 family inet6
//R6
set interfaces ge-0/0/2 unit 0 family mpls
set protocols mpls interface ge-0/0/2.0
set protocols ldp interface ge-0/0/2.0

以上の設定でCE Site間でIPv6通信ができるようになります。

…が、またここで罠があります。
前回設定したIPv4の通信ができなくなっています。
具体的にはR2とR5がIPv6 Prefixしか広報しない動作になっています。

//R2
lab@R2# run show route advertising-protocol bgp 172.16.1.6

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             Self                         100        65001 I
//R5
lab@R5# run show route advertising-protocol bgp 172.16.1.6

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::7/128             Self                         100        65007 I

これは「family inet6 labeled-unicast」コマンドを設定したために、Label付きのIPv6の経路情報のみ送受信する動作に変わってしまったためです。
なので、IPv4の経路情報も送受信する設定を追加します。
(受信時も設定は必要なのでR6にも投入します)

//R2
set protocols bgp group INTERNAL family inet unicast
//R5
set protocols bgp group INTERNAL family inet unicast
//R6
set protocols bgp group INTERNAL family inet unicast

これで前回同様にR1とR7のIPv4 Loopback Address情報も広報するようになります。

念のため確認します。

//R2
lab@R2# run show route advertising-protocol bgp 172.16.1.6

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           Self                         100        65001 I

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             Self                         100        65001 I

lab@R2# run show route receive-protocol bgp 172.16.1.6

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.7/32           172.16.1.5                   100        65007 I

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::7/128             ::ffff:172.16.1.5            100        65007 I
//R5
lab@R5# run show route advertising-protocol bgp 172.16.1.6

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.7/32           Self                         100        65007 I

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::7/128             Self                         100        65007 I

lab@R5# run show route receive-protocol bgp 172.16.1.6

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           172.16.1.2                   100        65001 I

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             ::ffff:172.16.1.2            100        65001 I

inet6.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

R2とR5はそれぞれIPv4IPv6の経路情報を広報し、かつR6から対向のCE Siteの経路情報を受信していますね。

これで設定は以上になります。

最後に、今回投入した設定を機器ごとに載せておきます。
一気に設定投入したい時のコピペ用にお使いください。

//R2
set protocols mpls ipv6-tunneling
set interfaces ge-0/0/1 unit 0 family inet6
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family inet6 labeled-unicast explicit-null
//R3
set interfaces ge-0/0/6 unit 0 family mpls
set protocols mpls interface ge-0/0/6.0
set protocols ldp interface ge-0/0/6.0
//R4
set interfaces ge-0/0/6 unit 0 family mpls
set protocols mpls interface ge-0/0/6.0
set protocols ldp interface ge-0/0/6.0
//R5
set protocols mpls ipv6-tunneling
set interfaces ge-0/0/0 unit 0 family inet6
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family inet6 labeled-unicast explicit-null
//R6
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family mpls
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ldp interface ge-0/0/1.0
set protocols ldp interface ge-0/0/2.0
set protocols bgp group INTERNAL family inet unicast
set protocols bgp group INTERNAL family inet6 labeled-unicast explicit-null
set protocols mpls ipv6-tunneling

3. MPLS LDP - 6PE 動作確認

では実際に動作を確認します。改めて各種showコマンドの結果も見ていきます。CE Site1(R1)からCE Site2(R7)方向を確認します。
基本的な観点は前回と同様です。
R1からR7へのパケットは
・R2はinet6.3テーブルを参照してShimヘッダーを二重に挿入してR3へ転送
・R3はmpls.0テーブルを参照してLabelをSwapしてR4へ転送
・R4はmpls.0テーブルを参照して(PHP動作にて)Shimヘッダーを1つPopしてR5へ転送
・R5はShimヘッダーをPopしてinet6.0テーブルを参照して(宛先 IPv6 Addressによって)R7へ転送
といった動作となります。
前回と異なる点はR2は二重にShimヘッダーを挿入し、R5でShimヘッダーを外します。
(なんで二重かはおいおい説明します…)

ではR2から見ていきます。

//R2
lab@R2# run show route 3fff::7

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3fff::7/128        *[BGP/170] 00:20:16, localpref 100, from 172.16.1.6
                      AS path: 65007 I, validation-state: unverified
                    >  to 10.1.23.3 via ge-0/0/1.0, Push 2, Push 299808(top)

lab@R2# run show route ::ffff:172.16.1.5

inet6.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::ffff:172.16.1.5/128
                   *[LDP/9] 00:20:49, metric 1
                    >  to 10.1.23.3 via ge-0/0/1.0, Push 299808

ルーティングテーブルを確認すると、3fff::7(R7のLoopback Address)宛は「Push 2, Push 299808(top)」としてパケットを10.1.23.3(R3)へ転送する様になっています。
この「Push 2, Push 299808(top)」はLabelが二重に付くことを意味します。
実際にR1からR7へPingを飛ばしてR2-R3間のパケットキャプチャーを見てみます。

ルーティングテーブルのとおり、Label 299808とLabel 2が挿入されています。

次にR3を見ていきます。

//R3
lab@R3# run show route label 299808

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299808             *[LDP/9] 09:15:05, metric 1
                    >  to 10.1.34.4 via ge-0/0/1.0, Swap 299808

(Label値は一緒ですが)Labe 299808をLabel 299808へSwapして10.1.34.4(R4)へ転送する様になっています。

実際にR3-R4間のパケットキャプチャーを見てみます。

(さっきとほぼ変わりませんが)ルーティングテーブルのとおり、Label 299808が付与されています。Label 2はそのまま残っています。
R4へ転送されてるので問題ありませんね。

次にR4を見ていきます。

//R4
lab@R4# run show route label 299808

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299808             *[LDP/9] 09:20:50, metric 1
                    >  to 10.1.45.5 via ge-0/0/1.0, Pop
299808(S=0)        *[LDP/9] 09:20:50, metric 1
                    >  to 10.1.45.5 via ge-0/0/1.0, Pop

Label 299808は二種類あります。今回のパケットのLebel 299808のBottom of Stackビットは0なので後者のエントリーが選択されます(どっちもPop処理ですが)
※Label 2があるのでBottom of Stackではない
Label 299808なShimヘッダーは外され10.1.45.5(R5)へ転送される様になっています。

実際にR4-R5間のパケットキャプチャーを見てみます。

Label 299808なShimヘッダーは外されてます。
また、R5へ転送されてるので問題ありませんね。

最後にR5を見ます。R5で受信時ではLabel 2なShimヘッダーが付いてるため、まずmpls.0テーブルを確認します。

//R5
lab@R5# run show route label 2

mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2                  *[MPLS/0] 09:34:45, metric 1
                       to table inet6.0
2(S=0)             *[MPLS/0] 09:34:45, metric 1
                       to table mpls.0

また二種類ありますね。Bottom of Stackビットは1なので前者のエントリーが選択されます。
エントリー内容を見ると「to table inet6.0」と表示されています。
これは「inet6.0テーブルをlookupしてルーティングをしなさい」と命令してることを意味します。
6PE使用時においては明示的にinet6.0テーブルへのlookupを行う様にするため、このようにLabel 2を付ける必要があります。
(パケットキャプチャーのとおり、Label 2は「IPv6 Explicit NULL」LabelとしてRFC3032で定義されてます。
また前述のとおり、このLabel値が付いてるパケットはIPv6パケットとして処理されるため、物理IFにinet6が必要になります)
なので、6PEではIngress LERでLabelを二重に挿入してパケット転送する約束となっています。
(Ingress LERで「各Routerでパケット転送する用のLabel」と「Egress LERでIPv6ルーティングテーブルを参照する命令用のLabel」を付ける、というイメージです)

念のためR5のinet6.0テーブルも見ましょう。

//R5
lab@R5# run show route 3fff::7

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3fff::7/128        *[BGP/170] 09:54:26, localpref 100
                      AS path: 65007 I, validation-state: unverified
                    >  to 2001:db8:1:57::7 via ge-0/0/1.0

BGPでの広報によってR7(2001:db8:1:57::7)へ転送する様になっていますね。
これでCE Site1からCE Site2方向は問題無さそうです。

参考までに、CE Site2からCE Site1方向のルーティングテーブルも確認します。
見かたは一緒なので、説明は省略します。

//R5
lab@R5# run show route 3fff::1

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3fff::1/128        *[BGP/170] 01:15:27, localpref 100, from 172.16.1.6
                      AS path: 65001 I, validation-state: unverified
                    >  to 10.1.45.4 via ge-0/0/0.0, Push 2, Push 299776(top)
//R4
lab@R4# run show route label 299776

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299776             *[LDP/9] 09:59:23, metric 1
                    >  to 10.1.34.3 via ge-0/0/0.0, Swap 299776
//R3
lab@R3# run show route label 299776

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299776             *[LDP/9] 10:02:27, metric 1
                    >  to 10.1.23.2 via ge-0/0/0.0, Pop
299776(S=0)        *[LDP/9] 10:02:27, metric 1
                    >  to 10.1.23.2 via ge-0/0/0.0, Pop
//R2
lab@R2# run show route label 2

mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2                  *[MPLS/0] 10:09:25, metric 1
                       to table inet6.0
2(S=0)             *[MPLS/0] 10:09:25, metric 1
                       to table mpls.0

lab@R2# run show route 3fff::1

inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3fff::1/128        *[BGP/170] 10:09:29, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    >  to 2001:db8:1:12::1 via ge-0/0/0.0

R7から3fff::1宛もMPLSによってR1へパケット転送できそうですね。

最後にCE Site間でIPv6 Pingが通ることを改めて確認します。
ついでにIPv4 Pingも通ることも確認します。

//R1
lab@R1# run ping 3fff::7 source 3fff::1 rapid
PING6(56=40+8+8 bytes) 3fff::1 --> 3fff::7
!!!!!
--- 3fff::7 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 2.719/3.019/3.294/0.185 ms

lab@R1# run ping 172.16.1.7 source 172.16.1.1 rapid
PING 172.16.1.7 (172.16.1.7): 56 data bytes
!!!!!
--- 172.16.1.7 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.863/3.260/3.582/0.244 ms

はい、無事にIPv6 Over IPv4な環境でIPv6 PingIPv4 Pingが飛びました!
今回は以上になります。

今回、二回に渡ってMPLSの検証を行いました。
MPLSのLabel配布プロトコルは(今回使った)LDPの他にもRSVPがありますが、パケット転送のテーブルの確認方法は一緒です!!
ぜひ参考にしてください!!

ここまで読んでくださりありがとうございました!!!!

4. 参考資料

MPLS JAPAN 2008 - MPLS-IXでの6PE運用
Juniper Documentation - MPLS Applications User Guide - IPv6-over-Ipv4 Tunnelswww.juniper.net

vJunosでLDPを動かしてみた。 ~その1~

今回から二回に渡り、vJunos-routerを使ってLDPによるMPLSの検証をしたいと思います。
今回の「その1」はLDPまで設定して、MPLSによるIPv4パケット転送を確認します。
次回の「その2」は6PEを使ったIPv6 over IPv4を確認したいと思います。

主にJunosの設定と確認について書き記します。
例によって用語の詳しい説明は行いません。わからない用語は各自でググってください。

1. MPLS LDP 構成

トポロジーは以下の通りです。

MPLSを動かすネットワーク(疑似Service-Provider(疑似SP)網)を中心に、Customer Edge(CE)なSiteを2つ用意します。
疑似SP網でMPLSにてパケット転送を行った上で、CE RouterのLoopback Address間で通信できることがゴールとなります。
CEとProvider Edge(PE) RouterでIPv4IPv6によるeBGP Peeringを行います(IPv6によるCE間通信を行うのは次回ですが)
また、疑似SP網内はRoute-Reflector(RR)によってBGPの経路を広報します。

2-1. MPLS LDP - OSPF 設定・確認

それでは設定していきます。
IP(v4、v6) Addressの設定は完了していることとします。
まず、疑似SP網内でUnderlayとなるOSPFを設定し、R2~R6のLoopback Addressをお互い広報します。

//R2
set routing-options router-id 172.16.1.2
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R3
set routing-options router-id 172.16.1.3
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/6.0
//R4
set routing-options router-id 172.16.1.4
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/6.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
//R5
set routing-options router-id 172.16.1.5
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
//R6
set routing-options router-id 172.16.1.6
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0

OSPF設定で特筆すべき点は…特にないですw

R2~R6でお互いのLoopback Addressを学習できてるか確認します。
念のため、OSPFを動かしているIFでAdjacencyが確立してるかも見ましょう。
BlogではR6のみ確認します(実際はR2~R5でも確認してます)

//R6
lab@R6# run show ospf neighbor
Address          Interface              State           ID               Pri  Dead
10.1.36.3        ge-0/0/1.0             Full            172.16.1.3       128    31
10.1.46.4        ge-0/0/2.0             Full            172.16.1.4       128    34

lab@R6# run show route protocol ospf 172.16.1/24

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.2/32      *[OSPF/10] 00:05:09, metric 2
                    >  to 10.1.36.3 via ge-0/0/1.0
172.16.1.3/32      *[OSPF/10] 00:05:09, metric 1
                    >  to 10.1.36.3 via ge-0/0/1.0
172.16.1.4/32      *[OSPF/10] 00:04:59, metric 1
                    >  to 10.1.46.4 via ge-0/0/2.0
172.16.1.5/32      *[OSPF/10] 00:04:59, metric 2
                    >  to 10.1.46.4 via ge-0/0/2.0

neighbor Stateが「Full」となっており、かつR2~R5のLoopback Addressを学習していますね。
OSPFの設定は以上です。

2-2. MPLS LDP - BGP 設定・確認

続いて、BGPの設定をしていきます。
CEなR1とR7はeBGPの設定、PEなR2とR5はeBGPとiBGPの設定、PなR3とR4はiBGPの設定、R6は文字通りRRの設定をします。
前述の通り、eBGPはIPv4に加えてIPv6でのPeeringも行います。
R1(R7)は自身のLoopback AddressをR2(R5)に広報します。
R2~R5は(R6がRRなので)R6のみとiBGP Peeringします。

//R1
set policy-options policy-statement BGP_R2_V4_EXPORT term 0011 from protocol direct
set policy-options policy-statement BGP_R2_V4_EXPORT term 0011 from route-filter 172.16.1.1/32 exact
set policy-options policy-statement BGP_R2_V4_EXPORT term 0011 then accept
set policy-options policy-statement BGP_R2_V4_EXPORT term 9991 then reject
set policy-options policy-statement BGP_R2_V6_EXPORT term 0011 from protocol direct
set policy-options policy-statement BGP_R2_V6_EXPORT term 0011 from route-filter 3fff::1/128 exact
set policy-options policy-statement BGP_R2_V6_EXPORT term 0011 then accept
set policy-options policy-statement BGP_R2_V6_EXPORT term 9991 then reject
set routing-options router-id 172.16.1.1
set routing-options autonomous-system 65001
set protocols bgp group EXTERNAL type external
set protocols bgp group EXTERNAL neighbor 10.1.12.2 export BGP_R2_V4_EXPORT
set protocols bgp group EXTERNAL neighbor 10.1.12.2 peer-as 65002
set protocols bgp group EXTERNAL neighbor 2001:db8:1:12::2 export BGP_R2_V6_EXPORT
set protocols bgp group EXTERNAL neighbor 2001:db8:1:12::2 peer-as 65002
//R2
set policy-options policy-statement BGP_R6_EXPORT term 0011 from protocol bgp
set policy-options policy-statement BGP_R6_EXPORT term 0011 then next-hop self
set policy-options policy-statement BGP_R6_EXPORT term 0011 then accept
set policy-options policy-statement BGP_R6_EXPORT term 9991 then reject
set routing-options autonomous-system 65002
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.2
set protocols bgp group INTERNAL neighbor 172.16.1.6 export BGP_R6_EXPORT
set protocols bgp group EXTERNAL type external
set protocols bgp group EXTERNAL neighbor 10.1.12.1 peer-as 65001
set protocols bgp group EXTERNAL neighbor 2001:db8:1:12::1 peer-as 65001
//R3
set routing-options autonomous-system 65002
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.3
set protocols bgp group INTERNAL neighbor 172.16.1.6
//R4
set routing-options autonomous-system 65002
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.4
set protocols bgp group INTERNAL neighbor 172.16.1.6
//R5
set policy-options policy-statement BGP_R6_EXPORT term 0011 from protocol bgp
set policy-options policy-statement BGP_R6_EXPORT term 0011 then next-hop self
set policy-options policy-statement BGP_R6_EXPORT term 0011 then accept
set policy-options policy-statement BGP_R6_EXPORT term 9991 then reject
set routing-options autonomous-system 65002
set protocols bgp group EXTERNAL type external
set protocols bgp group EXTERNAL neighbor 10.1.57.7 peer-as 65007
set protocols bgp group EXTERNAL neighbor 2001:db8:1:57::7 peer-as 65007
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.5
set protocols bgp group INTERNAL neighbor 172.16.1.6 export BGP_R6_EXPORT
//R6
set routing-options autonomous-system 65002
set protocols bgp group INTERNAL type internal
set protocols bgp group INTERNAL local-address 172.16.1.6
set protocols bgp group INTERNAL cluster 172.16.1.6
set protocols bgp group INTERNAL neighbor 172.16.1.2
set protocols bgp group INTERNAL neighbor 172.16.1.3
set protocols bgp group INTERNAL neighbor 172.16.1.4
set protocols bgp group INTERNAL neighbor 172.16.1.5
//R7
set policy-options policy-statement BGP_R5_V4_EXPORT term 0011 from protocol direct
set policy-options policy-statement BGP_R5_V4_EXPORT term 0011 from route-filter 172.16.1.7/32 exact
set policy-options policy-statement BGP_R5_V4_EXPORT term 0011 then accept
set policy-options policy-statement BGP_R5_V4_EXPORT term 9991 then reject
set policy-options policy-statement BGP_R5_V6_EXPORT term 0011 from protocol direct
set policy-options policy-statement BGP_R5_V6_EXPORT term 0011 from route-filter 3fff::7/128 exact
set policy-options policy-statement BGP_R5_V6_EXPORT term 0011 then accept
set policy-options policy-statement BGP_R5_V6_EXPORT term 9991 then reject
set routing-options router-id 172.16.1.7
set routing-options autonomous-system 65007
set protocols bgp group EXTERNAL type external
set protocols bgp group EXTERNAL neighbor 10.1.57.5 export BGP_R5_V4_EXPORT
set protocols bgp group EXTERNAL neighbor 10.1.57.5 peer-as 65002
set protocols bgp group EXTERNAL neighbor 2001:db8:1:57::5 export BGP_R5_V6_EXPORT
set protocols bgp group EXTERNAL neighbor 2001:db8:1:57::5 peer-as 65002

R1とR7はIPv4IPv6のLoopback Addressを広報する設定をしています。
R6はRoute-Reflectorとなるため、clusterオプションを設定しています。
clusterオプションが入っているgroupのネイバーはRoute-Reflector Clientとなります。
また、PEのR2とR5についてはnext-hop self設定を行い、BGPにおけるネクストホップ(Protocol next hop)を変更しています。

BGPの確認をしていきます。
まず、R2にてPeering状況と、R1よりIPv4IPv6の経路情報(Loopback Address)が広報されているか確認します。

//R2
lab@R2# run show bgp summary 
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 3 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       2          2          0          0          0          0
inet6.0              
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.1.12.1             65001         13         11       0       0        4:18 Establ
  inet.0: 1/1/1/0
172.16.1.6            65002         10         10       0       0        3:20 Establ
  inet.0: 1/1/1/0
2001:db8:1:12::1       65001         13         11       0       0        4:08 Establ
  inet6.0: 1/1/1/0

[edit]
lab@R2# run show route table inet.0 receive-protocol bgp 10.1.12.1

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           10.1.12.1                               65001 I

[edit]
lab@R2# run show route table inet6.0 receive-protocol bgp 2001:db8:1:12::1

inet6.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 3fff::1/128             2001:db8:1:12::1                        65001 I

lab@R2# run show route advertising-protocol bgp 172.16.1.6               

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           Self                         100        65001 I

「run show bgp summary 」コマンドにて10.1.12.1(R1 IPv4)、172.16.1.6(R6)、2001:db8:1:12::1(R1 IPv6)とBGPネイバーが確立(Establ)していますね。
また、「run show route table inet.0(inet6.0) receive-protocol bgp~」コマンドでR1のLoopback Address(172.16.1.1/32、3fff::1/128)の経路情報を受信していることが確認できます。
最後の「run show route table inet.0 advertising-protocol bgp~」コマンドでR6(172.16.1.6)へ(R1のIPv4 Loopback Addressな)経路情報を広報していることが確認できます。
ちなみに、この時点ではR1のIPv6 Loopback Addressは広報できません。

次に、RRであるR6を見ていきます。

//R6
lab@R6# run show bgp summary 
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 4 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.2            65002         35         32       0       0       14:08 Establ
  inet.0: 1/1/1/0
172.16.1.3            65002         35         34       0       0       14:22 Establ
  inet.0: 0/0/0/0
172.16.1.4            65002         31         30       0       0       12:36 Establ
  inet.0: 0/0/0/0
172.16.1.5            65002         30         27       0       0       11:52 Establ
  inet.0: 1/1/1/0

[edit]
lab@R6# run show route table inet.0 receive-protocol bgp 172.16.1.2 

inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           172.16.1.2                   100        65001 I

[edit]
lab@R6# run show route table inet.0 advertising-protocol bgp 172.16.1.5   

inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           172.16.1.2                   100        65001 I

R2~R5とBGPネイバーが確立していますね。
また、R2(172.16.1.2)から経路情報を受信し、「run show route table inet.0 advertising-protocol bgp~」コマンドでR5(172.16.1.5)へ広報していることが確認できます。

ちなみに、(run) show bgp neighbor~コマンドにて、対向のRouterをRoute-Reflector Clientとして見なしているか確認できます。

//R6
lab@R6# run show bgp neighbor 172.16.1.2 
Peer: 172.16.1.2+179 AS 65002  Local: 172.16.1.6+54043 AS 65002
  Group: INTERNAL              Routing-Instance: master
  Forwarding routing-instance: master  
  Type: Internal    State: Established  (route reflector client)Flags: <Sync>
<snip>


次に、R5にて確認します。

//R5
lab@R5# run show bgp summary                                 
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 3 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       2          2          0          0          0          0
inet6.0              
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.1.57.7             65007         66         64       0       0       28:15 Establ
  inet.0: 1/1/1/0
172.16.1.6            65002         63         62       0       0       27:19 Establ
  inet.0: 1/1/1/0
2001:db8:1:57::7       65007         66         63       0       0       28:04 Establ
  inet6.0: 1/1/1/0

[edit]
lab@R5# run show route receive-protocol bgp 172.16.1.6       

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           172.16.1.2                   100        65001 I

inet6.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

[edit]
lab@R5# run show route advertising-protocol bgp 10.1.57.7    

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           Self                                    65001 I

RRのR6(172.16.1.6)およびCEのR7(IPv4: 10.1.57.7 、IPv6: 2001:db8:1:57::7)とBGPネイバー確立していることが確認できます。
また、R6から経路情報を受信しており、R7へ広報していることが確認できます。

最後にR7にてR1のLoopback Addressな経路情報を受信しているか確認します。

//R7
[edit]
lab@R7# run show route receive-protocol bgp 10.1.57.5 

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.1.1/32           10.1.57.5    

lab@R7# run show route 172.16.1.1/32 

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[BGP/170] 00:45:39, localpref 100
                      AS path: 65002 65001 I, validation-state: unverified
                    >  to 10.1.57.5 via ge-0/0/0.0

R5から経路情報を受信し、ルーティングテーブルにR1のLoopback Address(172.16.1.1)がエントリーされていることが確認できました。
これで、CE Site1からの経路情報はCE Site 2へ広報されました!!

同様の観点でCE Site 2の経路情報(R7のLoopback Address)もCE Site1へ広報されているか確認する必要がありますが、今回は省略します。
この時点でR1とR7のLoopback Address間でPing疎通はできます。

//R1
lab@R1# run ping 172.16.1.7 source 172.16.1.1 rapid 
PING 172.16.1.7 (172.16.1.7): 56 data bytes
!!!!!
--- 172.16.1.7 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.876/3.212/3.877/0.355 ms

MPLSの設定をまだしていないので、疑似SP網ではIPヘッダー(宛先 IP Address)によるルーティングを行っています。

2-3. MPLS LDP - LDP 設定・確認

では、疑似SP網内でMPLSでパケット転送する設定をしていきます。
今回はLDPを使ってLabel配布を行います。

//R2
set interfaces ge-0/0/1 unit 0 family mpls
set protocols mpls interface ge-0/0/1.0
set protocols ldp interface ge-0/0/1.0
//R3
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family mpls
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/0.0
set protocols ldp interface ge-0/0/0.0
set protocols ldp interface ge-0/0/1.0
//R4
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols ldp interface ge-0/0/0.0
set protocols ldp interface ge-0/0/1.0
//R5
set interfaces ge-0/0/0 unit 0 family mpls
set protocols mpls interface ge-0/0/0.0
set protocols ldp interface ge-0/0/0.0

物理IF配下でfamily mplsを有効にして、protocols mplsとldpで対象IFを定義すればいいだけです。
わざわざfamily mplsを有効にするコマンドは必要なのか…
ちなみにMPLSで転送したいIFのみを対象とすればよいので、R6やR6間のリンクに対して設定は必要ありません。

動作確認ですが、かなりややこしいです。ある程度のBGPの知識が必要になります。
まず、各Router間でLDPネイバーが確立してるか確認します。

//R2
lab@R2# run show ldp session 
  Address                           State       Connection  Hold time  Adv. Mode
172.16.1.3                          Operational Open          23         DU
//R3
lab@R3# run show ldp session                      
  Address                           State       Connection  Hold time  Adv. Mode
172.16.1.2                          Operational Open          28         DU
172.16.1.4                          Operational Open          28         DU
//R4
lab@R4# run show ldp session 
  Address                           State       Connection  Hold time  Adv. Mode
172.16.1.3                          Operational Open          20         DU
172.16.1.5                          Operational Open          20         DU
//R5
lab@R5# run show ldp session 
  Address                           State       Connection  Hold time  Adv. Mode
172.16.1.4                          Operational Open          27         DU

「State」がOperational、「Connection 」がOpenとなっていればLDPネイバー確立しています。
R2~R5いずれも確立していますね。
続いて、LDP(MPLS)を有効にして作成されたinet.3テーブルを確認します。
inet.3テーブルはMPLSによってパケット転送を行うためのルーティングテーブルになります。
詳しい説明は後ほどします。

//R2
lab@R2# run show route table inet.3    

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.3/32      *[LDP/9] 00:18:19, metric 1
                    >  to 10.1.23.3 via ge-0/0/1.0
172.16.1.4/32      *[LDP/9] 00:17:54, metric 1
                    >  to 10.1.23.3 via ge-0/0/1.0, Push 299792
172.16.1.5/32      *[LDP/9] 00:17:24, metric 1
                    >  to 10.1.23.3 via ge-0/0/1.0, Push 299808
//R3
lab@R3# run show route table inet.3  

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.2/32      *[LDP/9] 00:23:44, metric 1
                    >  to 10.1.23.2 via ge-0/0/0.0
172.16.1.4/32      *[LDP/9] 00:23:19, metric 1
                    >  to 10.1.34.4 via ge-0/0/1.0
172.16.1.5/32      *[LDP/9] 00:22:48, metric 1
                    >  to 10.1.34.4 via ge-0/0/1.0, Push 299808
//R4
lab@R4# run show route table inet.3  

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.2/32      *[LDP/9] 00:23:39, metric 1
                    >  to 10.1.34.3 via ge-0/0/0.0, Push 299776
172.16.1.3/32      *[LDP/9] 00:23:39, metric 1
                    >  to 10.1.34.3 via ge-0/0/0.0
172.16.1.5/32      *[LDP/9] 00:23:08, metric 1
                    >  to 10.1.45.5 via ge-0/0/1.0
//R5
lab@R5# run show route table inet.3  

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.2/32      *[LDP/9] 00:23:32, metric 1
                    >  to 10.1.45.4 via ge-0/0/0.0, Push 299792
172.16.1.3/32      *[LDP/9] 00:23:32, metric 1
                    >  to 10.1.45.4 via ge-0/0/0.0, Push 299776
172.16.1.4/32      *[LDP/9] 00:23:32, metric 1
                    >  to 10.1.45.4 via ge-0/0/0.0

いずれのRouterも他のRouterのLoopback Addressを学習しています。
これはJunosの仕様で、Defaultでは自身のLoopback Address(正確にはRouter ID)に対するLabelを広報します。
BGPでの通信においてProtocol next hopの解決時、大抵はLoopback Addressであることを見越した実装となっているようです。
BGP Protocol next hopの解決時はinet.0とinet.3テーブルをlookupし、inet.3テーブルによったパケット転送を行うのであれば、定義されたLabelを付与する動作となっています。
その辺のマニアックな話はココに書いてあります(JunosにおけるMPLS動作を理解する点ではメッチャ重要だったりする…)

…まあ文章書いてる自分でも良く分からんので、動作確認しながら説明します。
前述のとおり、LDPはBGPによる通信が前提となっています。
このネットワークでは、CE Site(R1とR7のLoopback Address)間で通信する際にMPLSが使われます。
まずR2にて、CE Site2なR7宛の経路情報を見ていきます。

//R2
lab@R2# run show route 172.16.1.7              

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.7/32      *[BGP/170] 00:51:25, localpref 100, from 172.16.1.6
                      AS path: 65007 I, validation-state: unverified
                    >  to 10.1.23.3 via ge-0/0/1.0, Push 299808

エントリーの最後に「Push 299808」があり、Label 299808が付与されて転送されることが確認できます。
これは172.16.1.7/32のProtocol next hopがinet.3内のエントリーに該当するため、Label(Shimヘッダー)が付与されることを意味しています。

172.16.1.7/32の詳細を見ます。

//R2
lab@R2# run show route 172.16.1.7 extensive    

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
172.16.1.7/32 (1 entry, 1 announced)
<snip>
                Protocol next hop: 172.16.1.5
<snip>

lab@R2# run show route table inet.3 172.16.1.5 

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.5/32      *[LDP/9] 01:03:22, metric 1
                    >  to 10.1.23.3 via ge-0/0/1.0, Push 299808

Protocol next hopが172.16.1.5(next-hop self設定したR5)となっており、このAddressはinet.3テーブルにエントリーされています。
そのため、LDPによって定義されたLabel 299808が付与されて10.1.23.3(R3)へパケット転送を行う動作となります。
実際にR1からR7へPingを飛ばし、R2とR3間のパケットキャプチャーも見てみます。

R7宛なEcho Requestパケットに、Shimヘッダー(MPLS Header)が挿入されてR3へ転送されています。
R2のルーティングテーブルに沿ってLabel 299808となっています。

続いて、R3のルーティングテーブルを確認します。
R3はShimヘッダーが付与された状態でパケットを受信するため、見るべきテーブルはmpls.0テーブルになります。
MPLSで通信すると言っても、Routerによって確認するテーブルが異なります(この辺がMPLSを理解する上で、とっつきにくい箇所だと思っている…)

//R3
lab@R3# run show route table mpls.0 | no-more

mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 06:03:57, metric 1
                       to table inet.0
0(S=0)             *[MPLS/0] 06:03:57, metric 1
                       to table mpls.0
1                  *[MPLS/0] 06:03:57, metric 1
                       Receive
2                  *[MPLS/0] 06:03:57, metric 1
                       to table inet6.0
2(S=0)             *[MPLS/0] 06:03:57, metric 1
                       to table mpls.0
13                 *[MPLS/0] 06:03:57, metric 1
                       Receive
299776             *[LDP/9] 06:03:56, metric 1
                    >  to 10.1.23.2 via ge-0/0/0.0, Pop
299776(S=0)        *[LDP/9] 06:03:56, metric 1
                    >  to 10.1.23.2 via ge-0/0/0.0, Pop
299792             *[LDP/9] 06:03:31, metric 1
                    >  to 10.1.34.4 via ge-0/0/1.0, Pop
299792(S=0)        *[LDP/9] 06:03:31, metric 1
                    >  to 10.1.34.4 via ge-0/0/1.0, Pop
299808             *[LDP/9] 06:03:00, metric 1
                    >  to 10.1.34.4 via ge-0/0/1.0, Swap 299808

一番下に299808がありますね。
エントリーを見ると「Swap 299808」より(同じLabel値ですが)299808にSwapし、「to 10.1.34.4」よりこのAddressを持つR4へ転送することがわかります。

R3とR4間のパケットキャプチャーも見てみます。

(パッと見、さっきとほぼ一緒ですが)R3のmpls.0テーブルのとおり、Label 299808にてR4に転送されています。

続いてR4のルーティングテーブルを確認します。
Shimヘッダーが付与されているのでmpls.0テーブルを見ます。
ちなみに、「show route label xxx」コマンドで対象のLabel値のエントリーのみ表示されます。

//R4
lab@R4# run show route label 299808

mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299808             *[LDP/9] 00:00:45, metric 1
                    >  to 10.1.34.3 via ge-0/0/0.0, Pop
299808(S=0)        *[LDP/9] 00:00:45, metric 1
                    >  to 10.1.34.3 via ge-0/0/0.0, Pop

Label 299808は2種類ありますね。
今回のパケットのBottom of Stackビットは1なので前者のエントリーが選択されます(どっちもPop処理ですが)
Popなので、Shimヘッダーを外してL2ヘッダー && L3ヘッダーな構造のパケットへと戻します。
これはPHP(Penultimate Hop Poping)という動作になります。
(R4は(MPLSネットワークの最後のRouterとなる)Egress LERなR5の1つ手前のRouterなので、Shimヘッダーが外されます。
PHPについては色々なWebページで説明があるので、詳しくはググってください)

R4とR5間のパケットキャプチャーも見てみます。

Shimヘッダーが外されてR5に転送されています。

後はR5にて宛先 IP Addressを見てパケットがR7へルーティングされる…といった具合でR7へ届く動作となります。
R7からR1へのEcho Replyも同様に
・R5はinet.3テーブルを参照してShimヘッダーを挿入してR4へ転送
・R4はmpls.0テーブルを参照してLabelをSwapしてR3へ転送
・R3はmpls.0テーブルを参照して(PHP動作にて)ShimヘッダーをPopしてR2へ転送
・R2はinet.0テーブルを参照して(宛先 IP Addressによって)R1へ転送
といった動作になります。
(Shimヘッダーを挿入する)Ingress LERはinet.3テーブルを参照し、他のMPLS enableなRouterはmpls.0テーブルを参照してパケット転送する…というところがミソでしょうか。

最後にCE Site間でPingが通ることを改めて確認します。
なお、TracerouteをすることによってLabel値がわかります。

//R1
lab@R1> ping 172.16.1.7 source 172.16.1.1 rapid
PING 172.16.1.7 (172.16.1.7): 56 data bytes
!!!!!

lab@R1> traceroute 172.16.1.7 source 172.16.1.1
traceroute to 172.16.1.7 (172.16.1.7) from 172.16.1.1, 30 hops max, 52 byte packets
 1  10.1.12.2 (10.1.12.2)  1.244 ms  0.882 ms  0.805 ms
 2  10.1.23.3 (10.1.23.3)  1.847 ms  1.592 ms  1.778 ms
     MPLS Label=299840 CoS=0 TTL=1 S=1
 3  10.1.34.4 (10.1.34.4)  2.082 ms  2.124 ms  1.658 ms
     MPLS Label=299776 CoS=0 TTL=1 S=1
 4  10.1.45.5 (10.1.45.5)  2.580 ms  2.597 ms  3.026 ms
 5  172.16.1.7 (172.16.1.7)  3.607 ms  3.636 ms  4.208 ms

他ASからMPLSを使っていることがわかってしまうので、わからないようにする設定もあります。

という訳でLDPを使ったMPLSの検証が無事できました!!!
JunosにおけるLabel Switching動作の確認方法(ルーティングテーブルの追っかけ方)について、できる限り詳しく書いてみたつもりです。
用語の理解や参考資料も併用して読み進めれば、貴方も脱MPLS初心者!!

次回は続きとしてこのトポロジーにて6PEを使った通信を検証したいと思います!!!
ここまで読んでくださりありがとうございました!!!!

3. 参考資料

Juniper Documentation - MPLS Applications User Guide - LDP Overviewwww.juniper.net

Juniper Documentation - LSP Routeswww.juniper.net
NETWORK FUNTIME - JUNOS ROUTERS: WHAT DOES THE INET.3 TABLE ACTUALLY DO?www.networkfuntimes.com
JPNIC 資料 - MPLS~基礎、実現するサービス、そして最新動向~