Junosで始めるMPLS入門その2 RSVP-TE LSP編

前回の記事で、Static LSPによる手動でのラベルパスの設定を行いました。
手動で設定するのは運用上とても面倒なので、今回は動的なラベル配布プロトコルである RSVP-TE を利用した基本動作を確認したいと思います。
表記の簡略化のため、今後RSVP-TEをRSVPと記載しますが同義です。

RSVPとは

~~RFC読んでください~~
ラベル配布を行うシグナリングプロトコルの一つです。
ラベル情報のほかに、帯域予約や明示的な経路の設定などが可能でLDPよりも高度な運用が可能です。
現在はラベル配布プロトコルにLDPとRSVPが広く利用されているので、この二つを理解していればMPLSの運用で困ることはないと思います。
※MP-BGPというBGPを拡張したシグナリング方法もありますが、これは後で扱います。

ラベルの配布方法

動的なラベルの配布方法には大きく分けて二つの手順（モード）があります。

DU（Downstream Unsolicited）
- 宛先prefix(FEC)にラベルを割り当て、宛先（下流）のLSRからラベルを配布する方式
- LDPがこの方式です
- OSPFなどのIGPの経路情報をラベルにマッピングするのでLSPはIGPの最短経路に依存します
DoD（Downstream-on-Demand）
- 問い合わせに対してラベル情報を返す方式
- RSVPがこの方式です
- LSPがIGPの最短パスに依存しない設計が可能です

RSVP Negotiation

LSPをinitiationするHead-End LSR(送信元)からTail-End LSR(宛先)に対してPATHメッセージを送り、ラベル情報を要求します。
このPATHメッセージには以下のオブジェクトが含まれています。

Label Request Objetct
- ラベルの割り当て要求
ERO（Explicit Route Object）
- 宛先までのパス(ネクストホップ)情報の一覧
- このパス情報を元にPATHメッセージが送信される
RRO（Record Route Object）
- 経由したリンク情報の一覧
Session Object
- LSPの優先度や名前など

PATHメッセージを受信したTail-End LSRは、ラベル割り当てを行い逆方向のRESVメッセージで返答します。
RESVメッセージにはLabel Objectでラベル情報が格納されています。
これをHop-by-Hopで行いLSPが確立します。詳細はGoogle先生に聞いてください。

余談ですが、かつてラベル配布プロトコルにはTDPやCR-LDPと呼ばれるものがありましたが、某ベンダの資格試験でしか見たことがないためここでは扱いません。そもそもJunosでは動きません。

RSVP LSPの設定

実際にラボ環境で動かしてみましょう。

構成

NW構成は前回と同じものを使用します。logical-systemの設定も同様です。
今回は Nagoya → Shinagawa 間のパスをRSVPで制御したいと思います。
primary pathとバックアップ用のsecondary pathを作成し、primary pathの障害時に速やかにsecondary pathにカットオーバーできる構成にします。戻りの経路にもバックアップパスを作成します。

事前準備

前回と同様、ルータでMPLSを有効にする必要があります。

root@lab-vmx01:Nagoya> show configuration protocols mpls
interface all;

RSVPを有効にします。

root@lab-vmx01:Nagoya> show configuration protocols rsvp
interface all;

EROの設定

RSVPのPATHメッセージはEROを元に生成されるので、EROの設定を行います。

EROの作成方法

EROには作り方が二通りあります。
明示的にパスを指定する方法と、CSPFというアルゴリズムで計算されたパスを利用する方法です。

Explicit ERO
- Strict Mode
  - 宛先までの経路を明示的に指定
- Loose Mode
  - 宛先までの経路をIGPの最短経路で指定
Dynamic ERO
- CSPF
  - 宛先までの経路をCSPFで計算して指定

CSPFについての詳しい説明についてはここでは割愛します。
OSPFで使われているダイクストラアルゴリズムを拡張して、メトリックに加えて利用可能な帯域など、トラフィックエンジニアリング(TE)に必要な情報を伝搬できるようにしたものです。

Explicit EROのモード

CSPFに完全依存しないExplicit EROには以下の二つのモードがあるので、設計によって使い分けます。
二つを組み合わせて使うこともできます。

Strict ERO
- LSPの経路を明示的に指定する方法
- ここに指定されたネクストホップを必ず通る
Loose ERO
- LSPの経路をIGPの最短経路に委ねる方法
- ここに指定されたホップまでの経路はIGPの最短経路で到達する

Nagoya → Shinagawa 方向のパス

以下の経路のパスになるようにShinagawa向けのEROを設定します。ここではCSPFは使わずに、Explict EROで設定をします。
Primary Path：Nagoya → Dojima → Otemachi → Shibuya → Ikebukuro → Shinagawa
Secondary Path：Nagoya → Dojima → [IGP Shortest Path] → Shinagawa

f:id:cognify:20170506104934p:plain

primary pathは完全にstrict指定で到達し、secondary pathではネクストホップのDojimaまでstrictで、その先はOSPFの最短メトリックに任せるlooseに設定にしています。
また、ネクストホップはインターフェースのアドレスを設定しても問題ありませんが、各ルータのloopback addressをOSPFで学習しているのでそれを設定します。

root@lab-vmx01:Nagoya> show configuration protocols mpls
label-switched-path Shinagawa {
    to 10.255.255.7;
    no-cspf;
    primary to_Shinagawa_ACT;
    secondary to_Shinagawa_STBY;
}
path to_Shinagawa_ACT {
    10.255.255.2 strict;
    10.255.255.1 strict;
    10.255.255.3 strict;
    10.255.255.5 strict;
    10.0.0.19 strict;
}
path to_Shinagawa_STBY {
    10.255.255.2 strict;
    10.0.0.21 loose;
}
interface all;

Shinagawa → Nagoya 方向のパス

以下の経路のパスになるようにShinagawa向けのEROを設定します。
Primary Path：Shinagawa → Ikebukuro → [IGP Shortest Path] → Nagoya
Secondary Path：Shinagawa → [IGP Shortest Path] → Nagoya

f:id:cognify:20170506104919p:plain

こちらのパスは殆どがIGPに依存しています。

root@lab-vmx01:Shinagawa> show configuration protocols mpls
label-switched-path Nagoya {
    to 10.255.255.8;
    no-cspf;
    primary to_Nagoya_ACT;
    secondary to_Nagoya_STBY;
}
path to_Nagoya_ACT {
    10.255.255.5 strict;
    10.0.0.26 loose;
}
path to_Nagoya_STBY {
    10.0.0.23 loose;
}
interface all;

secondary側にLSPが切り替わった場合、完全にIGPの最短経路で到達するようになります。

LSPを作成したら、宛先のnext-hopをLSPに向けます。

root@lab-vmx01# show | compare
[edit logical-systems Nagoya]
+   routing-options {
+       static {
+           route 10.255.255.7/32 {
+               lsp-next-hop Shinagawa;
+           }
+       }
+   }
[edit logical-systems Shinagawa]
+   routing-options {
+       static {
+           route 10.255.255.8/32 {
+               lsp-next-hop Nagoya;
+           }
+       }
+   }

RSVP LSPの確認

RSVP Neighbor

RSVPのneighborがupしていることを確認します。

root@lab-vmx01> show rsvp neighbor logical-system Nagoya
RSVP neighbor: 2 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.0.0.22             0  1/0    10:04:09        9  3992/3992 910
10.0.0.27             5  1/0     9:05:12        9  3602/3602 728

root@lab-vmx01> show rsvp neighbor logical-system Shinagawa
RSVP neighbor: 2 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.0.0.18             5  2/1     8:44:45        9  4469/4469 1608
10.0.0.20             0  1/0     8:48:24        9  3492/3492 30

ActivePath

ActivePathに設定したPrimary Path(to_Shinagawa_ACT & to_Nagoya_ACT)が使われていることがわかります。

root@lab-vmx01: Nagoya> show mpls lsp
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
10.255.255.7    10.255.255.8    Up     0 *     to_Shinagawa_ACT Shinagawa
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname
10.255.255.8    10.255.255.7    Up       0  1 FF       3        - Nagoya
Total 1 displayed, Up 1, Down 0

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

root@lab-vmx01:Shinagawa> show mpls lsp
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
10.255.255.8    10.255.255.7    Up     0 *     to_Nagoya_ACT    Nagoya
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname
10.255.255.7    10.255.255.8    Up       0  1 FF       3        - Shinagawa
Total 1 displayed, Up 1, Down 0

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

RSVP Traceroute

RSVP LSPのtracerouteでPrimary Pathを通ることが確認できます。

root@lab-vmx01:Nagoya> traceroute mpls rsvp Shinagawa
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299872  RSVP-TE     10.0.0.22        (null)           Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    2   299840  RSVP-TE     10.0.0.0         10.0.0.22        Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    3   299872  RSVP-TE     10.0.0.3         10.0.0.0         Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    4   299856  RSVP-TE     10.0.0.15        10.0.0.3         Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    5        3  RSVP-TE     10.0.0.19        10.0.0.15        Egress
  FEC-Stack-Sent: RSVP

  Path 1 via lt-0/0/0.23 destination 127.0.0.64

root@lab-vmx01:Nagoya> traceroute 10.255.255.7
traceroute to 10.255.255.7 (10.255.255.7), 30 hops max, 48 byte packets
 1  10.0.0.22 (10.0.0.22)  0.774 ms  0.493 ms  0.429 ms
     MPLS Label=299920 CoS=0 TTL=1 S=1
 2  10.0.0.0 (10.0.0.0)  0.393 ms  0.430 ms  0.412 ms
     MPLS Label=299856 CoS=0 TTL=1 S=1
 3  10.0.0.3 (10.0.0.3)  0.381 ms  0.397 ms  0.372 ms
     MPLS Label=299920 CoS=0 TTL=1 S=1
 4  10.0.0.15 (10.0.0.15)  0.379 ms  0.427 ms  0.383 ms
     MPLS Label=299888 CoS=0 TTL=1 S=1
 5  10.255.255.7 (10.255.255.7)  0.398 ms  0.386 ms  0.381 ms

root@lab-vmx01:Shinagawa> traceroute mpls rsvp Nagoya
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299872  RSVP-TE     10.0.0.18        (null)           Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    2   299840  RSVP-TE     10.0.0.8         10.0.0.18        Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    3   299792  RSVP-TE     10.0.0.25        10.0.0.8         Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    4        3  RSVP-TE     10.0.0.26        10.0.0.25        Egress
  FEC-Stack-Sent: RSVP

  Path 1 via lt-0/0/0.19 destination 127.0.0.64

root@lab-vmx01:Shinagawa> traceroute 10.255.255.8
traceroute to 10.255.255.8 (10.255.255.8), 30 hops max, 48 byte packets
 1  10.0.0.18 (10.0.0.18)  0.846 ms  0.676 ms  0.405 ms
     MPLS Label=299904 CoS=0 TTL=1 S=1
 2  10.0.0.8 (10.0.0.8)  0.368 ms  0.487 ms  0.411 ms
     MPLS Label=299856 CoS=0 TTL=1 S=1
 3  10.0.0.25 (10.0.0.25)  0.380 ms  0.385 ms  0.394 ms
     MPLS Label=299808 CoS=0 TTL=1 S=1
 4  10.255.255.8 (10.255.255.8)  0.402 ms  0.380 ms  0.375 ms

障害試験 (LSP Cutover)

上記までで正常にLSPが張れていることが確認できました。
では特定の場所やリンクで障害が起きたらどうなるでしょうか？

ここで、Ikebukuro ⇔ Shinagawa 間の回線に障害が発生 したと仮定します。想定通りの動作であれば事前に設定したSecondary PathへLSPが高速で切り替わるはずです。

f:id:cognify:20170506105138p:plain

ここでは回線障害を模して、IkebukuroのShinagawa向けIFを明示的にshutします。

root@lab-vmx01# show | compare
[edit logical-systems Ikebukuro interfaces lt-0/0/0 unit 18]
+     disable;

これにより、ActivePathを張っていた双方向のLSPはここを通れなくなったので、どこか別の経路に迂回したはずです。
Secondary Pathには、looseモードの設定を適用したので、IGPの最短メトリックで到達すれば想定通りです。

