vSRXを活用した、JUNOSのお勉強まとめ【mpBGP / MPLS-VPN編】
今回も、引き続き、JUNOSのお勉強メモです。
ttsubo.hatenablog.com
◼︎ 前回の記事での技術課題
エンド端末間での疎通確認において、エンド端末"pc1"から、エンド端末"pc2"側"10.0.0.1"に対して、pingをうってみたところ、
pingは成功した。この時、pc2側でパケットキャプチャを行ったところ、ICMP Echo Request / Replyが観測されなかった。
「誰がICMP Echo Replyを送信したのだろうか?」というものでした。
まず、こちらのトポロジ構成をご覧ください。
BGP運用経験の豊富な方は、すでに発生事象の原因にお気づきだと思います。
[ AS: 65000 ] [ AS: 65000 ] 10.0.0.1 10.0.0.2 10.0.0.3 +---------+ +--------+ +---------+ | | | | | | | vSRX-1 | | vSRX-2 | | vSRX-3 | +-----+ 172.16.0.0/30 | +-----+ | 192.168.0.0/30 | | 192.168.1.0/30 | +-----+ | 172.16.1.0/30 +-----+ 10.0.0.1/24 | pc1 +-----------------+ GRT +----------------+ | | +----------------+ GRT +-----------------+ pc2 | 10.0.1.1/24 +-----+ .1 .2 | +-----+ | .1 .2 | | .1 .2 | +-----+ | .1 .2 +-----+ 10.0.2.1/24 | | | | | | +---------+ +--------+ +---------+ : : : : : : : : : < --------- > : : < ---------- > : : < ---------- > : : < --------- > : static : LDP(ospf) LDP(ospf) : static : : : : : < ------------------------------------ > : iBGP
vSRX-1側での追跡調査
まず、vSRX-1で保持しているルーティング情報を確認してみましょう。
root@vSRX-1> show route table inet.0 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[BGP/170] 03:08:48, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299792 10.0.0.1/32 *[Direct/0] 07:51:02 > via lo0.0 10.0.0.2/32 *[OSPF/10] 04:12:50, metric 1 > to 192.168.0.2 via ge-0/0/1.0 10.0.0.3/32 *[OSPF/10] 04:12:50, metric 2 > to 192.168.0.2 via ge-0/0/1.0 10.0.1.0/24 *[BGP/170] 03:08:48, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299792 10.0.2.0/24 *[BGP/170] 03:08:48, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299792 172.16.0.0/30 *[Direct/0] 06:30:00 > via ge-0/0/0.0 172.16.0.2/32 *[Local/0] 06:30:00 Local via ge-0/0/0.0 172.16.1.0/30 *[BGP/170] 03:25:48, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299792 192.168.0.0/30 *[Direct/0] 06:32:29 > via ge-0/0/1.0 192.168.0.1/32 *[Local/0] 06:32:29 Local via ge-0/0/1.0 192.168.1.0/30 *[OSPF/10] 04:12:50, metric 2 > to 192.168.0.2 via ge-0/0/1.0 224.0.0.5/32 *[OSPF/10] 04:13:05, metric 1 MultiRecv
はい、お察しの通りでしたね。
vSRXでのルーティング情報は、グローバルルーティングテーブル(GRT)で全て保持することになります。
このGRTでは、OSPF, BGPなどのルーティングプロトコルで学習したルーティング情報に加えて、スタティック経路や、ダイレクト接続された経路も保持することになります。
そして、vSRX-1では、pc1から10.0.0.1”宛のIPパケットを受信した際には、このGRTをルックアップして、次の転送先が決定されますが、この場合だと、ループバックインタフェースが選定されます。
最終的に、vSRX-1のルップバックインタフェースが、ICMP Echo Replyを送信することになります。
これが、前回記事での技術課題の発生原因です。
課題解決を目指して ... mpBGP/ MPLS-VPM化
そもそも、エンド端末を使う人の立場から述べると、
「エンド端末"pc1", "pc2"間で通信できればよくて、vSRX側で構成されるバックボーンネットワークと通信したいわけではない。」
と主張されるのでしょう。
この技術課題を解決する手段として、mpBGP / MPLS-VPN適用が有望だと思います。
そこで、今回のJUNOSのお勉強の素材として、mpBGP / MPLS-VPN対応に着手してみます。
◼︎ vSRXトポロジ構成
前回と同様のトポロジ構成になっています。このトポロジ構成の特徴は、mpBGP / MPLS-VPN対応です。
従って、GRT / VRFの関係がわかりやすいよう記載しました。
[ AS: 65000 ] [ AS: 65000 ] 10.0.0.1 10.0.0.2 10.0.0.3 +---------+ +--------+ +---------+ | | | | | | | vSRX-1 | | vSRX-2 | | vSRX-3 | | +-----+ | 192.168.0.0/30 | | 192.168.1.0/30 | +-----+ | | | GRT +----------------+ | | +----------------+ GRT | | | +--+--+ | .1 .2 | | .1 .2 | +--+--+ | | | | | | | | | +-----+ 172.16.0.0/30 | +--+--+ | | | | +--+--+ | 172.16.1.0/30 +-----+ 10.0.0.1/24 | pc1 +-----------------+ VRF | | | | | | VRF +-----------------+ pc2 | 10.0.1.1/24 +-----+ .1 .2 | +-----+ | | | | +-----+ | .1 .2 +-----+ 10.0.2.1/24 +---------+ +--------+ +---------+ : : : : : : : : : < --------- > : : < ---------- > : : < ---------- > : : < --------- > : static : LDP(ospf) LDP(ospf) : static : : : : : < ------------------------------------ > : mp-iBGP
ここでのポイントは、エンド端末を収容するvSRXルータは、ProviderEdge(PE)ルータの役割を担うということです。
なお、PEルータでは、GRT, VRFテーブルをおのおの保持しており、エンド端末との間で共有すべきルーティング情報は、VRFテーブルで保持することになります。
PEルータ間でのエンド端末に関わるBGP経路情報を共有する際には、GRTテーブルを介してmp-BGP UPDATEメッセージでやりとりが行われます。そして、最終的にVRFテーブルに保持されます。
◼︎ JUNOSルーティング設定
mpBGP / MPLS-VPNに関わる各種ルーティング設定を行います。
(0) 事前準備
前回の記事で設定したBGP関連のコンフィグ設定を、全て削除しておきます。
ただし、OSPF, LDPのコンフィグ設定は、前回のまま活用することとします。
root@vSRX-1# delete protocols bgp root@vSRX-1# delete policy-options [edit] root@vSRX-1# show | compare [edit protocols] - bgp { - group INTERNAL { - type internal; - local-address 10.0.0.1; - export export-bgp; - neighbor 10.0.0.3; - } - } [edit] - policy-options { - policy-statement export-bgp { - term 1 { - from { - route-filter 172.16.0.0/30 exact; - } - then accept; - } - } - } root@vSRX-1# commit
vSRX-3では、スタティック経路の設定も削除しておきます。
root@vSRX-3# delete routing-options static
(1) mpBGP / MPLS-VPN基本設定
1. routing-instancesを設定する
root@vSRX-1# set routing-instances VPN-A instance-type vrf root@vSRX-1# set routing-instances VPN-A interface ge-0/0/0.0 root@vSRX-1# set routing-instances VPN-A route-distinguisher 65000:101 root@vSRX-1# set routing-instances VPN-A vrf-target target:65000:101 root@vSRX-1# show | compare [edit] + routing-instances { + VPN-A { + instance-type vrf; + interface ge-0/0/0.0; + route-distinguisher 65000:101; + vrf-target target:65000:101; + } + } root@vSRX-1# commit
2. protocolsを設定する
root@vSRX-1# set protocols bgp group L3VPN type internal root@vSRX-1# set protocols bgp group L3VPN local-address 10.0.0.1 root@vSRX-1# set protocols bgp group L3VPN neighbor 10.0.0.3 root@vSRX-1# set protocols bgp group L3VPN family inet-vpn unicast root@vSRX-1# show | compare [edit protocols] + bgp { + group L3VPN { + type internal; + local-address 10.0.0.1; + family inet-vpn { + unicast; + } + neighbor 10.0.0.3; + } + } root@vSRX-1# commit
3. static routeを設定する
vSRX-3側では、pc2配下のスタティック経路をエントリしておく必要があります。
set routing-instances VPN-A routing-options static route 10.0.0.0/24 next-hop 172.16.1.2 set routing-instances VPN-A routing-options static route 10.0.1.0/24 next-hop 172.16.1.2 set routing-instances VPN-A routing-options static route 10.0.2.0/24 next-hop 172.16.1.2 root@vSRX-3# show | compare [edit routing-instances VPN-A routing-options static] + route 10.0.0.0/24 next-hop 172.16.1.2; + route 10.0.1.0/24 next-hop 172.16.1.2; + route 10.0.2.0/24 next-hop 172.16.1.2; root@vSRX-3# commit
4. BGP Peerの状態を確認しておく
root@vSRX-1> show bgp neighbor Peer: 10.0.0.3+50824 AS 65000 Local: 10.0.0.1+179 AS 65000 Type: Internal State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Preference LocalAddress AddressFamily Rib-group Refresh> Address families configured: inet-vpn-unicast Local Address: 10.0.0.1 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.0.0.3 Local ID: 10.0.0.1 Active Holdtime: 90 Keepalive Interval: 30 Group index: 0 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-vpn-unicast NLRI advertised by peer: inet-vpn-unicast NLRI for this session: inet-vpn-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-vpn-unicast NLRI of received end-of-rib markers: inet-vpn-unicast NLRI of all end-of-rib markers sent: inet-vpn-unicast Peer supports 4 byte AS extension (peer-as 65000) Peer does not support Addpath Table bgp.l3vpn.0 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: not advertising Active prefixes: 4 Received prefixes: 4 Accepted prefixes: 4 Suppressed due to damping: 0 Table VPN-A.inet.0 Bit: 20000 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: in sync Active prefixes: 4 Received prefixes: 4 Accepted prefixes: 4 Suppressed due to damping: 0 Advertised prefixes: 1 Last traffic (seconds): Received 16 Sent 22 Checked 32 Input messages: Total 137 Updates 8 Refreshes 0 Octets 2973 Output messages: Total 136 Updates 7 Refreshes 0 Octets 2913 Output Queue[1]: 0 (VPN-A.inet.0, inet-vpn-unicast)
5. VPN-Aのアドバタイズ経路を確認しておく
通常のBGP設定と異なり、mpBGP/MPLS-VPN設定の場合は、vSRX-3ルータ側でExport policy適用せずとも、アドバタイズされるようです。
対向側(vSRX-3ルータ)からアドバタイズされた経路を受信できるようになりました。
root@vSRX-1> show route receive-protocol bgp 10.0.0.3 table bgp.l3vpn.0 bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 65000:101:10.0.0.0/24 * 10.0.0.3 100 I 65000:101:10.0.1.0/24 * 10.0.0.3 100 I 65000:101:10.0.2.0/24 * 10.0.0.3 100 I 65000:101:172.16.1.0/30 * 10.0.0.3 100 I
つづいて、対向側(vSRX-3ルータ)へのアドバイズを確認してみました。
しかしながら、"172.16.0.0/30"は、アドバタイズされていないようです。
root@vSRX-1> show route advertising-protocol bgp 10.0.0.3 VPN-A.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.0.0/30 Not advertised 100 I
ここでのトラブル解析として、各々のvSRXルータでのVRFテーブルの保持状態を確認してみます。
まずは、vSRX-1側から確認します。
root@vSRX-1> show route table VPN-A.inet.0 VPN-A.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[BGP/170] 00:43:58, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top) 10.0.1.0/24 *[BGP/170] 00:17:30, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top) 10.0.2.0/24 *[BGP/170] 00:17:30, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top) 172.16.0.0/30 *[Direct/0] 01:21:51 > via ge-0/0/0.0 172.16.0.2/32 *[Local/0] 01:21:51 Local via ge-0/0/0.0 172.16.1.0/30 *[BGP/170] 00:43:58, localpref 100, from 10.0.0.3 AS path: I, validation-state: unverified > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top)
問題なく、VRFテーブルは構築できているようです。
つづいて、vSRX-3側でも確認してみます。
root@vSRX-3> show route table VPN-A.inet.0 VPN-A.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[Static/5] 00:46:45 > to 172.16.1.2 via ge-0/0/1.0 10.0.1.0/24 *[Static/5] 00:20:17 > to 172.16.1.2 via ge-0/0/1.0 10.0.2.0/24 *[Static/5] 00:20:17 > to 172.16.1.2 via ge-0/0/1.0 172.16.1.0/30 *[Direct/0] 01:12:49 > via ge-0/0/1.0 172.16.1.1/32 *[Local/0] 01:12:49 Local via ge-0/0/1.0
やはり、vSRX-1側でのダイレクト接続経路"172.16.0.0/30"が、VRFテーブルに保持されておりませんね。
どうやら、pc1側では、スタティック経路が存在しないので、next-hopに該当するダイレクト接続経路"172.16.0.0/30"を、敢えて、BGP経路としてアドバタイズしていないようです。
6. ダイレクト接続経路"172.16.0.0/30"を再配布するには、
CiscoのIOSの"redistribute connected"コマンドのように、BGP経路に再配布する方法をいろいろ試行錯誤してみましたが、うまく行きません。そこで、不本意ながら、default-routeを再配布する方法で、問題回避を試みました。
root@vSRX-1# set routing-instances VPN-A routing-options static route 0.0.0.0/0 next-hop 172.16.0.1 [edit] root@vSRX-1# show | compare [edit routing-instances VPN-A] + routing-options { + static { + route 0.0.0.0/0 next-hop 172.16.0.1; + } + } root@vSRX-1# commit
とりあえず、vSRX-1側で、ダイレクト接続経路"172.16.0.0/30"をアドバタイズするようになりました。
root@vSRX-1> show route advertising-protocol bgp 10.0.0.3 VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 0.0.0.0/0 Self 100 I * 172.16.0.0/30 Self 100 I
改めて、vSRX-3側でのVRFテーブルの保持状態を確認してみます。
root@vSRX-3> show route table VPN-A.inet.0 VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:03:03, localpref 100, from 10.0.0.1 AS path: I, validation-state: unverified > to 192.168.1.1 via ge-0/0/0.0, Push 299824, Push 299776(top) 10.0.0.0/24 *[Static/5] 00:57:51 > to 172.16.1.2 via ge-0/0/1.0 10.0.1.0/24 *[Static/5] 00:31:23 > to 172.16.1.2 via ge-0/0/1.0 10.0.2.0/24 *[Static/5] 00:31:23 > to 172.16.1.2 via ge-0/0/1.0 172.16.0.0/30 *[BGP/170] 00:03:03, localpref 100, from 10.0.0.1 AS path: I, validation-state: unverified > to 192.168.1.1 via ge-0/0/0.0, Push 299824, Push 299776(top) 172.16.1.0/30 *[Direct/0] 01:23:55 > via ge-0/0/1.0 172.16.1.1/32 *[Local/0] 01:23:55 Local via ge-0/0/1.0
今回は、問題なく、VRFテーブルは構築できているようです。
(2) エンド端末間での疎通確認
エンドエンド端末間でpingをうってみましょう。
1. "172.16.1.2"宛にpingをうってみる
tsubo@pc1:~$ ping 172.16.1.2 PING 172.16.1.2 (172.16.1.2) 56(84) bytes of data. 64 bytes from 172.16.1.2: icmp_seq=1 ttl=61 time=0.849 ms 64 bytes from 172.16.1.2: icmp_seq=2 ttl=61 time=0.905 ms 64 bytes from 172.16.1.2: icmp_seq=3 ttl=61 time=0.829 ms 64 bytes from 172.16.1.2: icmp_seq=4 ttl=61 time=0.759 ms 64 bytes from 172.16.1.2: icmp_seq=5 ttl=61 time=0.960 ms ^C --- 172.16.1.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.759/0.860/0.960/0.073 ms
pingが成功しました!
この時、pc2側でtcpdumpを動作させて、パケットモニタリングしておきます。
root@pc2:~# tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 23:04:48.390124 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 1, length 64 23:04:48.390160 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 1, length 64 23:04:49.390956 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 2, length 64 23:04:49.390985 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 2, length 64 23:04:50.390871 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 3, length 64 23:04:50.390901 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 3, length 64 23:04:51.390847 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 4, length 64 23:04:51.390876 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 4, length 64 23:04:52.391451 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 5, length 64 23:04:52.391480 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 5, length 64 23:04:53.393256 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28 23:04:53.394175 ARP, Reply 172.16.1.1 is-at 00:0c:29:70:81:a6 (oui Unknown), length 46 ^C 12 packets captured 12 packets received by filter 0 packets dropped by kernel
期待通り、ICMP Echo Request / Replyが観測できました。
2. "10.0.0.1"宛にpingをうってみる
tsubo@pc1:~$ ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq=1 ttl=61 time=1.68 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=61 time=1.10 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=61 time=0.794 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=61 time=0.975 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=61 time=0.763 ms ^C --- 10.0.0.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 0.763/1.064/1.685/0.334 ms
こちらも、pingが成功しましたね!
この時、pc2側でtcpdumpを動作させて、パケットモニタリングしておきます。
root@pc2:~# tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 23:07:52.149141 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 1, length 64 23:07:52.149182 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 1, length 64 23:07:53.150952 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 2, length 64 23:07:53.150983 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 2, length 64 23:07:54.152578 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 3, length 64 23:07:54.152607 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 3, length 64 23:07:55.151633 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 4, length 64 23:07:55.151664 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 4, length 64 23:07:56.153395 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 5, length 64 23:07:56.153424 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 5, length 64 23:07:57.152492 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28 23:07:57.153588 ARP, Reply 172.16.1.1 is-at 00:0c:29:70:81:a6 (oui Unknown), length 46 ^C 12 packets captured 12 packets received by filter 0 packets dropped by kernel
こちらも、期待通り、ICMP Echo Request / Replyが観測できましたね!
ただし、pc1拠点相当を、さらに追加する場合には、default-routeを再配布する方法は採用できません。
CiscoのIOSの"redistribute connected"コマンド相当をサルベージする必要があるのかもしれません。
◼︎ 3/27追記「@kazubuさんから、回避策を教えてもらいました」
こちらが、Direct経路がBGPアドバタイズ経路に乗らない件の回避策になります。
では、早速、試してみましょう。
1. 暫定的に設定しておいたdefault-routeの再配布の設定を削除する
root@vSRX-1# delete routing-instances VPN-A routing-options static root@vSRX-1# commit
2. routing-instanceにvrf-table-labelを設定する
root@vSRX-1# set routing-instances VPN-A vrf-table-label root@vSRX-1# show | compare [edit routing-instances VPN-A] + vrf-table-label; root@vSRX-1# commit
vSRX-1側で、ダイレクト接続経路"172.16.0.0/30"をアドバタイズされるようになりました。
root@vSRX-1> show route advertising-protocol bgp 10.0.0.3 VPN-A.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.0.0/30 Self 100 I
対向側(vSRX-3)でも、ダイレクト接続経路"172.16.0.0/30"が、受信できたことも確認できました。
root@vSRX-3> show route receive-protocol bgp 10.0.0.1 table bgp.l3vpn.0 bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 65000:101:172.16.0.0/30 * 10.0.0.1 100 I
以下、個人的な所感です。
今まで、「VRFにて保持されるルーティング情報は、一律、BGP Peerにアドバタイズされる。」と理解しておりました。
ところが、通常のMPLSルータでは、「VRFにて保持されるルーティング情報は、next-hopが検出されるタイミングでVPNラベルが付与されるので、BGP Peerへのアドバタイズも可能になる」という仕様なんですね。
ダイレクト接続経路の場合だと、このままでは、next-hopが検出されないので、BGP Peerへのアドバタイズは行われない。
そこで、ダイレクト接続経路に対して、明示的にVPNラベルを付与する必要がある。
その方法は、JUNOSの場合だと、"vhf-table-label"を設定し、CiscoのIOSの場合だと、"redistribute connected"を設定する。
ちょっとだけ、賢くなりました。これにて、一件落着という感じです。
◼︎ 最終的なコンフィグ内容の確認
1. vSRX-1側コンフィグ内容
root@vSRX-1> show configuration ... (snip) routing-options { router-id 10.0.0.1; autonomous-system 65000; } protocols { mpls { interface ge-0/0/1.0; } bgp { group L3VPN { type internal; local-address 10.0.0.1; family inet-vpn { unicast; } neighbor 10.0.0.3; } } ospf { area 0.0.0.0 { interface ge-0/0/1.0; interface lo0.0 { passive; } } } ldp { interface ge-0/0/1.0; } } routing-instances { VPN-A { instance-type vrf; interface ge-0/0/0.0; route-distinguisher 65000:101; vrf-target target:65000:101; vrf-table-label; } }
2. vSRX-3側コンフィグ内容
root@vSRX-3> show configuration ... (snip) routing-options { router-id 10.0.0.3; autonomous-system 65000; } protocols { mpls { interface ge-0/0/0.0; } bgp { group L3VPN { type internal; local-address 10.0.0.3; family inet-vpn { unicast; } neighbor 10.0.0.1; } } ospf { area 0.0.0.0 { interface ge-0/0/0.0; interface lo0.0 { passive; } } } ldp { interface ge-0/0/0.0; } } routing-instances { VPN-A { instance-type vrf; interface ge-0/0/1.0; route-distinguisher 65000:101; vrf-target target:65000:101; routing-options { static { route 10.0.0.0/24 next-hop 172.16.1.2; route 10.0.1.0/24 next-hop 172.16.1.2; route 10.0.2.0/24 next-hop 172.16.1.2; } } } }
◼︎ 最後に
今回は、JUNOSによる、mpBGP / MPLS-VPNの基本動作を確認しました。
基本的なJUNOSコマンド操作感は、とてもわかりやすいと感じました。
以上です。