JunOSでのInter-ASオプションCの萜ずし穎

画像の代替

この蚘事は、ラゞオ局のリスナヌの芁望に応じお曞かれおいたす。 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の構成に関する問題が少なくなるず思いたす。しかし、䜕か質問がある堎合は、コメントを曞くか、私に電報で曞いおください。

ご枅聎ありがずうございたした。

Source: https://habr.com/ru/post/J336486/


All Articles