LSPの状態確認

LSPがSecondary Path(to_Shinagawa_STBY & to_Nagoya_STBY)に切り替わっていることが確認できます。

root@lab-vmx01:Nagoya> show mpls lsp
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
10.255.255.7    10.255.255.8    Up     0       to_Shinagawa_STBY Shinagawa
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname
10.255.255.8    10.255.255.7    Up       0  1 FF       3        - Nagoya
Total 1 displayed, Up 1, Down 0

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

root@lab-vmx01:Shinagawa> show mpls lsp
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
10.255.255.8    10.255.255.7    Up     0       to_Nagoya_STBY   Nagoya
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname
10.255.255.7    10.255.255.8    Up       0  1 FF       3        - Shinagawa
Total 1 displayed, Up 1, Down 0

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

経路の確認

TracerouteでパスがSecondary Path になっていることが確認できます。
Nagoya → Dojima → Shibuya → Toyosu → Shinagawaの経路になっています。これはOSPFの最小メトリック経路とも一致します。

root@lab-vmx01:Nagoya> traceroute mpls rsvp Shinagawa
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299888  RSVP-TE     10.0.0.22        (null)           Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    2   299888  RSVP-TE     10.0.0.11        10.0.0.22        Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    3   299808  RSVP-TE     10.0.0.17        10.0.0.11        Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    4        3  RSVP-TE     10.0.0.21        10.0.0.17        Egress
  FEC-Stack-Sent: RSVP

  Path 1 via lt-0/0/0.23 destination 127.0.0.64

f:id:cognify:20170506105308p:plain

戻りの経路も同様にIGPの最短経路で上記の逆方向になっています。

root@lab-vmx01:Shinagawa> traceroute mpls rsvp Nagoya
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299824  RSVP-TE     10.0.0.20        (null)           Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    2   299904  RSVP-TE     10.0.0.16        10.0.0.20        Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    3   299904  RSVP-TE     10.0.0.10        10.0.0.16        Success
  FEC-Stack-Sent: RSVP
  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    4        3  RSVP-TE     10.0.0.23        10.0.0.10        Egress
  FEC-Stack-Sent: RSVP

  Path 1 via lt-0/0/0.21 destination 127.0.0.64

f:id:cognify:20170506105328p:plain

Ikebukuro ⇔ Shinagawa間のLSPステータスがDeadとなっています。IFを解放して障害が復旧すれば、再度status upに戻ります。
一度DownしたLSPが再度安定した状態とみなされるまでには、retry-timerの2倍の時間がかかります。

root@lab-vmx01:Shinagawa> show rsvp neighbor detail
RSVP neighbor: 2 learned
Address: 10.0.0.18 via: lt-0/0/0.19 status: Dead
  Last changed time: 3:33, Idle: 3:40 sec, Up cnt: 2, Down cnt: 2
  Message received: 1624
  Hello: sent 4511, received: 4511, interval: 9 sec
  Remote instance: 0x0, Local instance: 0x18d0c77e
  Refresh reduction:  not operational

Transit LSRの状態も確認すると、PrimaryがDownしてSecondaryがUpしているのが確認できます。

root@lab-vmx01: Shibuya> show mpls lsp logical-system
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname
10.255.255.7    10.255.255.8    Dn       0  0  -       -        - Shinagawa
10.255.255.7    10.255.255.8    Up       0  1 FF  299888   299808 Shinagawa
10.255.255.8    10.255.255.7    Up       0  1 FF  299904   299904 Nagoya
Total 3 displayed, Up 2, Down 1

ここまででLSPの切り替えを確認できました。
この機能を使うとユーザトラフィックの中断を最小限に抑えた遅延の少ないLSP移行が簡単にできます。

まとめ

今回はRSVPでのLSPのシグナリングを行いました。
あまり良い例ではありませんでしたが、RSVPのシグナリングとHot Standby LSPのRepairが確認できました。
前回と合わせてMPLSネットワークの基本であるLSP制御についてはある程度触れたので、次回から本格的なノード障害時のプロテクション動作や、高速なReRoute動作について確認していきたいと思います。

COGNITIVE

Networking