July 2012 - Test - lists.nanog.org

RE: FYI Netflix is down
by Dan Golding 02 Jul '12

02 Jul '12

> -----Original Message----- > From: Greg D. Moore [mailto:mooregr@greenms.com] > > > If folks have not read it, I would suggest reading Normal Accidents by > Charles Perrow. > Also, Human Error by James Reason.

1 0

Re: FYI Netflix is down
by Greg D. Moore 02 Jul '12

02 Jul '12

At 03:08 PM 7/2/2012, George Herbert wrote: If folks have not read it, I would suggest reading Normal Accidents by Charles Perrow. The "it can't happen" is almost guaranteed to happen. ;-) And when it does, it'll often interact in ways we can't predict or sometimes even understand. As for pulling the plug to test stuff. I recall a demo at Netapps in the early 00's. They were talking about their fault tolerance and how great it was. So I walked up to their demo array and said, "So, it shouldn't be a problem if I pulled this drive right here?" Before I could the salesperson or tech guy, can't remember, told me to stop. He didn't want to risk it. That right there said loads about their confidence in their own system. >Late reply, but: > >On Sat, Jun 30, 2012 at 12:30 AM, Lynda <shrdlu(a)deaddrop.org> wrote: > >... > > Second, and more important. I *was* a "computer science guy" in a > past life, > > and this is nonsense. You can have astonishingly large software projects > > that just continue to run smoothly, day in, day out, and they don't hit the > > news, because they don't break. There are data centers that don't hit the > > news, in precisely the same way. > >I really need to write the book on IT reliability I keep meaning to. > >There's reliability - backwards looking statistical, which can be 100% >for a given service or datacenter - and then there's dependability, >forwards-predicted outage risks, which people often *assert* equals >the prior reliability record, but in reality you often have a number >of latent failures (and latent cascade paths) that you do not >understand, did not identify previously, and are not aware of. > >I've had or had to respond to over a billion dollars of culminative IT >disaster loss over my consulting career so far; I have NEVER seen >anyone who did it perfect, even the best pros. And I include myself >in that list. > >Looking at other fields like aerospace and nuclear engineering, what >is done in IT is not anywhere close to the same level of QA and >engineering analysis and testing. We cannot assert better results >with less work. > >"Oh, that never happens", except I've had my stuff in three locations >that had catastrophic generator failures. "Oh, that never happens" >when you're doing power maintenance and the best-rated electrical >company in California, in conjunction with the generator vendor and a >couple of independent power EEs, mis-balance the maintenance generator >loads between legs and blow the generators and datacenter. "Oh, that >never happens" that the datacenter burns (or starts to burn and then >gets flooded). "Oh, that never happens" that the FM-200 goes off or >preaction breaks and water leaks. "Oh, that never happens" that well >maintained and monitored and triple-redundant AC units all trip >offline due to a common mode failure over the course of a weekend and >the room gets up to 106 degrees. Oh thank god the next thing didn't >go wrong in THAT situation, because the spot temperature meters >indicated that the ceiling height of that particular room peaked at 1 >degree short of the temp at which the sprinkler heads are supposed to >discharge, so we nearly lost that room to flooding rather than just a >10% disk and 15% power supply attrition over the next year... > >Don't be so confident in the infrastructure. It's not engineered or >built or maintained well enough to actually support that assertion. >The same can be said of the application software and application >architecture and integration. > > >-- >-george william herbert >george.herbert(a)gmail.com Greg D. Moore http://greenmountainsoftware.wordpress.com/ CEO QuiCR: Quick, Crowdsourced Responses. http://www.quicr.net

1 0

How do the lowest layers of the DSL stack work?
by James Bensley 02 Jul '12

02 Jul '12

