この記事は、ラジオ局のリスナーの要望に応じて書かれています。 JunOSでオプションCを設定する場合、多くの人が同じ質問を持っています。 JunOSでは、すべてがCiscoほど簡単ではなく、いくつかの問題が発生する可能性があります。 ポイントに直接行きましょう：症状は、Juniper機器でOpt.Cインターフェイスを整理するためにASBR BGP-LUセッションを構成したことです（リフレクター間のVPNv4セッションは当然ですが、それは何の関係もありません）が、さまざまな自律システムのPEルーターのループバック間にpingがありますただし、L3VPNは機能しません。 これがなぜ起こっているのか、どう対処するのかを理解しましょう。
Opt.Cは、opt.Bやopt.Aとは異なり、異なる自律システムのASBR間のセッションだけでなく、自律システム間のループバックにラベル付きのルートを転送するように設計されたASBR間のBGP-LUセッションを含む複雑なソリューションです。原則として、VPNv4プレフィックスを送信するように設計された、異なる自律システムのリフレクタ間のVPNv4セッション。 自律システム内で、ラベル付きのルートをリモートループバックに自分で配布する方法を選択します。ASBRから直接またはRRを介したBGP-LUセッション、またはIGPからASBRへのBGP-LUルートの再配布が可能です。 それぞれのアプローチには長所と短所があります。opt.Cの動作原理を説明した私の前回の記事でそれについて読むことができます。 選択はあなた次第ですが、私は個人的にはすべてがBGPを介して排他的に機能する場合に気に入っていますが、再配布が行われるセグメントとBGPが排他的に使用されるセグメントがあるネットワークを運用しています。
エミュレーターで問題を再現し、その本質の底に到達しましょう。 このグリッドをご覧ください：
ローカル自律システム内の隣接する自律システムからeBGP-LUによって取得されたラベルは、iBGP-LUを使用して配布されます（以前に書いたように、再配布を使用できますが、このアプローチは好きではありませんが、独自の落とし穴があります。さらに書きます）：
ジョイントの構成は同じで、RZN-ASBR1の場合は次のようになります。
bormoglotx@RZN-ASBR1# show protocols bgp group PE { type internal; family inet { labeled-unicast; } export NHS; neighbor 62.0.0.1 { local-address 62.0.0.3; } } group ASBR { type external; family inet { labeled-unicast; } export LO-export; neighbor 30.0.0.1 { local-address 30.0.0.0; peer-as 71; } } [edit] bormoglotx@RZN-ASBR1# show policy-options policy-statement NHS then { next-hop self; accept; } [edit] bormoglotx@RZN-ASBR1# show policy-options policy-statement LO-export term Lo { from { protocol ospf; route-filter 62.0.0.0/24 prefix-length-range /32-/32; } then accept; } term Lo-local { from { protocol direct; route-filter 62.0.0.0/24 prefix-length-range /32-/32; } then accept; } then reject;
TULA-ASBR1の場合、すべてが同じであり、アドレス指定用に調整されます。 最初のポリシーは、ローカルPEルーターの方向にハングアップし、単にネクストホップを自身と交換します。 2番目のポリシーは、リモートASBRの方向にハングし、ループバックへのルートのみを近隣の自律システムにエクスポートするように設計されています。
注：ポリシーには2つの用語があります-最初の用語はigpにあるループバックをエクスポートし、2番目の用語はigpではなく直接プロトコルでribにインストールされているため、独自のASBRループバックをエクスポートします。 これは1つの用語で実行できますが、私にとってはより便利です。
RZN-ASBR1とTULA-ASBR1間のBGP-LUセッションの状態を確認します。
bormoglotx@RZN-ASBR1> show bgp neighbor 30.0.0.1 Peer: 30.0.0.1+179 AS 71 Local: 30.0.0.0+56580 AS 62 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ LO-export ] Options: <Preference LocalAddress AddressFamily PeerAS Refresh> Address families configured: inet-labeled-unicast Local Address: 30.0.0.0 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 71.0.0.3 Local ID: 62.0.0.3 Active Holdtime: 90 Keepalive Interval: 30 Group index: 1 Peer index: 0 BFD: disabled, down Local Interface: ge-0/0/0.0 NLRI for restart configured on peer: inet-labeled-unicast NLRI advertised by peer: inet-labeled-unicast NLRI for this session: inet-labeled-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-labeled-unicast NLRI of received end-of-rib markers: inet-labeled-unicast NLRI of all end-of-rib markers sent: inet-labeled-unicast Peer supports 4 byte AS extension (peer-as 71) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 3 Received prefixes: 3 Accepted prefixes: 3 Suppressed due to damping: 0 Advertised prefixes: 3 Last traffic (seconds): Received 3 Sent 27 Checked 26 Input messages: Total 1731 Updates 7 Refreshes 0 Octets 33145 Output messages: Total 1728 Updates 3 Refreshes 0 Octets 33030 Output Queue[0]: 0
すべて順調です。3つのルートを指定し、同じものを受け入れます。 私の場合、直接iBGP-LUセッションがASBRとPEの間に構成され、ループバックが送信されます（回線が小さいため、リフレクターはありません）。
さらに進みます。 近隣の自治でRZN-ASBR1を正確にアナウンスするものを確認しましょう。
bormoglotx@RZN-ASBR1> show route advertising-protocol bgp 30.0.0.1 inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 62.0.0.1/32 Self 2 I * 62.0.0.2/32 Self 1 I * 62.0.0.3/32 Self I
驚きはありません-ラップベックのみを提供します。 これで、vpnv4の間にvpnv4セッションが上昇するはずです。 チェック：
bormoglotx@RZN-PE1> show bgp summary group eBGP-VPNV4 Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 10 3 0 0 0 0 bgp.l3vpn.0 1 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 71.0.0.1 71 6 6 0 0 1:02 Establ bgp.l3vpn.0: 0/1/1/0 TEST1.inet.0: 0/1/1/0
さて、セッションは終了し、1つのルートを取得していることがわかります。 ただし、次のホップは使用できないため、ルーティングテーブルにはルートがありません。
bormoglotx@RZN-PE1> show route table bgp.l3vpn.0 hidden bgp.l3vpn.0: 3 destinations, 3 routes (2 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1:1:10.0.1.0/24 [BGP/170] 00:02:14, localpref 100, from 71.0.0.1 AS path: 71 I, validation-state: unverified Unusable
inet.3テーブルにはループバックへのルートがなく、bgpがネクストホップを解決するため、この状態になります。 これを行うには、bgp-luでresolve-vpnセッションを有効にして、ルートがinet.0とinet.3の両方に設定されるようにします（デフォルトでは、BGP-LUルートはinet.0テーブルに移動します）。
bormoglotx@RZN-PE1> show route table bgp.l3vpn.0 hidden bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) bormoglotx@RZN-PE1> show route table bgp.l3vpn.0 10.0.1.0/24 bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:1:10.0.1.0/24 *[BGP/170] 00:05:10, localpref 100, from 71.0.0.1 AS path: 71 I, validation-state: unverified > to 10.0.0.1 via ge-0/0/0.0, Push 16, Push 299968, Push 299792(top)
ご覧のとおり、ルートはすぐに非表示から消え、ルーティングテーブルにインストールされました。
理論的には、すべてが構成されており、ルートがあります-トラフィックは行くはずです
bormoglotx@RZN-PE1> show route table TEST1.inet.0 10.0.1.1 TEST1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:02:54, localpref 100, from 71.0.0.1 AS path: 71 I, validation-state: unverified > to 10.0.0.1 via ge-0/0/0.0, Push 16, Push 299968, Push 299792(top) bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid PING 10.0.1.1 (10.0.1.1): 56 data bytes ..... --- 10.0.1.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss
しかし、実際には、私たちは壮大な失敗に見舞われます。 さらに、PEルータのループバック間の接続は次のとおりです。
bormoglotx@RZN-PE1> ping source 62.0.0.1 71.0.0.1 rapid PING 71.0.0.1 (71.0.0.1): 56 data bytes !!!!! --- 71.0.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 9.564/13.021/16.509/2.846 ms
それを理解しましょう。 これを行うには、中間ルーターがラベルで何をするかを確認する必要があります。
したがって、RZN-PE1は、プッシュ16、プッシュ299968、プッシュ299792（上）の3つのタグをプッシュします。 ラベル299792は、RZN-ASBR1に到達するために必要です。ラベル299968は、RZN-ASBR1が71.0.0.1（TULA-PE1）プレフィックス用に生成したラベルであり、ラベル16はvpnv4ラベルです。
スタック内の最上位ラベルはラベル299792であり、RZN-P1ルーターはこれと連携して、通過mplsパケットを受信します。スタック内の次のラベルは参照しません。 上記のラベルが付いたパケットを受信することにより、RZN-P1が行うべきことを確認します。
bormoglotx@RZN-P1> show route table mpls.0 label 299792 mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299792 *[LDP/9] 13:37:43, metric 1 > to 10.0.1.0 via ge-0/0/1.0, Pop 299792(S=0) *[LDP/9] 13:37:43, metric 1 > to 10.0.1.0 via ge-0/0/1.0, Pop
RZN-P1はRZN-ASBR1へのLSPの最後から2番目のルーターであるため、すべてが論理的です。次に、トップラベル（PHP）を削除し、2つのラベルを持つパケットをASBRに送信します。 つまり、RZN-ASBR1では、スタック299968のトップマークが付いたパケットが到着します。
bormoglotx@RZN-ASBR1> show route table mpls.0 label 299968 mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299968 *[VPN/170] 00:39:11 > to 30.0.0.1 via ge-0/0/0.0, Swap 300000
ここでも犯罪はありません-予想どおり、特定のラベルのスワップが発生し、TULA-ASBR1に転送されます。
次に、隣接する自律システムに移動し、受信したTULA-ASB1パッケージで何が行われるかを確認します。
bormoglotx@TULA-ASBR1> show route table mpls.0 label 300000 mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 300000 *[VPN/170] 00:40:48 > to 20.0.1.1 via ge-0/0/1.0, Pop 300000(S=0) *[VPN/170] 00:40:48 > to 20.0.1.1 via ge-0/0/1.0, Pop
TULA-ASBR1はトップラベルを削除し、1つのラベル（vpnv4ラベルであるラベル16）のみでTULA-P1パケットの側面にトラフィックを送信します。 これが私たちの問題です-TULA-P1はそのようなラベルを知らず、単にパケットをドロップします（16を知っている場合、他のサービスのラベルになり、トラフィックは少し遅れてドロップします）。
bormoglotx@TULA-P1> show route table mpls.0 label 16 bormoglotx@TULA-P1>
なぜこれが起こっているのですか？ ポイントは、BGP-LUセッションを介してラベルを生成するための基礎としてどのルートが使用されるかです。 デフォルトでは、ラベル付きユニキャストセッションにinet.0テーブルが使用されます。受信したルートがそれにインストールされ、ルートが返されます。 同時に、IGPルートはループバックへのルートを生成するためのベースとして使用されます（inet.0で最適であるため）。この場合、これらはospfルートです。 ご存知のように、IGPルートにはMPLSラベルがないため、ルートがBGP-LUセッションを介して送信された場合、TULA-ASBR1ルーターはルーティングテーブルにラベルを削除し、特定のインターフェース（この場合は、ラベル-ルーターは、トップラベルの下に別のラベルがあることを知りません-そこに行きません）。 つまり、単に2つのLSPをステッチすることはありません。 上記のすべての本質を下の図に示します。
しかし、なぜリモートPEへのpingが通過するのでしょうか？ 簡単です-PEルーターがicmpリクエストを送信するとき、vpnv4ラベルをハングさせません-パケットには2つのラベルのスタックが付属しています（まあ、または再配布を使用する場合は1つ）。 トラフィックはまだリモート自律システムのASBR（この場合はTULA-ASBR1）に到着しますが、既にわかっているように、選択解除され、既に裸のIPトラフィックが宛先ホストと同じIGPドメインにあるPルーターを通過し、ルートを知っています（TULA-P1は戻りルートを知りませんが、これはトラフィックの転送を妨げません）。 つまり、次のように機能します。
この問題を解決するにはいくつかの方法があります。 mplsトラフィックエンジニアリングオプションから始めましょう。 これはあなたが考えた交通工学ではありません（RSVPという言葉が思い浮かんだと思います）。 4つのトラフィックエンジニアリングオプションがあります。
bormoglotx@RZN-ASBR1# set protocols mpls traffic-engineering ? Possible completions: bgp BGP destinations only bgp-igp BGP and IGP destinations bgp-igp-both-ribs BGP and IGP destinations with routes in both routing tables mpls-forwarding Use MPLS routes for forwarding, not routing
bgpオプションはデフォルトオプションです。これにより、ルーターはldpおよびrsvpルートをinet.3テーブルにインストールするため、bgpのみがこれらのルートにアクセスできます（VPNv4 \ L2-signaling \ EVPNルートのネクストホップ解決）。 ただし、BGP-LUルートがinet.3ではなくinet.0に移動することに注意してください。
Bgp-igpオプション-このオプションは、ルーターがrsvpおよびldpルートをinet.0テーブルにインストールすることを強制します。この場合、inet.3は空になります。 ASBRがL3VPNを終了するためのPEとして使用される場合、松葉杖なしで動作を停止することに注意する必要があります。 別の副作用はルーティングです。
Bgp-igp-both-ribsオプション-このオプションは、ルーターに、inet.0テーブルとinet.3テーブルの両方へのldpおよびrsvpルートのインストールを強制します。 前のオプションのような副作用は、ルーティングが「壊れる」ことですが、L3VPNは機能します。
Mpls転送オプション-このオプションは、ルーターにinet.3からinet.0へのルートのコピーを強制しますが、これらのルートは転送にのみ使用できます。 inet.3に変更はありません。 副作用-以前にipを通過したトラフィック（たとえば、リモートループバックへのbgpセッション）は、mplsを通過します（ただし、これはおそらくマイナスよりもプラスになります-どちら側を見るかによって異なります）。
これらのオプション、特に2番目と3番目のオプションは注意して使用する必要があります。 これらのオプションは両方ともルーティングを中断します-ldpおよびrsvpルートはinet.0テーブルに表示されるため、通常、メインのigpプロトコルはisisまたはospfです。 ただし、IGPルートは、ラベル配布プロトコルよりもプロトコルの優先度が高いため、優先度が低くなります。 ルーティングが壊れます。これは、オプションをオンにする前に、ospf / isisを介したループバックが最良のルートとして表示された場合、ldp / rsvpルートが代わりになることを意味します。 たとえば、一部のエクスポートポリシーでfrom ospf条件を設定すると、この条件はすべての結果を満たさなくなります...上記のように、2番目のオプションもinet.3テーブルが空になるため危険です。 それを覚えておいてください。 しかし、mpls-forwardingオプションはまさに必要なものです。 有効にすると、inet.3からのルートは単純にinet.0にコピーされますが、転送のみになります。つまり、トラフィックはクリーンなIPではなく、mplsを経由します。
これらのオプションはいずれも新しいLSPを生成せず、既存のLSPのみがinet.0にコピー（または転送）されることを理解することが重要です。 これらのオプション（リストの2番目、3番目、4番目のオプションを意味する）を使用すると、ルーターがLSPを使用してL2 / 3VPNトラフィックだけでなく通常のトラフィック（ポイント間の場合）このトラフィックを交換したい場合は、LSPがあります-たとえば、これらのポイントはルータールーターです）、通常はクリーンなIPを使用します。
このオプションをオンにして、何が起こるかを確認してください。 覚えているように、初期のTUAL-ASBR1は300000ラベルを発表し、スワップの代わりにポップラベルを作成しました。 このオプションを有効にすると、ラベルが再生成されます。
bormoglotx@RZN-ASBR1> show route receive-protocol bgp 30.0.0.1 71.0.0.1/32 detail inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden) * 71.0.0.1/32 (1 entry, 1 announced) Accepted Route Label: 300080 Nexthop: 30.0.0.1 MED: 2 AS path: 71 I
TULA-ASBR1がラベル300080を発表したので、このラベルが付いた中継パケットを持つルーターが何をするかを見てみましょう。
bormoglotx@TULA-ASBR1> show route table mpls.0 label 300080 mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 300080 *[VPN/170] 00:04:07 > to 20.0.1.1 via ge-0/0/1.0, Swap 299776
これですべてが正常になりました-スワップマークが発生しました-LSPが結合されました。 そして、inet.0ルーティングテーブルで何が起こるかを次に示します。
bormoglotx@TULA-ASBR1> show route table inet.0 71.0.0.0/24 inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 71.0.0.1/32 @[OSPF/10] 00:05:50, metric 2 > to 20.0.1.1 via ge-0/0/1.0 #[LDP/9] 00:05:50, metric 1 > to 20.0.1.1 via ge-0/0/1.0, Push 299776 71.0.0.2/32 @[OSPF/10] 00:05:50, metric 1 > to 20.0.1.1 via ge-0/0/1.0 #[LDP/9] 00:05:50, metric 1 > to 20.0.1.1 via ge-0/0/1.0 71.0.0.3/32 *[Direct/0] 14:16:29 > via lo0.0
新しいルートがテーブルに表示されました。 次に、転送にLSP（LDP \ RSVPルート、＃マーク）を使用し、すべての同じIGPルート（現在は@マーク）をルーティングします。 以前のように、隣接ASBRの側へのルートは、ラベルのないospfルートから生成されることに注意してください。 しかし、現在は転送にLDPルートを使用しているため、ルーターはラベルをポップせずにスワップします。
さて、L3VPNが巻き上げられていることを確認してください。
bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid PING 10.0.1.1 (10.0.1.1): 56 data bytes !!!!! --- 10.0.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 6.861/16.084/47.210/15.596 ms
ASBRのigpで再配布を行う場合：
次に、ASBRが受信したプレフィックスのラベルを生成し、ネットワーク内で配布するように、ldpプロトコルで出力ポリシーを実行する必要があります。 デフォルトでは、JunOSはループバックに対してのみタグを生成し、同じCiscoとは異なり、ldpを介して受信したタグを持つルートに対してのみ、したがって、Cisco機器にはこのような問題はありません（ただし、十分な問題があります）。
RZN-ASBR-1では、bgp経由で受信したルートをospfにエクスポートしました（PEとASBR間のbgp LUはなくなりました）。
bormoglotx@RZN-ASBR1> show route receive-protocol bgp 30.0.0.1 inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 71.0.0.1/32 30.0.0.1 2 71 I * 71.0.0.2/32 30.0.0.1 1 71 I * 71.0.0.3/32 30.0.0.1 71 I
エクスポートポリシーによると、これらのルートはospfに移動します。
bormoglotx@RZN-ASBR1> show configuration protocols ospf export OSPF-EXPORT; area 0.0.0.0 { interface lo0.0 { passive; } interface ge-0/0/1.0 { interface-type p2p; } interface ge-0/0/0.0 { passive; } } bormoglotx@RZN-ASBR1> show configuration policy-options policy-statement OSPF-EXPORT term Remote-Lo { from { route-filter 71.0.0.0/24 prefix-length-range /32-/32; } then accept; } then reject;
隣接する自律システムから受信したルートは、外部としてospfデータベースに分類され、igpドメイン内に配信されます。
bormoglotx@RZN-ASBR1> show ospf database OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 62.0.0.1 62.0.0.1 0x80000016 2576 0x22 0xf0fb 60 Router 62.0.0.2 62.0.0.2 0x80000017 2575 0x22 0xf57b 84 Router *62.0.0.3 62.0.0.3 0x8000001a 80 0x22 0xd2dd 72 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *71.0.0.1 62.0.0.3 0x80000001 80 0x22 0x2afc 36 Extern *71.0.0.2 62.0.0.3 0x80000001 80 0x22 0x1611 36 Extern *71.0.0.3 62.0.0.3 0x80000001 80 0x22 0x225 36
RZN-PE1のルートの可用性を確認します。
bormoglotx@RZN-PE1> show route 71.0.0.1/32 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 71.0.0.1/32 *[OSPF/150] 00:02:10, metric 2, tag 0 > to 10.0.0.1 via ge-0/0/0.0
ルートはinet.0テーブルにのみありますが、bgpがbgp.l3vpn.0テーブルにルートをインストールするためには、inet.3テーブルのプロトコルネクストホップの前にlspが存在する必要があります。 現在、inet.3テーブルには、71.0.0.1 / 32プレフィックスへのルートがありません。 ldpはこれらのプレフィックスのラベルを生成しないため、ルートはありません。
bormoglotx@RZN-ASBR1> show ldp database Input label database, 62.0.0.3:0--62.0.0.2:0 Label Prefix 299776 62.0.0.1/32 3 62.0.0.2/32 299792 62.0.0.3/32 Output label database, 62.0.0.3:0--62.0.0.2:0 Label Prefix 300640 62.0.0.1/32 300656 62.0.0.2/32 3 62.0.0.3/32
lspを表示するには、RZN-ASBR1でldpの出力ポリシーを作成する必要があります。このポリシーでは、71.0.0.0 / 24の範囲のプレフィックスに対してラベルを生成する必要があることを示します。
bormoglotx@RZN-ASBR1> show configuration protocols ldp egress-policy LDP-EXPORT; interface ge-0/0/1.0; bormoglotx@RZN-ASBR1> show configuration policy-options policy-statement LDP-EXPORT term Local-Lo { from { route-filter 62.0.0.3/32 exact; } then accept; } term Remote-Lo { from { route-filter 71.0.0.0/24 prefix-length-range /32-/32; } then accept; }
LDPの出力ポリシーには注意してください、多くの場合、初めて設定するときに、エンジニアは空のinetを取得します。 ポリシーで指定したプレフィックスはLDPを介してアナウンスされますが、ルーターはこれらすべてのFECのソースであると見なし、inet.3にインストールしません（inet.3のローカルFECはインストールされていないため-デフォルトJunOSのローカルFECは独自のループバックであり、ldpを使用してlspを構築してください。 上記のポリシーでは、第1項で独自のluppeckを、第2項でbgpによって取得された近隣の自律性のラップバックを与えます。 ASBRのinetの別の自治区からルートをインストールする場合3。 次に、隣接する自律システムの方向のセッションに対して、オプションresolve-vpnを追加します。
bormoglotx@RZN-ASBR1> show configuration protocols bgp group ASBR type external; family inet { labeled-unicast { resolve-vpn; } } export LO-export; neighbor 30.0.0.1 { local-address 30.0.0.0; peer-as 71; }
これで、71.0.0.0 / 24の範囲のプレフィックスのラベルが生成されます。
bormoglotx@RZN-ASBR1> show ldp database Input label database, 62.0.0.3:0--62.0.0.2:0 Label Prefix 299776 62.0.0.1/32 3 62.0.0.2/32 299792 62.0.0.3/32 299952 71.0.0.1/32 299968 71.0.0.2/32 299984 71.0.0.3/32 Output label database, 62.0.0.3:0--62.0.0.2:0 Label Prefix 3 62.0.0.1/32 3 62.0.0.2/32 3 62.0.0.3/32 300704 71.0.0.1/32 300720 71.0.0.2/32 300736 71.0.0.3/32
inet.3のRZN-PE1でのデータ操作の後、近隣の自律システムのループバックにルートが表示され、その結果、L3VPN内の接続が表示されます。
bormoglotx@RZN-PE1> show route 71.0.0.1/32 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 71.0.0.1/32 *[OSPF/150] 00:09:17, metric 2, tag 0 > to 10.0.0.1 via ge-0/0/0.0 inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 71.0.0.1/32 *[LDP/9] 00:02:14, metric 1 > to 10.0.0.1 via ge-0/0/0.0, Push 299952 bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid PING 10.0.1.1 (10.0.1.1): 56 data bytes !!!!! --- 10.0.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 7.054/11.118/21.571/5.493 ms
これが問題の最初の解決策であると考えました。 次に、2番目に進みましょう。
先ほど言ったように、デフォルトでラベル付きユニカットルートはinet.0テーブルからインストールおよび配信されます。デフォルトでは、ラベル付きのルートもありません。 ルータに、inetテーブルからのルートの送受信を強制することができます。 これは次のように行われます。
bormoglotx@RZN-ASBR1# show protocols bgp group ASBR type external; family inet { labeled-unicast { rib { inet.3; } } } export LO-export; neighbor 30.0.0.1 { local-address 30.0.0.0; peer-as 71; }
注：ospf / isisルートはinetテーブルにないため、ポリシーでインポートするためにigpプロトコルを指定しないでください。
次に、近隣の自律システムに与えるものを見てみましょう。
bormoglotx@RZN-ASBR1> show route advertising-protocol bgp 30.0.0.1 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 62.0.0.1/32 Self 1 I * 62.0.0.2/32 Self 1 I
ルートは2つだけで、その前は3つでした。 自分へのルートは提供されません（ループバックRZN-ASBR1へ）。 理由-inet.3テーブルで靱皮を探すと理解しやすいです：
bormoglotx@RZN-ASBR1> show route table inet.3 62.0.0.3/32 bormoglotx@RZN-ASBR1>
ローカルFECはinet.3にインストールされていないため、ルートがないことは論理的です。 ループバックを指定するには、テーブルinet.0からテーブルinet.3にループバックをコピーする必要があります。 これを行うには、rib骨グループを作成し、それをインターフェイスルートに掛けます。
bormoglotx@RZN-ASBR1> show configuration | compare rollback 4 [edit routing-options] + interface-routes { + rib-group inet inet.0>>>inet.3-Local-Lo; + } + rib-groups { + inet.0>>>inet.3-Local-Lo { + import-rib [ inet.0 inet.3 ]; + import-policy Local-Lo; + } + } [edit policy-options] + policy-statement Local-Lo { + term Lo { + from { + protocol direct; + route-filter 62.0.0.0/24 prefix-length-range /32-/32; + } + then accept; + } + then reject; + }
したがって、この行：
import-rib [ inet.0 inet.3 ]
inet.0テーブルからのルートをinet.3テーブルにコピーする必要があることを示しています。 そして、これがこの行です
import-policy Local-Lo
すべてのルートをコピーしないように、このインポートにポリシーを適用します。 さて、最後に、このrib骨グループはどこにねじ込まれなければなりません。 直接ルートをコピーするため、インターフェイスルートに固定します。
このような操作の後、ループバックへのルートはinet.3テーブルでアクセス可能になります（ただし、ldp / rsvpプロトコルではなく、inet.0のように直接フローでテーブルにインストールされます）。
[edit] bormoglotx@RZN-ASBR1# run show route 62.0.0.3/32 table inet.3 inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 62.0.0.3/32 *[Direct/0] 00:00:07 > via lo0.0
近隣の自治区にループバックを与えているかどうかを確認できます。
bormoglotx@RZN-ASBR1> show route advertising-protocol bgp 30.0.0.1 inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 62.0.0.1/32 Self 1 I * 62.0.0.2/32 Self 1 I * 62.0.0.3/32 Self I
彼らは1つの問題を解決しました。 しかし、2番目の問題が発生します。
bormoglotx@RZN-PE1> show route table TEST1.inet.0 TEST1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[Direct/0] 01:38:46 > via ge-0/0/5.0 10.0.0.1/32 *[Local/0] 01:38:46 Local via ge-0/0/5.0
bgpピアリングはPEルーターの間にあるため、L3VPNには隣接する自律システムへのルートはありません。
bormoglotx@RZN-PE1> show bgp summary group eBGP-VPNV4 Groups: 2 Peers: 2 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 7 0 0 0 0 0 bgp.l3vpn.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 71.0.0.1 71 179 183 0 1 18:34 Active
実際には、ASBRのルートはinet.3テーブルにあり、リモートPEとのラベルユニキャストセッションはinet.0から構築され、当然PEには何も返されません。これを行うには、ASBRに別のrib-groupを作成し、inet.3からinet.0にルートを転送します。
[edit] bormoglotx@RZN-ASBR1# show routing-options rib-groups inet.3>>>inet.0-Remote-Lo import-rib [ inet.3 inet.0 ]; import-policy Remote-Lo; [edit] bormoglotx@RZN-ASBR1# show policy-options policy-statement Remote-Lo term Lo { from { route-filter 71.0.0.0/24 prefix-length-range /32-/32; } then accept; } then reject;
そして、これらのルートを取得するBGPセッションに固定します。
bormoglotx@RZN-ASBR1# show protocols bgp group ASBR type external; family inet { labeled-unicast { rib-group inet.3>>>inet.0-Remote-Lo; rib { inet.3; } } } export LO-export; neighbor 30.0.0.1 { local-address 30.0.0.0; peer-as 71; }
2番目のASBRでも同様の設定を行う必要があります。IGPで再配布する場合は、その後、リモートループバックへのルートがPEのルーティングテーブルにインストールされ、eBGP vpnv4セッションが上がります（1つの自律性で再配布を禁止する人はいませんが、 2番目はBGPのみを使用します-選択はネットワーク管理者のみです）：
bormoglotx@RZN-PE1> show bgp summary group eBGP-VPNV4 Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 10 3 0 0 0 0 bgp.l3vpn.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 71.0.0.1 71 184 189 0 1 1:11 Establ bgp.l3vpn.0: 1/1/1/0 TEST1.inet.0: 1/1/1/0
これで、L3VPN内の接続を確認できます。
bormoglotx@RZN-PE1> ping routing-instance TEST1 source 10.0.0.1 10.0.1.1 rapid PING 10.0.1.1 (10.0.1.1): 56 data bytes !!!!! --- 10.0.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.332/37.029/83.503/29.868 ms
これで、JunOSでのopt.Cの構成に関する問題が少なくなると思います。しかし、何か質問がある場合は、コメントを書くか、私に電報で書いてください。
ご清聴ありがとうございました。