無料ブログはココログ

【GMPLS】 11. JuniperのGMPLSまとめ

11. JuniperのGMPLSまとめ

JUNOS6.4時点でのJuniperの実装をまとめると次のようになります。

  • LMPはスタティック。動的な情報交換はできないので、remote-idは手動で設定しないといけない。
  • LMPを使うときには一つ以上のコントロールチャネルが必要。
  • コントロールチャネルはpoint-to-pointでなければならない(GREトンネル可)。
  • コントロールチャネルに通常のRSVP、OSPFを流してはならない。
  • LMPのte-linkの中には複数のリソース(物理インタフェース)を含めることができる。
  • te-link中のリソースにもアドレスを割り当てられるが、使い方が不明。
  • OSPFとRSVPはpeer-interface設定でLMP情報を吸い上げる。
  • OSPFはトラフィックエンジニアリングが必須。そうしないとOpaque LSAが流れない。
  • パケットのLSPはUnidirectional。非パケットのLSP(TDM、波長、ファイバ)は自動的にBidirectionalになる。
  • 非パケットのLSP(TDM、波長、ファイバ)でもCSPFに対応。strictでなくてもよい。
  • 作成するLSPのタイプとしてpsc-1を選ぶと、LSPが張れない。その他(tdm, lambda, fiber)にすれば作成可能。
  • non packetのLSPの使い方がイマイチ分からない。

次の項目は対応していません。

  • ダイナミックLSP
  • Graceful restart
  • アンナンバードリンク上のRSVP-TE
  • GMPLS対応のIS-IS
  • GMPLSリンクバンドリング

【GMPLS】 10. 再実験

10. 再実験

いろいろと失敗を重ねているうちにだいぶ理解が深まりまってきました。 デバッグ性を重視して無理してイーサで押し通してきましたが、やはり光で攻めた方がいいようです。 改めて実験構成を作ってみました。

コントロールチャネルにはGREトンネル(gre.0)を使用し、192.168.250.0/24を割り当てます。 データチャネルにはso-0/1/1を使用します。

データチャネルの物理インタフェースにはIPアドレスを割り当てません。 不要だからです(もちろん管理用として割り当てることはできます)。 とは言っても、RSVPでLSPを作成するときに「どこを通すのか」指定しなければいけませんから、 LMPのte-linkにアドレスを割り当てます。 ここではR1側に10.1.3.1を、R2側に10.1.3.2を割り当てます。 ネットワークセグメントではないので、飛び飛びのアドレスで構いません。

te-linkの中には複数のリソース(物理ポートやタイムスロット、波長)を含めることができます。 この場合はso-0/1/1です。 te-link中のそれらリソースにもIPアドレスを割り当てる事もできるのですが、 Juniperでは使い方が分からないので、ここでは割り当てません。

順番に設定を見ていきます。最初はR1のインタフェース設定(↓)です。 so-0/1/1にIPアドレスを割り当てていない事に注目してください。

gsi@R1# show interfaces
fe-0/0/0 {
    speed 100m;
    mtu 1500;
    link-mode half-duplex;
    unit 0 {
        family inet {
            address 192.168.1.1/24;
        }
        family mpls;
    }
}
so-0/1/1 {
    description "Data channel";
    clocking internal;
    encapsulation ppp;
    sonet-options {
        rfc-2615;
    }
}
gre {
    unit 0 {
        tunnel {
            source 192.168.1.1;
            destination 192.168.1.2;
        }
        family inet {
            address 192.168.250.1/24;
        }
        family mpls;
    }
}

次にR1のLMPの設定(↓)です。 te-r1-r2という名称でte-linkを作成しました。 R1側は10.1.3.1を、R2側は10.1.3.2を割り当てています。 te-linkの中には物理インタフェースを複数組み込むことができます。 物理インタフェースの中にもlocal-address、remote-address設定がありますが、これは不要です。 remote-idは、show link-managementコマンドで調べた値を設定します。

peerの設定は前回の実験のときと同じです。

link-management {
    te-link te-r1-r2 {
        local-address 10.1.3.1;
        remote-address 10.1.3.2;
        remote-id 45787;
        interface so-0/1/1 {
            remote-id 22276;
        }
    }
    peer r2 {
        address 192.168.254.2;
        control-channel gre.0;
        te-link te-r1-r2;
    }
}

続いてRSVPとOSPFの設定です。 peer-interface設定でLMP情報をプロトコル側に供給するようにしています。 コントロールチャネルのインタフェースgre.0でRSVP、OSPFを動かしてはいけません。

注目はOSPFでtraffic-engineering設定を加えていることです。 マニュアルには書いてありませんが、これがないと動きません。

rsvp {
    interface fxp0.0 {
        disable;
    }
    interface gre.0 {
        disable;
    }
    peer-interface r2;
}
ospf {
    traffic-engineering;
    area 0.0.0.0 {
        interface lo0.0;
        interface fxp0.0 {
            disable;
        }
        interface fe-0/0/0.0;
        peer-interface r2;
    }
}

ここまでの設定で、LMP、OSPF、RSVPが機能します。

show ospf databaseコマンドの結果から、エリアローカルのOpaq LSAが生成されていることが分かります。 show ted databaseコマンドの結果からは、 トラフィックエンジニアリング用のPoint-to-Pointの仮想リンクが確認できます。 te-linkに割り当てたアドレスがキチンとTEDに反映されています。

gsi@R1# run show ospf neighbor
  Address         Interface             State      ID              Pri  Dead
192.168.1.2      fe-0/0/0.0             Full      192.168.254.2    128   34
192.168.250.2    r2                     Full      192.168.254.2    128   39

[edit]
gsi@R1# run show ospf database

    OSPF link state database, area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *192.168.254.1    192.168.254.1    0x8000002f   589  0x2  0x8a77  48
Router   192.168.254.2    192.168.254.2    0x8000003e   205  0x2  0x806e  48
Network *192.168.1.1      192.168.254.1    0x80000009     2  0x2  0x6a3f  32
OpaqArea*1.0.0.1          192.168.254.1    0x80000024   589  0x2  0x4811  28
OpaqArea 1.0.0.1          192.168.254.2    0x80000031   805  0x2  0x3218  28
OpaqArea*1.0.0.3          192.168.254.1    0x80000026   589  0x2  0x29f6 164
OpaqArea 1.0.0.3          192.168.254.2    0x8000002e   505  0x2  0xf423 164

[edit]
gsi@R1# run show ted database
TED database: 0 ISIS nodes 3 INET nodes
ID                            Type Age(s) LnkIn LnkOut Protocol
192.168.1.1-1                 Net    7373     0      2 OSPF(0.0.0.0)
    To: 192.168.254.1, Local: 0.0.0.0, Remote: 0.0.0.0
    To: 192.168.254.2, Local: 0.0.0.0, Remote: 0.0.0.0
ID                            Type Age(s) LnkIn LnkOut Protocol
192.168.254.1                 Rtr    5634     2      1 OSPF(0.0.0.0)
    To: 192.168.254.2, Local: 10.1.3.1, Remote: 10.1.3.2
ID                            Type Age(s) LnkIn LnkOut Protocol
192.168.254.2                 Rtr    5444     2      1 OSPF(0.0.0.0)
    To: 192.168.254.1, Local: 10.1.3.2, Remote: 10.1.3.1

[edit]
gsi@R1#

続いて、MPLSの設定です。

mpls {
    no-cspf;
    interface all;
    interface fxp0.0 {
        disable;
    }
}

ずいぶん簡単になってますが、これはLSPの設定をしていないからです。 GMPLSのLSP(TDM、波長、ファイバ)は基本的に双方向です(パケットは唯一、単方向)。 なので、R1とR2のどちらかでLSPを設定すればよいことになります。 ここではR2側からLSPを作成してみます。 R2から見ると、通したい場所はte-linkのR1側の部分、すなわち10.1.3.1です。

mpls {
    no-cspf;
    label-switched-path gmpls-1 {
        from 192.168.254.2;
        to 192.168.254.1;
        lsp-attributes {
            signal-bandwidth stm-1;
            switching-type tdm;
            gpid ppp;
        }
        primary gmpls-path-1;
    }
    path gmpls-path-1 {
        10.1.3.1;
    }
    interface all;
    interface fxp0.0 {
        disable;
    }
}

この設定により、gmpls-1と名付けたLSPがアップします。

gsi@R2# run show mpls lsp
Ingress LSP: 1 sessions
To              From            State Rt ActivePath       P     LSPname
192.168.254.1   192.168.254.2   Up     0 gmpls-path-1     *     gmpls-1 Bidir
Total 1 displayed, Up 1, Down 0

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

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

[edit]
gsi@R2# run show rsvp session detail
Ingress RSVP: 1 sessions

192.168.254.1
  From: 192.168.254.2, LSPstate: Up, ActiveRoute: 0
  LSPname: gmpls-1, LSPpath: Primary
  Bidirectional, Upstream label in: 0x5706, Upstream label out: -
  Suggested label received: -, Suggested label sent: 0x5706
  Recovery label received: -, Recovery label sent: 0x5706
  Resv style: 1 FF, Label in: -, Label out: 0x5706
  Time left:    -, Since: Wed Oct 13 14:04:14 2004
  Tspec: rate 0bps size 0bps peak 155.52Mbps m 20 M 1500
  Port number: sender 1 receiver 26873 protocol 0
  PATH rcvfrom: localclient
  Adspec: sent MTU 1500
  PATH sentto: 192.168.254.1 (r1) 139 pkts
  RESV rcvfrom: 192.168.254.1 (r1) 139 pkts
  Explct route: 10.1.3.1
  Record route:  10.1.3.1
Total 1 displayed, Up 1, Down 0

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

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

[edit]
gsi@R2#
gsi@R2# run show route forwarding-table family mpls
Routing table: mpls
MPLS:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            perm     0                    dscd    24     1
0                  user     0                    recv    23     3
1                  user     0                    recv    23     3
2                  user     0                    recv    23     3

[edit]
gsi@R2#

このLSPは双方向ですから、R1側からみても、このLSPはアップします。

gsi@R1# run show mpls lsp
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 1 sessions
To              From            State Rt Style Labelin Labelout LSPname
192.168.254.1   192.168.254.2   Up     0 1 FF  0x5706        - gmpls-1 Bidir
Total 1 displayed, Up 1, Down 0

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

[edit]
gsi@R1#

かなり苦労しましたが、無事にGMPLSのLSPが作られました。

データチャネルの物理リソースを追加してみる

ここまでの設定ですと、GMPLSのLSPを1本張ると終わってしまいます。 せっかくですので、データチャネルを追加してみましょう。 やり方、というか考え方は2通りあります。 一つは、te-linkの中に物理リソースを追加していく方法、 もう一つはte-linkごと新しく用意する方法です。

前者の場合、同じte-linkを使用して何本もLSPを作成できます。 つまり、10.1.3.1というアドレスを通るようにLSPを作成すると、 そのte-linkに含まれる物理リソースの中から空いているものを自動選択してくれるわけです。 実際にどの物理ポートを通るかは、 そのときのタイミング次第になってしまいますが、 管理する側としては、この方が便利だと思います。

後者の場合、どの物理リソースを通すのか人間側できちんと管理したい場合に使用します。

ここでは前者の場合、すなわち既存のte-linkの中に物理リソースを追加する方法をとってみたいと思います。 追加するのはso-0/1/3です。ここでも物理インタフェースにIPアドレスは不要です。

so-0/1/3 {
    description "Data channel";
    clocking internal;
    encapsulation ppp;
    sonet-options {
        rfc-2615;
    }
}

後は、te-linkの中にso-0/1/3を追加するだけです。

link-management {
    te-link te-r1-r2 {
        local-address 10.1.3.1;
        remote-address 10.1.3.2;
        remote-id 45787;
        interface so-0/1/3 {
            remote-id 22278;
        }
        interface so-0/1/1 {
            remote-id 22276;
        }
    }
    peer r2 {
        address 192.168.254.2;
        control-channel gre.0;
        te-link te-r1-r2;
    }
}

R2側からLSPを追加してみたいと思います。ここでは2本追加して、合計3本設定してみます。

mpls {
    no-cspf;
    label-switched-path gmpls-1 {
        from 192.168.254.2;
        to 192.168.254.1;
        lsp-attributes {
            signal-bandwidth stm-1;
            switching-type tdm;
            gpid ppp;
        }
        primary gmpls-path-1;
    }
    label-switched-path gmpls-2 {
        from 192.168.254.2;
        to 192.168.254.1;
        lsp-attributes {
            signal-bandwidth stm-1;
            switching-type tdm;
            gpid ethernet;
        }
        primary gmpls-path-1;
    }
    label-switched-path gmpls-3 {
        from 192.168.254.2;
        to 192.168.254.1;
        lsp-attributes {
            signal-bandwidth stm-1;
            switching-type tdm;
            gpid ethernet;
        }
        primary gmpls-path-1;
    }
    path gmpls-path-1 {
        10.1.3.1;
    }
    interface all;
    interface fxp0.0 {
        disable;
    }
}

すると、次のように最初の2本は作成できますが、3本目は弾かれてます。 リソースが足りないからです。

gsi@R2# run show mpls lsp
Ingress LSP: 3 sessions
To              From            State Rt ActivePath       P     LSPname
192.168.254.1   192.168.254.2   Up     0 gmpls-path-1     *     gmpls-1 Bidir
192.168.254.1   192.168.254.2   Up     0 gmpls-path-1     *     gmpls-2 Bidir
192.168.254.1   192.168.254.2   Dn     0 -                      gmpls-3 Bidir
Total 3 displayed, Up 2, Down 1

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

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

[edit]
gsi@R2#

以上のように、GMPLSのLSP作成は簡単にできることがわかりました。

最終的な設定 ( R1  R2)

コントロールチャネル上でモニターしたEtherealの データ

このLSPはどうやってつかうの?

それが目下の課題です。CCCを使うにはPSCじゃないとダメなので、このLSPには使えません。 普通にIPパケットをルーティングするしかないのかな?

つづく。

【GMPLS】 9. JuniperのLMPは変?

先日 から実験しているGMPLSですが、うまく動かないのも悔しいので、もう少しだけ試してみようと思います。

JuniperのGMPLSがうまく動作しない原因を突き詰めていくと、LMPがうまく機能していないように思えます。 マニュアルによると、LMPのピアを設定すれば、仮想的に割り当てたアドレスがOSPFなり、 RSVPなりでやりとりできるようになるはずなのですが・・・

After you have configured the LMP peers, add the peer interfaces to RSVP and OSPF. The peer interface name must match the peer name configured in LMP. Once the peer interfaces are added to the protocols, the traffic engineering link local and remote addresses can be signaled and advertised to peers like any other interface enabled for RSVP and OSPF. These addresses act as virtual interfaces for GMPLS.

とりあえず、コントロールチャネル上に何が流れてるのかを突き止めないといけません。 etherealでfe-0/0/0上をモニターしてみると、GRE上でOSPFの隣接が確立されてました。 GREはOSPFの動作対象から外してますから、 トラフィックエンジニアリング用のpeer-interface設定が効いているのに間違いありません。 実際、gre.0はOSPFが動いていません。

【etherealのデータ

gsi@R1# run show ospf interface gre.0

[edit protocols link-management]
gsi@R1#

ここまでは良さそうなのですが、 トラフィックエンジニアリング用に特別なLSAが流れてるかっていうと、そうでもないようです。 普通のLSAだけです。