Hi list, I am hoping someone here can explain to me (or point to an article that does) what is happening at the lower layers of an ADSL connection. This is an excerpt from the wiki page on ADSL (ANSI T1.413 Issue 2); "Up to 254 sub-carriers are used downstream; each of these 254 sub-carriers can support the modulation of 0 to 15 bits per baud. The baud rate is 4,000 symbols per second on each subcarrier. Thus the maximum theoretical downstream data rate of an ADSL system is 15.24 Mbit/s (254×15×4000). However, because the data is split up into packets (actually Reed–Solomon encoded codewords) of 255 bytes, the maximum achievable downstream data rate is 8.128 Mbit/s (including other overheads)." That is quite a drop in speed and I'm trying to understand where this is happening. Assuming a typical PPPoA set up, the ATM frames are 48 bytes of data payload and 5 header bytes, to make a total frame size of 53 bytes. Somewhere between the physical transfer rate at the bottom of the stack and this ATM layer, we are consuming all that bandwidth with other non-user data. Where is it going? According to that extract, it all disappeared because of RS encoding, which is hugely vague. Are ATM frames those used as the 68 data frames in a superframe? I understand that Reed-Solomon is splitting data into 255 byte codewords because an 8-bit symbol sized has been imposed to give a 32 byte parity block; Is the superframe where RS encoding is applied? If so, I don't understand how that consumes as much overhead as this statement claims. Could someone enlighten me as to what I'm missing between the ATM layer and the wire rate. Kind regards, James.

2 1

