Pasta is a user-space networking stack that allows rootless containers to access the network. Slirp4netns is another user-space networking stack that does the same thing. They both work by creating a virtual network interface inside the container and then routing traffic from that interface to the host’s network.
Here’s a quick demo of how Pasta can be used.
First, let’s create a simple rootless Podman container.
podman run -d --name test-container docker.io/library/alpine sleep infinity
Now, let’s inspect the network configuration of the container.
podman inspect test-container | grep IPAddress
You’ll notice that the container doesn’t have an IP address assigned to it by default. This is because it’s running in rootless mode, and it doesn’t have access to the host’s network namespace.
Now, let’s enable networking for the container using Pasta.
podman network create pasta-network
podman network connect pasta-network test-container
After connecting the container to the pasta-network, let’s inspect the network configuration again.
podman inspect test-container | grep IPAddress
You should now see an IP address assigned to the container, something like 10.88.0.2. This IP address is assigned by Pasta.
Let’s exec into the container and try to ping an external host.
podman exec -it test-container sh
/ # ping google.com
PING google.com (142.250.184.142): 56 data bytes
64 bytes from 142.250.184.142: seq=0 ttl=115 time=10.234 ms
64 bytes from 142.250.184.142: seq=1 ttl=115 time=10.567 ms
...
This shows that the container can now access the network.
So, what’s the difference between Pasta and Slirp4netns?
Both Pasta and Slirp4netns achieve the same goal: providing network access to rootless containers. However, they do it in different ways, and each has its own set of advantages and disadvantages.
Pasta is a newer implementation and is designed to be more performant. It uses a more direct approach to routing traffic, which can lead to lower latency and higher throughput. Pasta also supports more advanced networking features, such as IPv6 and multicast.
Slirp4netns is an older and more established implementation. It’s known for its simplicity and ease of use. Slirp4netns works by emulating a network interface and using the slirp library to handle network traffic. While it’s generally reliable, it can be slower than Pasta, especially for high-bandwidth applications.
Here’s a breakdown of how they work at a high level:
Pasta:
When a container is connected to a Pasta network, Pasta creates a virtual Ethernet device (veth) pair. One end of the veth pair is attached to the container’s network namespace, and the other end is attached to a bridge on the host. Pasta then sets up NAT rules on the host to forward traffic between the container and the external network. The key difference is that Pasta doesn’t rely on a separate slirp process. Instead, it integrates more directly with the kernel’s networking stack, using features like netfilter for NAT.
Slirp4netns:
Slirp4netns operates by creating a TAP device inside the container’s network namespace. This TAP device is then connected to a TUN device on the host, which is managed by a user-space process (the slirp4netns daemon). This daemon intercepts all traffic from the container’s TAP device and forwards it to the host’s network using NAT. It essentially acts as a virtual router and NAT device within user space.
The performance difference often comes down to this: Pasta’s integration with netfilter is generally more efficient than Slirp4netns’s user-space packet manipulation.
One significant advantage of Pasta is its support for more advanced networking scenarios out of the box. For instance, if you need your rootless containers to have IPv6 connectivity, Pasta is generally the preferred choice as it handles IPv6 routing and NAT more robustly. Slirp4netns’s IPv6 support can be more experimental or require additional configuration.
When choosing between Pasta and Slirp4netns, consider your specific needs. For general-purpose networking and when performance is a concern, Pasta is often the better option. If you need a simpler setup or are working with older systems where Slirp4netns is well-tested, it might still be a viable choice. However, the Podman community is increasingly favoring Pasta for its efficiency and feature set.
The next step you’ll likely encounter is figuring out how to expose specific ports from your rootless containers to the host or external network, which involves configuring port forwarding rules.