si@R1# run show ospf database

    OSPF link state database, area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *192.168.254.1    192.168.254.1    0x8000000a   961  0x2  0xde47  48
Router   192.168.254.2    192.168.254.2    0x8000000a   964  0x2  0xf22f  48
Network  192.168.1.2      192.168.254.2    0x80000003   240  0x2  0x624b  32

[edit protocols link-management]
gsi@R1# run show ospf database detail

    OSPF link state database, area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *192.168.254.1    192.168.254.1    0x8000000a   966  0x2  0xde47  48
  bits 0x0, link count 2
  id 192.168.1.2, data 192.168.1.1, Type Transit (2)
  TOS count 0, TOS 0 metric 1
  id 192.168.254.1, data 255.255.255.255, Type Stub (3)
  TOS count 0, TOS 0 metric 0
Router   192.168.254.2    192.168.254.2    0x8000000a   969  0x2  0xf22f  48
  bits 0x0, link count 2
  id 192.168.1.2, data 192.168.1.2, Type Transit (2)
  TOS count 0, TOS 0 metric 1
  id 192.168.254.2, data 255.255.255.255, Type Stub (3)
  TOS count 0, TOS 0 metric 0
Network  192.168.1.2      192.168.254.2    0x80000003   245  0x2  0x624b  32
  mask 255.255.255.0
  attached router 192.168.254.2
  attached router 192.168.254.1

[edit protocols link-management]
gsi@R1#

ルータLSAにConnection to P-to-Pがない事を考えると、 peer-interfaceの存在はどうなってしまったのでしょう?

GRE上には、OSPF以外にこれといってパケットが流れる様子はありません。 JuniperのLMPはスタティックということで納得するとしても、RSVPは変ですね。 GRE上にRSVPメッセージが流れないと、やっぱりおかしいです。

あらゆる可能性を排除するために、まずマニュアルのススメに従って、 データチャネル用の物理インタフェース(fe-0/0/1)に割り当てるアドレスと、 論理的なTEリンクに割り当てるアドレスを変えてみました。 が、まったく影響なし。

コントロールチャネルにGREを使うのがいけないのかと思って、 さらにso-0/1/1でJuniper間を直結してみましたが、 それでもダメ。

うーーん、どうしたものか・・・

つづく(のかな?)

【GMPLS】 8. LMPの概要

8. LMPの概要

LMPの概要をdraft-ietf-ccamp-lmp-10.txtから翻訳して抜粋。

2. LMP Overview

   LMPにおける二つの主な役割は、コントロールチャネルの管理と、リンクプ
   ロパティとの関連付けである。コントロールチャネルの管理は、隣接ノー
   ド間でコントロールチャネルを確立し、維持していくためのものである。
   これはConfigメッセージの交換と、高速なキープアライブをノード間でや
   りとりすることで実現する。キープアライブは、下位レベルが制御チャネ
   ルの障害を検出できないときに必要とされる。リンクプロパティの関連付
   けは、TEリンクのプロパティと同期をとり、TEリンクの設定をチェックす
   るためのものである。

   LMPでは、隣接ノード間で少なくとも一つの双方向コントロールチャネルを
   必要とする。コントロールチャネルのそれぞれの方向に関して
   CC_Id(Control Channel Id)が割り当てられ、LMP Configメッセージを使っ
   てそれら2方向のCC_Idが対応付けられる。Testメッセージを除き、全ての
   LMPパケットはUDP上にLMPのポート番号を使って流れる(Testメッセージは
   インバンドのメッセージなのでトランスポートに依存する)。コントロール
   チャネルのリンクレベルのエンコーディングはこの文書では規定しない。

   "LMP隣接(LMP adjacency)"は2つのノード間で少なくとも一つの双方向コ
   ントロールチャネルが確立されると形成される。複数のコントロールチャ
   ネルが同時にアクティブになってもよいが、コントロールチャネルのパラ
   メータはチャネルごとにネゴシエーションされなければならない(MUST)。
   LMP高速キープアライブをコントロールチャネル上で動かすなら、LMP
   Helloメッセージを交換しなければならない(MUST)。その他のLMPメッセー



J. Lang, Editor            Standards Track                   [Page 8]

