Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it clear that it is ok to use bonding #91

Merged
merged 1 commit into from
Aug 31, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions docs/unraid-os/release-notes/6.12.4.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ If rolling back earlier than 6.12.0, also see the [6.12.0 release notes](6.12.0.
The big news in this release is that we have resolved issues related to macvlan call traces and crashes!

The root of the problem is that macvlan used for custom Docker networks is unreliable when the parent interface is a
bridge (like br0), it works best on a physical interface (like eth0). We believe this to be a longstanding kernel
bridge (like br0), it works best on a physical interface (like eth0) or a bond (like bond0). We believe this to be a longstanding kernel
issue and have posted a [bug report](https://bugzilla.kernel.org/show_bug.cgi?id=217777).

If you are getting call traces related to macvlan, as a first step we recommend navigating to ***Settings > Docker***,
Expand All @@ -40,19 +40,20 @@ with advanced network management tools (Ubiquity) when in ipvlan mode.
For those users, we have a new method that reworks networking to avoid this. Tweak a few settings and your
Docker containers, VMs, and WireGuard tunnels should automatically adjust to use them:

* ***Settings > Network Settings > eth0 > Enable Bonding*** = Yes or No, either work with this solution
* ***Settings > Network Settings > eth0 > Enable Bridging*** = No
* ***Settings > Docker > Host access to custom networks*** = Enabled

Note: if you previously used the [2-nic docker segmentation method](https://forums.unraid.net/topic/137048-guide-how-to-solve-macvlan-and-ipvlan-issues-with-containers-on-a-custom-network/),
you will also want to revert that:

* ***Settings > Docker > custom network on interface eth0*** (i.e. make sure eth0 is configured for the custom network, not eth1)
* ***Settings > Docker > custom network on interface eth0 or bond0*** (i.e. make sure eth0/bond0 is configured for the custom network, not eth1/bond1)

When you Start the array, the host, VMs, and Docker containers will all be able to communicate, and there should be no more call traces!

### Troubleshooting

* If your Docker containers with custom IPs are not starting, edit them and change the "Network type" to "Custom: eth0". We attempted
* If your Docker containers with custom IPs are not starting, edit them and change the "Network type" to "Custom: eth0" or "Custom: bond0". We attempted
to do this automatically, but depending on how things were customized you may need to do it manually.
* If your VMs are having network issues, edit them and set the Network Source to "vhost0". Also, ensure there is a MAC address assigned.
* If your WireGuard tunnels will not start, make a dummy change to each tunnel and save.
Expand Down