Akamai Edgekey issues ?
Hi There, is anybody having any problems with sites that go through Akamai's CDN ? I'm having problems to connect to many served by them, just two examples. www.ti.com www.newark.com Cheers Jorge
Re: IP Fragmentation - Not reliable over the Internet?
On 31/08/2013 13:13, Randy Bush wrote: could you please test with ipv6? This is what I see for various IPv6 payloads (large ICMPv6 echo requests) from all RIPE Atlas probes that where available at the time to a single known good MTU 1500 destination: plenfail% nr_probes 100 9.641266 500 9.341039 10009.941298 12409.941308 124111.62 1300 144012.70 890 144114.70 1306 146015.18 1304 146119.84 1290 146222.02 1294 plen: IPv6 payload length (ie. not including 40byte IPv6 header) fail%: percentage of probes that didn't get any of the 5 pkts that were sent. Note that there is a large baseline failure rate in IPv6 on RIPE Atlas probes [1], which would explain the ~10% failure rate for the smaller packets. I plan to do more analysis and start writing this up on RIPE Labs over the next few days. cheers, Emile Aben RIPE NCC [1] https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong
Re: couldn't get address for 'w.au': no more ,
It would appear there's something very unhealthy with your specific nameservers regarding .au. A direct email I sent you bounced (well, delayed warning) due to : The error that the other server returned was: 451 4.1.8 Domain of sender address sc...@doc.net.au does not resolve That address fairly clearly does resolve, and I've had no problems sending email to anywhere else on the internet, so it's obviously a local issue. Scott On Sat, Aug 31, 2013 at 1:05 PM, Mr. James W. Laferriere bab...@baby-dragons.com wrote: Hello All , Are the roots for .au lost in the haze someplace ? During my attempts to reach http://www.coker.com.au/**bonnie++/http://www.coker.com.au/bonnie++/ I tried a 'dig www.coker.com.au +trace' Did some roots change recently ? Tia, JimL Which yielded ... ; DiG 9.9.3-P2 www.coker.com.au +trace ;; global options: +cmd . 7424IN NS i.root-servers.net. . 7424IN NS m.root-servers.net. . 7424IN NS k.root-servers.net. . 7424IN NS a.root-servers.net. . 7424IN NS h.root-servers.net. . 7424IN NS d.root-servers.net. . 7424IN NS c.root-servers.net. . 7424IN NS l.root-servers.net. . 7424IN NS e.root-servers.net. . 7424IN NS g.root-servers.net. . 7424IN NS j.root-servers.net. . 7424IN NS b.root-servers.net. . 7424IN NS f.root-servers.net. . 517152 IN RRSIG NS 8 0 518400 2013090700 2013083023 49656 . lWj707jP5hxvgq8BwU5+IVeyuE/**p3wcEmuQRfzuneoFClny1L/xyaT53 IkhG57jFzRPsXbuvOM6J/**9tZzkbyuN20b5T0QLuxJVQsZT20pzW**SIZ54 MVcVd2HTRtq+* *Gr0OetDI3THRkgK06IVH0yyKrPqDCQ**I/iHbc+iljg21f lmc= ;; Received 857 bytes from 50.0.96.199#53(50.0.96.199) in 195 ms au. 172800 IN NS z.au. au. 172800 IN NS y.au. au. 172800 IN NS x.au. au. 172800 IN NS w.au. au. 172800 IN NS v.au. au. 172800 IN NS u.au. au. 172800 IN NS s.au. au. 172800 IN NS r.au. au. 172800 IN NS b.au. au. 172800 IN NS a.au. au. 86400 IN NSECaw. NS RRSIG NSEC au. 86400 IN RRSIG NSEC 8 1 86400 2013090700 2013083023 49656 . LZo++** i1OBOYRDncdZe8aAuO1TaWgCWVXVc/**aquFb0oT0LBNAbkPljT55 dQV8jlrsZyZ0QbAm09P29wuq1UBuca**6a1YX72DZrvfDeqX+1oXaAlEPd ZfFl2eQsao39AZPlRVfVVw18am5VX8**V4K/VmYgBeq1lmV52OVqYz2UVB ygQ= dig: couldn't get address for 'z.au': no more -- +-**--**---+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 3237 Holden Road | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +-**--**---+
Re: IP Fragmentation - Not reliable over the Internet?
On Aug 27, 2013, at 12:34 AM, Owen DeLong o...@delong.com wrote: If I send a packet out as a legitimate series of fragments, what is the chance that they will get dropped somewhere in the middle of the path between the emitting host and the receiving host? To my thinking, the answer to that question is basically pretty close to 0 and if that changes in the core, very bad things will happen. I mostly agree. I will argue that the actual path of an IP datagram is end to end, so the question is not the core, but the end to end path. That said, with today's congestion control algorithms, TCP does pretty badly with an other-than-negligible loss rate, so end to end, fragmented messages have a negligible probability of being dropped, so the probability of sending a message that is fragmented and having it arrive at the intended destination is a negligibly small probability smaller than then probability of sending an unfragmented message and having it arrive. The primary argument against that is firewall behavior, in which firewalls are programmed to drop fragments with high probability. If we had a protocol that sat atop IP and did what fragmentation does that we could expect all non-TCP/SCTP protocols to use, I would have a very different viewpoint. But, playing the ball where it lies, the primary change I would recommend would be to support any firewall rule that permitted dropping the first fragment of a fragmented datagram in which the first fragment did NOT include the entire IP header and the entire subsequent header, and expecting a host to keep a fragment of a datagram no more than some stated number of seconds (I might pick two) with express permission to drop it more rapidly should the need arise. I would *not* support a rule that simple dropped fragments, or a protocol change that disallowed them. signature.asc Description: Message signed with OpenPGP using GPGMail
Any from O1 alive today?
Dear O1, Your managed modem service appears to not be authenticating users at this time. We have some grumpy dial-up users this morning. Our RADIUS is functioning normally (other services are able to authenticate against it successfully). Your support line (1-888-444-) rings fast-busy about 80% of the time I call it this morning (the other 20%, it works fine) Your on-call staff that I paged has yet to respond. Thanks, -Bobby
nanog bug contact
so i wrote to the old act...@nanog.org and nanog-act...@nanog.org and both bounced. i wrote to a friend at amsl and they said nanog lists are handled by nanog. so here is the public whine. the archive at http://mailman.nanog.org/pipermail/nanog/ seems not to have rolled on 2013.09.01 (gmt, edt, or whatever). and i can not find recent (sept) messages in the archive so i can point to them as a url. randy
Is this working ?
Is the list just silent of something is not working ?? Not very common to see almost two days without messages. -J
Re: Akamai Edgekey issues ?
Well it seems that the NANOG list is back alive !!! I sent that message two days ago (also reported via other channels that the list was not working) It is not a persistent problem but intermittent and it seems to affect only TWC customers that chose to use other public NS like Google's 8.8.8.8 and trying to reach sites served by Akamai's CDN. One popular one www.apple.comamong others. Now if you switch back to TWC suggested and controlled NSs 209.18.47.61 and 209.18.47.62, everything seems to work It is also a well known (imho) *bad* practice of TWC of tampering with DNS query replies, in theory you should be able to opt-out of it going to some obscure web page (http://www.dnsrsearch.com/prefs.php) which does not seem to always work. I spent almost two hours on the phone with TWC, unfortunately their basic levels of support have no clue at all, I went up to Level 3 but found out that I just escalated horizontally from India to Phillipines to Texas but at the same clue level and not able to reach any engineering minds with a clue. The Level 3 rep didn't know what Akamai is, and at all levels they got lost when I refused to go through the test your modem routine, and was based her assumption that something was not probably working because she was getting too many calls about the same issue. Quite effective monitoring system TWC !! I can't really identify if the problem is that TWC is tampering with akadns query replies and then breaking the CDN or just plain bad routing/peering or the NSA is running out of cycles/memory on the tap I've in my line :-) Cheers Jorge On Sat, Aug 31, 2013 at 7:26 PM, Jorge Amodio jmamo...@gmail.com wrote: Hi There, is anybody having any problems with sites that go through Akamai's CDN ? I'm having problems to connect to many served by them, just two examples. www.ti.com www.newark.com Cheers Jorge
Re: nanog bug contact
so i wrote to the old act...@nanog.org and nanog-act...@nanog.org and both bounced. i wrote to a friend at amsl and they said nanog lists are handled by nanog. so here is the public whine. the archive at http://mailman.nanog.org/pipermail/nanog/ seems not to have rolled on 2013.09.01 (gmt, edt, or whatever). and i can not find recent (sept) messages in the archive so i can point to them as a url. randy oh, and enjoy hitting the link You can get more information about this list. at the top pf the archive page randy
Re: Is this working ?
ack, -ls Jorge Amodio jmamo...@gmail.com wrote at Mon, Sep 02, 2013 at 03:10:06PM -0500: Is the list just silent of something is not working ?? Not very common to see almost two days without messages. -J --- End of jmamo...@gmail.com's quote ---
Re: Akamai Edgekey issues ?
Here is another bit of data... www.apple.com not reachable from a machine using Google's NS, reachable from an iPad using TWC NS IP addresses returned by each are different ... could be load balancing, or creative (broken) traffic engineering But for moments packets get lost at ae0.pr1.dfw10.tbone.rr.com this also could be TWC routing/peering issues but I don't know how many more levels of CS I have to go to reach somebody with a clue, after testing my modem zillion times ... pete@tango:~$ dig www.apple.com ; DiG 9.8.1-P1 www.apple.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46202 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.apple.com. IN A ;; ANSWER SECTION: www.apple.com. 723 IN CNAME www.isg-apple.com.akadns.net . www.isg-apple.com.akadns.net. 49 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 408 IN CNAME e3191.dscc.akamaiedge.net. e3191.dscc.akamaiedge.net. 9IN A 184.86.141.15 ;; Query time: 42 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Sep 2 21:06:57 2013 ;; MSG SIZE rcvd: 161 pete@tango:~$ dig @209.18.47.61 www.apple.com ; DiG 9.8.1-P1 @209.18.47.61 www.apple.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20041 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.apple.com. IN A ;; ANSWER SECTION: www.apple.com. 1135IN CNAME www.isg-apple.com.akadns.net . www.isg-apple.com.akadns.net. 50 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 442 IN CNAME e3191.dscc.akamaiedge.net. e3191.dscc.akamaiedge.net. 5IN A 23.42.157.15 ;; Query time: 39 msec ;; SERVER: 209.18.47.61#53(209.18.47.61) ;; WHEN: Mon Sep 2 21:07:09 2013 ;; MSG SIZE rcvd: 161 On Sat, Aug 31, 2013 at 7:26 PM, Jorge Amodio jmamo...@gmail.com wrote: Hi There, is anybody having any problems with sites that go through Akamai's CDN ? I'm having problems to connect to many served by them, just two examples. www.ti.com www.newark.com Cheers Jorge
Re: IP Fragmentation - Not reliable over the Internet?
On Sep 1, 2013, at 23:11 , Fred Baker (fred) f...@cisco.com wrote: On Aug 27, 2013, at 12:34 AM, Owen DeLong o...@delong.com wrote: If I send a packet out as a legitimate series of fragments, what is the chance that they will get dropped somewhere in the middle of the path between the emitting host and the receiving host? To my thinking, the answer to that question is basically pretty close to 0 and if that changes in the core, very bad things will happen. I mostly agree. I will argue that the actual path of an IP datagram is end to end, so the question is not the core, but the end to end path. That said, with today's congestion control algorithms, TCP does pretty badly with an other-than-negligible loss rate, so end to end, fragmented messages have a negligible probability of being dropped, so the probability of sending a message that is fragmented and having it arrive at the intended destination is a negligibly small probability smaller than then probability of sending an unfragmented message and having it arrive. Yes, the path is end-to-end and things happening near the end-points can be bad for a particular conversation. My point is that if somewhere in the core starts doing bad things to fragments on a regular basis, it will be very bad for massive numbers of users and not just the localized damage one would expect from something closer to the edge. Otherwise, we are saying the same thing. The primary argument against that is firewall behavior, in which firewalls are programmed to drop fragments with high probability. Which fortunately tend to be located at the edge and not in the core. If we had a protocol that sat atop IP and did what fragmentation does that we could expect all non-TCP/SCTP protocols to use, I would have a very different viewpoint. But, playing the ball where it lies, the primary change I would recommend would be to support any firewall rule that permitted dropping the first fragment of a fragmented datagram in which the first fragment did NOT include the entire IP header and the entire subsequent header, and expecting a host to keep a fragment of a datagram no more than some stated number of seconds (I might pick two) with express permission to drop it more rapidly should the need arise. I would *not* support a rule that simple dropped fragments, or a protocol change that disallowed them. I think I mostly agree, but I'd need to think it through a bit more than I can at the moment. Owen
Re: nanog bug contact
On 9/2/2013 7:27 PM, Randy Bush wrote: so i wrote to the old act...@nanog.org and nanog-act...@nanog.org and both bounced. i wrote to a friend at amsl and they said nanog lists are handled by nanog. so here is the public whine. the archive at http://mailman.nanog.org/pipermail/nanog/ seems not to have rolled on 2013.09.01 (gmt, edt, or whatever). and i can not find recent (sept) messages in the archive so i can point to them as a url. randy oh, and enjoy hitting the link You can get more information about this list. at the top pf the archive page It may be that they've broken all sorts of things. I received an email earlier, entitled as follows: mailman.nanog.org mailing list memberships reminder Ugh. I would never, ever, keep a setting on mailman that sent out those annoying reminder things, where (among other things) it tells you your password (such as it is). Then I noticed that something must have been resent, since the password showing was not one I would have chosen. Oh, but wait, there's more. Upon using the link provided: http://mailman.nanog.org/mailman/options/members/shrdlu%40deaddrop.org I encounter the following error: Bug in Mailman version 2.1.15 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Oh, be still my beating heart. I received this for the members mailing list, but I suspect that if they broke one thing, they broke multiples. BTW, I checked on the regular link for all nanog lists: http://mailman.nanog.org/mailman/options/nanog Same error. Please fix this. Consider not making updates without tests. Thanks ever so. -- http://www.groklaw.net/article.php?story=20130818120421175 (Time to read True Names again, I suppose.) True Names...and Other Dangers by Vernor Vinge ISBN-10: 0312862075 or ISBN-13: 978-0312862077
Re: Any from O1 alive today?
On Mon, Sep 2, 2013 at 7:57 AM, Robert Glover robe...@garlic.com wrote: Dear O1, Your managed modem service appears to not be authenticating users at this time. We have some grumpy dial-up users this morning. Our RADIUS is functioning normally (other services are able to authenticate against it successfully). Your support line (1-888-444-) rings fast-busy about 80% of the time I call it this morning (the other 20%, it works fine) Your on-call staff that I paged has yet to respond. Thanks, -Bobby Dear Bobby, Thank you for contacting the Infernal Referral Service for the Internet. All of our demon...er, agents are busy at the moment telling other users where to go, but if you'd like to stay on the line, your question will be answered in the order it was received. Currently, there is a 314 year, 1 month, 5 day, 9 hour and 26 minute hold time. If you would like to continue waiting, please press 'π' on your rotary phone now. Thank you for your continue patronage of the Internet. The LOLcats know you have a choice, and appreciate your Have a nice day, and thank you for flying Internet Express! Matt PS--perhaps you were thinking of someone else as the recipient of your mail?