Internet Draft       draft-ietf-ccamp-lmp-10.txt         October 2003

   
   ジはアクティブになっているどのチャネル上に投げてもよい(MAY)。シグナ
   リング、ルーティング、リンクプロパティ相関のために複数のコントロー
   ルチャネルを一つの論理コントロールチャネルに束ねることもある。

   LMPにおけるリンクプロパティ相関の機能は、複数のデータ用リンク(ポー
   トやリンクのコンポーネント)を一つのTEリンクに束ね、TEリンクのプロパ
   ティとして同期を取るためにある。リンクプロパティ相関の一部として、
   LinkSummaryメッセージが定義されている。LinkSummaryメッセージはロー
   カル、およびリモートのLink_Idsを含み、TEリンクを構成する全てのデー
   タリンクのリスト、そして様々なプロパティを含んでいる。LinkSummaryメッ
   セージの受信に対して、LinkSummaryAckまたはLinkSummaryNackメッセージ
   を送信し、そのリンクプロパティに同意するのか、反対するのか示さなけ
   ればならない。

   Message_Idsと再送により、LMPメッセージはリライアブルに配送される。
   Message_IdsはMESSAGE_IDオブジェクトで運ばれる。LMPメッセージは高々
   一つのMESSAGE_IDオブジェクトを持つ。コントロールチャネルに固有のメッ
   セージに関しては、Message_Idはそのメッセージが送られるコントロール
   チャネルで管理されたスコープにある。TEリンク固有のメッセージの場合、
   Message_IdはLMP隣接ごとに管理されたスコープにある。Message_Idの値は
   単純増加で、最大値に達すると元に戻る。

   この仕様では、二つのLMP手順を定義する。リンクコネクティビティ確認と、
   障害管理である。これら手順はコントロールチャネルが物理的なデータリ
   ンクと別々の場合に特に効果を発揮する。リンクコネクティビティ確認は、
   データプレーンの探索、Interface_Idの交換(Interface_IdsはGMPLSのシグ
   ナリングに使われ、ポートのラベルか、コンポーネントリンク識別子のど
   ちらかである)、そして物理的なコネクティビティの確認に用いられる。こ
   れは、Testメッセージをデータ用リンクに送信し、TestStatusメッセージ
   をコントロールチャネル経由で戻してもらうことで実現する。Testメッセー
   ジはデータ用リンクに送信しなければならない、唯一のLMPメッセージであ
   ることに注意してほしい。ChannelStatusメッセージは隣接ノード間で交換
   され、下流方向へのアラーム送信の省略、障害からのプロテクションと修
   復のために利用される。

   LMPリンクコネクティビティ確認では、Testメッセージをデータ用リンクに
   送信する。X-透過なデバイスでは、信号におけるXの要素を確かめ、変更す
   る能力を必要とする。LMPリンクコネクティビティ確認は、BeginVerifyメッ
   セージをコントロールチャネル経由で交換することで開始される。様々な
   透過要素をサポートするために、Verify Transport Mechanismを
   BeginVerifyおよびBeginVerifyAckメッセージに含めている。全てのデータ
   用リンクで透過機能を停止する必要はなく、最低限、どれか一つを終端で
   きればよい。またコントロールチャネルとTEリンクが同じ物理メディアを
   使わなければいけないわけでもない。ただし、コントロールチャネルはそ
   のTEリンクを制御しているエレメントと同じエレメントで終端しなければ



J. Lang, Editor            Standards Track                   [Page 9]

Internet Draft       draft-ietf-ccamp-lmp-10.txt         October 2003

   ならない。Test手順に関連してBeginVerifyメッセージが交換されるため、
   データ用リンクの動的な透過モードへの移行能力が求められる。

   LMP障害管理の手順はChannelStatusメッセージの交換に基づいている。こ
   れにはChannelStatus、ChannelStatusAck、ChannelStatusRequestおよび
   ChannelStatusResponseメッセージを利用する。ChannelStatusメッセージ
   は任意のタイミングで送信され、TEリンクのデータ用リンクの状況をLMPネ
   イバーに通達する。ChannelStatusAckメッセージはChannelStatusメッセー
   ジの受信に応じて返される。ChannelStatusRequestは、LMPネイバーにTEリ
   ンク内のデータチャネルの状況を報告させるために用いる。
   ChannelStatusResponseは、ChannelStatusRequestの受信に応じて返され、
   問い合わせされたデータ用リンクの状況を通知する。

つづく。

【GMPLS】 7. 実験は成功したのか?

7. 実験は成功したのか?

ここまでの実験で、一見うまくいっているようにも見えますが、 R1-R2間のデータチャネル fe-0/0/1 をモニターしてみると、RSVPのシグナリングが見えてしまってます。

No Time        Source                Destination           Protocol Info
 1 0.000000    10.0.1.1              10.0.1.2              RSVP     HELLO Message. 
 2 0.013158    10.0.1.2              10.0.1.1              RSVP     HELLO Message. 
 3 9.080752    10.0.1.1              10.0.1.2              RSVP     HELLO Message. 
 4 9.094033    10.0.1.2              10.0.1.1              RSVP     HELLO Message. 
 6 16.814830   10.0.1.2              10.0.1.1              RSVP     RESV Message. SESSION: IPv4-LSP, Destination 192.168.254.2, Tunnel ID 64135, Ext ID c0a8fe01. FILTERSPEC: IPv4-LSP, Tunnel Source: 192.168.254.1, LSP ID: 1. 
 7 16.901259   192.168.254.1         192.168.254.2         RSVP     PATH Message. SESSION: IPv4-LSP, Destination 192.168.254.2, Tunnel ID 64135, Ext ID c0a8fe01. SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 192.168.254.1, LSP ID: 1. 
 8 18.181299   10.0.1.1              10.0.1.2              RSVP     HELLO Message. 
 9 18.194599   10.0.1.2              10.0.1.1              RSVP     HELLO Message. 
