Synology DSM 7.3 Container Manager Multi-NIC and Macvlan Setup

A practical guide to using Macvlan with Synology DSM 7.3 and 7.2 Container Manager for multi-NIC binding, dedicated LAN IPs, Compose configuration, Open vSwitch, and common pitfalls.

Synology DSM 7.3 and DSM 7.2 ship with Container Manager, but its GUI mainly exposes the basic bridge and host networks. If your NAS has multiple NICs, for example LAN1 for the internal network and LAN2 for a separate router or subnet, and you want some containers to use LAN2 specifically or obtain an independent IP on that subnet, Docker macvlan is usually the right tool.

The common use cases are:

  • bind a container to a physical NIC and give it an independent IP on that subnet;
  • connect a container to both the default bridge network and a NIC-specific macvlan network.

The examples below assume the second NIC is ovs_eth1 and the LAN2 subnet is 192.168.2.0/24. Adjust the subnet, gateway, and interface name for your own network.

Confirm the physical interface name first

Enable SSH in DSM, log in to the NAS, and run:

1
ifconfig

If Open vSwitch is enabled, interface names usually look like ovs_eth0 and ovs_eth1. Machines with Virtual Machine Manager installed often have Open vSwitch enabled automatically.

If Open vSwitch is not enabled, the interface names are usually eth0, eth1, and so on.

The examples below use ovs_eth1 for the second NIC. If your NAS does not use Open vSwitch, replace ovs_eth1 with the actual name you see, such as eth1.

Scenario 1: Give a container a dedicated IP on a specific NIC

This is the most common setup. It works well for Pi-hole, AdGuard Home, downloaders, gateway-like services, and similar containers. The goal is to make the container appear directly on the LAN2 subnet with an IP that behaves like a physical device, instead of hiding it behind Synology’s default Docker network.

Container Manager cannot create a macvlan network directly from the GUI, so create it once over SSH:

1
2
3
4
5
6
sudo docker network create -d macvlan \
  --subnet=192.168.2.0/24 \
  --gateway=192.168.2.1 \
  --ip-range=192.168.2.200/29 \
  -o parent=ovs_eth1 \
  custom_lan2_net

The parameters mean:

  • -d macvlan: use the macvlan driver;
  • --subnet=192.168.2.0/24: the full LAN2 subnet;
  • --gateway=192.168.2.1: the gateway for LAN2, usually the router IP;
  • --ip-range=192.168.2.200/29: restrict the IP range Docker can allocate to avoid conflicts with phones, PCs, TVs, and other devices;
  • -o parent=ovs_eth1: bind this network to the selected physical NIC;
  • custom_lan2_net: the Docker network name.

After the network is created, open Container Manager in DSM and go to the “Network” page. You should see custom_lan2_net. From there, you can attach existing containers to it, or select it when creating a new container and assign a fixed IP inside that subnet.

Scenario 2: Connect one container to multiple networks

Some containers need to appear on more than one network. For example, a container may need to be reachable by the Synology host through the default bridge network while also having a dedicated physical-subnet IP on LAN2. In that case, attach the container to two virtual networks.

Method A: Add the second network in the GUI

Create the container normally first and select a primary network such as the default bridge. Do not start it yet; if it is already running, stop it first.

Then open the “Network” page in Container Manager, select custom_lan2_net, click “Manage”, check the target container, and save. After the container starts, it will usually have two virtual interfaces inside, such as eth0 and eth1.

This method is best when you only need to configure one or two containers and do not want to edit Compose files.

Method B: Use a Docker Compose project

If you prefer Container Manager’s “Project” feature, define both networks in docker-compose.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
version: '3.8'

services:
  my_node:
    image: nginx:latest
    container_name: multi_nic_container
    networks:
      default_bridge:
        ipv4_address: 172.20.0.10
      lan2_macvlan:
        ipv4_address: 192.168.2.205

networks:
  default_bridge:
    external: true
    name: bridge
  lan2_macvlan:
    external: true
    name: custom_lan2_net

Here, custom_lan2_net is the macvlan network you created over SSH. bridge references Synology’s built-in Docker bridge network.

The sample 172.20.0.10 only applies if your bridge network actually uses that subnet. On many Synology systems, Docker’s default bridge network is more commonly 172.17.0.0/16. Check the actual value with docker network inspect bridge.

The host-to-container Macvlan limitation

macvlan has one important trap: by default, the Linux kernel does not allow the host to communicate directly with containers through the same macvlan interface.

In practice, if a container only joins custom_lan2_net, DSM itself may not be able to access that container through its LAN2 physical-subnet IP. The container may also be unable to reach the host through that interface.

Common solutions are:

  • attach the container to the default bridge network as well, then let Synology reach it through the Docker internal address;
  • create an additional host-side macvlan sub-interface on the Synology NAS, so the host also joins the same macvlan communication domain.

The second option is closer to network engineering and has a higher maintenance cost. For most home and small-office setups, using both bridge and macvlan is simpler.

Avoid IP conflicts early

With macvlan, container IPs appear directly on the physical LAN, so avoid conflicts with your DHCP pool.

Ideally, exclude the Docker range on your main router. For example, if you plan to allocate 192.168.2.200/29 to Docker, do not let the router assign 192.168.2.200 through 192.168.2.207 to phones, computers, or other devices.

If your router cannot exclude a DHCP range easily, at least use a high address range that is unlikely to be assigned automatically, and keep a written record.

How to enable Open vSwitch

On DSM 7.x, Open vSwitch can be enabled from the GUI. You do not need to edit low-level network files manually. The easiest method is to install Synology’s Virtual Machine Manager, because VM network bridging depends on Open vSwitch and the setup wizard will prompt you to enable it.

Steps:

  1. Open DSM “Package Center”;
  2. search for and install Virtual Machine Manager;
  3. open the package and follow the wizard to enable Open vSwitch;
  4. wait for the network service to restart.

If you do not want to install VMM, enable it manually:

  1. Open “Control Panel”;
  2. go to “Network”;
  3. switch to the “Network Interface” tab;
  4. click “Manage” and choose “Open vSwitch Settings”;
  5. check “Enable Open vSwitch” and apply.

After applying the change, DSM will reinitialize the NICs and your browser session may disconnect briefly. Do not do this while the NAS is transferring large files or performing important writes.

Verify Open vSwitch

In the GUI, go back to “Control Panel -> Network -> Network Interface” and check the NIC status. The management menu should also show Open vSwitch settings.

From the command line, run again:

1
ifconfig

or:

1
ip addr

If you see interfaces such as ovs_eth0 and ovs_eth1, Open vSwitch is active. When creating a macvlan network, use the ovs_ interface in -o parent=, for example:

1
-o parent=ovs_eth1

If you still use eth1, the container may not connect through the expected NIC.

Pre-configuration checklist

Before making changes, confirm:

  • how many physical NICs the Synology NAS has, and which ports have cables connected;
  • which switch, router, or VLAN each port connects to;
  • whether DSM shows the target NIC as ethX or ovs_ethX;
  • whether --subnet and --gateway belong to the target NIC’s subnet;
  • whether --ip-range has been excluded from the DHCP pool;
  • whether the container needs to be accessed by the Synology host. If it does, attach it to bridge as well.

As long as the interface name, subnet, and IP pool are correct, DSM 7.3 Container Manager works well with macvlan for multi-NIC container deployment. The GUI handles day-to-day management, while SSH is only needed to create the underlying network.

记录并分享
Built with Hugo
Theme Stack designed by Jimmy