Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Dell PowerProtect Cyber Recovery 19.12 Installation Guide

PDF

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

  1. Save any previous Cyber Recovery configurations:
    crsetup.sh --save
  2. Stop the Cyber Recovery software:
    crsetup.sh --stop
  3. Remove the Docker cr_back and cr_front networks:
    docker network rm cr_front cr_back
  4. Stop the Docker services:
    systemctl stop docker.service
  5. Add a default-address-pools definition for your environment to the /etc/docker/daemon.json file:
    For example:
     
    
    {
        "default-address-pools": [
            {
            "base":"172.18.0.0/16",
           "size":24
            }
        ]
    }
    NOTE This code is an example; use values that are appropriate for your environment.
  6. Update the configuration:
    systemctl daemon-reload
  7. Restart the Docker services:
    systemctl start docker.service
  8. Verify that the docker0: interface is allocated from the pool that is defined in step 5.
  9. Re-create the Cyber Recovery containers :
    crsetup.sh --forcerecreate
  10. 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:

br-34b7ef904da6: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.19.0.1 netmask 255.255.0.0 broadcast 172.19.255.255
ether 02:42:e2:f6:55:6c txqueuelen 0 (Ethernet)
RX packets 6512 bytes 787096 (768.6 KiB)
RX errors 0 dropped 119 overruns 0 frame 0
TX packets 748 bytes 87677 (85.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br-ff67c646cfae: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255
ether 02:42:78:1e:27:78 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:43:eb:a8:44 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

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:

root@ldpda088 ~]# ifconfig
br-9954ec308097: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.18.2.1 netmask 255.255.255.0 broadcast 172.18.2.255
ether 02:42:91:5a:42:ef txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

br-fb8c116b865c: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.18.1.1 netmask 255.255.255.0 broadcast 172.18.1.255
ether 02:42:85:fc:ec:1a txqueuelen 0 (Ethernet)
RX packets 46928 bytes 5860719 (5.5 MiB)
RX errors 0 dropped 1031 overruns 0 frame 0
TX packets 3433 bytes 341151 (333.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.255.0 broadcast 172.18.0.255
ether 02:42:03:2f:e9:49 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\