mnathani: 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 brycec: lol yep it is. Perhaps the request was via proxy and the ip was passed in an X-Via header mnathani: possibly a load balancer or NAT type setup in front of the webserver that received the request ***: medum has quit IRC (Ping timeout: 250 seconds)
medum has joined #arpnetworks mercutio: yeah it is
172.16 through 172.31
well 172.16.0.0 to 172.31.255.255 ***: carvite has quit IRC (Ping timeout: 244 seconds)
carvite has joined #arpnetworks
fink has joined #arpnetworks
LT has joined #arpnetworks
LT has quit IRC (Quit: Leaving)
qbit has quit IRC (Quit: leaving)
qbit has joined #arpnetworks
qbit is now known as Guest31676
Guest31676 is now known as qbit
jcv has quit IRC (Ping timeout: 240 seconds)
freedomcode has joined #arpnetworks
acf_ has quit IRC (Ping timeout: 244 seconds)
reardencode has quit IRC (Ping timeout: 244 seconds)
tooth has quit IRC (Ping timeout: 244 seconds)
tooth has joined #arpnetworks
acf_ has joined #arpnetworks mercutio: 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 ***: tehfink has joined #arpnetworks
fink has quit IRC (Ping timeout: 258 seconds)
tehfink is now known as fink
freedomcode has quit IRC (Remote host closed the connection)
fink has quit IRC (Quit: fink) brycec: 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 acf_: that happens to me over my ARP tunnel
are your machines MTU set to the tunnel mtu? brycec: 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 -: brycec is multitasking acf_: a while ago (last month?) the issue began for me
Google had worked just fine over my tunnel with MTU 1500 until then brycec: i see acf_: 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) brycec: 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 mercutio: acf: tunnel mtus don't usually work with 1500? brycec: tunnel mtu is typically 1480 mercutio: usually there's 60 bytes overhead on ipv6 i thought brycec: well it's typically 1280 actually
mercutio: 40 bytes mercutio: ping is 8 bytes normally bryce brycec: ping -s is X bytes :P mercutio: 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. brycec: 1480 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=1 ttl=53 time=68.7 ms mercutio: 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 brycec: 1480 bytes from 74.125.237.211: icmp_req=1 ttl=57 time=138 ms
:P
(ARP to the IP you were hitting) mercutio: that's weird
i'm doing it to sydney
from auckland brycec: I can't do it from my home connection though. mercutio: yeah i think google just has weird network
so i'd blame google over he.net brycec: I'm blaming everybody :p mercutio: i've seen them capping mss on tcp before brycec: 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) acf_: > packets with length over 2000
isn't MTU still 1500? brycec: yep acf_: how do you have a 2000 byte packet going over a 1500 byte MTU Ethernet? brycec: To be frank, I haven't quite figured that out yet. Best guess is the host is reconstructing transparently acf_: ah
super strange that Google would be sending packets > 1500 bytes
given 1500 is the standard maximum Ethernet MTU brycec: Nah, just normal strange... Spec lets packet length go to 65535
Which means the packet would be broken up across frames acf_: > I see the headers and then the connection goes silent
do you have access to the box at the other end of the tunnel? brycec: No, that tunnel is HE acf_: 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? -: brycec isn't sure
brycec gives up for now, disables google ipv6 traffic and sails along mercutio: nah mtu doesn't chaneg tcp mss
unless you have a iptables rule to change to interface mtu