はじめての LISP (Location/Identifier Separation Protocol)
現在、広く使われている IP アドレスは「ネットワークアドレスを頼りにルーティングし」「ホストアドレスを頼りにエンドポイントに到達する」という、ふたつの機能があります。ネットワークのプロトコルである LISP (Locator/Identifier Separation Protocol) を使うと、これらふたつの機能を分離して扱うことで、よりネットワークを拡張出来るというメリットがあります。今回は最小の構成を作り、Cisco IOS で LISP を設定してみます。
尚、プログラミング言語にも LISP (LISt Processor) という同じ名前のものがありますが無関係です。
用語説明¶
LISP の用語を構成図に当てはめると以下のようになります。
以下では各々の用語について解説していきます。
ITR / ETR (Ingress Tunnel Router / Egress Tunnel Router)¶
LISP は IP を IP でカプセル化して通信を行います。送信側と宛先側でカプセル化/解除を行うトンネルルータのことを以下のように呼びます。
略称 | 正式名称 | 説明 |
---|---|---|
ITR | Ingress Tunnel Router | 送信側サイトでカプセル化を行うトンネルルータ |
ETR | Egress Tunnel Router | 宛先側サイトでカプセル化を解除するトンネルルータ |
実際の通信では ITR と ETR 間でトンネルを張り、その中をカプセル化したパケットを流します。トンネルルータは ITR と ETR 両方の役割を担う (送信もするが、受信もする) ので、xTR という表現も RFC 上で使われています。
EID / RLOC (Endpoint ID / Routing Locator)¶
冒頭でも記載した通り、従来の IP アドレスは「位置情報」「識別情報」をひとつのアドレスで表現していましたが、LISP ではこれらを以下のように分けて管理します。
略称 | 正式名称 | 説明 |
---|---|---|
EID | Endpoint ID | 端末を識別する情報 |
RLOC | Routing Locator | LISP のトンネルルータに割り当てるアドレス。送信側トンネルルータの RLOC と宛先側トンネルルータの RLOC 間で UDP のトンネルを生成し、実際の通信はその中を通す |
実際の通信は ITR 〜 ETR 間のトンネル内を通りますので、中継区間のルータは RLOC のアドレスだけ解決出来れば良く、EID、つまり LAN 側の経路情報を保持する必要ありません。ですので、LISP には「中継区間での経路保持数を減らせる」というメリットがあります。
MS / MR (Mapping Server / Mapping Resolver)¶
初期状態では ITR は ETR の RLOC を保持していません。実際の通信要求があり、ETR の RLOC を解決する必要が出た場合、"LISP マッピングサービス" をという仕組みを使って宛先 EID と RLOC の紐付けを解決します。この「EID と RLOC の紐付け」のことを "マッピング" と呼びます。LISP マッピングサービスの仕組みは主に以下で構成されています。
略称 | 正式名称 | 説明 |
---|---|---|
MS | Mapping Server | ETR からの登録要求を受け付ける |
MR | Mapping Resolver | ITR からの問い合わせを受け付ける |
LISP マッピングサービスを使ったマッピング情報の解決は次で詳しく説明します。
LISP マッピングサービス¶
LISP マッピングサービスの動作シーケンス図を以下に示します。
- 予め、Mapping Server には EID / RLOC のマッピング情報を登録 (≒ 設定) しておきます。
- ETR は自分が管理している EID / RLOC のマッピング情報を MS へ Map-Register メッセージで送信します。MS は受信した Map-Register メッセージ内のマッピング情報を自身に登録されているマッピング情報と照会し、一致していれば ETR の登録を完了します。もし不一致であれば MS に ETR が登録されない為、以下に続く Map-Resolver メッセージに応答出来ず、結果的に通信が出来ません。
- LAN 内から別拠点宛の通信を ITR が受信します。ここで言う ""別拠点宛通信の宛先" 情報が「EID」になります。
- ITR は EID を管理する RLOC を解決する為、最初に ITR 自身が保持するマッピング・キャッシュ情報を照会します。キャッシュ中に EID / RLOC のマッピング情報が無ければ Map-Request メッセージを MR へ送信します。
- MR は MS へ Map-Request メッセージを転送します。
- MS は受信した Map-Request メッセージの EID を自身に登録されたマッピング情報と照会します。マッピング情報があれば、紐付く RLOC (これが ETR になります) へ Map-Request メッセージを転送します。
- ETR は ITR へ Map-Reply メッセージを送信します。
- Map-Reply メッセージした ITR は EID / RLOC のマッピング情報をキャッシュします。次回以降の通信ではこのキャッシュを用いることで MR への照会を省略出来ます。
- 端末 〜 端末間の通信が成立します。
MR から MS への問い合わせは LISP ALT (Alternative Logical Topology) や LISP DDT (Delegated Database Tree) といった仕組みを使うそうです。しかし、ひとつの組織内だけで LISP を使うのであれば MS と MR を同じルータに兼務させることで ALT や DDT を用いないシンプルな構成にするのが一般的だそうです。
Priority と Weight¶
LISP では同じ EID に対して複数の RLOC を登録することが出来ます。この場合、RLOC のうちもっとも Priority 値が高い RLOC が利用されます。もし複数の RLOC の Priority 値が同じであれば、各々の Weight 値の比率に応じて負荷分散を行います。
検証構成図¶
以下の構成で LISP を設定してみます。MS と MR は一台のルータで兼務します。検証環境は VIRL で構築し、ルータは全て IOSv 15.6(2)T を利用しています。(サイト内では無い) コアネットワーク部分は OSPF でルーティングさせています。
コンフィグ¶
各ルータのコンフィグは以下の通りです。
xTR1¶
xTR1 の全体コンフィグは以下の通りです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
以下、コンフィグのポイントを説明していきます。LISP のプロセスは router lisp で開始します。locator-set [SITENAME] でサイトの定義をし、そのサイトに紐付ける RLOC のアドレスを定義します。このアドレスは通常、自身のルータが持つ WAN 向けインターフェイスのうち、いずれかのアドレスになると思います。今回は負荷分散しないので Priority や Weight は意味を持ちませんので、適当に 1 を指定しています。
1 2 3 |
|
MS へ登録する EID は database-mapping でサイト名と紐付け、設定します。
1 2 |
|
ITR として利用する MR のアドレスは ipv4 itr map-resolver [MR-ADDRESS] で設定します。ETR として利用する MS のアドレスは ipv4 etr map-server [MS-ADDRESS] key [KEY-STRING] で設定します。
1 2 3 4 |
|
xTR2¶
xTR2 の全体コンフィグは以下の通りです。xTR1 と基本的には同じです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
MS/MR¶
上述の通り、今回の構成では MS と MR を一台のルータに兼務させます。MS/MR の全コンフィグは以下の通りです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
MS として Map-Register メッセージを受信した際に照会する EID の情報は eid-prefix [PREFIX/MASK] で設定します。また、ETR と同じ認証キーを authentication-key [KEY-STRING] で設定しておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
INTERNET¶
中継ルータは、とりあえず INTERNET という名前にしました。全コンフィグは以下の通りです。アドレスと OSPF を喋らせているだけで、LISP は設定していません。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
A¶
SITE-1 側の端末見立てのルータは A としました。全コンフィグは以下の通りです。
1 2 3 4 5 6 7 8 9 |
|
B¶
SITE-2 側の端末見立てのルータは B としました。全コンフィグは以下の通りです。
1 2 3 4 5 6 7 8 9 |
|
状態確認コマンド¶
LISP に関する基本的な確認コマンドは以下の通りです。「MS/MR」欄や「xTR」欄に "○" が付いているのは『そのルータでよく利用するコマンド』です。"×" が付いているのは『実行しても殆ど意味が無い、または無意味なコマンド』です。
コマンド | MS/MR | xTR | 説明 |
---|---|---|---|
show lisp session | ○ | ○ | LISP セッションの確立状況を確認出来る |
show lisp site | ○ | × | サイトごとのマッピング情報を確認出来る |
show ip lisp database | × | ○ | ETR 自身が管理しているマッピング情報を表示する |
show ip lisp map-cache | × | ○ | ITR がキャッシュしているマッピング情報を表示する |
初期状態¶
MS/MR¶
Map-Register メッセージ受信以前の初期状態では show lisp session を確認しても何も表示されません。
1 |
|
show lisp site では MS 上に設定した EID の情報が表示されます。但し、まだ ETR から Map-Register メッセージを受信していない為、Last Register が「never」表示になっています。
1 2 3 4 5 6 7 8 9 |
|
MS や MR では LISP マッピングサービスは提供していますが、自分自身には LAN が無いので、show ip lisp database を確認しても何も表示されません。
1 2 |
|
MS や MR が Map-Reply を受信することは無く、マッピング情報をキャッシュすることはありません。マッピング情報をキャッシュするのは Map-Reply を受信した ITR だけです。ですので、show ip lisp map-cache を確認しても何も表示されません。
1 |
|
xTR1¶
xTR 側で show lisp session を確認すると、xTR 自身に表示されている MR のアドレスが表示されます。しかし、まだ MR と通信出来ていない為、State が Unknown になっています。
1 2 3 4 5 |
|
show ip lisp database を確認すると自身が管理しているマッピング情報が表示されます。
1 2 3 4 5 6 7 |
|
まだ ETR からの Map-Reply を受信しておらず、キャッシュが生成されていない為、show ip lisp map-cache を確認しても何も表示されません。
1 2 3 4 5 |
|
xTR2¶
xTR2 も基本的には xTR1 と同様です。
1 2 3 4 5 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 |
|
Map-Register 送信後の状態¶
xTR1、xTR2、MS/MR 間を接続し、ETR から MS へ Map-Register が送信された後の状態を確認してみます。
MS/MR¶
show lisp session を確認すると xTR とセッションが確立していることが分かります。
1 2 3 4 5 6 |
|
show lisp site を確認すると Up が yes になっており、かつ、最後に Map-Register メッセージを受信してからの経過時間が表示されています。
1 2 3 4 5 6 7 8 9 |
|
xTR1¶
show lisp session を確認すると、xTR でもセッションが確立していることが分かります。
1 2 3 4 5 |
|
show ip lisp database の表示も特に変わりません。
1 2 3 4 5 6 7 |
|
同じく、show ip lisp map-cache の表示も特に変わりません。
1 2 3 4 5 |
|
xTR2¶
xTR2 も基本的には xTR1 と同様です。
1 2 3 4 5 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 |
|
Map-Request 送信後の状態¶
A から B へ Ping することで Map-Request メッセージが送信された状態を確認してみます。
A¶
B (192.168.2.222) 宛に Ping してみます。2 発、Ping 欠けがあった後、通信出来るようになりました。
1 2 3 4 5 |
|
MS/MR¶
MS/MR の表示は特に変わりません。
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 |
|
xTR1¶
show lisp session や show ip lisp database の表示は変わりません。
1 2 3 4 5 |
|
1 2 3 4 5 6 7 |
|
ETR から Map-Reply メッセージを受信したのでマッピング情報をキャッシュした為、show ip lisp map-cache でキャッシュを確認することが出来ます。
1 2 3 4 5 6 7 8 |
|
xTR2¶
xTR2 も基本的には xTR1 と同様です。
1 2 3 4 5 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 |
|
参考 URL¶
- Cisco IOS IP Routing: LISP Command Reference
- VIRLでLISP (1)
- RFC6830 The Locator/ID Separation Protocol (LISP)
- RFC6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments
- RFC6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
- RFC6833 Locator/ID Separation Protocol (LISP) Map-Server Interface
- RFC6834 Locator/ID Separation Protocol (LISP) Map-Versioning
- RFC6835 The Locator/ID Separation Protocol Internet Groper (LIG)
- RFC6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)