ジュニパーのルーティングインスタンス

ルーティングインスタンスは、ルーティングテーブル、インターフェイス、およびルーティングプロトコルパラメータの集合です。 ルーティングプロトコルは、ルーティングテーブル内の情報を制御します。1つのルーティングインスタンスには、IPv4とIPv6の両方のルートと、複数の物理インターフェイスまたは論理インターフェイスが同時に存在できます。 複数の論理ユニット（サブインターフェース）に分割された1つの物理インターフェースを異なるルーティングインスタンスに割り当てることができます（ただし、同じユニット（サブインターフェース）、またはユニットに分割しない場合、物理インターフェースを異なるルーティングインスタンスに接続することはできません） ）

ルーティングインスタンスはJunOSオペレーティングシステムの強力なツールであり、cリブグループ、ファイアウォールフィルター、およびポリシーと組み合わせることで、あらゆるタスクを実行できます。 残念ながら、多くのエンジニアは、ほとんどのルーティングインスタンスの目的を知りません。

JunOSでは、構成に使用できるルーティングインスタンスの幅広い選択肢が提供されます。

routing-instances { routing-instance-name { interface interface-name; instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf); } } 

執筆時点では、次のタイプのルーティングインスタンスを構成に使用できます。
1. VRF、
2.転送、
3.仮想ルーター、
4.非転送、
5. VPLS、
6.レイヤー2 VPN
7. Layer2コントロール（MXシリーズルーターのみ）、
8.仮想スイッチ（MXシリーズルーターのみ）、
9.レイヤー2バックホールVPN（MXシリーズルーターのみ）（これについては別の投稿を書きます）。

誰かが記事で何らかの事務的または不正確なものを見つけた場合（私も人間であり、誤解する可能性があります）、誰かが追加する場合は、必要な情報へのリンクを含む個人的なメッセージを書いてください。

VRF（仮想ルーティングおよび転送）。

ほとんどの人は、このタイプのルーティングインスタンスを知っています。 その機能は、シスコの世界と同様であり、MPLSベースのサービスの実装に使用されます（たとえば、L3VPN、6VPE）。

VRFは、メインルーター（またはスイッチ）内の独立したルーターではありません。 VRFは、ルーティングテーブルとクライアントインターフェイスを、メインルーティングテーブルとルーターインターフェイス、およびルーティングテーブルと他のクライアントインターフェイスから分離します。 VRF設定は次のとおりです。

 root@PE2# show routing-instances 6pe-2 { instance-type vrf; interface ge-0/0/3.101; route-distinguisher 2001:31133; vrf-target target:200:31133; vrf-table-label; routing-options { router-id 101.101.101.101; } protocols { ospf3 { export isis-ce2-export; area 0.0.0.0 { interface ge-0/0/3.101; } } } } 

このルーティングインスタンスの機能は、すべてのルーティングプロトコル、静的ルート、ラベル配布プロトコルldp（ただし、rsvpはサポートされません）、およびルートのエクスポートとインポート（メインルーティングインスタンスのルーティングプロトコルおよびルーターで構成された他のVRFから）をサポートします。

構成では、一意のルート識別子値、ルートターゲット（インポートおよびエクスポート）値、およびこのルーティングインスタンスに関連するクライアント側のインターフェースを指定する必要があります。 RTとRDの使用は、l3vpn（それぞれ、およびこのロジックを使用する他のテクノロジー、たとえば6VPE）の実装における重要な概念の1つです。これらの2つの値により、異なるクライアントおよび後続のクライアントから受信した重複クライアントアドレス（RD）およびフィルタープレフィックスを使用できますそれらを分離ルーティングテーブル（RT）にインストールします。 このルーティングインスタンスは、instance_name.inet.0またはinstance_name.inet6.0という名前の独自のルーティングテーブルを作成します。

 vrf1.inet.0: 12 destinations, 22 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 *[OSPF/10] 01:59:31, metric 2 > to 10.0.1.1 via ge-0/0/0.0 10.1.1.1/32 *[OSPF/10] 01:59:31, metric 2 > to 10.0.1.1 via ge-0/0/0.0 10.2.2.2/32 *[OSPF/10] 01:59:31, metric 2 > to 10.0.1.1 via ge-0/0/0.0 

クライアントのルーティングテーブルには、このクライアントの他のサイトへのルートとその内部ルートのみがあります。 つまり、クライアントにとって、プロバイダーのネットワークは透過的であり、すべてのサイトが接続されているルーターのように見えます。

クライアントのルーティングテーブルに加えて、別のルーティングテーブルbgp.l3vpn.0がルーター上に作成され、bgpプロトコル（アドレスファミリinet-vpnユニキャスト）を使用してルーターが受信したすべてのルートが、構成されたRTインポート値に従ってインストールされます。

 bgp.l3vpn.0: 12 destinations, 9 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 100:100:10.0.0.0/16 * 10.2.2.2 0 100 ? 100:100:10.0.1.1/32 * 10.2.2.2 0 100 ? 200:100:10.0.0.0/16 * 10.3.3.3 0 100 ? 

注：このVRFでISISプロトコルを実行する必要がある場合、NETアドレスでLo論理インターフェイスの追加ユニットを設定し、この論理インターフェイスをVRFに接続する必要があります。

 ce2-l3vpn { instance-type vrf; interface ge-0/0/2.0; interface lo0.1; # VRF  unit 1  Lo0 route-distinguisher 10.0.1.0:31133; vrf-target target:10:31133; protocols { isis { export isis-ce2-export; interface ge-0/0/2.0; interface lo0.1; } } } 

注：構成には、vrf-table-labelコマンドがあります。 デフォルトでは、JunOSはクライアントルートにネクストホップごとのラベル割り当てを使用します。 上記のコマンドは、ラベル配布モードをper-vrfに設定します。つまり、特定のvrfのすべてのルートは同じラベルを持ちます。 （興味がある人がいれば、これについての記事を書きます。）

次のタイプのルーティングインスタンス- 転送に渡します。

ご存知のように、JunOSは、特にこの新人がシスコの世界から来た場合、一見理解できない構成で多くの新人を怖がらせます。 たとえば、Ciscoでポリシーベースルーティング（PBR）を実行する必要がある場合、アクセスリストと単純なルートマップを記述します。 JunOSではすべてがより複雑になりますが、ジュニパーのアプローチを理解すれば、それがTsiskovskyのアプローチよりもはるかにエレガントであることを理解できます。 なぜこれを書いているのですか？ 実際、ルーティングインスタンスの転送は、PBRの目的のために特別に考案されたものです（ジュニパーの世界では、このタイプのルーティングはフィルターベースのルーティングと呼ばれます）。 このルーティングインスタンスの構成は次のとおりです。

 [edit routing-instances] root# show forward { instance-type forwarding; routing-options { static { route 10.0.0.0/24 next-hop 10.0.1.1; } } } 

すべてがシンプルです-RT、RDではありません。 このルーティングインスタンスは、インターフェイスの指定とルーティングプロトコルの構成をサポートしていません*。 実際のところ、FBRの操作にはこれは必要ありません。 必要なネクストホップで静的ルートを作成し、ルーターにパケットが到着するインターフェイスにフィルターを配置します。たとえば、発信アドレスが一致した場合、静的ルートに沿って構成されたルーティングインスタンスを介してトラフィックを送信します。そうでない場合、パケットはメインルーティングテーブルに従って「飛行」します。

ただし、ルーティングインスタンスが必要なネクストホップにパケットを送信できるようにするには、このネクストホップへのルートが必要です。 これを行うには、ルーティングテーブルinet.0から構成済みのルーティングインスタンス（instance_name.inet.0と呼ばれます）のルーティングテーブルにルートを転送する必要があります。すべてのルートが必要なわけではありません（直接接続されていることも覚えています）。 これは、リブグループを使用して行われます 。詳細については、 こちらを参照してください 。

このルーティングインスタンスは、メインのルート以外のルートに沿ってトラフィックを誘導できるコンテンツを操作することにより、独自のルーティングテーブルを作成します。

* JunOSでは、このタイプのルーティングインスタンスでospfまたはisisなどを構成できます（BGPはサポートされていません）が、ルーティングインスタンスにインターフェイスが割り当てられていないため、ルーティングプロトコルの使用は無意味になり、メインテーブルからrib-経由でルートを追加できます個別のルーティングプロトコルを使用しないグループ。

仮想ルーター。

ルーティングインスタンスの仮想ルーター機能は、シスコのvrf-liteに似ています。 このルーティングインスタンスにより、ripからbgpへのルーティングプロトコルの実行、GREおよびipsecトンネルの作成、natおよびdhcp機能の実装、LDPプロトコルのサポートが可能になります（ただし、RSVPはサポートされません）。 このルーティングインスタンスの主な目的は、クライアントインターフェイスとそのルーティングテーブルを分離することです。 仮想ルーターの最も近いものは、ルーティングインスタンスの非転送（以下で説明します）と呼ばれますが、それらの機能はやや似ています。 ただし、検討しているルーティングインスタンスタイプは、instance_name.inet.0（instance_name.inet6.0）という名前の別のルーティングテーブルへのルートを設定します。

 r6.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 60.0.0.0/30 *[Direct/0] 00:11:18 > via ge-0/0/2.0 60.0.0.1/32 *[Local/0] 00:11:18 Local via ge-0/0/2.0 60.1.1.1/32 *[OSPF/10] 00:11:04, metric 2 > to 60.0.0.2 via ge-0/0/2.0 224.0.0.5/32 *[OSPF/10] 00:11:19, metric 1 MultiRecv 

このルーティングインスタンスにあるルートのみがクライアントに与えられます。 リブグループを使用すると、メインルーティングテーブルからクライアントのルーティングテーブルにルートを再配布したり、ルーターに存在する仮想ルーター間でルートを再配布したりできます。

このタイプのルーティングインスタンスは非常に頻繁に使用されます。 VRFと比較すると、このルーティングインスタンスによりRTとRDを設定する必要がなくなります。 このルーティングインスタンスの設定例を次に示します。

 r6 { instance-type virtual-router; interface ge-0/0/2.0; } protocols { ospf { export export-200; area 0.0.0.0 { interface all; } } } 

次のタイプのルーティングインスタンスは、転送なしです。

このタイプのルーティングインスタンスは、前の3つとは異なり、独自のルーティングテーブルを作成しますが、メインのデフォルト転送テーブルにすべてのルートをインストールします。

fibとribの違いは、すべてのルート（ospfプロトコルなど）がribに到達することです（たとえば、同じプレフィックスに2つのルートがあります-両方がribに表示されます）が、これらのルートのうち最適なもののみがfibに移動して使用されますトラフィック転送（例外、例えばECMP）。 また、ribは、ネットワーク内のピア間のルーティング情報の保存と交換を目的としており、トラフィックの送信には不便です。 Fibは、トラフィックの送信に必要なデータをすばやく見つけるように設計されており、ハードウェアベースのトラフィック処理を実装することを可能にします。

このルーティングインスタンスは、第3レベル（VLANなど）でネットワークをセグメント化する必要がある場合に使用されます。 設定は次のとおりです。

 [edit routing-instances] root# show noforward { instance-type no-forwarding; interface ge-0/0/3.0; routing-options { auto-export; } protocols { ospf { export export-100; area 0.0.0.0 { interface ge-0/0/3.0; } } } } 

注：自動エクスポートは、メインルーティングインスタンスとルーティングインスタンスの非転送で構成する必要があります。そうしないと、期待どおりの結果が得られません。

このルーティングインスタンスがどのように機能するかを見てみましょう。 ルーティングインスタンスがいくつか構成されています。

 root> show route instance summary Instance Type Primary RIB Active/holddown/hidden master forwarding inet.0 19/0/0 __juniper_private1__ forwarding __juniper_private1__.inet.0 7/0/0 __juniper_private2__ forwarding __juniper_private2__.inet.0 0/0/1 __master.anon__ forwarding forward forwarding forward.inet.0 7/0/0 no-frw non-forwarding no-frw.inet.0 16/0/0 virtual-router virtual-router virtual-router.inet.0 14/0/0 

3つの構成済みのルーティングインスタンスと1つの既定のルーティングインスタンスがあるという結論から得られます（プライベートルーティングインスタンスは考慮しません）。

タイプvirtual-routerの1.virtual-router（ルーティングテーブルvirtual-router.inet.0と一致）
タイプ転送を使用した2.forward（ルーティングテーブルforward.inet.0に対応）
3.default（inet.0ルーティングテーブルに一致）
4.非転送タイプのno-frw（ルーティングテーブルno-frw.inet.0と一致）

今のところ、通常どおり-各ルーティングインスタンスには独自のルーティングテーブルがあります。
次に、ルーターの転送テーブルでの状況を見てみましょう。

 root> show route forwarding-table | match table Routing table: default.inet Routing table: __master.anon__.inet Routing table: forward.inet Routing table: virtual-router.inet Routing table: default.iso Routing table: __master.anon__.iso Routing table: forward.iso Routing table: virtual-router.iso Routing table: default.inet6 Routing table: __master.anon__.inet6 Routing table: forward.inet6 Routing table: virtual-router.inet6 Routing table: default.mpls Routing table: :mpls-oam.mpls Routing table: default.ethernet-switching Routing table: default.vmembers Routing table: default.device-route Routing table: default.MSTI Routing table: default.dhcp-snooping 

転送テーブルのみが作成されます：
1.virtual-router.inet.0
2.forward.inet.0
3. default.inet.0

no-frw.inet.0のforwarding-tableは存在しないため、ルーティングインスタンスno-forwardingは、そのルートをforwarding-tableのデフォルトにインストールします（より正確には、ルーティングテーブルに加えて、ルーティングインスタンスno-forwardingはそのルートをデフォルトのinetにエクスポートします。 0、彼らはデファウルフィブに入る）。

その後、疑問が生じます-なぜこのルーティングインスタンスが必要なのですか？ シスコとは異なり、ジュニパーのハードウェアでは、同じインスタンスで同じルーティングプロトコルの2つのコピーを実行できません。 つまり、シスコでospf 1プロセスとospf 2プロセスを同時に開始できる場合、JunOSでは[edit protocols]階層レベルで、同じプロセスの2つのコピー、たとえばOSPFを開始する方法はありません（エリアと混同しないでください。いくつかあるかもしれないので）。 このルーティングインスタンスは、同じルーティングプロトコルの複数のコピーを実行するように設計されています。

このルーティングインスタンスの機能は、BGPを除くすべてのルーティングプロトコルをサポートします。 ldpまたはrsvpラベル割り当てプロトコルもサポートされていません。

完全を期すために、次のスキームを検討してください（ジュニパーのWebサイトから取得）。

したがって、CE2がCE3とのみ通信し、それに応じてCE1がCE4とのみ通信できるようにするとします。 ここでは、ルーティングインスタンスの非転送を使用します。
PE0およびPE2でno-forwardingタイプの2つのルーティングインスタンス（1および2）を作成し、それらに必要なインターフェイスを指定して、ospfを実行します。

ospfルーティングインスタンス1プロセスがCE1からルートを受信し、これらのルートにタグ100を追加してデフォルトのリブinet.0にエクスポートし、ospfルーティングインスタンス2プロセスがCE2から受信したルートに200タグを追加してデフォルトにエクスポートするポリシーを作成しますリブinet.0

つまり、CE1とCE2からのすべてのルートをinet.0で受け取り、CE1からのルートとCE2からのルートを明確に区別できます。

さらに、これらのルートはタグとともにPE2に転送されます。 ポリシーを使用して、ルーティングインスタンス1のPE2で、200のタグを持つルートのみをCE3にエクスポートするように指定します。したがって、100のタグを持つルートのみをCE4にエクスポートする必要があります。その結果、3番目のレベルでほぼVLANを取得しました

必要に応じて、CE1とCE4の間、したがってCE2とCE3の間でトラフィック交換が可能です。 CE1とCE3の間でトラフィック交換が不可能なのはなぜですか？ 単純な理由により、CE1にはCE2またはCE3へのルートがありません。 同様の状況は、このトポロジの他のルーターでも見られます。

一見すると、考慮されているルーティングインスタンスは仮想ルーターに非常に似ています。 しかし、他の目的のためであり、機能が少ないことを理解していただければ幸いです。

VPLS。

VPLSテクノロジーの動作原理は、この記事の本文には含まれていませんが、説明によって部分的に影響を受けます（そうでない場合は何も説明できません）。

Virtual Private LAN Serviceを実装する必要があります。このルーティングインスタンスを作成します。 実際、機能的にVRFを繰り返します（特にBGPシグナリングを使用する場合）が、L2サービスの実装を目的としています。 このタイプのルーティングインスタンスを使用すると、クライアントサイト間の仮想l2接続から完全に接続されたトポロジを自動的に作成できます。 このルーティングインスタンスは、ルーティングおよびラベル配布プロトコルを実行する必要がないため、それらの構成をサポートしていません。 このルーティングインスタンスはIPアドレスではなくl2で動作するため、転送テーブルにはMACアドレスが格納されます。

 Routing table: vpls_bgp_signalig.vpls VPLS: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 587 1 ge-0/0/3.0 user 0 comp 580 2 lsi.1048577 user 0 comp 581 2 ca:04:76:68:00:1c/48 dynm 0 ucst 577 3 ge-0/0/3.0 ca:05:79:f4:00:1c/48 dynm 0 indr 262142 5 10.0.0.2 Push 262146, Push 17(top) 572 2 ge-0/0/0.0 ca:08:5f:e4:00:1c/48 dynm 0 indr 262142 5 10.0.0.2 Push 262146, Push 17(top) 572 2 ge-0/0/0.0 

以下は、いずれかのクライアント（BGPシグナリング）のルーティングテーブルです。

 customer1.site1.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.1:100:1:1/96 *[L2VPN/170/-101] 04:00:26, metric2 1 Indirect 10.0.1.2:100:2:1/96 *[BGP/170] 00:04:23, localpref 100, from 1.1.1.254 AS path: I > to 20.0.0.2 via ge-0/0/1.0 10.0.1.3:100:3:1/96 *[BGP/170] 00:04:54, localpref 100, from 1.1.1.254 AS path: I > to 20.0.2.2 via ge-0/0/0.0, Push 299808 to 20.0.1.2 via ge-0/0/2.0, Push 299808 

10.0.1.1:100:1:1/96-このプレフィックスはクライアントのサイトを示し、以下で構成されます。
1.10.0.1.1：100-RD
2. 1-サイトID
3. 1-ラベルブロックオフセット（ラベルブロックシフト。誰かが興味を持っている場合、VPLSを編成するときのラベル操作に関する記事を別に書くことができます）

上記のルーティングテーブルに加えて、JunOSには別のルーティングテーブルbgp.l2vpn.0があり、このPEルーターのすべてのl2vpnルートが表示されます（bgpをアラームとして使用する場合）。

 bgp.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 30.0.1.1:100:102:97/96 *[BGP/170] 00:04:55, localpref 100, from 1.1.1.254 AS path: I > to 20.0.2.2 via ge-0/0/0.0, Push 299808 to 20.0.1.2 via ge-0/0/2.0, Push 299808 10.0.1.2:100:2:1/96 *[BGP/170] 00:04:23, localpref 100, from 1.1.1.254 AS path: I > to 20.0.0.2 via ge-0/0/1.0 

このルーティングインスタンスの設定は、VPLSの編成に使用されるシグナリング（BGP（Compell draft）またはLDP（Martini））に依存します。 設定は選択に応じて変わります。

Komplドラフト（BGPシグナリング）に従ってVPLSを実装すると、構成は次のようになります。

 routing-instances { customer1.site1 { instance-type vpls; interface ge-0/0/3.0; route-distinguisher 10.0.1.1:100; vrf-target target:10.0.1.0:100; protocols { vpls { no-tunnel-services; site site1 { site-range 10; site-identifier 1; interface ge-0/0/3.0; } } } } 

Compellドラフトには自動検出PEルーターが含まれているため、構成では、インターフェイスに加えてRTとRDを指定する必要があります。 前に示したように、RDは、クライアントサイトが接続されているPEルーターを検索および識別するために使用されます。 階層レベル[ルーティングインスタンスプロトコルvplの編集]では、サイトの名前、そのサイト識別子（構成で指定されている場合はJunOSで自動的に指定できます）、およびクライアントのサイトの最大数（サイト範囲）を指定する必要があり、サイト識別子はサイト範囲未満。

LDPシグナリング（Martini）を使用する場合、構成は少し簡単になります。

 ce3-vpls-ldp { instance-type vpls; interface ge-0/0/3.0; protocols { vpls { no-tunnel-services; vpls-id 101; neighbor 1.1.1.1; neighbor 2.2.2.2; } } } 

このVPLSテクノロジーは、追加の「松葉杖」なしで自動検出をサポートしません*。したがって、基本構成では、クライアントが接続されているインターフェイスのみが指定され、RTもRDもありません。 階層レベル[ルーティングインスタンスプロトコルvplの編集]では、クライアントサイトが接続されているすべてのPEルーターのループバックと、このクライアントのすべてのVPLSルーティングインスタンスで同じでなければならないVPLS-IDを指定する必要があります。

*この場合に自動検出を使用するには、アドレスファミリbgp l2vpn auto-discovery-onlyを使用してBGPを使用する必要があります。 同時に、PEルータでネイバーを明示的に指定する必要はありませんが、RT、RD、およびl2vpn-idを設定する必要があります。

 vpls100 { instance-type vpls; interface ge-1/1/0.100; l2vpn-id l2vpn-id:100:200; vrf-target target:100:208; protocols { vpls { no-tunnel-services; } } } 

このルーティングインスタンスが確立した接続のステータスは、show vpls connectionsコマンドで確認できます。

 [edit] root# run show vpls connections Layer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned <- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label MM -- MTU mismatch MI -- Mesh-Group ID not available BK -- Backup connection ST -- Standby connection PF -- Profile parse failure PB -- Profile busy RS -- remote site standby SN -- Static Neighbor VM -- VLAN ID mismatch Legend for interface status Up -- operational Dn -- down Instance: customer1.site1 Local site: site1 (1) connection-site Type St Time last up # Up trans 2 rmt Up Nov 2 00:25:33 2015 1 Remote PE: 1.1.1.2, Negotiated control-word: No Incoming label: 262154, Outgoing label: 262153 Local interface: lsi.1049099, Status: Up, Encapsulation: VPLS Description: Intf - vpls customer1.site1 local site 1 remote site 2 3 rmt Up Nov 2 00:25:01 2015 1 Remote PE: 1.1.1.3, Negotiated control-word: No Incoming label: 262155, Outgoing label: 262153 Local interface: lsi.1049098, Status: Up, Encapsulation: VPLS Description: Intf - vpls customer1.site1 local site 1 remote site 3 

クライアントの観点からは、このテクノロジーはクライアントのサイトが接続されているスイッチのように見えます。

レイヤー2 VPN

Junosには、（少なくとも私が知っている限り）l2vpnを作成する3つの方法があります（VPLSとは異なり、l2vpnにはp2pトポロジがあります）。 このルーティングインスタンスは、設定が近く、VPLS BGPシグナリングにシグナリングされています。 この構成には、rdおよびrtを指定してPEルーターを検索し、p2p接続を確立することが含まれます。

 root# show instance-type l2vpn; interface ge-0/0/3.0; route-distinguisher 100:100; vrf-target target:1:1; protocols { l2vpn { encapsulation-type ethernet-vlan; no-control-word; site site2 { site-identifier 2; interface ge-0/0/3.0 { remote-site-id 1; } } } } 

彼女の兄のルーティングインスタンスvplと同様に、このルーティングインスタンスは、その目的のために、ルーティングプロトコルの構成を意味するものではありません。

このルーティングインスタンスの利点は、構成が容易であり、他のタイプのl2vpnとは異なり、スケーラビリティが優れていることです（必要に応じて他のサイトを簡単に追加できます）。 VPLSとは異なり、ルーティングインスタンスl2vpnはクロスプラットフォームの相互作用をサポートしていません（たとえば、ジュニパーとシスコの間）。

このルーティングインスタンスでは、VPLSを作成することはできませんが、複数の仮想L2接続を構成することはできます（ただし、これは本格的なVPLSではありません）。

ルーティングテーブルは、VPLSとほぼ同じに見えます。

 root@PE1> show route table vpn.l2vpn.0 vpn1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100:100:1:1/96 *[BGP/170] 00:14:00, localpref 100, from 10.1.1.1 AS path: I > to 10.0.0.2 via ge-0/0/3.0, label-switched-path pe1_to_pe2 200:200:1:2/96 *[L2VPN/170/-101] 00:17:35, metric2 1 Indirect 

show l2vpn connectionsコマンドを使用して接続のステータスを確認できます。出力はshow vpls connections（routing-instance VPLS）出力に似ています。

Layer2-control

このルーティングインスタンスは、VPLSマルチホーミングを使用してSTPファミリプロトコルを実行するように設計されています。そのアプリケーションはこの記事で非常によく説明されているので、繰り返しません。

仮想スイッチ

MXシリーズルーターは、ルーティングに加えて、スイッチに固有の機能も実行できます。最初に、MXシリーズルーターでVLANおよびトランクポートを構成する場合、すべてのVLANおよびトランクインターフェイスは、デフォルトスイッチルーティングインスタンスと呼ばれる同じブリッジドミアンに分類されます。 MXシリーズルーターは、カスタムルーティングインスタンス仮想スイッチを構成する機能を提供します。

 [edit] routing-instances { routing-instance-name ( instance-type virtual-switch; bridge-domains { bridge-domain-name { domain-type bridge; interface interface-name; vlan-id (all | none | number); vlan-id-list [ vlan-id-numbers ]; vlan-tags outer number inner number; } } protocols { mstp { ...mstp-configuration ... } } } } 

このルーティングインスタンスを使用すると、ルーターにスイッチ機能を実装し、インターフェイスと1つ以上のVLANを分離できます。つまり、仮想スイッチを使用すると、第3レベルでのネットワークセグメンテーションに頼らずに、第2レベルでのネットワークセグメンテーションが可能になります（IPアドレスを節約できます）。各セグメントに対して、STPファミリから独自のプロトコルを実行できます。MXシリーズルーターは、STP、RSTP、MSTP、VSTPのプロトコルをサポートしています。

ご清聴ありがとうございました！