-
Notifications
You must be signed in to change notification settings - Fork 258
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
Docker container loses its network adapters sporadically #2363
Labels
Comments
Hi. I wanted to give you an update concerning the loss of network adapters in containers. As it turns out, the problem isn't limited to strongswan specific containers. It also happened with a barebone alpine container today. Hence I changed the title of the issue. Alpine container data: Network adapter config file
The VM uptime was 2 days and 6 hours. Here is the docker inspect result from the VM: docker inspect
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The setup
I am currently happily using GNS3 for topologies containing mainly lightweight containers.
One of these images uses the IPSec solution from Strongswan.
In my current topology, I have 4 to 8 IPSec routers based on said image.
Problem
Sometimes the containers running the IPSec image are losing all of their configured network adapters/interfaces (eth0, eth1) except their loopback interface (lo). This lead to the network node being completely unreachable from the outside. Only manually reloading the node resolves the problem.
GNS3 version and operating system:
To Reproduce
Since the error occurs rather infrequent (on average once a week), I don't really know, where it stems from or what causes it.
I can give you a rough rundown of my setup though.
Dockerfile:
entrypoint.sh:
swanctl-template.conf
Screenshots or videos
![image](https://private-user-images.githubusercontent.com/122979336/316436417-df2569f1-325b-486e-9396-8a0016a9d9df.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjAyOTI4MzEsIm5iZiI6MTcyMDI5MjUzMSwicGF0aCI6Ii8xMjI5NzkzMzYvMzE2NDM2NDE3LWRmMjU2OWYxLTMyNWItNDg2ZS05Mzk2LThhMDAxNmE5ZDlkZi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNzA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDcwNlQxOTAyMTFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mODI4ZGNmNWUyYjA3YjU0MWQwYWUyYTM1ZTYzZTBhNjc5OTNmZTcyZjZiZjk0ZjAxYTNkZGQwMjcxNmViNzMwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.Oj2r81XlW273Ib07dFJPC6P_l1uUY9gjqeZ6Q5QjyTU)
Topology clip:
I will add a screenshot of the "ip addr" command once it happens again.
Additional context
I am using gns3-web-ui, but the problem is also visible, when connecting via ssh to the GNS3 VM and inspecting the corresponding container directly.
If I had to take a guess, I would say it has something to do with concurrent access to the network adapters or ubridge itself.
The text was updated successfully, but these errors were encountered: