Skip to content

[WIP, RFC] networking: add veth pairs via nix config#13181

Closed
kampfschlaefer wants to merge 5 commits intoNixOS:release-15.09from
kampfschlaefer:create_veth_pairs
Closed

[WIP, RFC] networking: add veth pairs via nix config#13181
kampfschlaefer wants to merge 5 commits intoNixOS:release-15.09from
kampfschlaefer:create_veth_pairs

Conversation

@kampfschlaefer
Copy link
Copy Markdown
Contributor

This allows to define veth pairs and use them in other network components or
with containers and network namespaces.

One issue I didn't yet manage to solve: When releasing veths from network
namespaces, the devices are gone. But the systemd-unit doesn't recognize this.
It only detects the -netdev job as failed when the stop fails (which fails as
the device is already gone).

Because of this it is not possible to use these veth pairs with containers
without manual intervention. Or maybe it works with a clever definition of
unit-dependencies?

Also the networkd-way of doing this is missing completely…

This allows to define veth pairs and use them in other network components or
with containers and network namespaces.

One issue I didn't yet manage to solve: When releasing veths from network
namespaces, the devices are gone. But the systemd-unit doesn't recognize this.
It only detects the -netdev job as failed when the stop fails (which fails as
the device is already gone).

Because of this it is not possible to use these veth pairs with containers
without manual intervention. Or maybe it works with a clever definition of
unit-dependencies?
@mention-bot
Copy link
Copy Markdown

By analyzing the blame information on this pull request, we identified @wmertens, @wkennington and @edolstra to be potential reviewers

@edolstra
Copy link
Copy Markdown
Member

Did you have a use case in mind here? I mean, as you point out, this can't be used with typical container tools, because one half of the veth pair will be destroyed when the target namespace is destroyed. Also, such tools probably expect to create/configure the veth pairs themselves anyway.

@kampfschlaefer
Copy link
Copy Markdown
Contributor Author

Did you have a use case in mind here? I mean, as you point out, this can't be used with typical container tools, because one half of the veth pair will be destroyed when the target namespace is destroyed. Also, such tools probably expect to create/configure the veth pairs themselves anyway.

The use-case in my mind is containers with more then one virtual interface and all these interfaces placed into bridges on the outside of the container. For example a bridge lan and a bridge dbnet and the containers have their first veth pair in the lan bridge and the second in the dbnet bridge. And the lan-bridge might also have the physical interface of the host.

I am currently evaluating several ways to accomplish that. I see that systemd-nspawn also supports using more the one veth-pair but for all but the first you would need additional code to handle these special things like bridging.
And somehow it feels cleaner for me to define these connections as network interfaces similar to the other network stuff then to define these things as options for nixos-containers.

@kampfschlaefer
Copy link
Copy Markdown
Contributor Author

The idea is obsolete by #15496.

@nbp nbp mentioned this pull request Feb 26, 2017
4 tasks
@kampfschlaefer kampfschlaefer deleted the create_veth_pairs branch August 29, 2017 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants