Concerning the CAS, there is the docker bridge interface, as seen in the TS log. See the below.
[
{
"Name": "bridge",
"Id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Created": "xxxx-07-07T12:23:58.xxxxxxxxxxxxxxxxx",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "x.x.0.0/16",
"Gateway": "x.x.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
CAS 3.2.2.1/MC 3.x.x.x
This is completely an address/routing issue, as a result of a conflict between addresses/subnets within the customer's environment and the docker bridge network within the CAS.
This is an address/routing issue on CAS, witt the fix provided in CAS 4.1.1.x. An upgrade of the MC to ver. 4.1.1.1 would not fix this address/routing issue.
Workaround:
CAS(config)# ip route <Connected MC_IP> /32 <Default Gateway for Connected CAS_IP> device-name 0:0
This would be addressing the specific connectivity issue, a static route that allows every traffic intended for the MC, x.x.x.x/32 to go through the particular default gateway for the CAS.