状況によっては、Cisco Cloud Network Controller とのサブネットの競合に関する問題が発生することがあります。この問題は、次の条件が満たされた場合に発生する可能性があります。
-
Cisco Cloud Network Controller がリリース 25.0(2) で実行されている
-
Cisco Cloud Network Controller のインフラ VPC サブネットが 172.17.0.0/16 CIDR 内に構成されている(たとえば、Azure での Cisco Cloud Network Controller の展開 の手順の一部として [インフラ VPC プール(Infra VPC Pool)] フィールドに 172.17.10.0/24
と入力した場合)。
-
Cisco Cloud Network Controller のインフラ サブネットで使用している 172.17.0.0/16 CIDR に重複して別のものが構成されている(たとえば、Docker ブリッジの IP サブネットが、Cisco Cloud
Network Controller のデフォルト サブネットである 172.17.0.0/16
で構成されている場合)。
この状況では、このサブネットの競合が原因で Cisco Cloud Network Controller が CCR プライベート IP アドレスに到達できない可能性があり、Cisco Cloud Network Controller は影響を受ける
CCR に対して SSH 接続障害を発生させます。
root として Cisco Cloud Network Controller にログインし、route -n
コマンドを入力すれば、競合の可能性があるかどうかを判断できます。
[root@ACI-Cloud-Fabric-1 ~]# route -n
以下のような出力が表示されることが想定されます。
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.17 0.0.0.0 UG 16 0 0 oobmgmt
169.254.169.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0
169.254.254.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.17.0.12 0.0.0.0 255.255.255.252 U 0 0 0 bond0
172.17.0.16 0.0.0.0 255.255.255.240 U 0 0 0 oobmgmt
この出力例では、強調表示されたテキストは、Docker ブリッジが 172.17.0.0/16
で構成されていることを示しています。
これは Cisco Cloud Network Controller のインフラ サブネットに使用した 172.17.0.0/16 CIDR と重複しているため、CCR への接続が失われ、CCR に SSH で接続できないという問題が発生する可能性があります。
CCR に ping を実行しようとすると、ホストに到達できないというメッセージが表示されます(次の例では、172.17.0.84 が CCR のプライベート IP アドレスです)。
[root@ACI-Cloud-Fabric-1 ~]# ping 172.17.0.84
PING 172.17.0.84 (172.17.0.84) 56(84) bytes of data.
From 172.17.0.1 icmp_seq=1 Destination Host Unreachable
From 172.17.0.1 icmp_seq=2 Destination Host Unreachable
From 172.17.0.1 icmp_seq=3 Destination Host Unreachable
From 172.17.0.1 icmp_seq=5 Destination Host Unreachable
From 172.17.0.1 icmp_seq=6 Destination Host Unreachable
^C
--- 172.17.0.84 ping statistics ---
9 packets transmitted, 0 received, +5 errors, 100% packet loss, time 8225ms
pipe 4
[root@ACI-Cloud-Fabric-1 ~]#
この状況で競合を解決するには、次のような REST API 投稿を入力して、競合の原因となっている他の領域の IP アドレスを変更します。
https://{{apic}}/api/plgnhandler/mo/.xml
<apPluginPolContr>
<apContainerPol containerBip="<new-IP-address>" />
</apPluginPolContr>
たとえば、上記のシナリオ例で示した 172.17.0.0/16 CIDR の下から Docker ブリッジの IP アドレスを移動するには、次のような REST API 投稿を入力します。
https://{{apic}}/api/plgnhandler/mo/.xml
<apPluginPolContr>
<apContainerPol containerBip="172.19.0.1/16" />
</apPluginPolContr>
ここで、172.19.0.1/16
は Docker ブリッジの新しいサブネットです。これにより、Docker ブリッジの IP アドレスが 172.19.0.0/16 CIDR に移動するので、172.17.0.0/16 CIDR で構成されている Cisco Cloud Network
Controller のインフラ サブネットとの競合がなくなります。
以前と同じコマンドを使用して、競合がなくなったことを確認できます。
[root@ACI-Cloud-Fabric-1 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.17 0.0.0.0 UG 16 0 0 oobmgmt
169.254.169.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0
169.254.254.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
172.17.0.12 0.0.0.0 255.255.255.252 U 0 0 0 bond0
172.17.0.16 0.0.0.0 255.255.255.240 U 0 0 0 oobmgmt
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
この出力例では、強調表示されたテキストは、Docker ブリッジが IP アドレス 172.19.0.0
で構成されていることを示しています。Cisco Cloud Network Controller のインフラ サブネットに使用している 172.17.0.0/16 CIDR との重複がないため、CCR との接続に問題はありません。
[root@ACI-Cloud-Fabric-1 ~]# ping 172.17.0.84
PING 172.17.0.84 (172.17.0.84) 56(84) bytes of data.
64 bytes from 172.17.0.84: icmp_seq=1 ttl=255 time=1.15 ms
64 bytes from 172.17.0.84: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 172.17.0.84: icmp_seq=3 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=4 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=5 ttl=255 time=1.09 ms
64 bytes from 172.17.0.84: icmp_seq=6 ttl=255 time=1.06 ms
64 bytes from 172.17.0.84: icmp_seq=7 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=8 ttl=255 time=1.05 ms
^C
--- 172.17.0.84 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7005ms
rtt min/avg/max/mdev = 1.014/1.061/1.153/0.046 ms
[root@ACI-Cloud-Fabric-1 ~]#