JANOG57 NETCON 問題解説(Level1-12)

2026/2/11-13 にかけて大阪で開催された JANOG57 NETCON の問題 1-12 を解説します。

問題
事象の確認
原因調査
対処方法
コンフィグ
1. RT1
2. RT2
3. RR1

問題

問題文

あなたはこれから L3VPN 設定作業をする予定です。

事前に RR1 が広報している経路情報を確認すると、RT-01 から学習している経路が一部 RT-02 に広報されていないのを発見した。このまま作業に入って良いかを念のためメンターに確認したが「大丈夫大丈夫。そのまま進めてー」と言われました。とはいえメンターの言葉の軽さに、本当に大丈夫なのか正直ちょっと不安になってきました。

本当に問題ないのか、VPN設定作業前に事前確認をしてみてください。

達成条件

RR1 での show bgp vpnv4 unicast neighbors 2.2.2.2 advertised-routes | i 192.168.102 の結果が以下のようになるようにしてください。

192.168.102.0/24   1.1.1.1         1.1.1.1         ?

制約

Static Routeを設定するのは禁止です。
すでにある設定を削除するのは禁止です。
既存の状態に影響を与えないようにしてください。
事前確認以上のことは行わないこと

事象の確認

ではまず達成条件のコマンド確認してみましょう。

RP/0/RP0/CPU0:RR1#show bgp vpnv4 unicast neighbors 2.2.2.2 advertised-routes | i 192.168.102
Sun Feb 22 02:37:59.810 UTC
RP/0/RP0/CPU0:RR1#

何も出ないので、問題文の通り「広報されていない」っぽいですね。そして達成条件からすると 192.168.102.0/24 が広報されていれば良さそうです。これは RT1 の VPN CUST_B から広報されるもののようです。ではちゃんと広報されているのか確認してみます。

RP/0/RP0/CPU0:RT1#show bgp vpnv4 unicast summary | begin Neighbor
Sun Feb 22 02:42:26.741 UTC
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.10.10.10       0    57      23      21       13    0    0 00:14:28          1

RP/0/RP0/CPU0:RT1#show bgp vpnv4 unicast neighbors 10.10.10.10 advertised-routes
Sun Feb 22 02:42:38.737 UTC
Network            Next Hop        From            AS Path
Route Distinguisher: 1.1.1.1:1
Route Distinguisher Version: 13
192.168.101.0/24   1.1.1.1         Local           ?
Route Distinguisher: 1.1.1.1:2
Route Distinguisher Version: 11
192.168.102.0/24   1.1.1.1         Local           ?

Processed 2 prefixes, 2 paths

10.10.10.10(RR1) に対して、192.168.102.0/24 は広報しているみたいですね。RR1 でも経路は見えています。

