Jump to content
Hoopster

[6.5.0]+ Call Traces when assigning IP to Dockers

64 posts in this topic Last Reply

Recommended Posts

Currently using a mix of everything:

bridge

host

br1 (custom IP)

br1.3 (VLAN)

but not using br0 or br0.x

and so far no call traces...

 

current NICs are

Intel I211 (igb) - eth0

Intel I219-V (e1000e) -eth1

 

Share this post


Link to post

So I finally decided that using ( br0 which unraid runs on ) with VLAN's is not a good idea for me.

 

Since I have more ethernet adapters on my server, I decided to use eth4 and put all my docker VLAN's on that.

 

It's fairly early, but I'm pretty sure that I have gotten rid of my call traces.

 

One note, you have to set interface IPv4 address assignment to None.  If you don't do that, unraid will assign an arbitrary ip address.  But the bigger problem especially with my network is that you will constantly loose and regain an ip address on the main VLAN interface from the dhcp server.  This would occur randomly between 15 minutes to two hours.

 

So my final setup for the VLAN is as follows:

 

1168687376_ScreenShot2018-06-12at5_06_47PM.thumb.png.894343d1adbc3c4c38e10eb3c874e3a8.png

 

And I have a docker pool setup as:

 

889359873_ScreenShot2018-06-12at5_11_04PM.thumb.png.719f4e76755f9aa0a69c6202b5008fb6.png

 

Hope this helps anyone with VLAN problems.

 

I will report my results back after a few days.

Share this post


Link to post

You probably want to set the VLAN IPv4 address to none too.

Why?

* if you don't want unRAID to be accessible directly on that VLAN

* dockers won't be able to access unRAID on that IP, while unRAID will try to talk/respond to the dockers using the directly attached IP

 

Share this post


Link to post
Posted (edited)

Okay, I think I will try that.

 

I decided to update to 6.5.3 and 2 hours later I got another call trace.

 

That could be the reason for the macvlan broadcast call traces.

Edited by Limy

Share this post


Link to post
1 hour ago, ken-ji said:

You probably want to set the VLAN IPv4 address to none too.

Why?

* if you don't want unRAID to be accessible directly on that VLAN

* dockers won't be able to access unRAID on that IP, while unRAID will try to talk/respond to the dockers using the directly attached IP

 

Hi ken-ji,

 

Can you be a bit more specific.  When I set IPv4 address assignment: to None on my example VLAN 34, I cannot then start the dockers and br4.34 is no longer available.

 

Thanks.

Share this post


Link to post

My network settings for eth1

image.thumb.png.bc8bfff0cb2f9ed231af637142de1cc7.png

My Docker Settings

image.thumb.png.e6ac311c8654476076c35e8df5bb0fe6.png

 

Hope this helps.

  • Upvote 1

Share this post


Link to post

Hi ken-ji,

 

Posting that helped a lot and I was able to figure out my issue.  Apparently I needed to assign a pool to br4 as well in order for br4.34 to be available.  So my docker settings now look as follows:

 

2056989612_ScreenShot2018-06-13at8_47_45AM.thumb.png.d9ebdda34c17df3a6e341daf9427857b.png

 

Just out of curiosity, are you actually using 192.168.2.XXX for anything in your system.  Or did you just set this up for isolation.

 

Thanks for you help.  I will see if this rids me of the call traces.

Share this post


Link to post

Odd. You shouldn't need to since from the docker networking point of view br4 should be independent of br4.34

I'll look into stopping my array to help check that out or maybe @bonienl can confirm.

 

192.168.2.xxx is my main network.

I've assigned it to br1 so as to allow any dockers running on br1 to be able to access unraid (nginx reverse proxy, etc) and vice versa, otherwise the macvlan security limitation kicks in.

 

you can just nuke the docker network on br0 and place it in br1. which might be why I never see call traces :D

Share this post


Link to post

Main interface (eth4) and VLAN interface (br4.34) work completely independent from each other. And each may have different settings.

 

As @ken-ji suggests the easiest approch is to uncheck br0 under docker settings and assign the same network settings to either a VLAN interface or another physical interface.

If you don't specify a DHCP pool then docker will do DHCP assignment which may interfere with your router DHCP server.

 

Share this post


Link to post

Thanks @ken-ji and @bonienl.

 

Well, after reading what you wrote, I’m wondering if there is some sort of bug / glitch that caused br4.34 to be available only after I setup a pool on br4.

 

At any rate on my system br0 192.168.19.xxx is my main unsaid network.  I have some dockers running on that which are operating in bridge mode.

 

So @bonienl are you inferring that in the Docker Settings a pool should always be assigned otherwise Docker is running a DHCP server and is competing with my routers DHCP server?

 

By the way, ever since I setup br4 as shown in my earlier post, my system has totally settled down. I’m not actually using 192.168.2.xxx in my system / router at all.

 

I’m going to leave my system going for a couple more days to see if the call traces are resolved.  If so, I can do some more experimenting.

Share this post


Link to post
6 hours ago, Limy said:

in the Docker Settings a pool should always be assigned otherwise Docker is running a DHCP server and is competing with my routers DHCP server

 

Docker itself is unaware of the IP addresses handed out by your regular DHCP server. If no explicit DHCP pool is configured, docker will simply start with the first IP address in the range (usually .1) as assignment. This may or may not interfere depending on your current IP assignments.

 

It is safer to set up a docker DHCP pool, which is in a range not used by your router or other devices.

 

Share this post


Link to post
1 hour ago, bonienl said:

 

Docker itself is unaware of the IP addresses handed out by your regular DHCP server. If no explicit DHCP pool is configured, docker will simply start with the first IP address in the range (usually .1) as assignment. This may or may not interfere depending on your current IP assignments.

 

It is safer to set up a docker DHCP pool, which is in a range not used by your router or other devices.

 

Okay, thanks for clarifying.  BTW with my current setup no call traces so far with broadcast messages and macvlan.

 

I should note that one other change I adopted from @ken-ji‘s setup, is that I also setup the Network Protocol to IPv4 + IPv6 for both the interface and the VLAN which I cannot really see that resolving any issue.  I just thought I should mention it.

Share this post


Link to post

Yeah. that shouldn't have any impact either way.

I left mine enabled, because I'm studying IPv6 deployments, but since my ISP doesn't have IPv6 yet, I need to be sure I understand what I'm doing as it will a break the entire internet from my network's point of view.

Share this post


Link to post
Posted (edited)

So I have been running my system since Wednesday of last week and I no longer have any call traces on macvlan.

 

I may try the next suggestion and place 192.168.19.xxx with a DHCP pool on br4.

 

Right now, I’m very happy that I can eliminate the call traces.

 

*** Just an update on this.  No more call traces in my system as of July 4th.  I would say my problems have been resolved. *** :)

Edited by Limy
Update

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now