LOL at this :
Mailing list subscription confirmation notice for mailing list
Gramps-users
We have received a request from 172.29.29.5 for subscription of your
email address,
pretty sure thats an RFC1918 address
lol yep it is. Perhaps the request was via proxy and the ip was passed in an X-Via header
possibly a load balancer or NAT type setup in front of the webserver that received the request
yeah it is
172.16 through 172.31
well 172.16.0.0 to 172.31.255.255
http://blog.streamingmedia.com/2014/11/cogent-now-admits-slowed-netflixs-traffic-creating-fast-lane-slow-lane.html
not likely to be balanced, but interesting none the less
Anybody else with a HE.net tunnel having problems with Google ipv6 traffic? At work and at home both (two different connections, same ipv6 POP) I've had lots of connection timeouts, but ping/mtr don't show any disruptions.
I've just now taken to forcing all google traffic over ipv4 and that's running smoothly, but it's certainly not much of a long-term solution
that happens to me over my ARP tunnel
are your machines MTU set to the tunnel mtu?
to be frank, I have no idea off hand. It may be a red herring, but everything has worked fine for years, I've made no changes at home or work, etc
a while ago (last month?) the issue began for me
Google had worked just fine over my tunnel with MTU 1500 until then
i see
did some debugging, determined that the ICMP PTB message was being sent properly, but the frames from Google were still too big
(I could still have a configuration error, idk what it is though)
If nothing else, it looks like I do have some fun mtu issues elsewhere... should be interesting
thanks for the tip, acf_
HE says the tunnel mtu is 1480, yet the largest packet I can get through is 1432 (1432+40 = 1472 < 1480) Where are those 8 bytes going? hm
could be an extension header (and exactly one) i suppose
acf: tunnel mtus don't usually work with 1500?
tunnel mtu is typically 1480
usually there's 60 bytes overhead on ipv6 i thought
well it's typically 1280 actually
mercutio: 40 bytes
ping is 8 bytes normally bryce
ping -s is X bytes :P
well udp is' i think ping has similar overhead
you sure
i think i can only do 1472 on ipv4
 # ping -s1472 www.google.com
PING www.google.com (74.125.237.212) 1472(1500) bytes of data.
1480 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=1 ttl=53 time=68.7 ms
my gogole ping isn't actually working
i have no idea why
 # ping -s1472 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 1472(1500) bytes of data.
1480 bytes from 4.2.2.2: icmp_seq=1 ttl=54 time=137 ms
1480 bytes from 4.2.2.2: icmp_seq=2 ttl=54 time=139 ms
# ping -s1442 www.google.com
PING www.google.com (74.125.237.211) 1442(1470) bytes of data.
1450 bytes from syd01s19-in-f19.1e100.net (74.125.237.211): icmp_seq=1 ttl=56 time=24.6 ms
that took a while to find, with google i can only do up to 1442
1480 bytes from 74.125.237.211: icmp_req=1 ttl=57 time=138 ms
:P
(ARP to the IP you were hitting)
that's weird
i'm doing it to sydney
from auckland
I can't do it from my home connection though.
yeah i think google just has weird network
so i'd blame google over he.net
I'm blaming everybody :p
i've seen them capping mss on tcp before
Anyways, the specific issue I'm troubleshooting is a specific request to a specific IP (replaying an http GET). On my home gif0 I see the headers and then the connection goes silent, but that same request on ARP shows some very large responses (gzipped response, packets with length over 2000) that are apparently being silently dropped before making it back to my gif0. So... that suggests the issue is
remote from me, either Google network or HE. Anybody disagree with that theory?
(This is what it looks like for those curious http://sprunge.us/OGSG)
> packets with length over 2000
isn't MTU still 1500?
yep
how do you have a 2000 byte packet going over a 1500 byte MTU Ethernet?
To be frank, I haven't quite figured that out yet. Best guess is the host is reconstructing transparently
ah
super strange that Google would be sending packets > 1500 bytes
given 1500 is the standard maximum Ethernet MTU
Nah, just normal strange... Spec lets packet length go to 65535
Which means the packet would be broken up across frames
> I see the headers and then the connection goes silent
do you have access to the box at the other end of the tunnel?
No, that tunnel is HE
if you have MTUs in your part of the path that are greater than the tunnel MTU
well, really just the box doing the TCP I think
path MTU discovery will be done
Google will try sending a 1500 byte packet, and the HE box will send back a ICMP packet too big
the annoying part is that Google doesn't seem to honor those
I guess when you set the MTU on a Linux machine, it also affects the TCP MSS?
nah mtu doesn't chaneg tcp mss
unless you have a iptables rule to change to interface mtu