プレフィックスごと-1つのラベル-1つのクライアントプレフィックス。つまり、100個のクライアントvrfsがあり、各クライアントに100個のプレフィックスがある場合、100x100 = 10,000個のラベルを取得します。これは今日の標準では非常に無駄です。 デフォルトでvrfタグを配布するこの方法は、Ciscoルーターで使用されます。
ネクストホップごと -同じネクストホップを持つすべてのクライアントプレフィックスの1つのラベル。 クライアントルータが1つのリンクでPEルータに接続されている場合、すべてのプレフィックスは同じネクストホップを持つことになり、これは同じラベルを意味します。 JunOSでデフォルトでVRFラベルを配布するためのこのメカニズム。
per-vrf-vrf全体に1つのラベル。 ラベル配布の観点から、このモードは非常に経済的です。100個のクライアントvrfsがあり、各クライアントに100個のプレフィックスがある場合、100x1 = 100個のラベルを取得します。 このvrfラベルの配布では、ルータはmplsルックアップに加えてipルックアップを実行する必要があります。
上記のように、デフォルトでは、JunOSはネクストホップごとのラベル配布を使用します。 この動作を変更する場合は、vrf-table-labelコマンドを使用する必要があります（混乱した構成が好きな場合は、ポリシーを使用してラベル配布メカニズムを設定できます）。または、トンネルPICを使用します。 それでは、このチームとそれなしですべてがどのように機能するかを見てみましょう。 このようなスキームをオプションCで使用します。
vrf-table labelコマンドなし （およびvtインターフェイスの作成）。
PE1のVRF設定は次のとおりです。
bormoglotx@PE1> show configuration routing-instances CE1 instance-type vrf; interface ge-0/0/3.10; interface ge-0/0/3.20; route-distinguisher 1:1; vrf-target { import target:2:100; export target:2:100; } protocols { ospf { export ospf-export; area 0.0.0.0 { interface ge-0/0/3.10; interface ge-0/0/3.20; } } }
bormoglotx@PE1> show configuration interfaces ge-0/0/3 description "to SW1"; vlan-tagging; unit 10 { description "to CE1 site 1"; vlan-id 10; family inet { address 10.0.0.1/24; } } unit 20 { description "to CE1 site 2"; vlan-id 20; family inet { address 20.0.0.1/24; } }
したがって、ルータはvpnv4プレフィックスの生成を開始し、それらをルーティングリフレクタに送信します。 この場合、ルーターのアドレスは10.0.10.10です。
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/24 Self 100 I * 10.1.1.1/32 Self 2 100 I * 20.0.0.0/24 Self 100 I * 20.1.1.1/32 Self 2 100 I
PE1は、リフレクターに4つのルートを送信します。2つの接続されたネットワークと、ospfを介して受信する2つの/ 32（CEルータールーター）です。 これらのプレフィックスに対して生成されたラベルを見てみましょう。
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) * 10.0.0.0/24 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 299888 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [1] I Communities: target:2:100 * 10.1.1.1/32 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 299888 Nexthop: Self Flags: Nexthop Change MED: 2 Localpref: 100 AS path: [1] I Communities: target:2:100 rte-type:0.0.0.0:1:0 * 20.0.0.0/24 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 299904 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [1] I Communities: target:2:100 * 20.1.1.1/32 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 299904 Nexthop: Self Flags: Nexthop Change MED: 2 Localpref: 100 AS path: [1] I Communities: target:2:100 rte-type:0.0.0.0:1:0
明確にするために、結論からラベルの値のみを選択します。
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label VPN Label: 299888 VPN Label: 299888 VPN Label: 299904 VPN Label: 299904
10.0.0.0/8の範囲のプレフィックスの場合、ラベル299888が生成され、20.0.0.0 / 8の範囲のプレフィックスの場合、ラベル299904が生成されることがわかります。しかし、非常に快適なニュアンスはありません。この場合、JunOSはIPルックアップを生成しません。 これは何を脅かすのですか？ IPヘッダーが解析されないため、フィルターを使用できません。
実際に確認してみましょう。
以下の結論によれば、ラベル299904のパケットを受信したPE1は、単純にそれをge-0 / 0 / 3.20インターフェイスに送信します。
bormoglotx@PE1> show route table mpls.0 label 299904 mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299904 *[VPN/170] 00:46:19 > to 20.0.0.2 via ge-0/0/3.20, Pop
299888とラベル付けされたパケットの場合-ge-0 / 0 / 3.10インターフェース：
bormoglotx@PE1> show route table mpls.0 label 299888 mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299888 *[VPN/170] 00:46:25 > to 10.0.0.2 via ge-0/0/3.10, Pop
ご覧のとおり、ルーターはラベルを削除し、IPルックアップを実行せずに、着信ラベルに応じてパケットをインターフェイスに送信します。
PE2でvpnv4ルートを確認します。
PE2#sh ip bgp vpnv4 rd 1:1 labels Network Next Hop In label/Out label Route Distinguisher: 1:1 10.0.0.0/24 10.0.10.1 nolabel/299888 10.1.1.1/32 10.0.10.1 nolabel/299888 20.0.0.0/24 10.0.10.1 nolabel/299904 20.1.1.1/32 10.0.10.1 nolabel/299904
次に、CE2のルーティングテーブルを見てみましょう。
CE2#sh ip rou | b Ga Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks O E2 10.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10 C 10.0.1.0/24 is directly connected, GigabitEthernet1/0.10 L 10.0.1.2/32 is directly connected, GigabitEthernet1/0.10 O E2 10.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10 C 10.1.1.2/32 is directly connected, Loopback0 20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks O E2 20.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10 O E2 20.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
すべてが順調です-ルートがあります。 これで、トレースを20.0.0.2に実行できます-アドレスCE1-2：
CE2#traceroute 20.0.0.2 Type escape sequence to abort. Tracing the route to 20.0.0.2 1 10.0.1.1 36 msec 32 msec 8 msec 2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 56 msec 64 msec 60 msec 3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 72 msec 108 msec 40 msec 4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 60 msec 88 msec 60 msec 5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 76 msec 68 msec 64 msec 6 10.0.2.1 [MPLS: Label 299904 Exp 0] 60 msec 52 msec 64 msec 7 20.0.0.2 60 msec 60 msec 56 msec
すべてが予測可能-オプションCによる標準トレース
ここで、トレースを20.0.0.1に実行します-これは、クライアント側へのPE1インターフェースのアドレスです（記事の冒頭に、インターフェース構成が示されています）。
CE2#traceroute 20.0.0.1 Type escape sequence to abort. Tracing the route to 20.0.0.1 1 10.0.1.1 40 msec 4 msec 16 msec 2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 80 msec 64 msec 60 msec 3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 56 msec 60 msec 72 msec 4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 48 msec 76 msec 112 msec 5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 68 msec 96 msec 64 msec 6 10.0.2.1 [MPLS: Label 299904 Exp 0] 80 msec 68 msec 4 msec 7 20.0.0.2 92 msec 72 msec 64 msec 8 20.0.0.1 96 msec 48 msec 88 msec
出力を前の出力と比較すると、最大20.0.0.1がもう1つのホップであることがわかります。 20.0.0.1はネットワーク20.0.0.0/24へのゲートウェイであるため、どのようになりますか？ よく見ると、PEルーター（10.0.2.1-コアに面したインターフェイス）からのパケットがCEルーター（アドレス20.0.0.2）に送信され、PEルーター（20.0.0.1）に返されていることがわかります。 先ほど言ったように、JunOSはIPルックアップを行わず、単にパケットをクライアントインターフェイスに転送しましたが、ここでクライアントルーターはIPパケットの宛先アドレスをチェックし、PE1に送り返しました（下図を参照）。
つまり、この場合、ルーターはネットワークのコアからラベル付きのパケットを受信し、mpls.0テーブルを見て、パケットで何をする必要があるかを確認し、チェックを外して、クライアントに向けてインターフェースに送信しました。
クライアントインターフェイスのPEルーターでフィルターをハングさせるか、QoSを構成すると、上記を考慮して、インストールされたフィルターに従ってトラフィックが処理されません。
インターフェースのクライアント側にフィルターを掛けます：
bormoglotx@PE1# show firewall family inet filter To-CE1-2 term 1 { from { destination-address { 20.0.0.0/24; } } then { reject; } } term 2 { then accept; } [edit] bormoglotx@PE1# show interfaces ge-0/0/3.20 description "to CE1 site 2"; vlan-id 20; family inet { filter { output To-CE1-2; } address 20.0.0.1/24; }
そして、CE2を使用してネットワーク20.0.0.0/24にpingを実行します。
CE2#ping 20.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/69/72 ms
フィルターがありますが、機能しません。 vrf-tableラベルオプションを有効にして、この状況を変更します。
[edit] bormoglotx@PE1# set routing-instances CE1 vrf-table-label
CE2を使用してネットワーク20.0.0.0/24へのpingを再度開始してみましょう。
CE2#ping 20.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds: UUUUU Success rate is 0 percent (0/5)
これで、ホストに到達できなくなります-フィルターが満たされます。 フィルターを削除し、pingを再度実行して以下を確認します。
[edit] bormoglotx@PE1# deactivate interfaces ge-0/0/3.20 family inet filter [edit] bormoglotx@PE1# show | compare [edit interfaces ge-0/0/3 unit 20 family inet] ! inactive: filter { ... }
CE2#ping 20.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/148 ms
すべてが素晴らしいです。 これで、JunOSでvrfラベルを配布するためのデフォルトのメカニズムで、どのような落とし穴が待ち受けているかが明確にわかりました。 すでにvrf-table-labelコマンドを指定し、上記のフィルターを無効にしたので、vrf-table-labelオプションを有効にしてルーターの動作について説明し始めます 。
PE1がルートリフレクタに通知するルートを見てみましょう。
bormoglotx @ PE1> show route Advertising-protocol bgp 10.0.10.10
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/24 Self 100 I * 10.1.1.1/32 Self 2 100 I * 20.0.0.0/24 Self 100 I * 20.1.1.1/32 Self 2 100 I
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) * 10.0.0.0/24 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 16 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [1] I Communities: target:2:100 * 10.1.1.1/32 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 16 Nexthop: Self Flags: Nexthop Change MED: 2 Localpref: 100 AS path: [1] I Communities: target:2:100 rte-type:0.0.0.0:1:0 * 20.0.0.0/24 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 16 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [1] I Communities: target:2:100 * 20.1.1.1/32 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 1:1 VPN Label: 16 Nexthop: Self Flags: Nexthop Change MED: 2 Localpref: 100 AS path: [1] I Communities: target:2:100 rte-type:0.0.0.0:1:0
ご覧のとおり、vrf CE1からのすべてのルートに対して1つのラベルしかありません。
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label VPN Label: 16 VPN Label: 16 VPN Label: 16 VPN Label: 16
CE2から20.0.0.1までトレースを再度実行します。
CE2#traceroute 20.0.0.1 Type escape sequence to abort. Tracing the route to 20.0.0.1 1 10.0.1.1 32 msec 16 msec 20 msec 2 10.1.3.2 [MPLS: Labels 20/18/16 Exp 0] 76 msec 48 msec 68 msec 3 10.1.2.1 [MPLS: Labels 18/16 Exp 0] 68 msec 48 msec 56 msec 4 10.2.0.1 [MPLS: Labels 299952/16 Exp 0] 52 msec 48 msec 52 msec 5 10.0.3.2 [MPLS: Labels 299808/16 Exp 0] 52 msec 52 msec 52 msec 6 20.0.0.1 76 msec 52 msec 72 msec
現在、icmpパケットはCE1-2をループしません。
PE1のルート自体は、わずかに異なります。
bormoglotx@PE1> show route table mpls.0 label 16 mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 16 *[VPN/0] 00:04:23 to table CE1.inet.0, Pop
通常の言語では、ラベル16のパケットを受信する場合、テーブルCE1.inet.0でチェックを外してIPルックアップを行う必要があります。 ネクストホップごとのタグを生成するときに、この機能がジュニパーに実装されないのはなぜですか？ それは、ジュニパーのハードウェアアーキテクチャに関するものです。PFEは、mplsとip lookupの両方を同時に行うことはできません。 ダブルルックアップを実装するには、いわゆるトンネルサービスPIC、次にトンネルPIC（vt-fpc / pic / port.unit-numberインターフェイス）が必要です。 M120シャーシのPICは次のようになります。
注： ここで、vtインターフェイスの作成とvrfへの追加について読むことができます。
これで、パケット処理アルゴリズムが変更されます。ルーターは、ネットワークコアからラベル付きのパケットを受信し、mpls.0テーブルを見て、パケットで何をする必要があるかを確認し、チェックを外してvtインターフェイスに送信します。その後、vtインターフェイスからのパケットは再びPFEに送られますPFEはIPルックアップを実行できます（その後、クライアント側に送信します）。
ただし、トンネルPICが必要なため、この機能の使用には一定の制限が課せられます。 したがって、このようなPICがない場合は、vrf-table-labelコマンドを実行すると、JunOSはまったく同じ機能を実行する仮想lsi（ラベルスイッチングインターフェイス）インターフェイス（ACX、M、MX、Tシリーズプラットフォームでサポート）を自動的に作成しますvtインターフェイスのように：
bormoglotx@PE1> show interfaces terse | match lsi lsi up up lsi.0 up up inet
このインターフェイスは構成に使用できません。 各vrfに対して、このvrf用に生成されたラベルに関連付けられた個別のlsiインターフェイスが作成されます。 たとえば、別のvrfを作成し、現在のlsiインターフェイスの数を確認します。
bormoglotx@PE1> show configuration routing-instances ? Possible completions: <[Enter]> Execute this command <instance_name> Routing instance name CE1 Routing instance name CE2 Routing instance name + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups | Pipe through a command
bormoglotx@PE1> show interfaces terse | match lsi lsi up up lsi.0 up up inet lsi.1 up up inet
次のコマンドを使用して、どのlsiユニットがルーティングインスタンスに対応するかを確認できます。たとえば、show interfaces lsi routing-instance instance-name。
bormoglotx@PE1> show interfaces lsi routing-instance CE1 | match logical Logical interface lsi.0 (Index 71) (SNMP ifIndex 524) bormoglotx@PE1> show interfaces lsi routing-instance CE2 | match logical Logical interface lsi.1 (Index 81) (SNMP ifIndex 525)
lsiインターフェイスはvplsルーティングインスタンス（no-tunnel-servicesコマンド）に対しても作成されます。この場合のトラフィックは上記のように処理されます。ただし、vplsはmacアドレスのみで動作し、クライアントIPアドレスについては何も知りませんが、これは完全に別の話。
ご清聴ありがとうございました！