Re: NANOG Digest, Vol 54, Issue 3 (Comcast's IPv6 Information Site Unreachable)
by Brzozowski, John 02 Jul '12

02 Jul '12

Folks, We will report back shortly with some updates. Thanks for the mail. John ========================================= John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net ========================================= On Jul 1, 2012, at 10:46 PM, <nanog-request(a)nanog.org> <nanog-request(a)nanog.org> wrote: > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Comcast's IPv6 Information Site Unreachable (Sadiq Saif) > 2. RE: Comcast's IPv6 Information Site Unreachable (Frank Bulk) > 3. Re: Comcast's IPv6 Information Site Unreachable (Derek Ivey) > 4. Re: [c-nsp] NTP Servers (Jimmy Hess) > 5. Re: Comcast's IPv6 Information Site Unreachable (Jimmy Hess) > 6. Re: FYI Netflix is down (steve pirk [egrep]) > 7. Re: Comcast's IPv6 Information Site Unreachable (Derek Ivey) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 1 Jul 2012 19:37:54 -0400 > From: Sadiq Saif <sadiq(a)asininetech.com> > To: Derek Ivey <derek(a)derekivey.com> > Cc: nanog(a)nanog.org > Subject: Re: Comcast's IPv6 Information Site Unreachable > Message-ID: > <CABSLv--jqtdX3eyORRRaWgXtV_UAjFY7jzGEcVRyDo_WmQ60KA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Website is reachable here via my HE tunnel. Pings are not going > through though as you showed. > > On Sun, Jul 1, 2012 at 7:28 PM, Derek Ivey <derek(a)derekivey.com> wrote: >> Anyone else having trouble getting to Comcast's IPv6 Information site? It >> appears to be unreachable over IPv6. >> >> [root@server ~]# ping6 comcast6.net >> PING comcast6.net(speedlab-app05.newcastlerdc.de.panjde.comcast.net) 56 data >> bytes >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=0 Destination >> unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=1 Destination >> unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=2 Destination >> unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=3 Destination >> unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=4 Destination >> unreachable: Administratively prohibited >> ^C >> --- comcast6.net ping statistics --- >> 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4008ms >> >> [root@server ~]# traceroute6 comcast6.net >> traceroute to comcast6.net (2001:558:fe16:7:69:252:216:215), 30 hops max, 40 >> byte packets >> 1 pfsense.d3r3k.net (2001:470:8:d15::1) 0.278 ms 0.282 ms 0.317 ms >> 2 2001:470:7:d15::1 (2001:470:7:d15::1) 20.794 ms 24.746 ms 28.569 ms >> 3 gige-g4-12.core1.ash1.he.net (2001:470:0:90::1) 28.946 ms 29.124 ms >> 29.144 ms >> 4 as6453.gige-g3-16.core1.ash1.he.net (2001:470:0:191::2) 28.917 ms >> 28.936 ms 28.097 ms >> 5 if-ae2.2.tcore2.AEQ-Ashburn.ipv6.as6453.net (2001:5a0:600:500::1) >> 28.059 ms 31.771 ms 57.135 ms >> 6 2001:5a0:600:500::72 (2001:5a0:600:500::72) 28.959 ms 2001:559::31d >> (2001:559::31d) 29.041 ms 29.060 ms >> 7 pos-3-11-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f5a4::1) >> 32.553 ms 19.810 ms 16.526 ms >> 8 2001:558:0:f669::2 (2001:558:0:f669::2) 39.019 ms 37.954 ms 36.368 ms >> 9 2001:558:0:f57f::1 (2001:558:0:f57f::1) 67.134 ms 67.151 ms 67.166 ms >> 10 pos-2-7-0-0-cr01.denver.co.ibone.comcast.net (2001:558:0:f54d::1) >> 81.571 ms 81.507 ms 81.569 ms >> 11 2001:558:0:f744::2 (2001:558:0:f744::2) 80.633 ms 80.760 ms 79.825 ms >> 12 2001:558:d0:33::1 (2001:558:d0:33::1) 104.686 ms 105.060 ms 105.040 ms >> 13 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.335 ms >> 103.962 ms 104.068 ms >> 14 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.492 ms !X >> 104.597 ms !X 104.999 ms !X >> >> Thanks, >> Derek >> > > > > -- > Sadiq S > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > > > ------------------------------ > > Message: 2 > Date: Sun, 1 Jul 2012 20:35:24 -0500 > From: "Frank Bulk" <frnkblk(a)iname.com> > To: "'Derek Ivey'" <derek(a)derekivey.com>, <nanog(a)nanog.org> > Subject: RE: Comcast's IPv6 Information Site Unreachable > Message-ID: <000201cd57f2$f3973e90$dac5bbb0$(a)iname.com> > Content-Type: text/plain; charset="us-ascii" > > ICMP to www.comcast6.net has been blocked since 3:16 pm Central on 6/7/2012. > But their site loads fine over port 80. > > Frank > > -----Original Message----- > From: Derek Ivey [mailto:derek@derekivey.com] > Sent: Sunday, July 01, 2012 6:28 PM > To: nanog(a)nanog.org > Subject: Comcast's IPv6 Information Site Unreachable > > Anyone else having trouble getting to Comcast's IPv6 Information site? > It appears to be unreachable over IPv6. > > [root@server ~]# ping6 comcast6.net > PING comcast6.net(speedlab-app05.newcastlerdc.de.panjde.comcast.net) 56 > data bytes > From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=0 > Destination unreachable: Administratively prohibited > From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=1 > Destination unreachable: Administratively prohibited > From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=2 > Destination unreachable: Administratively prohibited > From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=3 > Destination unreachable: Administratively prohibited > From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=4 > Destination unreachable: Administratively prohibited > ^C > --- comcast6.net ping statistics --- > 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4008ms > > [root@server ~]# traceroute6 comcast6.net > traceroute to comcast6.net (2001:558:fe16:7:69:252:216:215), 30 hops > max, 40 byte packets > 1 pfsense.d3r3k.net (2001:470:8:d15::1) 0.278 ms 0.282 ms 0.317 ms > 2 2001:470:7:d15::1 (2001:470:7:d15::1) 20.794 ms 24.746 ms 28.569 ms > 3 gige-g4-12.core1.ash1.he.net (2001:470:0:90::1) 28.946 ms 29.124 > ms 29.144 ms > 4 as6453.gige-g3-16.core1.ash1.he.net (2001:470:0:191::2) 28.917 ms > 28.936 ms 28.097 ms > 5 if-ae2.2.tcore2.AEQ-Ashburn.ipv6.as6453.net (2001:5a0:600:500::1) > 28.059 ms 31.771 ms 57.135 ms > 6 2001:5a0:600:500::72 (2001:5a0:600:500::72) 28.959 ms > 2001:559::31d (2001:559::31d) 29.041 ms 29.060 ms > 7 pos-3-11-0-0-cr01.ashburn.va.ibone.comcast.net > (2001:558:0:f5a4::1) 32.553 ms 19.810 ms 16.526 ms > 8 2001:558:0:f669::2 (2001:558:0:f669::2) 39.019 ms 37.954 ms 36.368 ms > 9 2001:558:0:f57f::1 (2001:558:0:f57f::1) 67.134 ms 67.151 ms 67.166 ms > 10 pos-2-7-0-0-cr01.denver.co.ibone.comcast.net (2001:558:0:f54d::1) > 81.571 ms 81.507 ms 81.569 ms > 11 2001:558:0:f744::2 (2001:558:0:f744::2) 80.633 ms 80.760 ms 79.825 ms > 12 2001:558:d0:33::1 (2001:558:d0:33::1) 104.686 ms 105.060 ms 105.040 ms > 13 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.335 > ms 103.962 ms 104.068 ms > 14 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.492 ms > !X 104.597 ms !X 104.999 ms !X > > Thanks, > Derek > > > > > > > ------------------------------ > > Message: 3 > Date: Sun, 01 Jul 2012 21:44:40 -0400 > From: Derek Ivey <derek(a)derekivey.com> > To: Frank Bulk <frnkblk(a)iname.com> > Cc: nanog(a)nanog.org > Subject: Re: Comcast's IPv6 Information Site Unreachable > Message-ID: <4FF0FD08.8050706(a)derekivey.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Thanks for the input guys! Sounds like it might be an issue with my > tunnel then. I had problems getting to a few sites last week > (http://www.dslreports.com/forum/r27265527-IPV6-Issues-Facebook-and-Engadget) > and HE resolved the issue pretty quickly. I will ask them if they are > aware of it. > > Thanks, > Derek > > > On 7/1/2012 9:35 PM, Frank Bulk wrote: >> ICMP to www.comcast6.net has been blocked since 3:16 pm Central on 6/7/2012. >> But their site loads fine over port 80. >> >> Frank >> >> -----Original Message----- >> From: Derek Ivey [mailto:derek@derekivey.com] >> Sent: Sunday, July 01, 2012 6:28 PM >> To: nanog(a)nanog.org >> Subject: Comcast's IPv6 Information Site Unreachable >> >> Anyone else having trouble getting to Comcast's IPv6 Information site? >> It appears to be unreachable over IPv6. >> >> [root@server ~]# ping6 comcast6.net >> PING comcast6.net(speedlab-app05.newcastlerdc.de.panjde.comcast.net) 56 >> data bytes >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=0 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=1 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=2 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=3 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=4 >> Destination unreachable: Administratively prohibited >> ^C >> --- comcast6.net ping statistics --- >> 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4008ms >> >> [root@server ~]# traceroute6 comcast6.net >> traceroute to comcast6.net (2001:558:fe16:7:69:252:216:215), 30 hops >> max, 40 byte packets >> 1 pfsense.d3r3k.net (2001:470:8:d15::1) 0.278 ms 0.282 ms 0.317 ms >> 2 2001:470:7:d15::1 (2001:470:7:d15::1) 20.794 ms 24.746 ms 28.569 ms >> 3 gige-g4-12.core1.ash1.he.net (2001:470:0:90::1) 28.946 ms 29.124 >> ms 29.144 ms >> 4 as6453.gige-g3-16.core1.ash1.he.net (2001:470:0:191::2) 28.917 ms >> 28.936 ms 28.097 ms >> 5 if-ae2.2.tcore2.AEQ-Ashburn.ipv6.as6453.net (2001:5a0:600:500::1) >> 28.059 ms 31.771 ms 57.135 ms >> 6 2001:5a0:600:500::72 (2001:5a0:600:500::72) 28.959 ms >> 2001:559::31d (2001:559::31d) 29.041 ms 29.060 ms >> 7 pos-3-11-0-0-cr01.ashburn.va.ibone.comcast.net >> (2001:558:0:f5a4::1) 32.553 ms 19.810 ms 16.526 ms >> 8 2001:558:0:f669::2 (2001:558:0:f669::2) 39.019 ms 37.954 ms 36.368 ms >> 9 2001:558:0:f57f::1 (2001:558:0:f57f::1) 67.134 ms 67.151 ms 67.166 ms >> 10 pos-2-7-0-0-cr01.denver.co.ibone.comcast.net (2001:558:0:f54d::1) >> 81.571 ms 81.507 ms 81.569 ms >> 11 2001:558:0:f744::2 (2001:558:0:f744::2) 80.633 ms 80.760 ms 79.825 ms >> 12 2001:558:d0:33::1 (2001:558:d0:33::1) 104.686 ms 105.060 ms 105.040 ms >> 13 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.335 >> ms 103.962 ms 104.068 ms >> 14 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.492 ms >> !X 104.597 ms !X 104.999 ms !X >> >> Thanks, >> Derek >> >> >> > > > > > > ------------------------------ > > Message: 4 > Date: Sun, 1 Jul 2012 20:59:42 -0500 > From: Jimmy Hess <mysidia(a)gmail.com> > To: PC <paul4004(a)gmail.com> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: Re: [c-nsp] NTP Servers > Message-ID: > <CAAAwwbX-fEzaLRPrbrhM4MowFY=FJ2aGe=T4xFN+TprqKmG_GQ(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 7/1/12, PC <paul4004(a)gmail.com> wrote: >> If your application requires sub-5 second accuracy, (such as end of a >> banking day), then Windows NTP is unsuitable for the purpose. > Looks like CYA on Microsoft's part. > > That i've seen, Windows NTP in physical environments with a hardware > system clock not having issues consistently provides accuracy better > than +/- 0.5 against the time source it's synced with, but in > virtual environments, which have incompatibilities with high > sub-second RTC accuracy in the first place, neither Windows nor Unix > NTP services are able to provide that consistently without much > tinkering. > > If it's absolutely critical that you have sub-5 second accuracy, > even Unix NTP is not to be considered good enough, you need highly > accurate hardware time source, something more accurate than the usual > system clock you find in a PC or server. Unix NTP can only do so much > to correct for a broken system clock; although it does do a very > good job disciplining PC real-time clocks that consistently run a bit > too fast or too slow, ultimately the > personal computer clocks can at times be unreliable.... > > If they were perfect, you wouldn't need time sync in the first place; > just set them once, > and correct the annual 0.01 seconds worth of error once a year.... > > -- > -JH > > > > ------------------------------ > > Message: 5 > Date: Sun, 1 Jul 2012 21:20:11 -0500 > From: Jimmy Hess <mysidia(a)gmail.com> > To: Derek Ivey <derek(a)derekivey.com> > Cc: nanog(a)nanog.org > Subject: Re: Comcast's IPv6 Information Site Unreachable > Message-ID: > <CAAAwwbVQmcmeGMG44FgSUS6+c9GRTAXBh6DF5P6BEp0rQJVJpA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 7/1/12, Derek Ivey <derek(a)derekivey.com> wrote: >> Anyone else having trouble getting to Comcast's IPv6 Information site? >> It appears to be unreachable over IPv6. > > Looks like just ICMP that's broken. > > ~# telnet comcast6.net 80 > Trying 2001:558:fe23:2:69:252:208:135... > Connected to comcast6.net (2001:558:fe23:2:69:252:208:135). > Escape character is '^]'. > HEAD / HTTP/1.1 > Host: comcast6.net > User-Agent: Telnet > > HTTP/1.1 200 OK > Date: Mon, 02 Jul 2012 02:21:33 GMT > Server: Apache/2.2.15 (Red Hat) > X-Powered-By: PHP/5.3.3 > Set-Cookie: 1a3c31c9847a772452af472ce0afd5f3=5hcm2m506se424huah4eo5lvo7; path=/ > P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM" > Cache-Control: no-cache > Pragma: no-cache > Connection: close > Content-Type: text/html; charset=utf-8 > > Connection closed by foreign host. > > > > ~# ping6 comcast6.net > PING comcast6.net(speedlab-app05.newcastlerdc.de.panjde.comcast.net) > 56 data bytes >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=0 > Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=1 > Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=2 > Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=3 > Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=4 > Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=5 > Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=6 > Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=7 > Destination unreachable: Administratively prohibited > > --- comcast6.net ping statistics --- > 8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 6999ms > > > > ------------------------------ > > Message: 6 > Date: Sun, 1 Jul 2012 19:38:16 -0700 > From: "steve pirk [egrep]" <steve(a)pirk.com> > To: Jay Ashworth <jra(a)baylink.com> > Cc: NANOG <nanog(a)nanog.org> > Subject: Re: FYI Netflix is down > Message-ID: > <CAK4no06996brnEm=9117ANePGqrj6_6FDc999KD+ae_kWyWAbA(a)mail.gmail.com> > Content-Type: text/plain; charset=windows-1252 > > On Sun, Jul 1, 2012 at 11:38 AM, Jay Ashworth <jra(a)baylink.com> wrote: > >> Not entirely. Datacenters do go down, our best efforts to the contrary >> notwithstanding. Amazon doesn't guarantee you redundancy on EC2, only >> the tools to provide it yourself. 25% Amazon; 75% service provider >> clients; >> that's my appraisal of the blame. >> > >> From a Wired article: > >> That?s what was supposed to happen at Netflix Friday night. But it didn?t >> work out that way. According to Twitter messages from Netflix Director of >> Cloud Architecture Adrian Cockcroft and Instagram Engineer Rick Branson, it >> looks like an Amazon Elastic Load Balancing service, designed to spread >> Netflix?s processing loads across data centers, failed during the outage. >> Without that ELB service working properly, the Netflix and Pintrest >> services hosted by Amazon crashed. > > http://www.wired.com/wiredenterprise/2012/06/real-clouds-crush-amazon/ > > The GSLB fail-over that was supposed to take place for the affected > services (that had configured their applications to fail-over) failed. > > I heard about this the day after Google announced the Compute Engine > addition to the App Engine product lines they have. The demo was awesome. > I imagine Google has GSLB down pat by now, so some companies might start > looking... ;-] > > --steve > > > ------------------------------ > > Message: 7 > Date: Sun, 01 Jul 2012 22:45:51 -0400 > From: Derek Ivey <derek(a)derekivey.com> > To: Jimmy Hess <mysidia(a)gmail.com> > Cc: nanog(a)nanog.org > Subject: Re: Comcast's IPv6 Information Site Unreachable > Message-ID: <4FF10B5F.2090205(a)derekivey.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Someone replied to my DSL Reports thread: > http://www.dslreports.com/forum/r27289866- > > Apparently there is an ACL issue with their load balancer that is > blocking ICMP and causing PMTU issues for people who use tunnels. > > http://www.dslreports.com/forum/r27226136- > <http://www.gossamer-threads.com/lists/nsp/ipv6/34197> > > It looks like it's been going on since June 11. It's strange that > Comcast hasn't resolved the issue by now. > > Thanks, > Derek > > On 7/1/2012 10:20 PM, Jimmy Hess wrote: >> On 7/1/12, Derek Ivey <derek(a)derekivey.com> wrote: >>> Anyone else having trouble getting to Comcast's IPv6 Information site? >>> It appears to be unreachable over IPv6. >> Looks like just ICMP that's broken. >> >> ~# telnet comcast6.net 80 >> Trying 2001:558:fe23:2:69:252:208:135... >> Connected to comcast6.net (2001:558:fe23:2:69:252:208:135). >> Escape character is '^]'. >> HEAD / HTTP/1.1 >> Host: comcast6.net >> User-Agent: Telnet >> >> HTTP/1.1 200 OK >> Date: Mon, 02 Jul 2012 02:21:33 GMT >> Server: Apache/2.2.15 (Red Hat) >> X-Powered-By: PHP/5.3.3 >> Set-Cookie: 1a3c31c9847a772452af472ce0afd5f3=5hcm2m506se424huah4eo5lvo7; path=/ >> P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM" >> Cache-Control: no-cache >> Pragma: no-cache >> Connection: close >> Content-Type: text/html; charset=utf-8 >> >> Connection closed by foreign host. >> >> >> >> ~# ping6 comcast6.net >> PING comcast6.net(speedlab-app05.newcastlerdc.de.panjde.comcast.net) >> 56 data bytes >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=0 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=1 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=2 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=3 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=4 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=5 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=6 >> Destination unreachable: Administratively prohibited >> From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=7 >> Destination unreachable: Administratively prohibited >> >> --- comcast6.net ping statistics --- >> 8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 6999ms > > > > > End of NANOG Digest, Vol 54, Issue 3 > ************************************

1 0

Comcast's IPv6 Information Site Unreachable
by Derek Ivey 01 Jul '12

01 Jul '12

Anyone else having trouble getting to Comcast's IPv6 Information site? It appears to be unreachable over IPv6. [root@server ~]# ping6 comcast6.net PING comcast6.net(speedlab-app05.newcastlerdc.de.panjde.comcast.net) 56 data bytes From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=0 Destination unreachable: Administratively prohibited From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=1 Destination unreachable: Administratively prohibited From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=2 Destination unreachable: Administratively prohibited From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=3 Destination unreachable: Administratively prohibited From te-4-1-ur01.newcastlerdc.de.panjde.comcast.net icmp_seq=4 Destination unreachable: Administratively prohibited ^C --- comcast6.net ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4008ms [root@server ~]# traceroute6 comcast6.net traceroute to comcast6.net (2001:558:fe16:7:69:252:216:215), 30 hops max, 40 byte packets 1 pfsense.d3r3k.net (2001:470:8:d15::1) 0.278 ms 0.282 ms 0.317 ms 2 2001:470:7:d15::1 (2001:470:7:d15::1) 20.794 ms 24.746 ms 28.569 ms 3 gige-g4-12.core1.ash1.he.net (2001:470:0:90::1) 28.946 ms 29.124 ms 29.144 ms 4 as6453.gige-g3-16.core1.ash1.he.net (2001:470:0:191::2) 28.917 ms 28.936 ms 28.097 ms 5 if-ae2.2.tcore2.AEQ-Ashburn.ipv6.as6453.net (2001:5a0:600:500::1) 28.059 ms 31.771 ms 57.135 ms 6 2001:5a0:600:500::72 (2001:5a0:600:500::72) 28.959 ms 2001:559::31d (2001:559::31d) 29.041 ms 29.060 ms 7 pos-3-11-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f5a4::1) 32.553 ms 19.810 ms 16.526 ms 8 2001:558:0:f669::2 (2001:558:0:f669::2) 39.019 ms 37.954 ms 36.368 ms 9 2001:558:0:f57f::1 (2001:558:0:f57f::1) 67.134 ms 67.151 ms 67.166 ms 10 pos-2-7-0-0-cr01.denver.co.ibone.comcast.net (2001:558:0:f54d::1) 81.571 ms 81.507 ms 81.569 ms 11 2001:558:0:f744::2 (2001:558:0:f744::2) 80.633 ms 80.760 ms 79.825 ms 12 2001:558:d0:33::1 (2001:558:d0:33::1) 104.686 ms 105.060 ms 105.040 ms 13 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.335 ms 103.962 ms 104.068 ms 14 te-3-1-ur03.cmc.co.ndcwest.comcast.net (2001:558:d0:5::1) 104.492 ms !X 104.597 ms !X 104.999 ms !X Thanks, Derek

4 5

RE: [c-nsp] NTP Servers
by Keith Medcalf 01 Jul '12

01 Jul '12

> Or you can ask the it guys to use a windows server... Eg: > > http://support.microsoft.com/kb/816042 That is a joke Jared? You left off the smiley. Windows doesn't do NTP out-of-the-box (Microsoft assertions to the contrary notwithstanding). You can build a reasonably working standard daemon, however don't expect time to be very accurate. Windows out-of-the-box can keep time +/- 10 minutes or so using the Microsoft lets-pretend-NTP. You can build the current standard NTPD distribution on Windows. You can also spend lots of time to make it "work as well as possible" (once you manage to get it to compile, that is). Even so, when you have configured it to the optimality of accuracy, this is what you can expect: remote refid st t when poll reach delay offset jitter ============================================================================== +tic.nrc.ca .PPS. 1 u 13 64 377 55.544 5.913 0.870 -tac.nrc.ca .ATOM. 1 u 48 64 377 56.188 4.768 3.041 -toc.nrc.ca .ATOM. 1 u 1 64 377 55.485 4.758 0.981 +tick.usask.ca .GPS. 1 u 34 64 377 19.566 6.942 5.699 *tock.usask.ca .GPS. 1 u 29 64 377 19.665 5.955 1.937 -clock.isc.org .GPS. 1 u 37 64 377 53.091 8.311 0.649 +clock.sjc.he.ne .CDMA. 1 u 48 64 377 43.591 6.066 2.501 offset: 0.005955 s frequency: 23.346 ppm poll adjust: -30 watchdog timer: 47 s is about the best you will get. Statistics are pretty awful: Date # O.Avg O.Median O.Range O.CI O.Skew O.Kurt F.Avg F.Median F.Range F.CI F.Kurt 2012-01 899 0.765559 0.004198 20.05221 0.000371 -0.56023 0.751151 21.31698 20.9705 2.9685 0.108050 -0.88068 2012-02 9673 0.237434 -7.46502 59.75607 0.000156 -1.43583 8.609085 19.01126 19.3495 5.2995 0.040683 -0.54578 2012-03 1380 -0.02157 -14.8416 44.00043 0.000124 -1.08589 4.559049 18.08941 16.822 7.536 0.045387 0.268831 2012-04 1322 0.196654 21.16261 106.1250 0.000141 -0.48643 26.05868 17.56811 16.812 6.111 0.040561 -0.38021 2012-05 8849 0.118125 27.44213 72.01526 0.000161 0.296114 8.939429 17.88685 15.2595 9.3195 0.080186 1.121740 2012-06 1457 0.409662 -20.2809 63.32684 0.000114 -1.44144 11.98237 20.50724 19.5425 6.7425 0.042372 -0.08891 6102 0.201651 21.16261 106.1250 6.065429 -0.84354 13.78161 18.71838 16.1125 10.1725 0.023443 1.215941 This is from a custom ntpd build using the highest precision that it can manage to coerce from Windoze. Of course, this may be accurate enough for most uses -- at least it does not have to time-step. Doesn't compare to ntpd on linux on an 80286 with 640K ram booting from a floppy, which can maintain time sync within less than 1 ms easily. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org

5 5