📚

JANOG NETCON問題解説 MPLS-3

2022/01/27に公開

JANOG49プログラム委員の大塚です。
今回NETCONの問題作成に参加しましたので「カテゴリMPLS, 問題名MPLS-3(90点)」について解説します。

問題文

BGP AS65000でVPNv4サービスを運用するJANOG太郎さんは新案件のため新しくAS64512を構築し、AS65000で提供してきたサービスも継続提供することから同ASらをeBGP接続させることとしました。

JANOG太郎さんは物理作業の後、IPアドレス設定やBGPピア設定を行いeBGP接続が正常に確立されており、vrf10の経路が正常に交換されていることを確認しました。

ところがPing試験を実施したところHost01:10.0.1.2からhost02:10.0.2.2に対するのPingが飛びません。

あなたはJANOG太郎さんに変わりこの状況を改善する必要があります。

各ルーターのコンフィグや経路情報などを確認した上で、既存設定を一切削除することなくPingが飛ぶようにして下さい。

また、Pingが飛ばなかった理由を説明して下さい。

トポロジーとコンフィグ

今回のトポロジーはこちらです

各ルーターの初期状態コンフィグは下記の通りです

R1 Config

!! IOS XR Configuration 7.5.1
!
hostname R1
!
vrf vrf10
rd 172.16.0.1:10
address-family ipv4 unicast
 import route-target
  65000:10
 !
 export route-target
  65000:10
 !
!
!
interface Loopback0
ipv4 address 172.16.0.1 255.255.255.255
!
interface Loopback10
vrf vrf10
ipv4 address 10.0.0.1 255.255.255.255
!
interface GigabitEthernet0/0/0/0
description ### to R2:gi0/0/0/0 ###
ipv4 address 10.1.2.1 255.255.255.0
!
interface GigabitEthernet0/0/0/1
description ### to R3:gi0/0/0/0 ###
ipv4 address 10.1.3.1 255.255.255.0
!
interface GigabitEthernet0/0/0/2
description ### to Host01 ###
vrf vrf10
ipv4 address 10.0.1.1 255.255.255.0
!
rd-set auto
end-set
!
route-policy permit-all
 pass
end-policy
!
router ospf 1
router-id 172.16.0.1
area 0
 interface Loopback0
 !
 interface GigabitEthernet0/0/0/0
  network point-to-point
 !
 interface GigabitEthernet0/0/0/1
  network point-to-point
 !
!
!
router bgp 65000
bgp router-id 172.16.0.1
bgp log neighbor changes detail
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor-group ibgp
 remote-as 65000
 update-source Loopback0
 address-family vpnv4 unicast
 !
!
neighbor 172.16.0.2
 use neighbor-group ibgp
!
neighbor 172.16.0.3
 use neighbor-group ibgp
!
vrf vrf10
 address-family ipv4 unicast
  redistribute connected
 !
!
!
mpls ldp
router-id 172.16.0.1
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
!
!
end

R2 Config

!! IOS XR Configuration 7.5.1
!
hostname R2
!
vrf vrf10
rd 172.16.0.2:10
address-family ipv4 unicast
 import route-target
  65000:10
 !
 export route-target
  65000:10
 !
!
!
interface Loopback0
ipv4 address 172.16.0.2 255.255.255.255
!
interface Loopback10
vrf vrf10
ipv4 address 10.0.0.2 255.255.255.255
!
interface GigabitEthernet0/0/0/0
description ### to R1:gi0/0/0/0 ###
ipv4 address 10.1.2.2 255.255.255.0
!
interface GigabitEthernet0/0/0/1
description ### to R3:gi0/0/0/1 ###
ipv4 address 10.2.3.2 255.255.255.0
!
interface GigabitEthernet0/0/0/2
description ### to R4:gi0/0/0/0 ###
ipv4 address 10.2.4.2 255.255.255.0
!
route-policy detour
 prepend as-path 65000 3
 pass
end-policy
!
route-policy permit-all
 pass
end-policy
!
router ospf 1
router-id 172.16.0.2
area 0
 interface Loopback0
 !
 interface GigabitEthernet0/0/0/0
  network point-to-point
 !
 interface GigabitEthernet0/0/0/1
  network point-to-point
 !
!
!
router bgp 65000
bgp router-id 172.16.0.2
mpls activate
 interface GigabitEthernet0/0/0/2
!
bgp log neighbor changes detail
address-family ipv4 unicast
!
address-family vpnv4 unicast
 retain route-target all
!
neighbor-group ebgp
 remote-as 64512
 address-family vpnv4 unicast
  route-policy permit-all in
  route-policy permit-all out
 !
!
neighbor-group ibgp
 remote-as 65000
 update-source Loopback0
 address-family vpnv4 unicast
  next-hop-self
 !
!
neighbor 10.2.4.4
 use neighbor-group ebgp
!
neighbor 172.16.0.1
 use neighbor-group ibgp
!
neighbor 172.16.0.3
 use neighbor-group ibgp
!
vrf vrf10
 address-family ipv4 unicast
  redistribute connected
 !
!
!
mpls ldp
router-id 172.16.0.2
address-family ipv4
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
!
!
end

R3 Config

!! IOS XR Configuration 7.5.1
!
hostname R3
!
vrf vrf10
rd 172.16.0.3:10
address-family ipv4 unicast
 import route-target
  65000:10
 !
 export route-target
  65000:10
 !
!
!
interface Loopback0
ipv4 address 172.16.0.3 255.255.255.255
!
interface Loopback10
vrf vrf10
ipv4 address 10.0.0.3 255.255.255.255
!
interface GigabitEthernet0/0/0/0
description ### to R1:gi0/0/0/1 ###
ipv4 address 10.1.3.3 255.255.255.0
!
interface GigabitEthernet0/0/0/1
description ### to R2:gi0/0/0/1 ###
ipv4 address 10.2.3.3 255.255.255.0
!
interface GigabitEthernet0/0/0/2
description ### to R4:gi0/0/0/1 ###
ipv4 address 10.3.4.3 255.255.255.0
!
route-policy permit-all
 pass
end-policy
!
router ospf 1
router-id 172.16.0.3
area 0
 interface Loopback0
 !
 interface GigabitEthernet0/0/0/0
  network point-to-point
 !
 interface GigabitEthernet0/0/0/1
  network point-to-point
 !
!
!
router bgp 65000
bgp router-id 172.16.0.3
bgp log neighbor changes detail
address-family ipv4 unicast
!
address-family vpnv4 unicast
 retain route-target all
!
neighbor-group ebgp
 remote-as 64512
 address-family vpnv4 unicast
  route-policy permit-all in
  route-policy permit-all out
 !
!
neighbor-group ibgp
 remote-as 65000
 update-source Loopback0
 address-family vpnv4 unicast
  next-hop-self
 !
!
neighbor 10.3.4.4
 use neighbor-group ebgp
!
neighbor 172.16.0.1
 use neighbor-group ibgp
!
neighbor 172.16.0.2
 use neighbor-group ibgp
!
vrf vrf10
 address-family ipv4 unicast
  redistribute connected
 !
!
!
mpls ldp
router-id 172.16.0.3
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
!
!
end

R4 Config

!! IOS XR Configuration 7.5.1
!
hostname R4
!
vrf vrf10
 rd 172.16.0.4:10
 address-family ipv4 unicast
  import route-target
   65000:10
  !
  export route-target
   65000:10
  !
 !
!
interface Loopback0
 ipv4 address 172.16.0.4 255.255.255.255
!
interface Loopback10
 vrf vrf10
 ipv4 address 10.0.0.4 255.255.255.255
!
interface GigabitEthernet0/0/0/0
 description ### to R2:gi0/0/0/2 ###
 ipv4 address 10.2.4.4 255.255.255.0
