| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| mnathani | 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 | [00:28] |
| ..... (idle for 20mn) | ||
| brycec | lol yep it is. Perhaps the request was via proxy and the ip was passed in an X-Via header | [00:48] |
| mnathani | possibly a load balancer or NAT type setup in front of the webserver that received the request | [01:00] |
| *** | medum has quit IRC (Ping timeout: 250 seconds) | [01:03] |
| medum has joined #arpnetworks | [01:10] | |
| ..... (idle for 21mn) | ||
| mercutio | yeah it is
172.16 through 172.31 well 172.16.0.0 to 172.31.255.255 | [01:31] |
| *** | carvite has quit IRC (Ping timeout: 244 seconds) | [01:44] |
| carvite has joined #arpnetworks | [01:49] | |
| ........................... (idle for 2h14mn) | ||
| fink has joined #arpnetworks | [04:03] | |
| ...................... (idle for 1h46mn) | ||
| LT has joined #arpnetworks | [05:49] | |
| ....................................... (idle for 3h10mn) | ||
| LT has quit IRC (Quit: Leaving) | [08:59] | |
| .................................... (idle for 2h56mn) | ||
| qbit has quit IRC (Quit: leaving)
qbit has joined #arpnetworks qbit is now known as Guest31676 Guest31676 is now known as qbit | [11:55] | |
| .......................................... (idle for 3h27mn) | ||
| jcv has quit IRC (Ping timeout: 240 seconds) | [15:23] | |
| ........................ (idle for 1h56mn) | ||
| 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 | [17:19] | |
| ..... (idle for 22mn) | ||
| 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 | [17:48] |
| ..... (idle for 23mn) | ||
| *** | tehfink has joined #arpnetworks
fink has quit IRC (Ping timeout: 258 seconds) tehfink is now known as fink | [18:13] |
| .................... (idle for 1h37mn) | ||
| freedomcode has quit IRC (Remote host closed the connection)
fink has quit IRC (Quit: fink) | [19:53] | |
| ............. (idle for 1h4mn) | ||
| 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 | [20:58] |
| acf_ | that happens to me over my ARP tunnel
are your machines MTU set to the tunnel mtu? | [20:59] |
| 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 | [21:00] |
| acf_ | a while ago (last month?) the issue began for me
Google had worked just fine over my tunnel with MTU 1500 until then | [21:00] |
| brycec | i see | [21:01] |
| 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) | [21:03] |
| 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 | [21:08] |
| ..... (idle for 22mn) | ||
| mercutio | acf: tunnel mtus don't usually work with 1500? | [21:33] |
| brycec | tunnel mtu is typically 1480 | [21:34] |
| mercutio | usually there's 60 bytes overhead on ipv6 i thought | [21:34] |
| brycec | well it's typically 1280 actually
mercutio: 40 bytes | [21:34] |
| mercutio | ping is 8 bytes normally bryce | [21:34] |
| brycec | ping -s is X bytes :P | [21:34] |
| 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. | [21:34] |
| brycec | 1480 bytes from iad23s05-in-f5.1e100.net (74.125.228.5): icmp_req=1 ttl=53 time=68.7 ms | [21:35] |
| 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 | [21:35] |
| brycec | 1480 bytes from 74.125.237.211: icmp_req=1 ttl=57 time=138 ms
:P (ARP to the IP you were hitting) | [21:38] |
| mercutio | that's weird
i'm doing it to sydney from auckland | [21:38] |
| brycec | I can't do it from my home connection though. | [21:39] |
| mercutio | yeah i think google just has weird network
so i'd blame google over he.net | [21:39] |
| brycec | I'm blaming everybody :p | [21:39] |
| mercutio | i've seen them capping mss on tcp before | [21:39] |
| 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) | [21:44] |
| acf_ | > packets with length over 2000
isn't MTU still 1500? | [21:49] |
| brycec | yep | [21:49] |
| acf_ | how do you have a 2000 byte packet going over a 1500 byte MTU Ethernet? | [21:50] |
| brycec | To be frank, I haven't quite figured that out yet. Best guess is the host is reconstructing transparently | [21:51] |
| acf_ | ah
super strange that Google would be sending packets > 1500 bytes given 1500 is the standard maximum Ethernet MTU | [21:51] |
| brycec | Nah, just normal strange... Spec lets packet length go to 65535
Which means the packet would be broken up across frames | [21:52] |
| 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? | [21:53] |
| brycec | No, that tunnel is HE | [21:54] |
| 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? | [21:54] |
| brycec | brycec isn't sure | [21:59] |
| brycec gives up for now, disables google ipv6 traffic and sails along | [22:09] | |
| mercutio | nah mtu doesn't chaneg tcp mss
unless you have a iptables rule to change to interface mtu | [22:21] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |