COGNITIVE

Networking

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 基礎

検証手順

今回は、以下の順に設定を実施していきます。

  1. 新たにPEとCEを既存構成に接続
  2. PEとPでLDP neighborを確立
  3. Pルータ間でLDP Tunnelを確立
  4. PE同士でMP-iBGP接続
  5. PEにCEをBGPで接続、経路交換

大まかな流れは以上です。

構成

今回使用する構成は最終的に以下のようになります。
f:id:cognify:20170509084159p:plain
前回までの構成にエッジルータ(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
    • RSVP/LDPの経路をフォワーディングにのみ使用します

今回は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の拡張が頻繁に行われ、伝搬できる情報の種類を増やし続けています。
新しい技術に触れることも大切ですが、古くからある基礎に振り返ってみるのも悪くないのではと思いまとめてみました。

おわり