,
,
,
Part 2B: this half of the deep dive focuses on addressing (IPv4 and IPv6), policy routing, routing distribution, and MAC identity. If you have not read Part 2A yet, start there for the segmentation model, identity conventions, and split-horizon DNS.
Series navigation: Part 1 · Part 2A · Part 2B · Part 3
On this page:
IPv4 is straightforward, but it benefits from discipline:
Stable addressing is about more than convenience. It affects firewall policy, monitoring, reverse DNS, and your ability to answer questions such as “what changed” without guessing.
IPv6 is not an afterthought in our environment. We have been running IPv6 for decades and have contributed to improving IPv6 adoption in software, hardware and real networks. In our office we had IPv6 working roughly 25 years ago, including early deployments that relied on IPv6 transition mechanisms that traversed NAT long before they became mainstream—approaches that are now long obsolete.
Today, our IPv6 model is:
We use stateful stable assignment for servers, routers and switches (via DHCPv6 reservations or manual configuration) so infrastructure does not “lose” its address identity when links flap. Infrastructure devices and key workstations receive stable assignments (via DHCPv6 reservations or manual configuration) so identities remain predictable. General workstations, and peripherals receive dynamic leases within a dedicated sub-prefix. This keeps day-to-day client addressing flexible while maintaining deterministic infrastructure.
SLAAC is not inherently wrong, but “SLAAC-only everywhere” creates operational friction when you care about deterministic infrastructure:
For infrastructure devices and key workstations we want determinism. For general workstations and peripherals we want controlled dynamism. RA + DHCPv6 lets us express both cleanly.
This is the DSM gotcha that breaks more setups than people realise. DSM even hides it behind a somewhat misleading label: the “multiple gateways” setting is not just about having more than one default route, it is about making DSM program per-interface policy routing correctly on a multi-homed system. When a host has multiple active interfaces (multiple VLANs), you can otherwise easily end up with asymmetric routing:
That behaviour poisons state tracking (on routers and firewalls), breaks TCP in non-obvious ways, and creates the illusion that VLANs are misconfigured. In DSM you must explicitly enable support for multiple gateways under the network advanced settings, otherwise DSM may only program one main routing table instead of per-interface policy routing with appropriate source selection.
Operational rule: ensure the default route points at the interface that actually provides internet egress, and ensure failover priorities are explicit and correct. A “maintenance” VLAN should not accidentally become your default egress just because it was configured first.
In Part 3 we will show how we validate this at the DSM level (GUI) and at the Linux level (policy routing rules), but the design principle is simple: multi-homing requires explicit gateway policy.
In segmented environments you usually have multiple “next hops”: inter-VLAN routing, site-to-site VPN routing, and sometimes special egress routes toward security gateways. The goal is to make routing predictable for clients and services without requiring every device to be manually configured.
In our network, routing intent is centralised: routers and DHCP services distribute what clients need, including default gateway selection and reachability toward other VLANs and VPN-connected networks. The same mechanism is also how we propagate core infrastructure options such as the internal split-horizon DNS resolvers for that segment, a local time server (NTP), and—where applicable—proxy settings. The exact method varies by platform (IPv4 DHCP options versus IPv6 RA/DHCPv6 options), but the design principle is consistent: clients should not require artisanal static route configuration.
Here is the uncomfortable truth: “it works most of the time” is not an acceptable design criterion for a multi-VLAN trunk that supports both DSM and virtual machines.
In generic networking, reusing one MAC address across multiple VLAN-tagged subinterfaces is not automatically wrong. However, once you introduce DSM 7, Open vSwitch, VMM, multiple bridges, and Synology’s interface discovery heuristics, it becomes easy to create a situation where MAC identity is no longer a stable indicator of “where frames should live.” The result can be instability that looks like table poisoning: ARP/ND churn, MAC learning flaps, and intermittent reachability that comes and goes with interface events.
Our solution is to treat MAC identity as part of the design contract:
Part 3 will show how this intersects with DSM and VMM in practice, and how we correct it without fighting the system on every update.
Good engineering is not only what happens in the dataplane; it is also how people operate the system. DSM labels interfaces as LAN1…LAN5 for the base NICs, and additional interfaces can show up as LAN20, LAN30, and so on. We intentionally align these labels with VLAN meaning, so that selecting an interface in DSM or in a package UI is less error-prone.
This may sound cosmetic. It is not. In segmented networks, one wrong interface selection can turn into an outage or a security incident. Clear interface identity reduces mistakes.
If you want to implement the DSM 7 trunking approach in Part 3, verify these design prerequisites first:
In Part 3 we move from design to implementation: DSM 7.2.2-update-3, Open vSwitch, kernel VLAN interfaces, and the rc.network modifications that keep DSM, packages, and VMM aligned.
Previous: Multi-VLAN Trunking on Synology DSM 7 - Network design deep dive Part A
Next: Multi-VLAN Trunking on Synology DSM 7 - DSM 7.2.2 implementation
Copyright © 2026, ASK-Solutions