!
interface GigabitEthernet0/0/0/1
 description ### to R3:gi0/0/0/2 ###
 ipv4 address 10.3.4.4 255.255.255.0
!
interface GigabitEthernet0/0/0/2
 description ### to host02 ###
 vrf vrf10
 ipv4 address 10.0.2.1 255.255.255.0
!
route-policy permit-all
  pass
end-policy
!
router bgp 64512
 bgp router-id 172.16.0.4
 mpls activate
  interface GigabitEthernet0/0/0/0
  interface GigabitEthernet0/0/0/1
 !
 bgp log neighbor changes detail
 address-family ipv4 unicast
 !
 address-family vpnv4 unicast
  retain route-target all
 !
 neighbor-group ebgp
  remote-as 65000
  address-family vpnv4 unicast
   route-policy permit-all in
   route-policy permit-all out
  !
 !
 neighbor 10.2.4.2
  use neighbor-group ebgp
 !
 neighbor 10.3.4.3
  use neighbor-group ebgp
 !
 vrf vrf10
  address-family ipv4 unicast
   redistribute connected
  !
 !
!
end

問題解答例

今回の解答例は以下となります。

各ルーターのコンフィグや経路情報などを確認した上で、既存設定を一切削除することなくPingが飛ぶようにして下さい。

R2/R3/R4へStatic Routeを追加する

!R2
conf t
router static
address-family ipv4 unicast
10.2.4.4/32 GigabitEthernet0/0/0/2
commit
 
!R3
conf t
router static
address-family ipv4 unicast
10.3.4.4/32 GigabitEthernet0/0/0/2
commit
 
!R4
conf t
router static
address-family ipv4 unicast
10.2.4.2/32 GigabitEthernet0/0/0/0
10.3.4.3/32 GigabitEthernet0/0/0/1
commit

また、Pingが飛ばなかった理由を説明して下さい。

R2〜R4間とR3〜R4間で隣接ルーターに対する転送ラベルが存在せず網内でMPLS転送出来ないため

問題解説

今回のNW構成では2つのBGP ASらがeBGP接続されています。

これはBGPの拡張機能であるMulti Protocol BGP技術を用いたMPLS-VPNネットワークであり、ASBR同士でMP-eBGP接続するInter-AS Option Bを用いた構成です。
MPLS-VPNではその名の通りMPLSラベルに基づき転送され、2種類のラベルが使用されます。

ラベル 目的
VPNラベル ユーザーのVPNを識別するためのラベル、BGPにより交換される
転送ラベル MPLS網内の転送用に使用されるラベル、LDP等により交換される

今回は後者の転送ラベルが網内で正常に伝播されていないため、Host間の通信が出来ない状態となっていました。

解答例では/32のHost RouteをStaticで登録することによって転送ラベルを生成し網内伝搬させることによってHost間通信が出来るよう解決しています。

また今回問題の制約を多少緩く、「既存設定を一切削除することなくPingが飛ぶようにして下さい。」としていたため、元々Pingが飛ばなかった理由が説明出来て、結果的にPingが飛ぶ様になれば正解となります。

例えばR2/R3/R4で新たにSRを動作させR2/R3でSR Mapping ServerによりLDPとのIneterworkingを行うなど、既存コンフィグを消さずにPingが飛べばOKです。
採点をするスタッフ的には条件を判断しづらく大変かもしれませんが、チャレンジングな参加者がいらっしゃることを期待しています。

IPネットワークにおけるトラブルシューティングの考え方

皆様はIPネットワークでトラブルが発生した場合、どのようにトラブルシューティングを行なっていますか?
今回のようなIPネットワークで確認すべき観点としては下記事項などが挙げられます。

⓪Ping/Tracerouteによる到達性、経路確認

①物理的な問題
・ケーブルが正常に接続されているか
・光ファイバーの場合、光レベルは正常か
・トランシーバーやラインカードなど機器コンポーネントが故障していないか

②ルーター固有の問題
・ルーターOS上のプロセスが正常に動作しているか
・ソフトウェアバグに抵触していないか

