-
Notifications
You must be signed in to change notification settings - Fork 670
add test for PMTU discovery and packet fragmentation #1247
Conversation
c5b79ed
to
1aaeabf
Compare
I saw some failures on circle to start with. Quite reproducible there, though not 100% and not at all in my local setup. Dropping the message size from 65k to 10k appears to have solved this - it's done a dozen runs now, all but two of which succeeded, and both failures were due to #1243. I suspect on gce the test goes over a real network (@tomwilkie correct me if I am wrong), plus there's a whole load of cloud machinery at work. Both of which increase the probability of some packet loss. Since the test forces a very low PMTU, we end up with a lot of fragments when the original packet is large, and if any one of them get lost then the packet will get dropped and the test will fail. |
@rade yes we can't guarantee the VMs are on the same host, so the packets will have to traverse a real network. |
exec_on $HOST2 c2 $PING -s 10000 c1 2>&1 1>/dev/null || true | ||
assert_raises "exec_on $HOST2 c2 $PING -s 10000 c1" | ||
|
||
run_on $HOST2 "sudo iptables -D $drop_large_udp_packets" |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
@dpw mind taking a look at this? |
Seems reasonable. In some ways it might be nicer to figure out the true PMTU (e.g. with netcat and |
I was thinking of that, but a) grepping the logs is horrible, and b) the busybox ping does not have |
add test for PMTU discovery and packet fragmentation
All credit goes to @dpw for figuring out how to break the kernel's packet fragmentation:
Coverage increases as follows: