IPv6基礎学習 第五回 演習編「Cisco CSR1000vでIPv6 BGPネットワークの疎通確認と障害試験」

IPv6BGP,IPv6

はじめに

前回、第四回 演習編でCiscoCSR1000vを使いBGPネットワークを構築しました。

今回は第五回となる演習編で、第四回 演習編 で作ったBGPネットワークを使い疎通確認や障害試験を実施していきます。

第一回座学編IPv6の利用状況やIPv4の違いについて説明
第二回座学編IPv6アドレス表記と自動割り当てについて説明
第三回演習編Windows10+Cisco CSR1000vで簡易なIPv6ネットワークの構築
第四回演習編Cisco CSR1000vでIPv6 BGPネットワークの構築
第五回 演習編Cisco CSR1000vでIPv6 BGPネットワークの疎通確認と障害試験

実施概要と環境について

実施概要

ネットワーク構成は前回構築した同じものを使います。疎通確認はWindows10-01からWindows10-02にします。障害は主にCSR1000v-02で起こします。

環境

機器OS Version
Windows10-1/221H1(19043.1266)
CSR1000v-01/02/03/0417.3.4a

疎通確認

まずは正常時の状態で疎通確認をします。疎通イメージは下記となります。

Windows10-01からWindows10-02へPingとTracerouteを実施しました。疎通も問題なく、経路もイメージ図の通りとなってます。

C:\Users\kantaro>ping -6 2001:2:2:2:68d8:3784:8cc0:4eac

2001:2:2:2:68d8:3784:8cc0:4eac に ping を送信しています 32 バイトのデータ:
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =1ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =1ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 <1ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 <1ms

2001:2:2:2:68d8:3784:8cc0:4eac の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 1ms、平均 = 0ms

C:\Users\kantaro>

C:\Users\kantaro>tracert -6 -d 2001:2:2:2:68d8:3784:8cc0:4eac

2001:2:2:2:68d8:3784:8cc0:4eac へのルートをトレースしています。経由するホップ数は最大 30 です

  1    <1 ms    <1 ms    <1 ms  2001:1:1:1::1
  2    <1 ms    <1 ms    <1 ms  2001:1:1:99::2
  3     1 ms     1 ms    <1 ms  2001:2:2:2:68d8:3784:8cc0:4eac

トレースを完了しました。

C:\Users\kantaro>

一応、戻りの経路も確認してみます。Windows10-02からWindows10-01に対してのtracerouteです。
こちらも想定通り同経路で戻っていることが確認できます。

C:\Users\kantaro.LAB-INFRA>tracert -d 2001:1:1:1:4990:197f:9f1f:ce93

2001:1:1:1:4990:197f:9f1f:ce93 へのルートをトレースしています。経由するホップ数は最大 30 です

  1     1 ms    <1 ms    <1 ms  2001:2:2:2::1
  2     1 ms     1 ms    <1 ms  2001:1:1:99::1
  3     1 ms    <1 ms     1 ms  2001:1:1:1:4990:197f:9f1f:ce93

トレースを完了しました。

C:\Users\kantaro.LAB-INFRA>

また、CSR1000v-01にて正常時の状態でのBGP状態とルーティングテーブルを記載しときます。(対向のCSR1000v-02で障害が起きた場合、どう変わるのかを確認する為)

CSR1000v-01#show bgp ipv6 unicast summary
<省略>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2001:1:1:97::2  4          111    1706    1712       10    0    0 03:12:19        2
2001:1:1:99::2  4          222    1480    1488       10    0    0 02:47:08        1

CSR1000v-01#

CSR1000v-01#show bgp ipv6 unicast
<省略>
     Network          Next Hop            Metric LocPrf Weight Path
 * i  2001:1:1:1::/64  2001:1:1:97::2           0    100      0 i
 *>                    ::                       0         32768 i
 *>   2001:2:2:2::/64  2001:1:1:99::2           0             0 222 i
 * i                   2001:1:1:97::2           0    100      0 222 i
CSR1000v-01#

CSR1000v-01#show ipv6 route
<省略>
C   2001:1:1:1::/64 [0/0]
     via GigabitEthernet3, directly connected
L   2001:1:1:1::1/128 [0/0]
     via GigabitEthernet3, receive
C   2001:1:1:97::/64 [0/0]
     via GigabitEthernet4.14, directly connected
L   2001:1:1:97::1/128 [0/0]
     via GigabitEthernet4.14, receive
C   2001:1:1:99::/64 [0/0]
     via GigabitEthernet2.10, directly connected
L   2001:1:1:99::1/128 [0/0]
     via GigabitEthernet2.10, receive
B   2001:2:2:2::/64 [20/0], tag 222
     via FE80::20C:29FF:FE8D:8315, GigabitEthernet2.10
