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

Update limits on overlay networks #11412

Open
hoerup opened this issue Sep 23, 2020 · 15 comments
Open

Update limits on overlay networks #11412

hoerup opened this issue Sep 23, 2020 · 15 comments
Assignees
Labels
area/cli Relates to the CLI client lifecycle/frozen

Comments

@hoerup
Copy link

hoerup commented Sep 23, 2020

A while ago there were issues with loadbalancer 1) on large overlay networks, so a limit in overlay size was added to documentation in 2)
This issue has since been resolved, and according to 3) the limitations are no longer necessary.

The documentation should be updated accordingly

  1. Swarm Mode at Scale moby/moby#30820
  2. Add info about network size limits for swarm mode #5208
  3. Improve scalability of the Linux load balancing moby/moby#37372 (comment)
@clintmod
Copy link

clintmod commented Apr 6, 2021

@thaJeztah Is this true that a /24 is no longer required for an overlay network?

If so let me know and I can work on a PR for the docs.

The part of the docs in question:

You should create overlay networks with /24 blocks (the default), which limits you to 256 IP addresses, when you create networks using the default VIP-based endpoint-mode. This recommendation addresses limitations with swarm mode.

https://docs.docker.com/engine/reference/commandline/network_create/#overlay-network-limitations

@chey
Copy link

chey commented Sep 17, 2021

It would be good if the documentation included what version of docker this changed.

@craig-osterhout craig-osterhout added the area/cli Relates to the CLI client label Aug 3, 2022
@docker-robott
Copy link
Collaborator

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

@hoerup
Copy link
Author

hoerup commented Nov 29, 2022

Still relevant

@fannyfan414
Copy link

Any updates?

@fannyfan414
Copy link

/remove-lifecycle stale

@fannyfan414
Copy link

Any news?

@docker-robott
Copy link
Collaborator

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

@hoerup
Copy link
Author

hoerup commented May 25, 2023

/remove-lifecycle stale

@thaJeztah
Copy link
Member

@akerouanton @dvdksn Is any of this covered in the networking rewrite? (Sorry still haven't found time to look at the PR 🙈)

@dvdksn
Copy link
Collaborator

dvdksn commented May 25, 2023

We have not updated this bit yet, no. Sounds like we can just remove the Overlay network limitations🔗 section then?

@dvdksn dvdksn self-assigned this May 25, 2023
@akerouanton
Copy link
Member

@dvdksn I don't think so, because the overlay network is actually using a bridge interface internally to connect containers co-located on a same host. As such, the limitations I asked you to add to the bridge doc page also apply to the overlay driver.

@Rush
Copy link

Rush commented Feb 15, 2024

So if somebody creates a /16 overlay network, what problems could they be facing?

@dvdksn
Copy link
Collaborator

dvdksn commented Feb 15, 2024

I guess nothing, until you hit the limit of 1024 interfaces. That's hard-coded in the kernel. ref

But I will let @akerouanton correct me

@dounoit
Copy link

dounoit commented Mar 2, 2024

i only have 12 /24 overlay networks with encryption enabled - one manager and two worker nodes- when i first boot up the boxes- i'm able to spin up containers until i hit a limit and then any subsequent containers- even when i removed them- won't start up- all containers are stuck at a "ready" state or new:

ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
vkri0f9lwtzi docs_code.1 collabora/code:latest Running New 44 minutes ago

ID NAME MODE REPLICAS IMAGE PORTS
68uaoz7y3oiz docs_code replicated 0/1 collabora/code:latest

  • if i reboot the servers then im able to spin up the containers - ive tried to cleanup any lingering containers but am not able to free up any resources start these up again- im really leaning towards this being a network limitation issue although i don't think im pushin the envelope very much- i am running traefik in the front but even if these 5 webapps are all on the traefik network- there shouldn't be a probelm. its good to note- on some other hardware i was getting a network allocation OOM error. im deparate to fix this- do i need to change to /16 segments or try with the dnsrr? im pretty new to docker swarm at scale and really need some help- i have people that want to push to production very shortly and i can't even spin up all our containers or confidently restart them! Im grateful for any help friends :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cli Relates to the CLI client lifecycle/frozen
Projects
None yet
Development

No branches or pull requests