10 19.665171   192.168.254.2         192.168.254.1         RSVP     PATH Message. SESSION: IPv4-LSP, Destination 192.168.254.1, Tunnel ID 36276, Ext ID c0a8fe02. SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 192.168.254.2, LSP ID: 1. 
11 19.665725   10.0.1.1              10.0.1.2              RSVP     RESV Message. SESSION: IPv4-LSP, Destination 192.168.254.1, Tunnel ID 36276, Ext ID c0a8fe02. FILTERSPEC: IPv4-LSP, Tunnel Source: 192.168.254.2, LSP ID: 1. 
12 27.291897   10.0.1.1              10.0.1.2              RSVP     HELLO Message. 
13 27.305318   10.0.1.2              10.0.1.1              RSVP     HELLO Message. 
14 36.412512   10.0.1.1              10.0.1.2              RSVP     HELLO Message. 
15 36.426033   10.0.1.2              10.0.1.1              RSVP     HELLO Message. 
17 45.552885   10.0.1.1              10.0.1.2              RSVP     HELLO Message. 
18 45.566979   10.0.1.2              10.0.1.1              RSVP     HELLO Message. 
19 54.583646   10.0.1.1              10.0.1.2              RSVP     HELLO Message. 
20 54.597502   10.0.1.2              10.0.1.1              RSVP     HELLO Message. 

【イーサリアルの<データ

これは明らかに期待した動きではありません。 本来fe-0/0/1はデータチャネル専用で、制御パケットは流したくないのです。 そのためにわざわざLMPを使って、アウトバンドの制御チャネル用にGREトンネルを作成しているのですから、 そっちにRSVPが流れて欲しいわけです。

RSVPのインタフェース状況を見ると、fe-0/0/1でもRSVPがアップしてしまってます。

gsi@R1# run show rsvp interface
RSVP interface: 2 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
fe-0/0/0.0  Up         0   100%  100Mbps     100Mbps     0bps        0bps
fe-0/0/1.0  Up         1   100%  100Mbps     100Mbps     0bps        0bps

しかし、fe-0/0/1をRSVPから外すと、こんどはLSPが張れなくなります。

さらに、peer-interfaceで設定したピアの情報が出てきません。これは変ですね・・・
LMP→OSPF、LMP→RSVPの連携がうまくいってないように見えます。うーん。

とりあえず、実験は失敗なのですが、GMPLSの概念の一片は理解できたので、そういう意味では成功です。 後の課題としては、LMPについて理解が足りないので、もう少し机上調査が必要です。

つづく。

【GMPLS】 6. LSPを利用してみる

6. LSPを利用してみる

この作成したLSPを利用してみましょう。てっとり早く使うにはCCCがいいと思います。

fe-0/0/3が余ってますので、このイーサをCCCでGMPLSのLSPとくっつけてみます。 そしてfe-0/0/3の先にはCiscoルータ(R4, R6)を接続します。 R4-R6間は同じイーサセグメントになるはずです。

R1のCCCは次のように設定します。これでfe-0/0/3で受け取ったイーサフレームは全てLSP gmpls-fe-0/0/1に転送されます。

interfaces {
    fe-0/0/3 {
        speed 100m;
        link-mode half-duplex;
        encapsulation ethernet-ccc;
        unit 0;
    }
}
protocols {
    connections {
        remote-interface-switch fe-0/0/3-gmpls-fe-0/0/1 {
            interface fe-0/0/3.0;
            transmit-lsp gmpls-fe-0/0/1;
            receive-lsp gmpls-fe-0/0/1;
        }
    }
}

ここまでの設定 ( R1  R2)

これでR4とR6が同じイーサセグメントで繋がってます。実際にpingを飛ばしてみましょう。

R4#ping
Protocol [ip]:
Target IP address: 192.168.2.6
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 192.168.2.6, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/4 ms
R4#

ちゃんと繋がってますね。 etherealでLPS上のデータを見てみると、ether-label-ether-ip-icmpというスタックになっているのが確認できます。

No.     Time        Source                Destination           Protocol Info
     14 16.591392   192.168.2.4           192.168.2.6           ICMP     Echo (ping) request

Frame 14 (132 bytes on wire, 132 bytes captured)
    Arrival Time: Oct  8, 2004 18:55:37.832839000
    Time delta from previous packet: 1.431380000 seconds
    Time since reference or first frame: 16.591392000 seconds
    Frame Number: 14
    Packet Length: 132 bytes
    Capture Length: 132 bytes
Ethernet II, Src: 00:90:69:92:34:01, Dst: 00:90:69:61:30:01
    Destination: 00:90:69:61:30:01 (JuniperN_61:30:01)
    Source: 00:90:69:92:34:01 (JuniperN_92:34:01)
    Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header
    MPLS Label: Unknown (100080)
    MPLS Experimental Bits: 0
    MPLS Bottom Of Label Stack: 1
    MPLS TTL: 255
Ethernet II, Src: 00:05:9a:64:b8:1c, Dst: 00:0b:45:41:34:1c
    Destination: 00:0b:45:41:34:1c (Cisco_41:34:1c)
    Source: 00:05:9a:64:b8:1c (Cisco_64:b8:1c)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.2.4 (192.168.2.4), Dst Addr: 192.168.2.6 (192.168.2.6)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 100
    Identification: 0x289b (10395)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 255
    Protocol: ICMP (0x01)
    Header checksum: 0x0da3 (correct)
    Source: 192.168.2.4 (192.168.2.4)
    Destination: 192.168.2.6 (192.168.2.6)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 
    Checksum: 0x0669 (correct)
    Identifier: 0x0402
    Sequence number: 0x0614
    Data (72 bytes)