RP/0/RP0/CPU0:RR1#sh bg vpnv4 unicast rd 1.1.1.1:2 192.168.102.0/24
Sun Feb 22 02:48:11.461 UTC
BGP routing table entry for 192.168.102.0/24, Route Distinguisher: 1.1.1.1:2
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  10           10
Last Modified: Feb 22 02:29:04.987 for 00:19:06
Paths: (1 available, best #1)
  Advertised to peers (in unique update groups):
    1.1.1.1
  Path #1: Received by speaker 0
  Advertised to peers (in unique update groups):
    1.1.1.1
  Local, (Received from a RR-client)
    1.1.1.1 (metric 10) from 1.1.1.1 (1.1.1.1)
      Received Label 24001
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf
      Received Path ID 0, Local Path ID 1, version 10
      Extended community: RT:57:2

さて、RR1 までちゃんと届いているのに RT2 には届いていないのはなぜなんでしょう？

原因調査

よくありがちなのは「フィルタしている」ですかね。ではみてみましょう。この環境はすべて IOS-XR なので、フィルタに使われるのは route-policy です。あるかどうか確認してみます。

RP/0/RP0/CPU0:RR1#show rpl
Sun Feb 22 02:51:26.786 UTC
% No such configuration item(s)

RP/0/RP0/CPU0:RT1#show rpl
Sun Feb 22 02:51:37.737 UTC
% No such configuration item(s)

RP/0/RP0/CPU0:RT2#show rpl
Sun Feb 22 02:51:41.698 UTC
% No such configuration item(s)

何も Route-Policy は設定されてないようですね。ということはフィルタじゃなさそうなので、それぞれの定義が違うんでしょうか。コンフィグ見てみましょう。

RP/0/RP0/CPU0:RR1#show run router bgp
Sun Feb 22 02:52:35.096 UTC
router bgp 57
 bgp router-id 10.10.10.10
 address-family vpnv4 unicast
 !
 address-family ipv4 rt-filter
 !
 neighbor-group RTFILTER
  remote-as 57
  update-source Loopback0
  address-family vpnv4 unicast
   route-reflector-client
  !
  address-family ipv4 rt-filter
  !
 !
 neighbor 1.1.1.1
  use neighbor-group RTFILTER
 !
 neighbor 2.2.2.2
  use neighbor-group RTFILTER
 !
 vrf CUST_A
  address-family ipv4 unicast
  !
 !
 vrf CUST_B
  address-family ipv4 unicast
  !
 !
!

RR1 と RT1, RT2 間では別に設定も違わないようですね、うーん…

おや？そういえば「フィルタ」については何もなかったのに、それっぽい文字列がありますね？

RP/0/RP0/CPU0:RR1#show run router bgp | i filter
Sun Feb 22 02:54:08.193 UTC
 address-family ipv4 rt-filter
  address-family ipv4 rt-filter

実はこれ、「必要のないプレフィックスをもらわない」ようにできる機能を有効化しているものなんですね。

ルートターゲット制約

このドキュメントでは、プロバイダーエッジ（PE）ルータへ送信される VPNv4 および VPNv6 プレフィックスの交換が必要最小限に抑えられるメカニズムについて説明します。

簡単にいうと「自分が import しない route-target を持つプレフィックスは送らないでください」という申告に従って、広報する経路にフィルタを勝手にかける機能なのです。今回の構成では、RT2 ではまだ VPN CUST_B は設定前なので、CUST_B を import する設定がありません。そのため、RT2 は CUST_A 分のプレフィックスだけしか欲しくない！と宣言しているのです。本当にそうなっているかみてみましょう。

まず、RT1 でそれぞれの VPN がどのような Route Target になっているかみてみます。

RP/0/RP0/CPU0:RT1#show run formal | i route-target
Sun Feb 22 03:05:59.330 UTC
Building configuration...
vrf CUST_A address-family ipv4 unicast import route-target 57:1
vrf CUST_A address-family ipv4 unicast export route-target 57:1
vrf CUST_B address-family ipv4 unicast import route-target 57:2
vrf CUST_B address-family ipv4 unicast export route-target 57:2

CUST_A が 57:1、CUST_B が 57:2 ですね。では RR1 が 57:1 だけを広報するようになっているかみてみます。

RP/0/RP0/CPU0:RR1#show bgp vpnv4 unicast neighbors 2.2.2.2 rt-filter | i RT
Sun Feb 22 03:08:40.711 UTC
    Address family RT Constraint: advertised and received
 For Address Family: RT Constraint
  Update group: 0.2 Filter-group: 0.1  No Refresh request being processed  RT constraint nbr enabled for VPN updates:
  RT-Table with total RTs: 1
  RT:57:1

2.2.2.2 (RT2) には 57:1 しか広報しない RT Filter がかかっていることが確認できます。これが RT1 だと、57:1 も 57:2 も広報するようになっています。

RP/0/RP0/CPU0:RR1#show bgp vpnv4 unicast neighbors 1.1.1.1 rt-filter | i RT
Sun Feb 22 03:09:47.149 UTC
    Address family RT Constraint: advertised and received
 For Address Family: RT Constraint
  Update group: 0.2 Filter-group: 0.1  No Refresh request being processed  RT constraint nbr enabled for VPN updates:
  RT-Table with total RTs: 2
  RT:57:1  RT:57:2

「Cisco の固有機能なんか出すなよ！」と怒られそうですが、そうではなくちゃんと RFC になっている標準機能なんですね。

RFC 4684: Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)

This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachabili...

ですので、Juniper さんの JUNOS なんかでも使える機能です。興味があれば探してみてください。

対処方法

さぁ、経路が広報されていない原因はわかりました。では対処ですが、制約を確認すると以下の条件があります。

Static Routeを設定するのは禁止です。
すでにある設定を削除するのは禁止です。
既存の状態に影響を与えないようにしてください。
事前確認以上のことは行わないこと

1点目はまぁいいとして、2点目で「rt-filter の削除はだめ」ということがわかります。3点目と4点目はどういうことでしょう？ここで点数が取れなかった方もいるのではないかなと思います。

問題の状況の前提を考えてみましょう。

あなたはこれから L3VPN 設定作業をする予定です。

「これから設定作業をする＝まだ VPN が開通していない」のですから、既存の RT1 の CUST_B 側で RT2 の（設定予定の）CUST_B 経路が見えたらおかしいですよね？この時点で「事前確認以上のこと（＝設定作業完了）」をやっているので制約違反となります。

「じゃあ RT2 では CUST_B 設定せずに CUST_A で import 設定すれば、CUST_B の設定をしてないからいいよね」ってすると、今度は「CUST_A で見えてはいけない CUST_B の経路が見える」という、さらにまずい状況になります。商用で言えば「企業Aに企業Bの経路情報が見えて、到達可能になる」可能性がある状態ですし、プレフィックスが重複したら意図しないトラフィックの吸い込みだとか、なかなかヤバい状況になり得ます。

あくまで事前確認というレベルにしたいので方針としては

RT2 で「RT:57:2」を import することを宣言させる
RT2 からは広報しない

に留めることになります。

今回はチェックのためだけなので、CUST_B という「これから設定作業を行う」ものを作るのも良くないので、異なる名前で作ってみましょう。RT2 に以下の設定を入れます。

vrf CHECK
 rd 2.2.2.2:2
 address-family ipv4 unicast
  import route-target
   57:2
  !
 !
!
router bgp 57
 vrf CHECK
  address-family ipv4 unicast
  !
 !
!

ついでに RR1 でもデバッグ有効にしてどんなことが起こるかみてみます。

terminal monitor
debug bgp update
debug bgp all afi ipv4 all 2.2.2.2

さぁどうなる？

RP/0/RP0/CPU0:RR1#show bgp vpnv4 unicast neighbors 2.2.2.2 rt-filter | i RT
Sun Feb 22 03:24:21.130 UTC
    Address family RT Constraint: advertised and received
 For Address Family: RT Constraint
  Update group: 0.2 Filter-group: 0.1  No Refresh request being processed  RT constraint nbr enabled for VPN updates:
  RT-Table with total RTs: 2
  RT:57:1  RT:57:2

お、57:2 が見えるようになりましたね。では達成条件も見てみましょう。

RP/0/RP0/CPU0:RR1#show bgp vpnv4 unicast neighbors 2.2.2.2 advertised-routes | i 192.168.102
Sun Feb 22 03:25:20.741 UTC
192.168.102.0/24   1.1.1.1         1.1.1.1         ?

できてますね！ debug の結果も見てみると、ちゃんと「57:2 を受け取る！」宣言もしてるみたいです。