③データプレーンの問題
・データ転送に必要な情報が正常に交換され各種テーブルにインストールされているか

④コントロールプレーンの問題
・経路制御に必要な情報が正常に交換され各種テーブルにインストールされているか

もちろん、ITシステムにおけるトラブルシューティングに答えはありません。
システム構成や発生している状況・症状などによって調査方法や観点も変わります。

低いレイヤーから確認する手順や逆に高いレイヤーから確認する手順、あるいは経験や勘に基づき自身が怪しいと考える部位を集中的に確認するなど、様々な手法が考えれます。

今回のトラブルシーティング手順例

今回は上記③に問題があるケースですが、ここでは敢えて⓪→①→②→④→③の順番で切り分けを行う手順を示します。

⓪Ping/Traceroute
IPネットワークの切り分けにおいては必ず最初にこれらを実施する必要があります。
パケットフィルターにより故意的に応答しないよう設定されていて応答が無いケースなどもありますが、最も基本的な切り分け方法です。
最も基本的ながら、意外に忘れがちという方も少なくはないのではと思います。

Ping確認内容

  • Host間
    • Host間のPingは全く応答無し
    • Tracerouteも1hop目(Host01から見たR1もしくはHost02から見たR4)から応答が無い
  • 各Router間リンク(Global Routing Table)
    • Router間の個々の区間ではPing/Trace共に応答有り
  • 各Router Loopback lo10間(VRF vrf10)
    • vrf10に帰属している各Routerのlo10(10.0.0.X/32)間での確認、AS65000内は全て応答有り、AS跨ぎは全て応答無し

①物理的な問題に関する切り分け
show interfaceコマンドにより以下を確認します

  • IFが正常にUpしているか
  • パケットドロップの発生やエラーカウンターがカウントアップしていないか

IFは正常にUpしていて、エラーもありません

②ルーター固有の問題に関する切り分け
show procやshow proc cpuコマンドによりルーターのOSが異常な状態に陥っていないことを確認します
show loggingコマンドにより異常な、あるいは見慣れないログが出力されていないことを確認します

システム状態は正常であり、異常ログもありません

④コントロールプレーンに関する切り分け
今回の構成では様々なプロトコルが動作しています。SRv6でシンプルにしたくなっちゃいますね。
下記コマンドらにより各種プロトコルのネイバーが正常に確立されているか確認します
show ospf neighbor
show bfd session
show mpls ldp neighbor
show bgp vpnv4 unicast summary

また、下記コマンドらによりルーティングテーブルへ正常に経路がインストールされているか確認します
show bpg vpnv4 unicast vrf vrf10
show route vrf vrf10

ここまでは全て正常に動作しているはずです。
例えば、R4でルーティングテーブルを参照するとAS65000から受信した経路を正常に学習できていることが確認出来ます。

RP/0/RP0/CPU0:R4#show bgp vpnv4 uni vrf vrf10
/// snip ///
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 172.16.0.4:10 (default for vrf vrf10)
*> 10.0.0.1/32 10.2.4.2 0 65000 ?
*> 10.0.0.2/32 10.2.4.2 0 0 65000 ?
*> 10.0.0.3/32 10.2.4.2 0 65000 ?
*> 10.0.0.4/32 0.0.0.0 0 32768 ?
*> 10.0.1.0/24 10.2.4.2 0 65000 ?
*> 10.0.2.0/24 0.0.0.0 0 32768 ?
 
Processed 6 prefixes, 4 paths

ここまでの確認状況として以下が判明しています

Host間とAS跨ぎの通信が不可、AS内なら可
IFやシステムは問題無し
ルーティングテーブル的に通信不可の経路エントリーがある

③データプレーン
ここが問題の箇所となります。
前述のルーティングテーブルは正常ながらデータプレーンであるLFIBを確認すると、下記のように隣接ルーターR2/R3に対する転送ラベルのエントリーが存在しないことが分かります

RP/0/RP0/CPU0:R4#sh mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24001 24004 172.16.0.1:10:10.0.0.1/32 \
Gi0/0/0/0 10.2.4.2 0
24002 24007 172.16.0.2:10:10.0.0.2/32 \
Gi0/0/0/0 10.2.4.2 0
24003 24005 172.16.0.3:10:10.0.0.3/32 \
Gi0/0/0/0 10.2.4.2 0
24004 Aggregate vrf10: Per-VRF Aggr[V] \
vrf10 2816
24005 24008 172.16.0.1:10:10.0.1.0/24 \
Gi0/0/0/0 10.2.4.2 0

また冒頭の手順⓪にて解説したPing/Tracerouteによる調査を丹念に行なっていれば以下が判明しているはずです

  • AS65000内の通信は可能
  • ASを跨いだ通信が不可

切り分けにおいてはどこまで正常に動作していて、どこから異常になっているのかという分界点を見つけることが非常に重要です。
これらを切り分けやすくするため、今回の構成ではHost01からAS65000内にPingが打てるようあえてR1〜R3の各ルーターのloopback10を作成しvrf10に所属させています。

よって⓪と③の調査結果が結びつき、下記ように連想出来るようになるはずです。

ASを跨いだ通信が不可である(⓪)
通信不可の理由はASBR間のLFIBに問題があって転送ラベルが正常にインストールされていない(③)

ここまでの切り分けによって設計やプロトコル的な問題点がクリアになり、「LFIBで転送ラベルが正常にインストールできるようにすれば解決しそう?」との考えに至るはずです。

対処を行った後、再度データプレーン確認を行うと下記のように転送ラベルのエントリーが表示されるようになっており、Host間やAS跨ぎでのPingが飛ぶようになっているはずです。

RP/0/RP0/CPU0:R4#sh mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
XXXXX  Pop         10.2.4.2/32        Gi0/0/0/0    10.2.4.2        XXXX <<< 転送ラベルエントリーが出来ている
XXXXX  Pop         10.3.4.3/32        Gi0/0/0/1    10.3.4.3        XXXX <<< 転送ラベルエントリーが出来ている
24001  24004       172.16.0.1:10:10.0.0.1/32   \
                                      Gi0/0/0/0    10.2.4.2        0
24002  24007       172.16.0.2:10:10.0.0.2/32   \
                                      Gi0/0/0/0    10.2.4.2        0
24003  24005       172.16.0.3:10:10.0.0.3/32   \
                                      Gi0/0/0/0    10.2.4.2        0
24004  Aggregate   vrf10: Per-VRF Aggr[V]   \
                                      vrf10                        2816
24005  24008       172.16.0.1:10:10.0.1.0/24   \
                                      Gi0/0/0/0    10.2.4.2        0

今回は「LFIBに隣接ルータの転送ラベルを載せるために、ipv4 host routeをstaticで書く」を解答例として記載しています。

他にもBGP labeled unicastを使用した解決方法などもあるかもしれませんし、今回の解決方法は設計としてあまりスマートなものではありませんが最も単純な方法を掲載させていただいていることをご了承ください

最後に

今回はMPLS-VPN環境におけるトラブルシューティング事例を出題させて頂きました。

昨今、ネットワークの安定性やスケーラビリティ向上のためIPネットワークにおいてコントロールプレーンとデータプレーンを分割するアーキテクチャーが一般化しています。

意図した通り安定動作してくれていれば良いのですが、トラブルが発生した際は様々なコンポーネントを丹念に確認する必要があります。

今回のようなコントロールプレーンは正常動作しているけどデータプレーンに異常があるケースというケースは割とあるあるだったりします。

これらを切り分けるためにはプロトコルの仕様や動作、ルーターの実装やコンフィグ方法などをキチンと把握する必要があります。

今回出題した問題と同じ状況が皆様の環境で発生することは可能性として低いかと思いますが、今後の運用における何らかのヒントになればと思います。

Discussion