April 2012 - Outages - Outages Lists

DNS issues with .gov on Tuesday 4/24?
by Julian Y Koh 30 Apr '12

30 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Was anyone aware of any issues that might have affected DNS resolution for some .gov domains (specifically grants.gov) on Tuesday 4/24 around 3-5pm US Central Time? We weren't alerted to the problem until 4:25pm, and things started working again around 4:45pm, so we didn't have time to really troubleshoot. By the time we saw the ticket and the like, all we had time to do was verify that DNS was failing for us from AS103 and a couple of other DNS testing sites like kloth.net with the "no servers could be reached" error. Users report that DNS resolution was working though from their cellular data networks as well as the public Wi-Fi in the Burger King across the street from their offices, so it does not appear to have been a universal outage. Anecdotally, our users report that there may have been similar errors with nsf.gov and nih.gov earlier that day, but we have no actual data on that. We also found some earlier issues noted with .gov such as the one mentioned at <http://forums.comcast.com/t5/Connectivity-and-Modem-Help/Re-Comcast-DNS-iss…>. However, we have been unable to find any actual external verification of our exact issue, which would be useful since we had a few grant proposals get rejected because our researchers missed their deadline. Obviously there are any number of possible causes for this problem, and the grants.gov people seem to be having issues escalating our tickets with them to the group that would have a better chance of investigating from their end (and of course the actual problem could have been outside both of our spheres of influence). Thanks for any information that can be shared! - -- Julian Y. Koh Manager, Network Transport, Telecommunications and Network Services Northwestern University Information Technology (NUIT) 2001 Sheridan Road #G-166 Evanston, IL 60208 847-467-5780 NUIT Web Site: <http://www.it.northwestern.edu/> PGP Public Key:<http://bt.ittns.northwestern.edu/julian/pgppubkey.html> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk+eftsACgkQDlQHnMkeAWMswQCgnrfyqy4F8TNft8FlfnNTdjS6 AU4AnitqXt3L2EkNP7X2SNXO8E2yO+Qg =PmNP -----END PGP SIGNATURE-----

2 1

Re: [outages] Fwd: above.net / he.net routing problems in LAX?
by Erik S. 26 Apr '12

26 Apr '12

Rob, Thanks for getting back to us. You are indeed correct, the problem does appear to be inside the Corporate Colocation network. Their NOC has been insisting this was upstream and the routing issues we're seeing as a result incorrectly implicated peers along the way. I apologize for wasting your time, and again thank you for troubleshooting and responses. -Erik On 04/26/2012 07:40 PM, Rob Mosher wrote: > You appear to be a customer of Corporate Colocation. Their equipment is > the next hop in the traceroute, and the apparent point of failure. > Perhaps contacting your provider before erroneously posting to an > outages list may be prudent, as the point of failure does not seem to > lie within HE, Abovenet, or GT-T, all of which have been named in your > email. > > Also, GT-T should have sourced their trace from a non Equinix IX IP > address, and it would have gotten further. This obviously did not help > their diagnostics. > > Here is an MTR to 205.134.255.113, from an internal HE IP address. > Please contact your provider, Corporate Colocation, for further > troubleshooting. > > Host Loss% Snt Last Avg Best Wrst StDev > 1. gige-g3-8.core1.fmt1.he.net 0.0% 100 0.5 3.5 0.4 12.5 3.9 > 2. 10gigabitethernet1-1.core1.pao1.he.net 0.0% 99 0.8 3.5 0.7 11.5 3.6 > 3. 10gigabitethernet1-1.core1.lax1.he.net 0.0% 99 9.1 11.3 9.0 21.6 3.3 > 4. corporate-colocation-inc.gigabitethernet3- 70.4% 99 9.3 21.5 9.1 > 256.3 49.2 > 5. ??? > > > -- > Rob Mosher > Senior Network and Software Engineer > Hurricane Electric / AS6939 > > > On 4/26/2012 7:31 PM, Erik S. wrote: >> Hi Rob, >> >> Thanks for the quick response. Sorry for the confusion, the >> information I was provided at first was a little cloudy. We also use >> GT-T/Packet Exchange and they're pointing this at above.net. >> >> Here's the response we received from PKX/GT-T regarding the routing >> anomaly we're experiencing: >> >> -------- Original Message -------- >> Subject: GTT TT#(49181), SVC ID: PEX/NATIVE LAYER 3/9014-1 RE: Routing >> issue preventing our network from reaching * >> Date: Thu, 26 Apr 2012 21:52:27 +0000 >> From: GTT NOC <NOC(a)gt-t.net> >> >> From LAX core device the routes goes to abovenet for both the ip >> address and dies within the above net network. >> We will investigate with abovenet and update you shortly. >> >> cr1.lax1#traceroute 108.171.183.75 >> >> Type Ctrl-C to abort. >> >> ------------------------------------------------------------------- >> Tracing the route to 108.171.183.75, 30 hops max, 40 byte packets >> ------------------------------------------------------------------- >> TTL Hostname Probe1 Probe2 Probe3 >> 1 mpr1.lax2.us.above.net (206.223.123.71) 012.000 ms 001.000 ms >> 001.000 ms >> 2 * * * >> 3 * * * >> 4 * * * >> 5 * >> >> -- End forwarded message -- >> >> If they have not yet opened a ticket with you, this leads me to >> believe there's a problem elsewhere and we're being given the run-around. >> >> The particular trace above is to one of our off-site boxes at rackspace. >> >> This is an issue that seems to be impacting multiple networks and >> regions, so I'm not entirely convinced there's not something more >> going on. >> >> For example, besides the IP referenced above, our 205.134.0.0 subnets >> are also failing. I pulled this trace from Above.net's looking glass: >> >> traceroute to 205.134.255.113 (205.134.255.113), 30 hops max, 40 byte >> packets >> 1 xe-0-1-0.mpr1.lax12.us.above.net (64.125.31.189) 22.612 ms 0.421 ms >> 0.368 ms >> 2 10gigabitethernet1-3.core1.lax1.he.net (206.223.123.37) 0.944 ms >> 12.178 ms 0.956 ms >> 3 * * * >> 4 * * * >> 5 * * * >> 6 * * * >> 7 * * * >> 8 * * * >> 9 * * * >> 10 * * * >> 11 * * * >> 12 * * * >> 13 * * * >> 14 * * * >> 15 * * * >> 16 * * * >> 17 * * * >> 18 * * * >> 19 * * * >> 20 * * * >> 21 * * * >> 22 * * * >> 23 * * * >> 24 * * * >> 25 * * * >> 26 * * * >> 27 * corporate-colocation-inc.gigabitethernet3-16.core1.lax1.he.net >> (72.52.77.38) 1.135 ms !H * >> 28 * * * >> 29 * * * >> >> Tracing out from 205.134.255.113 anywhere yields this: >> >> root@wczverify1 [~]# traceroute above.net >> traceroute to above.net (64.125.228.35), 30 hops max, 40 byte packets >> 1 74.124.198.1 (74.124.198.1) 0.461 ms 0.465 ms 0.530 ms >> 2 gige-g2-19.core1.lax2.he.net (64.62.194.161) 0.363 ms 0.433 ms 0.509 ms >> 3 * * * >> 4 * * * >> 5 * * * >> 6 * * * >> >> >> If you could shed any additional light on this issue for us I'd be >> most appreciative. >> >> Thanks. >> >> Best Regards, >> >> Erik Soroka >> Tier III System Administrator >> InMotion Hosting, Inc. >> eriks(a)inmotionhosting.com >> 888-321-4678 (ext 834) >> 757-416-6575 (int'l) >> >> >> On 04/26/2012 07:20 PM, Rob Mosher wrote: >>> Hi Erik, >>> >>> Where did you get the information that we were blaming above.net for >>> anything? We are not aware of any issue between above.net and he.net, >>> nor have we seen any tickets opened regarding this. Can you please >>> include the source and destination IP addresses of the traceroute quoted >>> below, as well as a traceroute in the opposite direction if possible? >>> >>> As far as I can tell, everything looks clean here. >>> >>> root@tserv15:~# tcptraceroute lg.above.net >>> traceroute to lg.above.net (64.124.253.67), 30 hops max, 60 byte packets >>> 1 gige-g4-6.core1.lax1.he.net (66.220.18.41) 7.683 ms 7.725 ms >>> 7.821 ms >>> 2 mpr1.lax2.us.above.net (206.223.123.71) 0.781 ms 0.766 ms 0.767 ms >>> 3 xe-3-0-0.cr1.lax112.us.above.net (64.125.30.17) 1.055 ms 1.057 >>> ms 1.293 ms >>> 4 xe-2-1-0.cr1.sjc2.us.above.net (64.125.24.18) 10.125 ms 10.129 >>> ms 10.120 ms >>> 5 xe-1-1-0.er1.sjc2.us.above.net (64.125.26.198) 9.815 ms 9.800 ms >>> 9.800 ms >>> 6 f1-1.itr3.sjc2.us.corp.above.net (64.124.248.122) 10.239 ms >>> 10.002 ms 9.995 ms >>> 7 lg.above.net (64.124.253.67) 10.227 ms 10.338 ms 10.267 ms >>> >>> -- >>> Rob Mosher >>> Senior Network and Software Engineer >>> Hurricane Electric / AS6939 >>> >>> >>>> ---------- Forwarded message ---------- >>>> From: "Erik S." <eriks(a)inmotionhosting.com >>>> <mailto:eriks@inmotionhosting.com>> >>>> Date: Apr 26, 2012 6:06 PM >>>> Subject: [outages] above.net <http://above.net> / he.net >>>> <http://he.net> routing problems in LAX? >>>> To: "outages(a)outages.org <mailto:outages@outages.org>" >>>> <outages(a)outages.org <mailto:outages@outages.org>> >>>> >>>> We're seeing major routing issues in Los Angeles with peering from >>>> HE.net <-> Above.net, specifically after mpr1.lax2.us.above.net >>>> <http://mpr1.lax2.us.above.net>. >>>> >>>> Above.net's looking glass in LA shows traces dying right after he.net >>>> <http://he.net>, >>>> >>>> 1 xe-0-1-0.cr2.lax112.us.above.net >>>> <http://xe-0-1-0.cr2.lax112.us.above.net> (64.125.30.250 >>>> <tel:%2864.125.30.250>) 0.780 ms 0.571 ms 0.479 ms >>>> 2 xe-8-0-0.mpr1.lax12.us.above.net >>>> <http://xe-8-0-0.mpr1.lax12.us.above.net> (64.125.30.30) 0.393 ms >>>> 0.483 ms 0.404 ms >>>> 3 10gigabitethernet1-3.core1.lax1.he.net >>>> <http://10gigabitethernet1-3.core1.lax1.he.net> (206.223.123.37) >>>> 0.884 ms 4.619 ms 1.100 ms >>>> 4 * * * >>>> >>>> Both sides seem to be blaming the other. Is anyone routing via >>>> above.net <http://above.net> or he.net <http://he.net> seeing similar >>>> issues out west? >>>> >>>> Best Regards, >>>> >>>> Erik Soroka >>>> Tier III System Administrator >>>> InMotion Hosting, Inc. >>>> eriks(a)inmotionhosting.com <mailto:eriks@inmotionhosting.com> >>>> >>>> >>>> _______________________________________________ >>>> Outages mailing list >>>> Outages(a)outages.org <mailto:Outages@outages.org> >>>> https://puck.nether.net/mailman/listinfo/outages >>>> >> >

1 0

Re: [outages] Fwd: above.net / he.net routing problems in LAX?
by Erik S. 26 Apr '12

26 Apr '12

Hi Rob, Thanks for the quick response. Sorry for the confusion, the information I was provided at first was a little cloudy. We also use GT-T/Packet Exchange and they're pointing this at above.net. Here's the response we received from PKX/GT-T regarding the routing anomaly we're experiencing: -------- Original Message -------- Subject: GTT TT#(49181), SVC ID: PEX/NATIVE LAYER 3/9014-1 RE: Routing issue preventing our network from reaching * Date: Thu, 26 Apr 2012 21:52:27 +0000 From: GTT NOC <NOC(a)gt-t.net> From LAX core device the routes goes to abovenet for both the ip address and dies within the above net network. We will investigate with abovenet and update you shortly. cr1.lax1#traceroute 108.171.183.75 Type Ctrl-C to abort. ------------------------------------------------------------------- Tracing the route to 108.171.183.75, 30 hops max, 40 byte packets ------------------------------------------------------------------- TTL Hostname Probe1 Probe2 Probe3 1 mpr1.lax2.us.above.net (206.223.123.71) 012.000 ms 001.000 ms 001.000 ms 2 * * * 3 * * * 4 * * * 5 * -- End forwarded message -- If they have not yet opened a ticket with you, this leads me to believe there's a problem elsewhere and we're being given the run-around. The particular trace above is to one of our off-site boxes at rackspace. This is an issue that seems to be impacting multiple networks and regions, so I'm not entirely convinced there's not something more going on. For example, besides the IP referenced above, our 205.134.0.0 subnets are also failing. I pulled this trace from Above.net's looking glass: traceroute to 205.134.255.113 (205.134.255.113), 30 hops max, 40 byte packets 1 xe-0-1-0.mpr1.lax12.us.above.net (64.125.31.189) 22.612 ms 0.421 ms 0.368 ms 2 10gigabitethernet1-3.core1.lax1.he.net (206.223.123.37) 0.944 ms 12.178 ms 0.956 ms 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * corporate-colocation-inc.gigabitethernet3-16.core1.lax1.he.net (72.52.77.38) 1.135 ms !H * 28 * * * 29 * * * Tracing out from 205.134.255.113 anywhere yields this: root@wczverify1 [~]# traceroute above.net traceroute to above.net (64.125.228.35), 30 hops max, 40 byte packets 1 74.124.198.1 (74.124.198.1) 0.461 ms 0.465 ms 0.530 ms 2 gige-g2-19.core1.lax2.he.net (64.62.194.161) 0.363 ms 0.433 ms 0.509 ms 3 * * * 4 * * * 5 * * * 6 * * * If you could shed any additional light on this issue for us I'd be most appreciative. Thanks. Best Regards, Erik Soroka Tier III System Administrator InMotion Hosting, Inc. eriks(a)inmotionhosting.com 888-321-4678 (ext 834) 757-416-6575 (int'l) On 04/26/2012 07:20 PM, Rob Mosher wrote: > Hi Erik, > > Where did you get the information that we were blaming above.net for > anything? We are not aware of any issue between above.net and he.net, > nor have we seen any tickets opened regarding this. Can you please > include the source and destination IP addresses of the traceroute quoted > below, as well as a traceroute in the opposite direction if possible? > > As far as I can tell, everything looks clean here. > > root@tserv15:~# tcptraceroute lg.above.net > traceroute to lg.above.net (64.124.253.67), 30 hops max, 60 byte packets > 1 gige-g4-6.core1.lax1.he.net (66.220.18.41) 7.683 ms 7.725 ms > 7.821 ms > 2 mpr1.lax2.us.above.net (206.223.123.71) 0.781 ms 0.766 ms 0.767 ms > 3 xe-3-0-0.cr1.lax112.us.above.net (64.125.30.17) 1.055 ms 1.057 > ms 1.293 ms > 4 xe-2-1-0.cr1.sjc2.us.above.net (64.125.24.18) 10.125 ms 10.129 > ms 10.120 ms > 5 xe-1-1-0.er1.sjc2.us.above.net (64.125.26.198) 9.815 ms 9.800 ms > 9.800 ms > 6 f1-1.itr3.sjc2.us.corp.above.net (64.124.248.122) 10.239 ms > 10.002 ms 9.995 ms > 7 lg.above.net (64.124.253.67) 10.227 ms 10.338 ms 10.267 ms > > -- > Rob Mosher > Senior Network and Software Engineer > Hurricane Electric / AS6939 > > >> ---------- Forwarded message ---------- >> From: "Erik S." <eriks(a)inmotionhosting.com >> <mailto:eriks@inmotionhosting.com>> >> Date: Apr 26, 2012 6:06 PM >> Subject: [outages] above.net <http://above.net> / he.net >> <http://he.net> routing problems in LAX? >> To: "outages(a)outages.org <mailto:outages@outages.org>" >> <outages(a)outages.org <mailto:outages@outages.org>> >> >> We're seeing major routing issues in Los Angeles with peering from >> HE.net <-> Above.net, specifically after mpr1.lax2.us.above.net >> <http://mpr1.lax2.us.above.net>. >> >> Above.net's looking glass in LA shows traces dying right after he.net >> <http://he.net>, >> >> 1 xe-0-1-0.cr2.lax112.us.above.net >> <http://xe-0-1-0.cr2.lax112.us.above.net> (64.125.30.250 >> <tel:%2864.125.30.250>) 0.780 ms 0.571 ms 0.479 ms >> 2 xe-8-0-0.mpr1.lax12.us.above.net >> <http://xe-8-0-0.mpr1.lax12.us.above.net> (64.125.30.30) 0.393 ms >> 0.483 ms 0.404 ms >> 3 10gigabitethernet1-3.core1.lax1.he.net >> <http://10gigabitethernet1-3.core1.lax1.he.net> (206.223.123.37) >> 0.884 ms 4.619 ms 1.100 ms >> 4 * * * >> >> Both sides seem to be blaming the other. Is anyone routing via >> above.net <http://above.net> or he.net <http://he.net> seeing similar >> issues out west? >> >> Best Regards, >> >> Erik Soroka >> Tier III System Administrator >> InMotion Hosting, Inc. >> eriks(a)inmotionhosting.com <mailto:eriks@inmotionhosting.com> >> >> >> _______________________________________________ >> Outages mailing list >> Outages(a)outages.org <mailto:Outages@outages.org> >> https://puck.nether.net/mailman/listinfo/outages >> --

1 0

above.net / he.net routing problems in LAX?
by Erik S. 26 Apr '12

26 Apr '12

We're seeing major routing issues in Los Angeles with peering from HE.net <-> Above.net, specifically after mpr1.lax2.us.above.net. Above.net's looking glass in LA shows traces dying right after he.net, 1 xe-0-1-0.cr2.lax112.us.above.net (64.125.30.250) 0.780 ms 0.571 ms 0.479 ms 2 xe-8-0-0.mpr1.lax12.us.above.net (64.125.30.30) 0.393 ms 0.483 ms 0.404 ms 3 10gigabitethernet1-3.core1.lax1.he.net (206.223.123.37) 0.884 ms 4.619 ms 1.100 ms 4 * * * Both sides seem to be blaming the other. Is anyone routing via above.net or he.net seeing similar issues out west? Best Regards, Erik Soroka Tier III System Administrator InMotion Hosting, Inc. eriks(a)inmotionhosting.com

1 0

CenturyLink Issues in Atlanta
by Devon True 26 Apr '12

26 Apr '12

All: We are seeing some routing issues with our CenturyLink connection in Atlanta. If I am our peering router with CL, a traceroute sourced from one interface works while another fails. // works 2 63.233.83.253 0 msec 0 msec 4 msec 3 67.14.8.86 16 msec 16 msec 16 msec 4 63.148.124.242 [AS 209] 32 msec 36 msec 32 msec // fails 2 63.233.83.253 0 msec 4 msec 0 msec 3 * * * Is anyone else experiencing issues with CenturyLink? We have a ticket opened but there are no updates at this time. -- Devon

4 4

USAD SIP Dropped Calls
by Dan White 25 Apr '12

25 Apr '12

We are receiving customer complaints of dropped calls on our USAD SIP trunks. We are also noticing intermittent packet loss and high variability in latency (according to ping/traceroute). Is anyone else experiencing problems? dwhite@quark:~$ dig +short -x 66.116.118.50 cust-66.116.118.50.switchnap.com. dwhite@quark:~$ ping -A -q -c 50 66.116.118.50 PING 66.116.118.50 (66.116.118.50) 56(84) bytes of data. --- 66.116.118.50 ping statistics --- 50 packets transmitted, 43 received, 14% packet loss, time 9992ms rtt min/avg/max/mdev = 46.929/153.021/512.515/119.183 ms, pipe 3, ipg/ewma 203.936/104.808 ms dwhite@quark:~$ mtr --report -c 50 66.116.118.50 HOST: quark Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.0.2.1 0.0% 50 0.6 1.8 0.5 3.6 0.8 2.|-- olp-67-217-152-5.olp.net 0.0% 50 1.4 1.8 0.7 10.1 1.3 3.|-- router.olp.net 0.0% 50 0.9 0.9 0.7 4.1 0.5 4.|-- olp-67-217-152-34.olp.net 0.0% 50 1.2 7.0 1.2 277.4 39.0 5.|-- ae5-694.edge9.dallas1.lev 0.0% 50 8.2 8.6 8.1 23.8 2.3 6.|-- vlan80.csw3.dallas1.level 0.0% 50 8.1 11.8 8.1 20.5 4.2 7.|-- ae-82-82.ebr2.dallas1.lev 0.0% 50 8.2 8.7 8.1 17.6 1.5 8.|-- ae-2-2.ebr1.denver1.level 0.0% 50 22.6 25.8 22.5 34.3 4.3 9.|-- ae-1-6.bar2.lasvegas1.lev 0.0% 50 41.8 44.9 41.8 95.8 10.9 10.|-- ae-5-5.car2.lasvegas1.lev 0.0% 50 41.9 57.4 41.9 192.5 35.5 11.|-- switch-comm.car2.lasvegas 0.0% 50 42.7 42.8 42.6 43.1 0.1 12.|-- te2-6.las-core2-1.switchn 0.0% 50 42.9 51.6 42.6 239.4 35.7 13.|-- te4-1.las-esw09.switchnap 2.0% 50 43.2 43.9 42.9 59.0 3.0 14.|-- cust-66.209.71.30.switchn 34.0% 50 142.4 381.9 99.8 1371. 283.3 15.|-- cust-66.116.118.50.switch 64.0% 50 192.6 327.1 108.7 726.2 208.8 - Dan

4 4

Qwest ISP issues in Chicago
by Michael Vallaly 25 Apr '12

25 Apr '12

Seeing a major outage of Qwest connectivity in Chicago. SIP Trunks and Internet connectivity seem to be affected.. -Mike -- Michael Vallaly <mvallaly(a)nolatency.com>

4 4

Integra Outage Northern Colorado
by Blake Pfankuch 24 Apr '12

24 Apr '12

Seeing issues across a lot of our customers on Integra, including a branch office of ours. Anyone know what's up? We have a ticket open, but getting the usual sludge and no ETA. Blake Pfankuch

1 0

Rightnow reporting several lines doen in bay area
by Martin Hepworth 20 Apr '12

20 Apr '12

Anyone got any further info, they are pointing the finger at their providers -- Martin -- -- Martin Hepworth Oxford, UK

11 11

Re: [outages] [Outages-discussion] Short interruption to IPv6 version of Cogent's site
by Frank Bulk 20 Apr '12

20 Apr '12

Back up by 8 am Central. Frank -----Original Message----- From: outages-bounces(a)outages.org [mailto:outages-bounces@outages.org] On Behalf Of Frank Bulk Sent: Friday, April 20, 2012 7:21 AM To: outages(a)outages.org Subject: Re: [outages] [Outages-discussion] Short interruption to IPv6 version of Cogent's site IPv6 access to their website dropped again at 6:57 am Central. I can traceroute6 and ping6 it just fine, it's just HTTP access. In fact, v4 access to www.cogentco.com is down, resulting in "Database Error: Unable to connect to the database:Could not connect to MySQL". The v6 version of their site fails to load more quickly. =) nagios:~/bin# wget -4 www.cogentco.com --2012-04-20 07:20:40-- http://www.cogentco.com/ Resolving www.cogentco.com... 38.100.128.10 Connecting to www.cogentco.com|38.100.128.10|:80... connected. HTTP request sent, awaiting response... 500 Internal Server Error 2012-04-20 07:20:49 ERROR 500: Internal Server Error. nagios:~/bin# wget -6 www.cogentco.com --2012-04-20 07:20:54-- http://www.cogentco.com/ Resolving www.cogentco.com... 2001:550:1::cc01 Connecting to www.cogentco.com|2001:550:1::cc01|:80... connected. HTTP request sent, awaiting response... 500 Internal Server Error 2012-04-20 07:20:54 ERROR 500: Internal Server Error. nagios:~/bin# -----Original Message----- From: outages-discussion-bounces(a)outages.org [mailto:outages-discussion-bounces@outages.org] On Behalf Of Frank Bulk Sent: Friday, April 20, 2012 6:56 AM To: outages-discussion(a)outages.org Subject: [Outages-discussion] Short interruption to IPv6 version of Cogent's site Did anyone else see IPv6 access to www.cogentco.com and ipv6.cogentco.com down from 4 am until 5:27 am Central? Perhaps more was down, but I'm just monitoring the v6 side of that site today. Regards, _______________________________________________ Outages-discussion mailing list Outages-discussion(a)outages.org https://puck.nether.net/mailman/listinfo/outages-discussion _______________________________________________ Outages mailing list Outages(a)outages.org https://puck.nether.net/mailman/listinfo/outages

1 0