RP/0/RP0/CPU0:RR1#RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-rtr]: --bgp4_rcv_attributes--: END: nbr=2.2.2.2:: msg=0x0x787844179a20/63, updlen=44, attrbl=
0x0x787844179a37/40, ipv4reachlen=0, msginpath=0x0x787834825870, asloopcheck=1, attrwdrfl=0x00000000:: samecluster=0, local_as_prepended=0, attr_wdr_flags 0x00000000, mya
scount=0:: rcvdata=0x0x787844179a5f/0, errptr=0x0x787844179a58/7
RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-rtr] (ipv4rtf): Received UPDATE from 2.2.2.2 with attributes:
RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-rtr] (ipv4rtf): nexthop 2.2.2.2/32, origin i, localpref 100
RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-rtr] (ipv4rtf): Received prefix 57:2:57:2/96 (path ID: none) from 2.2.2.2 <<<
RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-rtr]: Received UPDATE from 2.2.2.2 (length incl. header = 63)
RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-rtr] (ipv4rtf): Wake up sync/rib thread ( afi 11), label version 3, rib version 3, bgp table version 3, standby
 ver 0
RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-upd] (vpn4u): Procesing RT delta refresh request for 2.2.2.2, delta size 1
RP/0/RP0/CPU0:Feb 22 03:23:07.212 UTC: bgp[1084]: [default-upd] (vpn4u): Triggering incremental refresh for 2.2.2.2.
RP/0/RP0/CPU0:Feb 22 03:23:09.213 UTC: bgp[1084]: [default-event] (vpn4u): Adding neighbor 2.2.2.2 to new refresh filter-group 0.2 in VPNv4 Unicast refresh sub-group id 1
 (parent subgrp 0.1) rtset size 2 in updgrp 0.2
RP/0/RP0/CPU0:Feb 22 03:23:09.222 UTC: bgp[1084]: [default-upd]: table-attr walk for table TBL:default (1/128), resume version 0, subgrp refresh version 0, refresh target
 version 13
