November 2012 - Test - lists.nanog.org

Re: Brasil/Mexico/Argentina connectivity
by Eduardo Casarero 20 Nov '12

20 Nov '12

El jueves, 15 de noviembre de 2012 01:05:37 p.m., Jima escribió: > On Wednesday, November 14th, 2012, Olivier CALVANO wrote: >> I am search one or more carrier for connect 3 sites in Brasil, Mexico >> and Argentina to one of our pop >> in USA or Spain. > > I don't deal with it directly, but my employer has used MPLS offerings > from (in alphabetical order) BT, Level 3/Global Crossing, and Verizon in > a number of countries. I suspect any of the three have access in all of > the countries listed. I imagine there are others, but those are the ones > that sprung to mind. > > Jima > > I think Level3 is your best, as L3 bought Globalcrossing. Here in Argentina L3 has heavy weight in the carriers market, also in Brazil. What i dont know is in Mexico.

1 0

RE: [outages] NTP Issues Today
by R. Benjamin Kessler 20 Nov '12

20 Nov '12

Logs from a Juniper router in a customer network - we had hundreds of these affected. They all synchronize to internal hosts (172.20.167.251 and .252) which are configured to get time from NIST and USNO CORP-NTP-01#sh ntp as address ref clock st when poll reach delay offset disp *~192.5.41.41 .IRIG. 1 354 512 377 34.2 0.36 1.4 +~132.163.4.101 .ACTS. 1 336 512 377 35.0 -2.54 18.7 ~127.127.7.1 127.127.7.1 10 59 64 377 0.0 0.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured CORP-NTP-02#sh ntp as address ref clock st when poll reach delay offset disp *~192.5.41.41 .IRIG. 1 65 512 377 36.5 0.91 0.6 +~132.163.4.101 .ACTS. 1 95 512 377 34.3 -1.31 22.8 ~127.127.7.1 127.127.7.1 10 44 64 377 0.0 0.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured Here are the logs from one of the Junipers: Nov 19 14:24:48 XXXX xntpd[912]: kernel time sync enabled 2001 Nov 19 15:50:11 XXXX xntpd[912]: synchronized to 172.20.167.252, stratum=2 Nov 19 16:41:23 XXXX xntpd[912]: no servers reachable Nov 19 16:44:24 XXXX xntpd[912]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:24 XXXX xntpd[912]: time correction of -378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 16:44:24 XXXX init: ntp (PID 912) exited with status=255 Nov 19 16:44:24 XXXX init: ntp (PID 70200) started Nov 19 16:44:24 XXXX xntpd[70200]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 16:44:24 XXXX xntpd[70200]: mlockall(): Resource temporarily unavailable Nov 19 16:44:24 XXXX xntpd[70200]: precision = 0.582 usec Nov 19 16:44:24 XXXX xntpd[70200]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 16:44:24 XXXX xntpd[70200]: kernel time sync status 2040 Nov 19 16:44:24 XXXX xntpd[70200]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 16:44:24 XXXX xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:24 XXXX xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:33 XXXX xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:32 XXXX xntpd[70200]: time reset -378691200.411331 s Nov 19 16:44:32 XXXX xntpd[70200]: kernel time sync disabled 2041 Nov 19 16:45:44 XXXX xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:45:51 XXXX xntpd[70200]: kernel time sync enabled 2001 Nov 19 16:45:56 XXXX xntpd[70200]: NTP Server Unreachable Nov 19 16:53:25 XXXX xntpd[70200]: no servers reachable Nov 19 17:03:09 XXXX xntpd[70200]: NTP Server Unreachable Nov 19 17:13:00 XXXX xntpd[70200]: NTP Server Unreachable Nov 19 17:20:27 XXXX xntpd[70200]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:27 XXXX xntpd[70200]: time correction of 378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 17:20:27 XXXX init: ntp (PID 70200) exited with status=255 Nov 19 17:20:27 XXXX init: ntp (PID 70766) started Nov 19 17:20:27 XXXX xntpd[70766]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 17:20:27 XXXX xntpd[70766]: mlockall(): Resource temporarily unavailable Nov 19 17:20:27 XXXX xntpd[70766]: precision = 0.570 usec Nov 19 17:20:27 XXXX xntpd[70766]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 17:20:27 XXXX xntpd[70766]: kernel time sync status 2040 Nov 19 17:20:27 XXXX xntpd[70766]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 17:20:27 XXXX xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:27 XXXX xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:35 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:36 XXXX xntpd[70766]: time reset +378691200.387434 s Nov 19 17:20:36 XXXX xntpd[70766]: kernel time sync disabled 6041 Nov 19 17:21:48 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:21:48 XXXX xntpd[70766]: kernel time sync disabled 2041 Nov 19 17:21:52 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 00:02:29 XXXX xntpd[70766]: synchronized to 172.20.167.251, stratum=2 Nov 20 01:44:56 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 02:19:03 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 02:53:12 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 03:44:26 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 05:26:58 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 05:44:02 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 07:43:35 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:00:39 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 08:34:48 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:51:54 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 10:34:22 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 20 11:25:16 XXXX xntpd[70766]: synchronized to 172.20.167.251, stratum=2 Nov 20 12:33:56 XXXX xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 20 14:16:05 XXXX xntpd[70766]: kernel time sync enabled 6001 Nov 20 14:33:10 XXXX xntpd[70766]: kernel time sync enabled 2001 Nov 20 15:07:19 XXXX xntpd[70766]: synchronized to 172.20.167.251, stratum=2 -----Original Message----- From: outages-bounces(a)outages.org [mailto:outages-bounces@outages.org] On Behalf Of Jeremy Chadwick Sent: Tuesday, November 20, 2012 10:38 AM To: Scott Voll Cc: Sid Rao; outages; nanog(a)nanog.org Subject: Re: [outages] NTP Issues Today I'm still waiting for someone who was affected by this to provide coherent logs from ntpd showing exactly when the time change happened. Getting these, at least on an *IX system, is far from difficult folks. Please don't omit anything from the logs either; for example if you know *exactly* what NTP servers were in use (not "ones you had configured" but which one was primarily chosen by ntpd ('*' mark) and which were secondary comparisons/fallbacks ('+' mark)), that would also be greatly helpful. This would be output from "ntpq -c peers" when run on your NTP server *at or around the time* the incident happened and recovered. What's been provided so far is that "something happened", with reports of clocks going back to year 2000, and other reports of clocks going back to (presumably) epoch time; those reporting it were using either usno.navy.mil, NIST, or Microsoft NTP servers. usno.navy.mil uses dedicated IRIG/AFNOR TCRs boxes, while NIST uses GPS. No idea what Microsoft uses. I asked on a public *IX forum if anyone saw anything NTP-wise that was out of the ordinary and not a single admin saw anything. I also saw nothing anomalous on either of my FreeBSD machines (9.1-PRERELEASE, running base system ntpd 4.2.4p8), but I sync with very specific stratum 1 and stratum 2 servers across the United States. As Mark Andrews from the ISC stated below (read slowly/carefully), ntpd will not allow large clock jumps -- the largest it'll allow out of the box is 1000s (and on some systems like Solaris ntpd, 500s) -- unless you're running with the -g flag (and shame on if you're you doing that). So I'm very surprised by this problem altogether. Can't deny what happened did, but figuring out *why* is important. Also, for Mike Lyon -- I looked at NIST's GPS graphs. Did you notice they have no data for 11/18, 11/19, or 11/20? I find that unnerving, do you not? -- | Jeremy Chadwick jdc(a)koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | On Tue, Nov 20, 2012 at 07:18:45AM -0800, Scott Voll wrote: > Same thing happened to us yesterday. ended up having to reboot > everything after we got time fixed. Major outage. > > Scott > > > On Mon, Nov 19, 2012 at 7:58 PM, Sid Rao <srao(a)ctigroup.com> wrote: > > > We had multiple servers synchronized with Windows/MS time change > > their clock to the year 2000 today. It broke many things, including > > AD authentication. > > > > These servers had been properly synchronized for years. > > > > They were synchronized with Microsoft and NIST NTP servers. > > > > This may not be isolated. > > > > Sid Rao | CTI Group | +1 (317) 262-4677 > > > > On Nov 19, 2012, at 10:29 PM, "George Herbert" > > <george.herbert(a)gmail.com> > > wrote: > > > > > crossreplying to outages list. > > > > > > Is anyone ELSE seeing GPS issues? This could well have been an > > > unrelated issue on that particular PBX. > > > > > > If this was real, then the mother of all infrastructure attacks > > > might be underway... > > > > > > One glitch on tick and tock and one malfunctioning PBX is not > > > sufficient evidence of pattern - much less hostile activity - to > > > induce panic, but it would perhaps be a wise time to check > > > time-related logs? > > > > > > > > > -george > > > > > > On Mon, Nov 19, 2012 at 6:08 PM, Wallace Keith > > > <kwallace(a)pcconnection.com> wrote: > > >> Just got paged with a pbx alarm that had 1970 as the year. By the > > >> time > > I logged in , it was showing 2012. Using GPS for time and date. > > >> > > >> -----Original Message----- > > >> From: Mark Andrews [mailto:marka@isc.org] > > >> Sent: Monday, November 19, 2012 8:42 PM > > >> To: Van Wolfe > > >> Cc: nanog(a)nanog.org > > >> Subject: Re: NTP Issues Today > > >> > > >> > > >> In message < > > CAMeggd4cDQwhxQE_JbvpNR-PKKe9LXqA+KzJ97anHFonjwZhdQ(a)mail.gmail.com> > > >> , Van Wolfe writes: > > >>> Hello, > > >>> > > >>> Did anyone else experience issues with NTP today? We had our > > >>> server times update to the year 2000 at around 3:30 MT, then > > >>> revert back to > > 2012. > > >>> > > >>> Thanks, > > >>> Van > > >> > > >> NTP should be immune from this sort of behaviour unless you did a > > ntpdate at the wrong moment. The clocks should have been marked as insane. > > >> > > >> Mark > > >> -- > > >> Mark Andrews, ISC > > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > > >> PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org > > >> > > >> > > > > > > > > > > > > -- > > > -george william herbert > > > george.herbert(a)gmail.com > > > > > > > > > > > > _______________________________________________ > > Outages mailing list > > Outages(a)outages.org > > https://puck.nether.net/mailman/listinfo/outages > > > _______________________________________________ > Outages mailing list > Outages(a)outages.org > https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages(a)outages.org https://puck.nether.net/mailman/listinfo/outages

1 0

NTP problems - (one) root cause
by Jay Ashworth 20 Nov '12

20 Nov '12

A subscriber to Outages who wishes to remain nameless passes along the pointer to this story: Apparently, either tick or tock got rebooted yesterday, and came up with its local clock set to 2000. And lots of people believed it. https://isc.sans.edu/diary.html?n&storyid=14548 Did you believe it? Why? (Yes, those are just rhetorical questions, intended to make people examine their NTP architecture more closely. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

1 0

AS 2379
by Eric C. Miller 20 Nov '12

20 Nov '12

Does anybody know of a list of BGP communities for AS2379 (EMBARK-WNPK now CenturyLink)? I haven't reached out to Centurylink yet, but I'm used to just finding them through Google Searches. Eric Miller, CCNP Network Engineering Consultant (407) 257-5115

2 1

Re: [outages] NTP Issues Today
by Colin Johnston 20 Nov '12

20 Nov '12

no idea, re sigterm cause checked firewall system logs and could not see cause from that either times are GMT Colin On 20 Nov 2012, at 17:05, Jeremy Chadwick <jdc(a)koitsu.org> wrote: > Colin, > > Signal 15 = SIGTERM, so something intentionally shut ntpd down on your > side. The logs I'd be interested in would be prior to what you've > provided, i.e. what lead to the SIGTERM. > > Also, no timezone is mentioned anywhere in your timestamps, so please > provide that (UTC offset would be best). > > -- > | Jeremy Chadwick jdc(a)koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > On Tue, Nov 20, 2012 at 05:02:06PM +0000, Colin Johnston wrote: >> >> On 20 Nov 2012, at 15:38, Jeremy Chadwick <jdc(a)koitsu.org> wrote: >> >>> I'm still waiting for someone who was affected by this to provide >>> coherent logs from ntpd showing exactly when the time change happened. >>> Getting these, at least on an *IX system, is far from difficult folks. >>> >> >> from firewall ntp logs >> Nov 19 09:58:06 [192.168.0.1.128.176] 2012:11:19-09:58:06 ntpd[21385]: ntpd exiting on signal 15 >> Nov 19 09:58:19 [192.168.0.1.128.176] 2012:11:19-09:58:19 selfmonng[3503]: W check Failed increment ntpd_running counter 3 - 3 >> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W NOTIFYEVENT Name=ntpd_running Level=INFO Id=147 sent >> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W triggerAction: 'cmd' >> Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W actionCmd(+): '/var/mdw/scripts/ntp restart' >> Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 ntpd[24120]: ntpd 4.2.4p8(a)1.1612-o Tue Feb 2 21:46:54 UTC 2010 (1) >> Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 selfmonng[3503]: W child returned status: exit='0' signal='0' >> Nov 19 09:58:35 [192.168.0.1.128.176] 2012:11:19-09:58:35 ntpd[24121]: kernel time sync status change 0001 >> >> was sync'd to 84.25.175.98, stratum 2 at the time I believe >> >> Colin