0000  00 90 69 61 30 01 00 90 69 92 34 01 88 47 18 6f   ..ia0...i.4..G.o
0010  01 ff 00 0b 45 41 34 1c 00 05 9a 64 b8 1c 08 00   ....EA4....d....
0020  45 00 00 64 28 9b 00 00 ff 01 0d a3 c0 a8 02 04   E..d(...........
0030  c0 a8 02 06 08 00 06 69 04 02 06 14 00 00 00 00   .......i........
0040  15 67 58 64 ab cd ab cd ab cd ab cd ab cd ab cd   .gXd............
0050  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0060  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0070  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................
0080  ab cd ab cd                                       ....

【イーサリアルの<データ

つづく。

【GMPLS】 5. MPLSの設定

5. MPLSの設定

最後にLSPを作成します。 データチャネル専用のイーサ(fe-0/0/1)には仮想的に10.0.1.0/24の管理アドレスを振ってますので、 そこを通るようにLSPを作成します。 そして、LSPのタイプをGMPLS用にpsc-1、タイプをethernetにします。

mpls {
    no-cspf;
    label-switched-path gmpls-fe-0/0/1 {
        from 192.168.254.1;
        to 192.168.254.2;
        lsp-attributes {
            switching-type psc-1;
            gpid ethernet;
        }
        primary gmpls-path-1;
    }
    path gmpls-path-1 {
        10.0.1.2;
    }
    interface all;
    interface fxp0.0 {
        disable;
    }
}

ここまでの設定 ( R1  R2)

これでgmpls-fe-0/0/1と名付けたLSPがアップします。

gsi@R1# run show mpls lsp
Ingress LSP: 1 sessions
To              From            State Rt ActivePath       P     LSPname
192.168.254.2   192.168.254.1   Up     0 gmpls-path-1     *     gmpls-fe-0/0/1
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State Rt Style Labelin Labelout LSPname
192.168.254.1   192.168.254.2   Up     0 1 FF       3        - gmpls-fe-0/0/1
Total 1 displayed, Up 1, Down 0

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

つづく。

【GMPLS】 4. RSVPとOSPFの設定

4. RSVPとOSPFの設定

LMPの目的は、制御パケットを流せないデータチャネルの代わりに、制御を肩代わりすることです。 LMPに設定した情報をRSVPとOSPFに供給しないといけません。


RSVPの設定

RSVPの設定は簡単です。 どのインタフェースでRSVPを動かすか指定して、LMPで設定したpeerを加えるだけです。 注意しなければいけないのは、peerで指定した制御チャネルのインタフェースは、RSVPを動かしてはいけない点です。 ここではgre.0を除く全てのインタフェースでRSVPを動かせばよいことになります。

R1の設定は次のようになります。

protocols {
    rsvp {
        interface fxp0.0 {
            disable;
        }
        interface gre.0 {
            disable;
        }
        interface all;
        peer-interface R2;
    }

OSPFの設定

LMPの情報をOSPFに渡すには、peer-interfaceを設定するだけです。R1の設定は次のようになります。

protocols {
    ospf {
        area 0.0.0.0 {
            interface lo0.0;
            interface fe-0/0/0.0;
            interface fxp0.0 {
                disable;
            }
            peer-interface R2;
        }

以上でRSVPとOSPFの設定は終わりました。

ここまでの設定 ( R1  R2)

つづく。

【GMPLS】 3. LMPの設定

3. LMPの設定

GMPLSの主要コンポーネント、LMP(Link Management Protocol)を設定してみます。 この設定はやや面倒です。

te-linkの設定

R1-R2間には、データチャネル専用のイーサネット(fe-0/0/1)を設置しましたが、 これをLMPで扱えるように te-link というものを作成します。 GMPLSでは物理インタフェースそのものが常にデータチャネルになるわけではなく、 ポートやタイムスロット、波長で細分化したいはずです。 そのために論理的なリンクを用意してLMPで扱うわけですが、それがte-linkの設定です。

と言っても、イーサネットの場合は物理インタフェース(fe-0/0/1)をまるごと使いますので、 次のような設定を入れることになります。 ここではte-fe-0/0/1という名称で作成しました。

protocols {
    link-management {
        te-link te-fe-0/0/1 {
            interface fe-0/0/1;
        }

te-linkの設定はまだ不完全ですが、先に進みます。

peerの設定

R1-R2間のデータチャネル専用のイーサネット(fe-0/0/1)には、 OSPFやRSVPといった制御プロトコルを流すわけにいきません。 (フォトニックの世界なら、波長に相当するわけですから、これは当然です)。 ですから代わりとなる制御チャンネルを作成しなければいけません。 この設定がpeerという設定です。

peerの設定には、相手先ルータのアドレス、どこのインタフェースを代わりに使うか、 そしてどのte-linkを分担するのか、を設定します。

R1から見た場合、相手先ルータR2のアドレスは192.168.254.2とします。 192.168.250.2でも大丈夫ですが、ルータIDの方がかっこいいでしょう。 制御チャンネルは先ほど作成したGREトンネルを使います。

protocols {
    link-management {
        te-link te-fe-0/0/1 {
            interface fe-0/0/1;
        }
        peer R2 {
            address 192.168.254.2;
            control-channel gre.0;
            te-link te-fe-0/0/1;
        }
    }
}

再びte-linkの設定

peerを設定したらte-linkの設定に戻ります。 peerの設定をしないと、te-linkに必要な情報が得られないため、こんな面倒なことになってます。 それでは show link-management コマンドで必要な情報を入手しましょう。 R1で実行すると次のようになります。

gsi@R1# run show link-management
Peer name: R2, System identifier: 11783
 State: Up, Control address: 192.168.254.2
   Control-channel                   State
   gre.0                             Active
  TE links:
   te-fe-0/0/1

 TE link name: te-fe-0/0/1, State: Up
  Local identifier: 55334, Remote identifier: 0, Encoding: Ethernet, Minimum bandwidth: 100Mbps,
  Maximum bandwidth: 100Mbps, Total bandwidth: 100Mbps, Available bandwidth: 100Mbps
    Name          Local ID  Remote ID      Bandwidth Used  LSP-name
    fe-0/0/1         54190          0        100Mbps   No

必要なのは、te-linkのidと、interfaceのidです。上記によると、

  • 自分のte-link idは55334
  • 相手のte-link idは0(不明)
  • 自分のinterface idは54190
  • 相手のinterface idは0(不明)

となっています。相手の情報を知らないのは仕方ないです。何も設定してませんから。重要なのは自分のidです。 自分のidを相手側(ここではR2)に設定します。R2の設定は次のようになります。

link-management {
    te-link te-fe-0/0/1 {
        remote-id 55334;
        interface fe-0/0/1 {
            remote-id 54190;
        }
    }
    peer R1 {
        address 192.168.254.1;
        control-channel gre.0;
        te-link te-fe-0/0/1;
    }
}

R1を設定するには、R2でshow link-managementを叩き、te-link idとinterface idを調べる必要があります。 実機で叩かないといけないのはいかにも不便ですが、juniperはそうなっています。 プロトコルの仕様上こうなっているのか、juniperの都合でこうなっているのかは不明です。 これは後で調べることにして、先に進みます。

te-linkにアドレスを振る

te-linkには管理用のIPアドレスを振る必要があります。 物理インタフェースにアドレス振ったんだから、そこから拾ってきて欲しいものですが・・・
fe-0/0/1には10.0.1.0/24のアドレスを割り当てましたから、次のように設定します。

link-management {
    te-link te-fe-0/0/1 {
        local-address 10.0.1.1;
        remote-address 10.0.1.2;
        remote-id 55334;
        interface fe-0/0/1 {
            local-address 10.0.1.1;
            remote-address 10.0.1.2;
            remote-id 54190;
        }
    }
    peer R2 {
        address 192.168.254.2;
        control-channel gre.0;
        te-link te-fe-0/0/1;
    }
}

LMPの設定はこれで完成です。

ここまでの設定 ( R1  R2)

つづく。

【GMPLS】 2. 実験構成

2. 実験構成

まずは基本構成を作成してみます。 Juniper M10を2台使って、アウトバンドでルーティングする構成を作ってみます。 これをGMPLSの構成に育ててみたいと思います。

Juniperのマニュアル

設定 ( R1  R2)

この構成の設定は簡単なので解説はいらないと思います。


GREトンネルの設定

最初にやるのは、GREトンネルの設定です。 GMPLSではLMP用のアウトバンド制御チャンネルが必要になるのですが、 それはポイントツーポイントでないといけないそうです(Juniperのマニュアルの片隅に書いてあります)。 プロトコルの仕様上なのか、Juniperの作りでそうなっているのかは分かりません。 それは後で調べるとして、ポイントツーポイントのリンクとしてここではGREトンネルを用意したいと思います。

設定 ( R1  R2)

R1には次のような設定を追加します(R2も同様)。

interfaces {
    gre {
        unit 0 {
            tunnel {
                source 192.168.1.1;
                destination 192.168.1.2;
            }
            family inet {
                address 192.168.250.1/24;
            }
            family mpls;
        }
    }

これ自体は普通のGREの設定なのですが、注意しないといけないのは、 作成したGREトンネルをOSPFルーティングの対象にしない点です。 ルーティング対象にすると、この後困ることになります。 MPLSのシグナリングを通すことになりますので、family mplsも入れておきます。


データチャンネル用のイーサネットの追加

データチャンネル専用のイーサネットとして、fe-0/0/1でR1-R2間を接続します。 データチャンネル専用なのですが、管理用のIPアドレス 10.0.1.0/24 を割り当てます。 このアドレスはRSVPでLSPを作成するときに「ここを通す」という指定に使います。 (イーサの場合、相手先ルータのMACアドレスを知るためにも使います。 そういう意味で、制御用の通信がまったく流れない、というわけではありません。 もちろんスタティックにARPテーブルを作っておけば、fe-0/0/1上には制御用通信はまったく流れません)。

設定 ( R1  R2)

R1のfe-0/0/1は次のようになります。 データチャネル専用ですから、OSPFのルーティング対象に入れてはいけません。

fe-0/0/1 {
    description "Data channel to R2";
    speed 100m;
    mtu 1500;
    link-mode half-duplex;
    unit 0 {
        family inet {
            address 10.0.1.1/24;
        }
        family mpls;
    }
}

基本構成はここまで。

つづく。

より以前の記事一覧