RP/0/RP0/CPU0:Feb 22 03:23:09.222 UTC: bgp[1084]: [default-upd] VRF CUST_A: table-attr walk for table TBL:CUST_A (1/1), resume version 0, subgrp refresh version 0, refres
h target version 13
RP/0/RP0/CPU0:Feb 22 03:23:09.222 UTC: bgp[1084]: [default-upd] VRF CUST_B: table-attr walk for table TBL:CUST_B (1/1), resume version 0, subgrp refresh version 0, refres
h target version 13
RP/0/RP0/CPU0:Feb 22 03:23:09.222 UTC: bgp[1084]: [default-upd] (vpn4u): Updgen (Refresh) - TBL:default (1/128) UG: 0.2 SG: 0.1 Refresh SG: 1 msg: 1 pfx: [tot] adv/wdn/sup/skp/be [Tblattr#: match/tot]  [2] 1/0/0/1/0 [2/4] ver: 0 -> 13 res ver: 0 -> 13 adv-disabled 0
RP/0/RP0/CPU0:Feb 22 03:23:09.222 UTC: bgp[1084]: [default-upd] (vpn4u): Updates replicated to neighbor 2.2.2.2

原因も確認できましたし、vrf CHECK 関連の部分だけ消せばいいので事前作業以上のこともやってないのでこれでOKです！

コンフィグ

今回のコンフィグです。

RT1

hostname RT1
!
vrf MGMT
 address-family ipv4 unicast
 !
 address-family ipv6 unicast
 !
!
vrf CUST_A
 rd 1.1.1.1:1
 address-family ipv4 unicast
  import route-target
   57:1
  !
  export route-target
   57:1
  !
 !
!
vrf CUST_B
 rd 1.1.1.1:2
 address-family ipv4 unicast
  import route-target
   57:2
  !
  export route-target
   57:2
  !
 !
!
interface Loopback0
 ipv4 address 1.1.1.1 255.255.255.255
!
interface Loopback101
 vrf CUST_A
 ipv4 address 192.168.101.1 255.255.255.0
!
interface Loopback102
 vrf CUST_B
 ipv4 address 192.168.102.1 255.255.255.0
!
interface MgmtEth0/RP0/CPU0/0
 vrf MGMT
!
interface GigabitEthernet0/0/0/0
 ipv4 address 10.1.10.1 255.255.255.0
!
router isis JANOG57
 net 49.0057.0010.0100.1001.00
 address-family ipv4 unicast
  router-id Loopback0
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/0
  address-family ipv4 unicast
  !
 !
!
router bgp 57
 bgp router-id 1.1.1.1
 address-family vpnv4 unicast
 !
 address-family ipv4 rt-filter
 !
 neighbor 10.10.10.10
  remote-as 57
  update-source Loopback0
  address-family vpnv4 unicast
  !
  address-family ipv4 rt-filter
  !
 !
 vrf CUST_A
  address-family ipv4 unicast
   redistribute connected
  !
 !
 vrf CUST_B
  address-family ipv4 unicast
   redistribute connected
  !
 !
!
end

RT2

hostname RT2
!
vrf MGMT
 address-family ipv4 unicast
 !
 address-family ipv6 unicast
 !
!
vrf CUST_A
 rd 2.2.2.2:1
 address-family ipv4 unicast
  import route-target
   57:1
  !
  export route-target
   57:1
  !
 !
!
interface Loopback0
 ipv4 address 2.2.2.2 255.255.255.255
!
interface Loopback201
 vrf CUST_A
 ipv4 address 192.168.201.2 255.255.255.0
!
interface MgmtEth0/RP0/CPU0/0
 vrf MGMT
!
interface GigabitEthernet0/0/0/0
 ipv4 address 10.2.10.2 255.255.255.0
!
router isis JANOG57
 net 49.0057.0020.0200.2002.00
 address-family ipv4 unicast
  router-id Loopback0
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/0
  address-family ipv4 unicast
  !
 !
!
router bgp 57
 bgp router-id 2.2.2.2
 address-family vpnv4 unicast
 !
 address-family ipv4 rt-filter
 !
 neighbor 10.10.10.10
  remote-as 57
  update-source Loopback0
  address-family vpnv4 unicast
  !
  address-family ipv4 rt-filter
  !
 !
 vrf CUST_A
  address-family ipv4 unicast
   redistribute connected
  !
 !
!
end

RR1

hostname RR1
!
vrf MGMT
 address-family ipv4 unicast
 !
 address-family ipv6 unicast
 !
!
vrf CUST_A
 rd 10.10.10.10:1
 address-family ipv4 unicast
  import route-target
   57:1
  !
  export route-target
   57:1
  !
 !
!
vrf CUST_B
 rd 10.10.10.10:2
 address-family ipv4 unicast
  import route-target
   57:2
  !
  export route-target
   57:2
  !
 !
!
interface Loopback0
 ipv4 address 10.10.10.10 255.255.255.255
!
interface MgmtEth0/RP0/CPU0/0
 vrf MGMT
!
interface GigabitEthernet0/0/0/1
 ipv4 address 10.1.10.10 255.255.255.0
!
interface GigabitEthernet0/0/0/2
 ipv4 address 10.2.10.10 255.255.255.0
!
router isis JANOG57
 net 49.0057.0100.1001.0010.00
 address-family ipv4 unicast
  router-id Loopback0
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/1
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/2
  address-family ipv4 unicast
  !
 !
!
router bgp 57
 bgp router-id 10.10.10.10
 address-family vpnv4 unicast
 !
 address-family ipv4 rt-filter
 !
 neighbor-group RTFILTER
  remote-as 57
  update-source Loopback0
  address-family vpnv4 unicast
   route-reflector-client
  !
  address-family ipv4 rt-filter
  !
 !
 neighbor 1.1.1.1
  use neighbor-group RTFILTER
 !
 neighbor 2.2.2.2
  use neighbor-group RTFILTER
 !
 vrf CUST_A
  address-family ipv4 unicast
  !
 !
 vrf CUST_B
  address-family ipv4 unicast
  !
 !
!
end