Junosで始めるMPLS入門 その3 LDP over RSVP VPN編
前回の記事でRSVPのシグナリングと、障害発生時にバックアップのLSPに高速で切り替えるLocal Repair(Fast ReRouteの一種)の動作を確認しました。
今回はLDPを使ったネットワークの動作を確認していきたいと思いますが、RSVPより機能の少ないLDPでただラベルを配布しても面白くないので、前回利用したRSVPネットワークの上にLDPをトンネリングして通し、離れた拠点同士をVPN接続します。
LDP over RSVPと呼ばれる、昔からよくMPLSコアネットワークで使われたLDPのスケーリング手法の一つです。
これによりRSVPのメリットを享受しつつLDPのオペレーションをスケールさせる、利便性の高い?MPLSネットワークを作ることができます。
今回からIPパケットにラベルをスタックする動作が加わります。
また、L3VPNを動かすにあたってMP-BGPというBGPを拡張したVPNラベルのシグナリングを行うので事前知識が若干必要になります。
MPLSとBGPを使ったVPN技術については以下の資料に基礎的な概要が記載されています。
MPLS-VPN 基礎
検証手順
今回は、以下の順に設定を実施していきます。
- 新たにPEとCEを既存構成に接続
- PEとPでLDP neighborを確立
- Pルータ間でLDP Tunnelを確立
- PE同士でMP-iBGP接続
- PEにCEをBGPで接続、経路交換
大まかな流れは以上です。
構成
今回使用する構成は最終的に以下のようになります。
前回までの構成にエッジルータ(PE)と顧客ルータ(CE)を新たに2台ずつ接続します。
IP-VPNなどに馴染みのある人は知っていると思いますが、MPLS-VPNでは以下の用語を使います。
- P(Provider Router)
- MPLSドメインのコアとなるLSR
- 網内転送用の最上部のラベルのみ参照し転送する
- PE(Provider Edge Router)
- MPLSドメインのエッジとなるLER
- Pと複数のCEと接続する
- CEの経路をVRF毎に管理し、識別用のラベルをPush,さらに網内転送用のラベルをPushしてPに転送する
- CE(Customer Edge Router)
- 非MPLSドメインのルータ
- 何らかの方法でPEと接続する
上記の構成では、RSVPドメインのルータ(各拠点)がPになります。
LDP Tunnelingの設定
PEルータが接続されたPルータ間でLDP Tunnelingを有効にすることで、直接接続されていないPE間でLDPのパケットのやり取りが行えるようになります。
パケットヘッダがラベルになっただけで、通常のIPパケットをencap/decapするVPNと同じイメージです。
LDPの有効化
LDPドメインとなるPとPEのインターフェースでLDPを有効にします。
oot@lab-vmx01# show | compare [edit logical-systems Fukuoka protocols] + ldp { + interface all; + } [edit logical-systems Nagoya protocols] + ldp { + interface all; + } [edit logical-systems Shinagawa protocols] + ldp { + interface all; + } [edit logical-systems Toyosu protocols] + ldp { + interface all; + }
P - PE間でLDP sessionが確立されます。
root@lab-vmx01:PE1> show ldp neighbor Address Interface Label space ID Hold time 10.0.0.28 lt-0/0/0.29 10.255.255.8:0 14 10.0.0.30 lt-0/0/0.31 10.255.255.9:0 14 root@lab-vmx01:PE2> show ldp neighbor Address Interface Label space ID Hold time 10.0.0.34 lt-0/0/0.35 10.255.255.6:0 12 10.0.0.36 lt-0/0/0.37 10.255.255.7:0 11 root@lab-vmx01> show ldp session logical-system PE1 Address State Connection Hold time Adv. Mode 10.255.255.8 Connecting Opening 0 DU 10.255.255.9 Connecting Opening 0 DU root@lab-vmx01> show ldp session logical-system PE2 Address State Connection Hold time Adv. Mode 10.255.255.6 Connecting Opening 0 DU 10.255.255.7 Connecting Opening 0 DU
PルータでのLDP Tunneling
前回の記事で、Pルータである Nagoya - Shinagawa 間でRSVPでLSPを作成しました。
このパスをそのまま利用してNagoyaとShinagawaでLDPをトンネリングします。
root@lab-vmx01> show configuration logical-systems Nagoya protocols mpls label-switched-path Shinagawa to 10.255.255.7; ldp-tunneling; no-cspf; primary to_Shinagawa_ACT; secondary to_Shinagawa_STBY;
LDP Tunneling時のラベルスタック
LDP over RSVP設定時の動作を細かく見ていきます。
LDPをトンネリングしているPルータ(Nagoya-Shinagawa)間の経路を見てみます。
前回の記事で設定したRSVPのstrict pathにLDPが従っていることがわかります。
root@lab-vmx01:PE1> traceroute mpls ldp 10.255.255.11 Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16 ttl Label Protocol Address Previous Hop Probe Status 1 299856 LDP 10.0.0.28 (null) Success FEC-Stack-Sent: LDP FEC-Change-Recieved: PUSH-RSVP ttl Label Protocol Address Previous Hop Probe Status 2 299920 RSVP-TE 10.0.0.22 10.0.0.28 Success FEC-Stack-Sent: RSVP,LDP ttl Label Protocol Address Previous Hop Probe Status 3 299856 RSVP-TE 10.0.0.0 10.0.0.22 Success FEC-Stack-Sent: RSVP,LDP ttl Label Protocol Address Previous Hop Probe Status 4 299920 RSVP-TE 10.0.0.3 10.0.0.0 Success FEC-Stack-Sent: RSVP,LDP ttl Label Protocol Address Previous Hop Probe Status 5 299888 RSVP-TE 10.0.0.15 10.0.0.3 Success FEC-Stack-Sent: RSVP,LDP ttl Label Protocol Address Previous Hop Probe Status 6 3 RSVP-TE 10.0.0.19 10.0.0.15 Egress FEC-Stack-Sent: RSVP,LDP FEC-Change-Recieved: POP-RSVP ttl Label Protocol Address Previous Hop Probe Status 6 3 RSVP-TE 10.0.0.19 10.0.0.15 Success FEC-Stack-Sent: LDP ttl Label Protocol Address Previous Hop Probe Status 7 3 LDP 10.0.0.37 10.0.0.19 Egress FEC-Stack-Sent: LDP Path 1 via lt-0/0/0.29 destination 127.0.0.64
上記の結果を詳しく見ていくと、いくつか重要なポイントがあります。
trace結果の前半と後半で、以下の記述があります。
- FEC-Stack-Sent: LDP FEC-Change-Recieved: PUSH-RSVP
- FEC-Stack-Sent: RSVP,LDP FEC-Change-Recieved: POP-RSVP
これが、LDPラベルの上にRSVPラベルをPushしている動作と、Popしている動作です。
RSVP区間ではラベルが何度もSwapされますが、下層のLDPラベルはSwapもPopもされません。
最後のRSVP Egress LSR(10.0.0.19)でRSVPラベルがPopされ、LDPラベルがtopとなった状態で転送されLDPのEgress LSR(10.0.0.37)に到達するとLDPラベルもPopされIPパケットで転送されます。
IGPトラフィックのLSP転送
IGPトラフィックをLSPでフォワーディングさせるために、いくつか設定が必要です。
root@lab-vmx01> show configuration logical-systems PE1 protocols mpls traffic-engineering { mpls-forwarding; } interface all;
このオプションを使わないで対向のPE2宛に traceroute を実行するとどうなるでしょうか?
実際にやってみます。
root@lab-vmx01:PE1> traceroute 10.255.255.11 traceroute to 10.255.255.11 (10.255.255.11), 30 hops max, 48 byte packets 1 10.0.0.28 (10.0.0.28) 0.644 ms 0.506 ms 0.425 ms 2 10.0.0.22 (10.0.0.22) 0.427 ms 0.412 ms 0.393 ms MPLS Label=299920 CoS=0 TTL=1 S=1 3 10.0.0.0 (10.0.0.0) 0.374 ms 0.468 ms 0.377 ms MPLS Label=299856 CoS=0 TTL=1 S=1 4 10.0.0.3 (10.0.0.3) 0.400 ms 0.418 ms 0.384 ms MPLS Label=299920 CoS=0 TTL=1 S=1 5 10.0.0.15 (10.0.0.15) 0.402 ms 0.436 ms 0.353 ms MPLS Label=299888 CoS=0 TTL=1 S=1 6 10.0.0.19 (10.0.0.19) 0.292 ms 0.298 ms 0.300 ms 7 10.255.255.11 (10.255.255.11) 0.434 ms 0.657 ms 0.471 ms
最初のホップにラベルがついていません。
つまりLDPの区間にラベルが付かずに転送されてしまったことになります。
その後はRSVPラベルがちゃんとついていますが、なぜこうなったのでしょうか。
IGPのトラフィックがLSPを経由できていない からです。
LDPとRSVPのLSPネクストホップの情報はinet.3というテーブルに格納されます。
このテーブルを再帰解決に使用できるプロトコルはBGPだけというのがJunosのデフォルトの仕様です。
このままではIGPのトラフィックがLSPで転送できません。
この問題を解決するために、Junosにはいくつかオプションが用意されています。
- traffic-engineering bgp-igp
- Egress LSR宛のBGPとIGPトラフィックを転送するのにLSPを使用するようにします
- inet.3 tableの経路がすべてinet.0 tableに移動され、inet.3は使用できなくなります
- traffic-engineering bgp-igp-both-ribs
- bgp-igpとほとんど同じですが、inet.3 tableにも経路が残ります
- traffic-engineering mpls-forwarding
今回はmpls-forwardingを使用してみます。
root@lab-vmx01# show | compare [edit logical-systems PE1 protocols mpls] + traffic-engineering { + mpls-forwarding; + } [edit logical-systems PE2 protocols mpls] + traffic-engineering { + mpls-forwarding; + }
再度traceしてみます。
root@lab-vmx01:PE1> traceroute 10.255.255.11 traceroute to 10.255.255.11 (10.255.255.11), 30 hops max, 48 byte packets 1 10.0.0.28 (10.0.0.28) 0.896 ms 0.482 ms 0.390 ms MPLS Label=299856 CoS=0 TTL=1 S=1 2 10.0.0.22 (10.0.0.22) 0.383 ms 0.401 ms 0.367 ms MPLS Label=299920 CoS=0 TTL=1 S=0 MPLS Label=299824 CoS=0 TTL=1 S=1 3 10.0.0.0 (10.0.0.0) 0.368 ms 0.379 ms 0.360 ms MPLS Label=299856 CoS=0 TTL=1 S=0 MPLS Label=299824 CoS=0 TTL=2 S=1 4 10.0.0.3 (10.0.0.3) 0.409 ms 0.382 ms 0.368 ms MPLS Label=299920 CoS=0 TTL=1 S=0 MPLS Label=299824 CoS=0 TTL=3 S=1 5 10.0.0.15 (10.0.0.15) 0.434 ms 0.395 ms 0.362 ms MPLS Label=299888 CoS=0 TTL=1 S=0 MPLS Label=299824 CoS=0 TTL=4 S=1 6 10.0.0.19 (10.0.0.19) 0.383 ms 0.403 ms 0.377 ms MPLS Label=299824 CoS=0 TTL=1 S=1 7 10.255.255.11 (10.255.255.11) 0.404 ms 0.421 ms 0.421 ms
今度はちゃんと最初のホップでLDPラベルがPushされました。LDPラベルの後にRSVPラベルがスタックされて付いていることが確認できます。
S=1が最下層のLDPラベルです。Label=299824がPE2に到達するまで変更されていないことがわかります。
せっかくなので、inet.0 tableも確認します。
root@lab-vmx01:PE1> show route table inet.0 inet.0: 33 destinations, 36 routes (33 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 10.255.255.11/32 @[OSPF/10] 00:05:56, metric 5 > to 10.0.0.28 via lt-0/0/0.29 to 10.0.0.30 via lt-0/0/0.31 #[LDP/9] 00:05:56, metric 1 > to 10.0.0.28 via lt-0/0/0.29, Push 299856
inet.3 tableからコピーされたLSPの宛先となるホストルートがありますが、経路にあまり見慣れない記号がついているのが確認できます。
@ = Routing Use Only
# = Forwarding Use Only
これがmpls-forwardingオプションを使用した場合の特徴で、フォワーディングにのみLSPを使用します。
詳細な説明は本筋から外れるのでここではしませんが、上記の各オプションの動作の違いは異なるルーティングプロトコルで学習した経路を再配布する場合などに顕著に現れますので、経路の優先度などに注意が必要です。
詳しく知りたい人はJuniperの公式ドキュメントを参考にしてください。
PEのMP-iBGP接続
PE1 - PE2 間でiBGP接続を行うため、BGP-L3VPNの設定をします。
root@lab-vmx01:PE1> show configuration protocols bgp group PE1-to-PE2 { type internal; local-address 10.255.255.10; family inet-vpn { unicast; } neighbor 10.255.255.11; } root@lab-vmx01:PE2> show configuration protocols bgp group PE2-to-PE1 { type internal; local-address 10.255.255.11; family inet-vpn { unicast; } neighbor 10.255.255.10; }
root@lab-vmx01:PE1> show bgp summary Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.255.255.11 59105 1899 1902 0 0 14:14:37 Establ bgp.l3vpn.0: 1/1/1/0
bgp.l3vpn.0 tableでのpeerが確立されます。
これによりRSVPドメインのPルータでBGPを有効にすることなく、遠方のPE間でiBGP接続ができました。
大規模なネットワークでは、これをPE間でフルメッシュに行うことで、コアルータがBGPの経路を持たない高速なコンバージェンスが可能なネットワークを作ることができます。
この考え方をBGP Free Coreといいます。
CEとPEのBGP接続
最後に両端のPEとCEをeBGPで接続します。
PEの設定
CEの経路をVRFで管理し、RDという識別子を付けVPNv4 Prefixを生成します。
これにより複数のCEで同一prefixを広報してきてもユニークなものとして扱うことができます。
CEからeBGPで受信した経路を、iBGPで対向のPEに広報します。
root@lab-vmx01:PE1> show configuration routing-instances VPN-A { instance-type vrf; interface lt-0/0/0.32; route-distinguisher 59105:1; vrf-import VPN-A-import; vrf-export VPN-A-export; protocols { bgp { group VPN-A-CE1 { type external; peer-as 65530; neighbor 192.168.10.2; } } } } root@lab-vmx01:PE1> show configuration policy-options policy-statement VPN-A-import term a { from { protocol bgp; community VPN-A; } then accept; } term b { then reject; } root@lab-vmx01:PE1> show configuration policy-options policy-statement VPN-A-export term a { from protocol bgp; then { community add VPN-A; accept; } } term b { then reject; } root@lab-vmx01:PE1> show configuration policy-options community VPN-A members target:59105:00;
CEの設定
root@lab-vmx01:CE1> show configuration group CE1-to-PE1 { type external; export EXPORT-MY-ROUTE; neighbor 192.168.10.1 { peer-as 59105; } } routing-options { autonomous-system 65530; } root@lab-vmx01:CE2> show configuration group CE2-to-PE2 { type external; export EXPORT-MY-ROUTE; neighbor 192.168.20.1 { peer-as 59105; } } routing-options { autonomous-system 65531; }
BGP経路確認
対向のCEの経路が受信できていることが確認できます。
root@lab-vmx01:CE1> show route inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.20.254/32 *[BGP/170] 02:00:44, localpref 100 AS path: 59105 65531 I, validation-state: unverified > to 192.168.10.1 via lt-0/0/0.33 root@lab-vmx01:CE2> show route inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.10.254/32 *[BGP/170] 02:01:14, localpref 100 AS path: 59105 65530 I, validation-state: unverified > to 192.168.20.1 via lt-0/0/0.39
ラベルの3階層スタック
今回の構成ではラベルが最大3つPushされることになります。
FRR作動時にはRSVPラベルがさらにPushされ4つになります。
+--------------+------------------------+ | RSVP Label | RSVP区間の網内転送ラベル | +--------------+------------------------+ | LDP Label | 宛先のPE(FEC)のラベル | +--------------+------------------------+ | BGP-VRF Label| CEの経路を識別するラベル | +--------------+------------------------+ | IP Packet | ユーザのデータ | +--------------+------------------------+
MP-BGP/LDP/RSVP とそれぞれの区間でそのラベルしか操作されないため、途中まで同じ経路(パス)を通る通信でも、内部では論理的に分離された通信が可能です。
まとめ
- MPLSはラベルをスタックし階層構造を作ることで、顧客ごとに論理的に分離したVPN通信を実現する
- RSVPには、LSPの冗長やQoS、帯域保証の機能などがある
- LDP over RSVPを使うことで、PE間でトラフィックエンジニアリングのメリットを享受したLDPシグナリングが可能
実際には複数の顧客のCEがPEに多数接続され、もっと複雑なネットワークになります。
ですが特に難解な技術をつかっているわけではありませんし、一つ一つの設定も簡単だったと思います。
Junosの場合、inet.3/mpls.0の役割や経路・ラベルの参照方法が理解できれば苦労しません。
これらを応用すれば、IPv4のみで構成されたMPLSドメインでIPv6通信を通すといったことも可能になります。
入門というタイトルなので扱いませんでしたが、最近ユースケースや課題が議論されている以下のような技術もMPLS関連で後で簡単に記事にしようと思います。
- Inter-AS Option B/C
- BGP-LU
- PCEP
- EVPN-MPLS(Data Plane)
etc...
これらは使い方によってはとてもおもしろいことができます。
MPLSとBGPは使い古されたプロトコルですが、現在でもアドレスファミリやTLVの拡張が頻繁に行われ、伝搬できる情報の種類を増やし続けています。
新しい技術に触れることも大切ですが、古くからある基礎に振り返ってみるのも悪くないのではと思いまとめてみました。
おわり