L   FF00::/8 [0/0]
     via Null0, receive
CSR1000v-01#

障害試験

次に障害試験を実施してみます。障害ケースは2通り実施します。

 障害ケース1 CSR1000v-02の筐体障害
 障害ケース2 CSR1000v-02のLAN側障害

※CSR1000v-02のWAN側リンク障害は筐体障害とほぼ同じ結果になりますので実施しませんでした。

障害ケース1 CSR1000v-02の筐体障害

まずはCSR1000v-02に障害を起こして切り替わるかを確認します。

障害を発生させた状態でWindows10-01からWindows10-02へPingとTracerouteを実施しました。疎通も問題なく、経路もイメージ図の通りです。

C:\Users\kantaro>ping -6 2001:2:2:2:68d8:3784:8cc0:4eac

2001:2:2:2:68d8:3784:8cc0:4eac に ping を送信しています 32 バイトのデータ:
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =2ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 <1ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =1ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 <1ms

2001:2:2:2:68d8:3784:8cc0:4eac の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 2ms、平均 = 0ms

C:\Users\kantaro>

C:\Users\kantaro>tracert -6 -d 2001:2:2:2:68d8:3784:8cc0:4eac

2001:2:2:2:68d8:3784:8cc0:4eac へのルートをトレースしています。経由するホップ数は最大 30 です

  1    <1 ms    <1 ms    <1 ms  2001:1:1:1::1
  2    <1 ms    <1 ms    <1 ms  2001:1:1:97::2
  3     1 ms    <1 ms     1 ms  2001:1:1:98::2
  4     2 ms    <1 ms     1 ms  2001:2:2:2:68d8:3784:8cc0:4eac

トレースを完了しました。

C:\Users\kantaro>

CSR1000v-01でBGPのステータスとルーティングテーブルを確認してみます。

「show bgp ipv6 unicast summary」では障害が発生したCSR1000v-02の2001:1:1:99::2がIdleとなり、ネイバーが切れている様子が分かります。

「show bgp ipv6 unicast」では対向のLANである2001:2:2:2::/64のプレフィックスが対向からもらえなくなり、渡りへの候補しかないことが分かります。

「show ipv6 route」では 対向のLANである2001:2:2:2::/64宛てのルーティングが渡りに向きました

CSR1000v-01#show bgp ipv6 unicast summary
<省略>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2001:1:1:97::2  4          111    2499    2505       13    0    0 04:41:45        2
2001:1:1:99::2  4          222       0       0        1    0    0 00:00:42 Idle

CSR1000v-01#show bgp ipv6 unicast
<省略>
     Network          Next Hop            Metric LocPrf Weight Path
 * i  2001:1:1:1::/64  2001:1:1:97::2           0    100      0 i
 *>                    ::                       0         32768 i
 *>i  2001:2:2:2::/64  2001:1:1:97::2           0    100      0 222 i

CSR1000v-01#show ipv6 route
<省略>
C   2001:1:1:1::/64 [0/0]
     via GigabitEthernet3, directly connected
L   2001:1:1:1::1/128 [0/0]
     via GigabitEthernet3, receive
C   2001:1:1:97::/64 [0/0]
     via GigabitEthernet4.14, directly connected
L   2001:1:1:97::1/128 [0/0]
     via GigabitEthernet4.14, receive
C   2001:1:1:99::/64 [0/0]
     via GigabitEthernet2.10, directly connected
L   2001:1:1:99::1/128 [0/0]
     via GigabitEthernet2.10, receive
B   2001:2:2:2::/64 [200/0], tag 222
     via 2001:1:1:97::2
L   FF00::/8 [0/0]
     via Null0, receive
CSR1000v-01#

障害ケース2 CSR1000v-02のLAN側障害

次にCSR1000v-02のLAN側で障害を発生させます。

障害を発生させても疎通は問題なしです。Windows10-01からWindows10-02へPingとTracerouteを実施しました。疎通も問題なく、経路もイメージ図の通りです。

C:\Users\kantaro>ping -6 2001:2:2:2:68d8:3784:8cc0:4eac

2001:2:2:2:68d8:3784:8cc0:4eac に ping を送信しています 32 バイトのデータ:
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =1ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =2ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =1ms
2001:2:2:2:68d8:3784:8cc0:4eac からの応答: 時間 =1ms

2001:2:2:2:68d8:3784:8cc0:4eac の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 1ms、最大 = 2ms、平均 = 1ms

C:\Users\kantaro>

C:\Users\kantaro>tracert -6 -d 2001:2:2:2:68d8:3784:8cc0:4eac

2001:2:2:2:68d8:3784:8cc0:4eac へのルートをトレースしています。経由するホップ数は最大 30 です

  1    <1 ms    <1 ms     2 ms  2001:1:1:1::1
  2     1 ms     1 ms    <1 ms  2001:1:1:99::2
  3     2 ms     1 ms     1 ms  2001:1:1:96::2
  4     1 ms     1 ms     1 ms  2001:2:2:2:68d8:3784:8cc0:4eac

トレースを完了しました。

C:\Users\kantaro>

CSR1000v-01でBGPのステータスとルーティングテーブルを確認してみます。

「show bgp ipv6 unicast summary」では障害が発生したCSR1000v-02の2001:1:1:99::2と正常にネイバーが張れています。

「show bgp ipv6 unicast」では対向のLANである2001:2:2:2::/64のプレフィックスが対向から受信しています。

「show ipv6 route」では 対向のLANである2001:2:2:2::/64宛てのルーティングも対向のCSR1000v-02へとNexthopが向いています。

今回の障害ケースはLAN側の障害の為、WAN観点では問題ありませんでした

CSR1000v-01#show bgp ipv6 unicast summary
<省略>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2001:1:1:97::2  4          111    2641    2649       14    0    0 04:57:52        2
2001:1:1:99::2  4          222     128     129       14    0    0 00:13:57        1

CSR1000v-01#

CSR1000v-01#show bgp ipv6 unicast
<省略>
     Network          Next Hop            Metric LocPrf Weight Path
 * i  2001:1:1:1::/64  2001:1:1:97::2           0    100      0 i
 *>                    ::                       0         32768 i
 *>   2001:2:2:2::/64  2001:1:1:99::2           0             0 222 i
 * i                   2001:1:1:97::2           0    100      0 222 i

CSR1000v-01#show ipv6 route
<省略>
C   2001:1:1:1::/64 [0/0]
     via GigabitEthernet3, directly connected
L   2001:1:1:1::1/128 [0/0]
     via GigabitEthernet3, receive
C   2001:1:1:97::/64 [0/0]
     via GigabitEthernet4.14, directly connected
L   2001:1:1:97::1/128 [0/0]
     via GigabitEthernet4.14, receive
C   2001:1:1:99::/64 [0/0]
     via GigabitEthernet2.10, directly connected
L   2001:1:1:99::1/128 [0/0]
     via GigabitEthernet2.10, receive
B   2001:2:2:2::/64 [20/0], tag 222
     via FE80::20C:29FF:FE8D:8315, GigabitEthernet2.10
L   FF00::/8 [0/0]
     via Null0, receive
CSR1000v-01#

LAN側なのでCSR1000v-02とCSR1000v-04のHSRPの状態を確認してみました。

障害を発生させたCSR1000v-02ではStateがInitでありHSRPが組めていません。CSR1000v-04がActiveとして稼働しています。IPv6でもHSRPが正常に切り替わっていることが分かります。

CSR1000v-02#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi3         1    115 P Init    unknown         unknown         FE80:2::FFFF
CSR1000v-02#
CSR1000v-04#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi3         1    110 P Active  local           unknown         FE80:2::FFFF
CSR1000v-04#

HSRPの仮想IPアドレスが切り替わり経路も想定通りか確認する為、Windows10-02からWindows10-01へtracerouteしてみました。

結果、1stホップでCSR1000v-04に行き、2ndホップでCSR1000v-02に行き、そのままWindows10-01へ行けていることが確認できました。

C:\Users\kantaro.LAB-INFRA>tracert -d 2001:1:1:1:4990:197f:9f1f:ce93

2001:1:1:1:4990:197f:9f1f:ce93 へのルートをトレースしています。経由するホップ数は最大 30 です

  1    <1 ms    <1 ms    <1 ms  2001:2:2:2::2
  2     1 ms     1 ms    <1 ms  2001:1:1:98::1
  3    <1 ms     1 ms    <1 ms  2001:1:1:1:4990:197f:9f1f:ce93

トレースを完了しました。

C:\Users\kantaro.LAB-INFRA>

以上で、IPv6 BGPネットワークでの疎通確認と障害試験を終わりにします。

第一回~第五回までのまとめ

IPv6シリーズとして第一回第二回で座学編、第三回第四回・第五回で演習編の記事を書かせていただきました。

座学編では、現状のIPv6の利用状況やIPv4との仕様的違い、また、IPv6特有のアドレス表記やWindowsがどうやってIPv6を学習するのかについて説明しました。

演習編では、実際にCiscoのCSR1000vを用いてWindows10へのIPv6アドレスの学習、及び、冗長構成のIPv6 BGPネットワークを組み疎通確認や障害試験を実施してみました。

私自身IPv6に関して商用環境レベルでの実装経験はまだ非常に少なく学習中の身であるため、また新しい知識を手に入れましたら当ブログで公開させていただきます。

IPv6BGP,IPv6