1 0

Re: [outages] NTP Issues Today
by Colin Johnston 20 Nov '12

20 Nov '12

On 20 Nov 2012, at 15:38, Jeremy Chadwick <jdc(a)koitsu.org> wrote: > I'm still waiting for someone who was affected by this to provide > coherent logs from ntpd showing exactly when the time change happened. > Getting these, at least on an *IX system, is far from difficult folks. > from firewall ntp logs Nov 19 09:58:06 [192.168.0.1.128.176] 2012:11:19-09:58:06 ntpd[21385]: ntpd exiting on signal 15 Nov 19 09:58:19 [192.168.0.1.128.176] 2012:11:19-09:58:19 selfmonng[3503]: W check Failed increment ntpd_running counter 3 - 3 Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W NOTIFYEVENT Name=ntpd_running Level=INFO Id=147 sent Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W triggerAction: 'cmd' Nov 19 09:58:22 [192.168.0.1.128.176] 2012:11:19-09:58:22 selfmonng[3503]: W actionCmd(+): '/var/mdw/scripts/ntp restart' Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 ntpd[24120]: ntpd 4.2.4p8(a)1.1612-o Tue Feb 2 21:46:54 UTC 2010 (1) Nov 19 09:58:25 [192.168.0.1.128.176] 2012:11:19-09:58:25 selfmonng[3503]: W child returned status: exit='0' signal='0' Nov 19 09:58:35 [192.168.0.1.128.176] 2012:11:19-09:58:35 ntpd[24121]: kernel time sync status change 0001 was sync'd to 84.25.175.98, stratum 2 at the time I believe Colin

1 0

Technical help required to check routing or filtering of Gobal IP routing range: 1.128.0.0 - 1.159.255.255 in the Level 3 Network Space.
by Attila Vekas 20 Nov '12

20 Nov '12

Hi All, I need technicial assistance with either a routing or ip restrication problem impacting our mobile ip customers in Australia. Customers using our Mobile Network are allocated an address in the 1.128.0.0 - 1.159.255.255 range to allow communication on the internet. I have a customer's who can't reach websites hosted oversea where the like cause appears to be some were in the Level 3 routing domain (I suspect). 1. Customer A trying to get www.readingeggs.com.au fails when using a Mobile Internet connection. C:\Documents and Settings\c832677>tracert www.readingeggs.com.au Tracing route to readingeggs.com.au [209.251.186.131] over a maximum of 30 hops: 1 458 ms 419 ms 539 ms 10.5.81.50 2 * * * Request timed out. 3 * * * Request timed out. 4 350 ms 659 ms 659 ms bundle-ether12.pie8.perth.telstra.net[120.151.2 55.17] 5 578 ms 629 ms 449 ms bundle-ether1.pie-core1.perth.telstra.net[203.5 0.6.221] 6 448 ms 509 ms 539 ms bundle-ether6.way-core4.adelaide.telstra.net[20 3.50.11.16] 7 457 ms 549 ms 529 ms bundle-ether9.exi-core1.melbourne.telstra.net[2 03.50.11.93] 8 468 ms 509 ms 539 ms bundle-ether12.chw-core2.sydney.telstra.net[203 .50.11.74] 9 458 ms 709 ms 559 ms bundle-ether1.oxf-gw2.sydney.telstra.net[203.50 .6.90] 10 448 ms 519 ms 789 ms 203.50.13.174 11 597 ms 759 ms 709 ms i-0-0-0-0.paix-core01.bx.telstraglobal.net[202. 84.140.145] 12 649 ms 659 ms 730 ms i-0-0-0-0.eqnx-core01.bi.telstraglobal.net[202. 84.140.142] 13 579 ms 719 ms 709 ms i-0-0-0-3.eqnx03.bi.telstraglobal.net[202.84.25 1.126] 14 599 ms 689 ms 689 ms l3-peer.eqnx03.pr.telstraglobal.net[134.159.61. 6] 15 618 ms 689 ms 689 ms ae-22-70.car2.SanJose1.Level3.net[4.69.152.68] 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. A successful traceroute to www.readingeggs.com is shown below and was obtained from a fix-line connection to the internet: C:\Documents and Settings\c832677>tracert www.readingeggs.com.au Tracing route to readingeggs.com.au [209.251.186.131] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 10.0.0.1 2 1 ms 1 ms 1 ms gigabitethernet2-16.lon69.melbourne.telstra.net[139.130.43.29] 3 4 ms 2 ms 3 ms bundle-ether3.exi-core1.melbourne.telstra.net [203.50.80.1] 4 23 ms 23 ms 23 ms bundle-ether12.chw-core2.sydney.telstra.net[203 .50.11.74] 5 22 ms 23 ms 23 ms bundle-ether1.oxf-gw2.sydney.telstra.net[203.50 .6.90] 6 16 ms 16 ms 16 ms tengigabitethernet14-0.sydo-core01.sydney.reach.com [203.50.13.42] 7 159 ms 158 ms 158 ms i-0-6-2-0.paix-core01.bx.telstraglobal.net[202. 84.140.90] 8 193 ms 192 ms 192 ms i-0-7-2-0.eqnx-core01.bi.telstraglobal.net[202. 84.140.30] 9 193 ms 193 ms 193 ms i-0-0-0-1.eqnx03.bi.telstraglobal.net[202.84.25 1.50] 10 208 ms 191 ms 208 ms l3-peer.eqnx03.pr.telstraglobal.net[134.159.61. 6] 11 209 ms 209 ms 209 ms ae-42-90.car2.SanJose1.Level3.net[4.69.152.196] 12 193 ms 193 ms 193 ms DATA-RETURN.car2.SanJose1.Level3.net[4.53.18.13 4] 13 234 ms 234 ms 234 ms t0-0-0-1.br1.stc.terremark.net[66.165.161.169] 14 235 ms 234 ms 234 ms po14.br1.mia.terremark.net [66.165.160.225] 15 359 ms 248 ms 250 ms t8-1.gw1.mia.terremark.net [66.165.161.82] 16 234 ms 234 ms 237 ms 66.165.170.14 17 229 ms 229 ms 229 ms 72.46.239.94 18 233 ms 233 ms 232 ms 209.251.186.131 In the above examples the source IP for the failed traceroute from the Australia's Mobile Network was a 1.126.42.153 address (Telstra) and for the working traceroute from the fix-line it was 139.130.43.29. It appears the path is being treated differently between routers: ae-22-70.car2.SanJose1.Level3.net [4.69.152.68] & ae-42-90.car2.SanJose1.Level3.net [4.69.152.196] from the Telstra Global Router. I am looking for network help and confirmation that the source network 1.128.0.0 - 1.159.255.255 is being routed correctly back to Telstra's network in Australia correctly on the SanJose - Level3 routers. Also check if any bogan filtering is in the network that could be blocking the source ranges from reaching the hosting URL. Regards, Attila Vekas Telstra

3 2

Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker
by Constantine A. Murenin 20 Nov '12

20 Nov '12

Dear NANOG@, I came across an interesting problem in trying to find an affordable KVM provider with IPv6 support. It seems like several rather major and reputable providers in the value sector do claim to have IPv6 support, but once you get your IPv6 addresses or subnets from them, you might be rather disappointed. == Example of edis.at == edis.at gives you an IPv4 address of, for example, 158.255.21x.xxx, and the IPv6 /112 that you get is 2a03:f80:ed15:158:255:21x:xxx:0/112 (really a /48), with 2a03:0f80:ed15::1 as the gateway. I've tried contacting them in an effort to receive any kind of a "proper" IPv6 address without the plaintext IPv4 embedment, but they've given me all sorts of crazy and (IMHO) far-sketched excuses; from not wanting to maintain a separate database of IPv6 addresses/subnets, and from lack of software provisioning support; to supposedly RIPE and/or edis' upstream providers requiring public whois entries for any /64's that edis.at would allocate for their customers, and to not having control of the underlying routers/switches/firewalls in any but one of their 13+ datacentres that thus makes creating 2^16 separate routes problematic. ??? All I'm asking for, are sane and short addresses and/or a saner /112, don't really care if it's still a shared /48 underneath. == Example of buyvm.net == On the other hand, buyvm.net claims to give you 16 IPv6 addresses. This is the kind of addresses that they give out (some consecutive 4 out of the 16 provided addresses listed): 2607:f358:0001:fed5:0022:a124:fe56:xxxx, 2607:f358:0001:fed5:0022:f6a6:dffe:xxxx, 2607:f358:0001:fed5:0022:c6a3:7826:xxxx, 2607:f358:0001:fed5:0022:654f:964d:xxxx. This is the response I've got from buyvm.net when trying to ask for some reasonable (shorter) addresses or a whole subnet instead: << We cannot offer that at this time as we have to store these IPs in MySQL which would slow down the database. >> WTF? Surely offering some 16 random addresses that are 128-bits long doesn't slow down MySQL, but offering one single, short and abbreviatable /64 or /112 subnet would. I'm puzzled! == == (HE's tunnelbroker.net, on the other hand, has no problem in giving out IPv6 addresses that, when abbreviated, can be represented by the same number of ASCII characters as an IPv4 address; for free, might I add.) == == Am _I_ supposed to have a MySQL database with the list of the IPv6 addresses that my virtual private servers have been assigned? Wouldn't it "slow down MySQL", so to speak? :-) What's your take on this? Since IPv6 is still a very low priority for many of the hosting providers (edis.at cited a rather negligible amount of IPv6 traffic, so, they argue that, as a small shop, they simply can't justify spending much R&D on further improving something that they consider already supported and not broken in the first place), would I be crazy to opt-out of such pathetic IPv6 support, and sign back up with a tunnelbroker from HE.net instead? (In fact, my preliminary tests show that IPv6 latency between Austria and Fremont, London and Moscow are either the same or slightly better when using the HE.net tunnelbroker in Prague, instead of edis.at native IPv6 support; bandwidth doesn't seem to be affected, either.) A little extra latency (only potentially) and MTU reduction by 20 bytes are the only negatives, right? Yet on the positive side, I'll get a proper and short /64 or /48 subnet, proper rDNS support, guaranteed proper intermediate hops with proper rDNS entries and no stupid hops impeding traceroute, potentially much better IPv6 routing/peering/latency, and short or custom ...:face:b00c::-style addresses to my liking; and, last but not least, a higher number of potential KVM providers to choose from, since I wouldn't require any native IPv6 support with such an arrangement. Comparing these options, seems like on the KVM hoster side, a blanket "IPv6 support" (with no /48 or /64 promises) is thus basically a useless concept anyways, and, at this time, should not even be sought? Any thoughts? Did I miss anything? In summary, I thought I have to have native IPv6 support in any new VPS that I buy, but looks like using a tunnelbroker might just be a much cleaner and better solution anyways. P.S. Does anyone other than me object to calling /48 subnets with allocations such as 2a03:f80:ed15:158:255:21x:xxx:0/112 as native IPv6 in this context of VPS hosting? How should such addresses/subnets/arrangements be called? Best regards, Constantine.

11 10

fiber termination tools
by Jon Lewis 20 Nov '12

20 Nov '12

We've always done our own fiber termination in-house using Corning Unicam (currently Unicam Pretium) tool kits and ends. Over the years I've dealt with fiber (primarily 62.5um mm FDDI), I've noticed that fiber seems to come in two "styles". Some lets me strip the buffer and coating easily in separate steps using the buffer/coating dual-notch mechanical stripper from our Corning tool kit. Some, it seems the buffer and coating are fused and the coating comes off with the buffer, but because both are being stripped at the same time, much more pulling force is needed, and the buffer/coating has to be removed in small steps or the fiber breaks :( First, I wonder if anyone knows why this is? Second, I wonder if a thermal stripper would help and is preferable to a strictly mechanical stripper? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

1 0

Re: NTP Issues Today
by Warren Bailey 20 Nov '12

20 Nov '12

Or you could just concede the fact that the navy is playing with time travel again. From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Scott Weeks <surfer(a)mauigateway.com> Date: 11/19/2012 3:52 PM (GMT-08:00) To: nanog(a)nanog.org Subject: Re: NTP Issues Today On 11/19/12 6:32 PM, "Scott Weeks" <surfer(a)mauigateway.com> wrote: >--- vanwolfe(a)gmail.com wrote: >From: Van Wolfe <vanwolfe(a)gmail.com> > >Did anyone else experience issues with NTP today? We had our server >times update to the year 2000 at around 3:30 MT, then revert back to 2012. >----------------------------------------- >You need to provide more information. For example, what NTP >source are you using? ------------------------------------------ --- chaynes(a)centracomm.net wrote: From: Clay Haynes <chaynes(a)centracomm.net> I can confirm this had happened on one of my test servers - it was pointing to tick.usno.navy.mil and tock.usno.navy.mil at the time. ------------------------------------------- That's not a very diverse set of NTP servers. In the future if you think it might be an outage, you might try on the 'outages' list: http://puck.nether.net/mailman/listinfo/outages For this one, you might ask the server contact if there was a problem: http://support.ntp.org/bin/view/Servers/TockUsnoNavyMil That assumes you've done your homework first and made sure it wasn't something in your network. scott

1 0