8000 Discrepancy between network behavior in gVisor and runc · Issue #10908 · google/gvisor · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Discrepancy between network behavior in gVisor and runc #10908

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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll 8000 occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
TheQuantumFractal opened this issue Sep 13, 2024 · 5 comments · Fixed by #10912
Closed

Discrepancy between network behavior in gVisor and runc #10908

TheQuantumFractal opened this issue Sep 13, 2024 · 5 comments · Fixed by #10912
Assignees
@kevinGC
Labels
area: networking Issue related to networking type: bug Something isn't working

Comments

@TheQuantumFractal
Copy link

Description

Packets that have incorrect MAC destination addresses in their ethernet headers are dropped in runc and gVisor in host network mode. However, in the standard user space networking mode, gVisor does not drop packets with incorrect MAC addresses.

cc: @pawalt, @luiscape

Steps to reproduce

I think you should be able to use scapy python library to create packets to replicate this behavior. You should be able to run this on the host:

from scapy.all import Ether, IP, ICMP, sendp
import time

# Define arbitrary source and destination MAC addresses (that do not correspond to real interfaces)
src_mac = "00:11:22:33:44:55"
dst_mac = "66:77:88:99:AA:BB"

# Define IP addresses for the packet
src_ip = "192.168.1.10"  # Arbitrary source IP address
dst_ip = "192.168.1.1"   # Replace with destination IP address of container

# Create the Ethernet frame with the custom MAC addresses
ether = Ether(src=src_mac, dst=dst_mac)

# Create the IP layer with the source and destination IP addresses
ip = IP(src=src_ip, dst=dst_ip)

# Create the ICMP Echo Request
icmp = ICMP()

# Combine the layers to form the complete packet
packet = ether / ip / icmp

# Send the packet on the network
for _ in range(100):
    sendp(packet, iface="eth0")  # Replace "eth0" with your gVisor container veth
    time.sleep(0.1)

You should be able to run tcpdump -veni eth0 with the container veth on the host to see that response packets are being sent when the request packets should have been dropped in the container. With runc or host networking, no response packets will be received (ICMP request packets are dropped).

runsc version

runsc version 40a09da5a1ab
spec: 1.1.0-rc.1

docker version (if using docker)

No response

uname

Linux ip-10-1-1-1.ec2.internal 5.15.0-209.161.7.2.el9uek.x86_64 #2 SMP Tue Aug 20 10:44:41 PDT 2024 x86_64 x86_64 x86_64 GNU/Linux

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response
@TheQuantumFractal TheQuantumFractal added the type: bug Something isn't working label Sep 13, 2024
@kevinGC
Copy link
Collaborator
kevinGC commented Sep 13, 2024

We're not verifying incoming MAC addresses, but it should be a quick fix to add that. I assume this never came up because IP routing, in most systems, delivers only the packets destined for the container. If I can ask, is there a reason your containers are receiving errant packets?

@kevinGC kevinGC added the area: networking Issue related to networking label Sep 13, 2024
@kevinGC kevinGC self-assigned this Sep 13, 2024
@TheQuantumFractal
Copy link
Author

Our network stack can change network packets on the host before they reach the container which can cause the container to receive packets with incorrect MAC addresses

@pawalt
Copy link
Contributor
pawalt commented Sep 13, 2024

Specifically, we have some custom overlay networking that allows containers to communicate like they're on a private IPV6 subnets between hosts. These containers don't know the MACs of each other, so we realized when working between runc and GVisor that the packets were forwarding fine on GVisor but not runc.

copybara-service bot pushed a commit that referenced this issue Sep 13, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
1d858ac 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
@copybara-service copybara-service bot mentioned this issue Sep 13, 2024
Merged
copybara-service bot pushed a commit that referenced this issue Sep 13, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
baed61d 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 14, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
147883d 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 14, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
0e88163 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 14, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
f79fab5 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 15, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
aff8725 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 15, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
c2198d8 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 16, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
b1de17a 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 16, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
32f5da7 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 16, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
7079adf 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 16, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
e9595db 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 16, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
6f581de 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
copybara-service bot pushed a commit that referenced this issue Sep 16, 2024
@kevinGC @gvisor-bot
netstack: check inbound MAC addresses in the fdbased link endpoint
68eb5f6 
We weren't verifying that inbound MAC addresses match the NIC, which led to
netstack ingesting packets not meant for it.

Fixes #10908.

PiperOrigin-RevId: 674438500
@kevinGC
Copy link
Collaborator
kevinGC commented Sep 17, 2024

This should be fixed. I repro'd and tested with your scapy snippet to confirm, and (after learning a bit about what constitutes a broadcast MAC address) this fixes + passes tests. Please re-open if you're still seeing this.

@pawalt
Copy link
Contributor
pawalt commented Sep 17, 2024

Thanks @kevinGC!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kevinGC kevinGC

Labels
area: networking Issue related to networking type: bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

netstack: check inbound MAC addresses in the fdbased link endpoint google/gvisor
3 participants
@kevinGC @pawalt @TheQuantumFractal
0