You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ran into an issue IP conflict recently that took me 2 weeks to debug 😨 ... Only to find out that docker swarm creates overlay networks starting with the private class A subnet range 10.0.0.0/8 and goes up from there sequentially, per swarm.
Basically I was having issues with my pfSense OpenVPN connection that I set to subnet 10.0.0.0/24. Everything worked, except I was unable to load web pages served from docker swarm lol. Using docker network inspect ingress I found that swarm was setting the this network to 10.0.0.0/24 and any odditional overlay networks to 10.0.1.0/24, then 10.0.2.0/24, and so on...
Hopefully this helps someone out in the future, but figured I should just configure swarm to start the subnet ranges from something like 10.200.0.0/16 to reduce any conflicts in the future, as the 10.0.0.0/8 block is a popular choice for VLAN subnets.
The text was updated successfully, but these errors were encountered:
When I "refresh" my VMs next, this will be a good time to do this, due to the fact that you can only change the subnet ranges during a docker swarm init.
Ran into an issue IP conflict recently that took me 2 weeks to debug 😨 ... Only to find out that docker swarm creates overlay networks starting with the private class A subnet range
10.0.0.0/8
and goes up from there sequentially, per swarm.Basically I was having issues with my pfSense OpenVPN connection that I set to subnet
10.0.0.0/24
. Everything worked, except I was unable to load web pages served from docker swarm lol. Usingdocker network inspect ingress
I found that swarm was setting the this network to10.0.0.0/24
and any odditional overlay networks to10.0.1.0/24
, then10.0.2.0/24
, and so on...Hopefully this helps someone out in the future, but figured I should just configure swarm to start the subnet ranges from something like
10.200.0.0/16
to reduce any conflicts in the future, as the10.0.0.0/8
block is a popular choice for VLAN subnets.The text was updated successfully, but these errors were encountered: