Readdressing the Docker network on an existing
Cyber Recovery deployment
Instruct Docker to use specified subnet ranges when creating
Cyber Recovery Docker bridges and networks.
Prerequisites
The
Cyber Recovery software or the
Cyber Recovery virtual appliance is deployed.
About this task
At installation, the
Cyber Recovery software creates the Docker
cr_back and
cr_front networks, which contain and isolate the Docker containers that run as part of the
Cyber Recovery deployment.
By default, Docker creates bridge interfaces for these networks and the
docker0 interface, and then assigns the 172.x subnet ranges, typically starting with 172.17.x, 172.18.x, and so on. These Docker IP ranges might conflict with your environment. If subnets in the
Cyber Recovery vault conflict with any of these Docker subnets, the
Cyber Recovery software is prevented from configuring any assets that are assigned to the conflicting vault subnet.
Steps
Save any previous
Cyber Recovery configurations:
crsetup.sh --save
Stop the
Cyber Recovery software:
crsetup.sh --stop
Remove the Docker
cr_back and
cr_front networks:
docker network rm cr_front cr_back
Stop the Docker services:
systemctl stop docker.service
Add a
default-address-pools definition for your environment to the
/etc/docker/daemon.json file:
NOTE This code is an example; use values that are appropriate for your environment.
Update the configuration:
systemctl daemon-reload
Restart the Docker services:
systemctl start docker.service
Verify that the
docker0: interface is allocated from the pool that is defined in step 5.
Re-create the
Cyber Recovery containers :
crsetup.sh --forcerecreate
Verify that bridge interfaces and the Docker
cr_back and
cr_front networks are on separate subnets that are based on the
default-address-pools configuration in the
/etc/docker/daemon.json file.
Example
NOTE The following provides an example only. Use values that are appropriate for your environment.
As an example, the following shows a typical
Cyber Recovery default Docker network bridge interface configuration for
docker0,
cr_front, and
cr_back:
This example assumes that there is a conflict with the 172.17.x subnet. To avoid the conflict, the procedure forces Docker to use subnets in the 172.18.x range.
The following example shows the modified network interfaces using the new 172.18.x subnets: