Re: Fiber terminations -- UPC vs APC
+1 here on going all APC on the panels, note we run a gpon network so making that choice was fairly easy for us. You do end up having to use a lot of sc or lc/upc - sc/apc patch cables on the colo equipment side of things but everything out in the field is 100% sc/apc. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / car...@race.com / http://www.race.com -Original Message- From: Lamar Owen lo...@pari.edu Date: Monday, November 19, 2012 2:30 PM To: Jeff Kell jeff-k...@utc.edu Cc: nanog@nanog.org nanog@nanog.org Subject: Re: Fiber terminations -- UPC vs APC On Nov 19, 2012, at 4:37 PM, Jeff Kell wrote: Looking for some guidance/references on the use of UPC versus APC terminations on fiber cabling. Traditionally we have done all of our fiber plant targeting data usage with UPC connectors. We are also looking at proposals for fiber distribution plant for video, and the possibility of using some of the existing fiber plant for that purpose; as well as any new fiber plant that gets installed for video potentially as data. The video folks are set, determined, and insistent that they need APC terminations. APC is pretty much the standard for high-power video distribution, and for very good reasons. The return loss is much better for APC than for UPC, for instance, and that can be very significant depending upon the equipment being used to drive. Much video distribution gear, including passive splitters and EDFA's, are only available with APC connectors. Mating an APC to a UPC will result in an 'air-gap attenuator' being created, and that may be a problem. A significant problem for some gear, in fact. Really high-power long-haul gear may need APC as well, even for networking stuff. Your choice boils down to parallel plants or only APC with UPC jumpers for non-APC equipment. You really really don't want to have any UPC connectors in a really high-power path that needs APC all the way; I have actually seen some warranty statements, for some older equipment, primarily EDFA modules, that indicate that the warranty would be voided if any non-APC connectors were in the path anywhere. The reflections from a UPC end can detune some of these lasers, and can, in theory at least, cause permanent transmitter damage that won't be under warranty. You could, though, provision half APC and half UPC, since the color coding is pretty clear. You can even use, say, all LC on your UPC patches and all SC on you APC patches or similar, and get both with little danger of intermating. I think I'd personally rather just provision all APC in the backbone fiber runs and install APC to UPC distribution runs to your network gear. But you'll have to train people to always plug green connectors into green connectors, and blue into blue, and never should green and blue mix. smime.p7s Description: S/MIME cryptographic signature
Big day for IPv6 - 1% native penetration
Hi, It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T.
Re: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker
On Sun, 18 Nov 2012 21:40:45 -0800 Owen DeLong o...@delong.com wrote: Setting up a proper IPv6 subnet and unique gateway for each VM is probably insane, but, potentially less insane than some other alternatives. I second that! I give out a proper configured /64 to every customer regardless of he has one, two or more VMs in his network. The alternatives did not work for us, furthermore scaling the networks is reduced to drop in more VMs until the /64 runs out of addresses (read: never) OR the situation calls for other setups anyway. Receiving a /112 should make one at least thinking about the underlying network design for a minute. It just looks awkward! Cheers Dan
Re: Big day for IPv6 - 1% native penetration
On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpfVNAIV5UfP.pgp Description: PGP signature
Re: Big day for IPv6 - 1% native penetration
It is entirely possible that Google's numbers are artificially low for a number of reasons. Owen On Nov 20, 2012, at 5:31 AM, Aaron Toponce aaron.topo...@gmail.com wrote: On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
Re: Big day for IPv6 - 1% native penetration
Or artificially high ... On Tue, Nov 20, 2012 at 8:45 AM, Owen DeLong o...@delong.com wrote: It is entirely possible that Google's numbers are artificially low for a number of reasons. Owen On Nov 20, 2012, at 5:31 AM, Aaron Toponce aaron.topo...@gmail.com wrote: On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Big day for IPv6 - 1% native penetration
APNIC labs have an interesting set of numbers on IPv6 uptake as well. http://labs.apnic.net/measureipv6/ On Tue, 20 Nov 2012, Owen DeLong wrote: It is entirely possible that Google's numbers are artificially low for a number of reasons. Owen On Nov 20, 2012, at 5:31 AM, Aaron Toponce aaron.topo...@gmail.com wrote: On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o wfms
RE: Big day for IPv6 - 1% native penetration
Tomas Podermanski wrote: Hi, It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) T. Or one could look at it as; despite 16 years of lethargy and lack of deployment by access networks, the traffic still finds a way. ;) Tony
Re: Big day for IPv6 - 1% native penetration
So, I assume 6in4 tunnels like HE.net are included in the native percentage? Oliver - Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux On Tue, Nov 20, 2012 at 9:02 AM, William F. Maton Sotomayor wma...@ottix.net wrote: APNIC labs have an interesting set of numbers on IPv6 uptake as well. http://labs.apnic.net/measureipv6/ On Tue, 20 Nov 2012, Owen DeLong wrote: It is entirely possible that Google's numbers are artificially low for a number of reasons. Owen On Nov 20, 2012, at 5:31 AM, Aaron Toponce aaron.topo...@gmail.com wrote: On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o wfms
Re: Big day for IPv6 - 1% native penetration
Hi, So, I assume 6in4 tunnels like HE.net are included in the native percentage? As the traffic is delivered as native traffic to Google I don't think Google can even see that there is a tunnel between them and the user. They might see a lower MTU, but to Google the traffic is native IPv6. - Sander
Re: Big day for IPv6 - 1% native penetration
Dr. Frederick Frankenstein: LIFE! DO YOU HEAR ME? GIVE MY CREATION... LIFE! On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013.
Re: Big day for IPv6 - 1% native penetration
* Oliver Garraux So, I assume 6in4 tunnels like HE.net are included in the native percentage? Probably. Fortunately, they are a drop in the ocean (at least from my point of view). -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Re: Big day for IPv6 - 1% native penetration
On Nov 20, 2012, at 7:06 AM, Sander Steffann san...@steffann.nl wrote: Hi, So, I assume 6in4 tunnels like HE.net are included in the native percentage? As the traffic is delivered as native traffic to Google I don't think Google can even see that there is a tunnel between them and the user. They might see a lower MTU, but to Google the traffic is native IPv6. - Sander That's only really true of the 6in4 (tunnel broker) tunnels. The 6to4 traffic that comes through our 6to4 or any other 6to4 gateways, OTOH, will have 2002::/16 addresses which makes it just as obvious as Teredo. Owen
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On Tue, Nov 20, 2012 at 2:35 AM, Derek Ivey de...@derekivey.com wrote: I saw this on Reddit and thought it was fascinating. I figured I'd share it here too since no one else did. http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-manhattan-hurricane-sandy hey lookie! 'free uprades'! also, one wonders what the bill is for such upgrades, and what the implications are for state-run-disaster relief vs national-level-disaster-relief? Also, how much of the VZ issue (phone stuff) is going to end up being caught in VZ's financials vs disaster-relief-funds ? -chris
Re: Big day for IPv6 - 1% native penetration
Hello, On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski tpo...@cis.vutbr.cz wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ? Paul signature.asc Description: PGP signature
Re: NTP Issues Today
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.herb...@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 kwall...@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:ma...@isc.org] Sent: Monday, November 19, 2012 8:42 PM To: Van Wolfe Cc: nanog@nanog.org Subject: Re: NTP Issues Today In message cameggd4cdqwhxqe_jbvpnr-pkke9lxqa+kzj97anhfonjwz...@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: ma...@isc.org -- -george william herbert george.herb...@gmail.com
RE: 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.
http://lookingglass.level3.net/ Should get U what U need. Robert D. Scottrob...@ufl.edu Senior Network Engineer352-273-0113 Phone UF Information Technology 352-392-2061 CNS Phone Tree CNS - Network Services 352-273-0743 FAX University of Florida 352-294-3571 FLR NOC Florida Lambda Rail321-663-0421 Cell Gainesville, FL 32611 3216630...@messaging.sprintpcs.com -Original Message- From: Attila Vekas [mailto:attilave...@gmail.com] Sent: Tuesday, November 20, 2012 1:18 AM To: NANOG@nanog.org Subject: 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. 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\c832677tracert 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\c832677tracert www.readingeggs.com.au Tracing route to readingeggs.com.au [209.251.186.131] over a maximum of 30 hops: 11 ms1 ms1 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] 423 ms23 ms23 ms bundle-ether12.chw-core2.sydney.telstra.net[203 .50.11.74] 522 ms23 ms23 ms bundle-ether1.oxf-gw2.sydney.telstra.net[203.50 .6.90] 616 ms16 ms16 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
Re: Big day for IPv6 - 1% native penetration
On Nov 20, 2012, at 08:45 , Owen DeLong o...@delong.com wrote: It is entirely possible that Google's numbers are artificially low for a number of reasons. AMS-IX publishes stats too: https://stats.ams-ix.net/sflow/ This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. Why do you think Google's numbers are lower than the real total? -- TTFN, patrick On Nov 20, 2012, at 5:31 AM, Aaron Toponce aaron.topo...@gmail.com wrote: On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o
Re: 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.
G'day! On Mon, Nov 19, 2012 at 10:18 PM, Attila Vekas attilave...@gmail.com wrote: Regards, Attila Vekas Telstra I'd say its AS23148 / Terremark with a bogon filter. your fixed line traceroute shows the next-hop being the connection between level3 and AS23148. 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.134] Cheers, Tom
Re: NTP Issues Today
In a message written on Mon, Nov 19, 2012 at 04:21:55PM -0700, Van Wolfe wrote:
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.
I'm surprised the various time geeks aren't all posting their logs, so
I'll kick off:
/tmp/parse-peerstats.pl peerstats.20121119
56250 76367.354 192.5.41.41 91b4 -378691200.312258363 0.088274002 0.014835425
0.263515353
56250 77391.354 192.5.41.41 91b4 -378691200.312258363 0.088274002 0.018668790
0.263749719
56250 78204.354 192.5.41.40 90b4 -378691200.785377324 0.088179350 0.014812585
0.263668835
56250 78416.355 192.5.41.41 91b4 -378691200.785974681 0.088312507 0.014832943
0.209966600
56250 79229.355 192.5.41.40 90b4 -378691200.785377324 0.088179350 0.018668723
378691200.785523713
56250 79442.355 192.5.41.41 91b4 -378691200.785974681 0.088312507 0.018689918
378691200.786114931
Or in more human readable form:
/tmp/parse-peerstats.pl peerstats.20121119
192.5.41.41 off by -378691200.312258363
192.5.41.41 off by -378691200.312258363
192.5.41.40 off by -378691200.785377324
192.5.41.41 off by -378691200.785974681
192.5.41.40 off by -378691200.785377324
192.5.41.41 off by -378691200.785974681
The script, if you want to run against your own stats:
#!/usr/bin/perl
while () {
chomp;
($day, $second, $addr, $status, $offset, $delay, $disp, $skew) = split;
if (($offset 10) || ($offset -10)) {
#print $addr off by $offset\n; # More human friendly
print $_\n; # Full details
}
}
It just looks for servers off by more than 10 econds and then prints
the line. 378691200 seconds is ~12 years, which lines up with the
year 2000 dates some are reporting.
The IP's are tick.usno.navy.mil and tock.usno.navy.mil.
I can confirm from my vantage point that tick and tock both went about
12 years wrong on Nov 19th for a bit, I can also report that my NTP
server with sufficient sources correctly determined they were haywire
and ignored them.
If your machines switched dates yesterday it probably means you're
NTP infrastructure is insufficiently peered and diversified.
--
Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
pgp9aMW4WaOuy.pgp
Description: PGP signature
Re: Big day for IPv6 - 1% native penetration
On 20 November 2012 16:05, Patrick W. Gilmore patr...@ianai.net wrote: On Nov 20, 2012, at 08:45 , Owen DeLong o...@delong.com wrote: It is entirely possible that Google's numbers are artificially low for a number of reasons. AMS-IX publishes stats too: https://stats.ams-ix.net/sflow/ This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. Why do you think Google's numbers are lower than the real total? They are also different stats which is why they give such different numbers. In a theoretical world with evenly distributed traffic patterns if 1% of users were IPv6 enabled it would require 100% of content to be IPv6 enabled before your traffic stats would show 1% of traffic going over IPv6. If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement. - Mike
Re: Big day for IPv6 - 1% native penetration
On Nov 20, 2012, at 11:42 , Mike Jones m...@mikejones.in wrote: On 20 November 2012 16:05, Patrick W. Gilmore patr...@ianai.net wrote: On Nov 20, 2012, at 08:45 , Owen DeLong o...@delong.com wrote: It is entirely possible that Google's numbers are artificially low for a number of reasons. AMS-IX publishes stats too: https://stats.ams-ix.net/sflow/ This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. Why do you think Google's numbers are lower than the real total? They are also different stats which is why they give such different numbers. In a theoretical world with evenly distributed traffic patterns if 1% of users were IPv6 enabled it would require 100% of content to be IPv6 enabled before your traffic stats would show 1% of traffic going over IPv6. If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement. There is even more complexity. Remember the 6-to-4 stuff? Suppose a user on Network A used a tunnel broker on HE, and his traffic passed over AMS-IX encapsulated in v4? He would show up as v4 to AMS-IX and v6 to Google. Lies, damned lies, and graphs. :) -- TTFN, patrick
Re: [outages] NTP Issues Today
On 20 Nov 2012, at 15:38, Jeremy Chadwick j...@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@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
Re: NTP Issues Today
On Tue, Nov 20, 2012 at 11:38 AM, Leo Bicknell bickn...@ufp.org wrote: If your machines switched dates yesterday it probably means you're NTP infrastructure is insufficiently peered and diversified. If you take anything away from this thread, this is it -Steve
RE: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
From: Christopher Morrow [mailto:morrowc.li...@gmail.com] http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-m anhattan-hurricane-sandy hey lookie! 'free uprades'! [WEG] Better that than we're going to replace all of this old technology with exactly the same stuff because that's what the standards document says to do like happened in the rebuilding efforts for Katrina. I remember someone presenting about that rebuilding effort during NANOG years ago, and I asked about opportunities for improvement and upgrades and was really depressed at the missed opportunity it represented as they confirmed that they were in fact laying new copper... Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: [outages] NTP Issues Today
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 j...@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 j...@koitsu.org | | UNIX Systems Administratorhttp://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 +, Colin Johnston wrote: On 20 Nov 2012, at 15:38, Jeremy Chadwick j...@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@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
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On Tue, Nov 20, 2012 at 11:55 AM, George, Wes wesley.geo...@twcable.com wrote: From: Christopher Morrow [mailto:morrowc.li...@gmail.com] http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-m anhattan-hurricane-sandy hey lookie! 'free uprades'! [WEG] Better that than we're going to replace all of this old technology with exactly the same stuff because that's what the standards document says to do like happened in the rebuilding efforts for Katrina. I remember someone presenting about that rebuilding effort during NANOG years ago, and I asked about opportunities for improvement and upgrades and was really depressed at the missed opportunity it represented as they confirmed that they were in fact laying new copper... yea. it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Also, now VZ can sell the copper to all the rest of us for use in fiber camouflage!
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On 11/20/12 9:10 AM, Christopher Morrow wrote: On Tue, Nov 20, 2012 at 11:55 AM, George, Wes wesley.geo...@twcable.com wrote: From: Christopher Morrow [mailto:morrowc.li...@gmail.com] http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-m anhattan-hurricane-sandy hey lookie! 'free uprades'! [WEG] Better that than we're going to replace all of this old technology with exactly the same stuff because that's what the standards document says to do like happened in the rebuilding efforts for Katrina. I remember someone presenting about that rebuilding effort during NANOG years ago, and I asked about opportunities for improvement and upgrades and was really depressed at the missed opportunity it represented as they confirmed that they were in fact laying new copper... yea. it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Also, now VZ can sell the copper to all the rest of us for use in fiber camouflage! 1200 pair is 5.5lbs per foot. That's somewhere in the neighborhood of $100k per mile at retail scrap prices.
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On 11/20/2012 12:10 PM, Christopher Morrow wrote: it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Be careful of what you wish for, Yes, you get fiber from the CO to the Building... however there is also a very big side-effect... Verizon is not obligated to provide equal access to Competitive providers (CLECs) on this Fiber Thus, you are also looking a significantly reduced competition. which is very likely to equate to a higher cost for end users. :) Faisal Imtiaz Snappy Internet Telecom
Re: Big day for IPv6 - 1% native penetration
On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski tpo...@cis.vutbr.cz wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ? Purely anecdotally, I can say: Yes. Atleast in my case I have native IPv6 at home and via my mobile devices, but not at my client sites. *Sidenote: That's why I am at those client sites, helping 'fix' that. ;) ... * /TJ
Re: NTP Issues Today
On 11/19/12 6:08 PM, Wallace Keith 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. I use GPS for my NTP server and didn't notice anything, but it's PPS disciplined after initial sync so it doesn't matter as long as the pulse keeps going. ntp0# ntpq -pn remote refid st t when poll reach delay offset jitter == 127.127.1.0 .LOCL. 12 l 10 64 3770.0000.000 0.015 +216.171.124.36 .ACTS. 1 u 167 1024 377 26.8012.387 0.015 +127.127.20.0.GPS.0 l 45 64 3770.000 -0.048 0.015 o127.127.22.0.PPS.0 l 27 64 3770.000 -0.048 0.015 ~Seth
Re: Plages d'adresses IP Orange
On 11/19/12 9:16 AM, Jamie Bowden wrote: Actually, this is kind of an interesting aside. Last time I checked, Canada counts as North America and large parts of Quebec are inhabited by folks who don't speak much, if any, English. Having said that, I can't recall having seen any Quebecois posting in French here, but I find it hard to believe those folks don't have use for a list like this. Quebecois French and French aren't exactly the same. My dad once had to order le pancakes for breakfast because the waitress didn't understand le crepes. ~Seth
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz fai...@snappydsl.net wrote: On 11/20/2012 12:10 PM, Christopher Morrow wrote: it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Be careful of what you wish for, Yes, you get fiber from the CO to the Building... however there is also a very big side-effect... Verizon is not obligated to provide equal access to Competitive providers (CLECs) on this Fiber Thus, you are also looking a significantly reduced competition. which is very likely to equate to a higher cost for end users. right, so in the end vz gets what it wants... a return to monopoly. conspiracy theories about verizon starting the floods?
AS 2379
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
Re: Big day for IPv6 - 1% native penetration
I've found myself becoming a snob about IPv6. I almost look down on IPv4-only networks in the same way that I won't go see a film that isn't projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to see the adoption rate edging up. However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me. I keep pestering my home ISP about turning it on (since their network is now 100% DOCSIS 3), but they just seem to think I'm making up words. One can hope, though. Blair On Tue, Nov 20, 2012 at 11:53 AM, TJ trej...@gmail.com wrote: On Tue, 20 Nov 2012 10:14:18 +0100 Tomas Podermanski tpo...@cis.vutbr.cz wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) Funny enough, the peaks are indicating... week-ends ! Do people use more google during the WE, or do they have more IPv6 @ home ? Purely anecdotally, I can say: Yes. Atleast in my case I have native IPv6 at home and via my mobile devices, but not at my client sites. *Sidenote: That's why I am at those client sites, helping 'fix' that. ;) ... * /TJ
Re: AS 2379
On Tue, Nov 20, 2012 at 1:24 PM, Eric C. Miller e...@ericheather.com wrote: 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. http://onesc.net/communities/ bgp communities onesc see AS209. Eric Miller, CCNP Network Engineering Consultant (407) 257-5115
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On 11/20/12 10:20 AM, Christopher Morrow wrote: On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz fai...@snappydsl.net wrote: On 11/20/2012 12:10 PM, Christopher Morrow wrote: it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Be careful of what you wish for, Yes, you get fiber from the CO to the Building... however there is also a very big side-effect... Verizon is not obligated to provide equal access to Competitive providers (CLECs) on this Fiber Thus, you are also looking a significantly reduced competition. which is very likely to equate to a higher cost for end users. right, so in the end vz gets what it wants... a return to monopoly. conspiracy theories about verizon starting the floods? The pressure on the regulatory front doesn't increase until the pain becomes acute...
Re: Big day for IPv6 - 1% native penetration
On 20 Nov 2012, at 16:42, Mike Jones m...@mikejones.in wrote: If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement. Which ties in with the 50% or so figure you can see at http://6lab.cisco.com/stats/. tim
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On 11/20/2012 1:20 PM, Christopher Morrow wrote: On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz fai...@snappydsl.net wrote: On 11/20/2012 12:10 PM, Christopher Morrow wrote: it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Be careful of what you wish for, Yes, you get fiber from the CO to the Building... however there is also a very big side-effect... Verizon is not obligated to provide equal access to Competitive providers (CLECs) on this Fiber Thus, you are also looking a significantly reduced competition. which is very likely to equate to a higher cost for end users. right, so in the end vz gets what it wants... a return to monopoly. conspiracy theories about verizon starting the floods? No Conspiracy theories... just the simple facts on where things stand, based on current regulatory environment. (I / We have no horse in this race) Faisal Imtiaz Snappy Internet Telecom.
Re: NTP Issues Today
After some private replies, I'm going to reply to my own post with some information here. It appears many people don't understand how the NTP protocol works. I suspect many people have configured a primary and a backup NTP server on many of their devices. It turns out this is the _WORST_ possible configuration if you want accurate time: http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3. To protect against two falseticking servers (tick and tock, as we saw on the 19th) you need _FIVE_ servers minimum configured if they are both in the list. More importantly, if you want to protect against a source (GPS, CDMA, IRIG, WWIV, ACTS, etc) false ticking, you need a minimum of _FOUR_ different source technologies in the list as well. It's not hard, my box that I posted the logs from peers with 18 servers using 8 source technologies, all freely available on the Internet... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpTEbSQgVa9z.pgp Description: PGP signature
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
- Original Message - From: Christopher Morrow morrowc.li...@gmail.com On Tue, Nov 20, 2012 at 2:35 AM, Derek Ivey de...@derekivey.com wrote: I saw this on Reddit and thought it was fascinating. I figured I'd share it here too since no one else did. http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-manhattan-hurricane-sandy hey lookie! 'free upgrades'! Not having yet read the piece, I assume the upgrades are the same thing that you'd get if you tried, today, to warranty a 5 year old 250GB Seagate HD: They'd send you a 750G or 1T, simply because they don't have anything smaller in stock. (If your system is embedded, and won't talk to larger drives, their apologies. :-) It's likely the same thing happens here: we don't have that older gear, so you get the newer stuff with our compliments. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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
NTP problems - (one) root cause
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?nstoryid=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 j...@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
Re: NTP Issues Today
- Original Message - From: Leo Bicknell bickn...@ufp.org To protect against two falseticking servers (tick and tock, as we saw on the 19th) you need _FIVE_ servers minimum configured if they are both in the list. More importantly, if you want to protect against a source (GPS, CDMA, IRIG, WWIV, ACTS, etc) false ticking, you need a minimum of _FOUR_ different source technologies in the list as well. It's not hard, my box that I posted the logs from peers with 18 servers using 8 source technologies, all freely available on the Internet... I'm curious, Leo, what your internal setup looks like. Do you have an internal pair of masters, all slaved to those externals and one another, with your machines homed to them? Full mesh? Or something else? In my last big gig, it was recommended to me that I have all the machines which had to speak to my DBMS NTP *to it*, and have only it connect to the rest of my NTP infrastructure. It coming unstuck was of less operational impact than *pieces of it* going out of sync with one another... Cheers, -- jra -- Jay R. Ashworth Baylink j...@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
Re: NTP Issues Today
On Nov 20, 2012, at 2:28 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Leo Bicknell bickn...@ufp.org To protect against two falseticking servers (tick and tock, as we saw on the 19th) you need _FIVE_ servers minimum configured if they are both in the list. More importantly, if you want to protect against a source (GPS, CDMA, IRIG, WWIV, ACTS, etc) false ticking, you need a minimum of _FOUR_ different source technologies in the list as well. It's not hard, my box that I posted the logs from peers with 18 servers using 8 source technologies, all freely available on the Internet... I'm curious, Leo, what your internal setup looks like. Do you have an internal pair of masters, all slaved to those externals and one another, with your machines homed to them? Full mesh? Or something else? In my last big gig, it was recommended to me that I have all the machines which had to speak to my DBMS NTP *to it*, and have only it connect to the rest of my NTP infrastructure. It coming unstuck was of less operational impact than *pieces of it* going out of sync with one another... here's a sample ntp config from one of my systems. -- snip -- # Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). server 0.fedora.pool.ntp.org server 1.fedora.pool.ntp.org server 2.fedora.pool.ntp.org server 3.fedora.pool.ntp.org # server 0.us.pool.ntp.org iburst maxpoll 9 server 1.us.pool.ntp.org iburst maxpoll 9 server 2.us.pool.ntp.org iburst maxpoll 9 server 129.250.35.250 iburst maxpoll 9 server 129.250.35.251 iburst maxpoll 9 -- snip -- You can audit its operation like this: nat:~$ ntpq -p -n -c ass remote refid st t when poll reach delay offset jitter == -129.250.35.250 164.244.221.197 2 u 68 512 377 19.248 -0.135 3.195 +129.250.35.251 192.5.41.40 2 u 439 512 377 41.8171.109 15.660 -206.57.44.17204.123.2.5 2 u 126 512 377 37.133 -6.443 9.631 +4.53.160.75 209.81.9.7 2 u 48 512 377 25.2091.551 8.804 -64.73.32.135192.5.41.41 2 u 349 512 377 23.418 -0.703 1.721 *50.116.38.157 64.250.177.145 2 u 380 512 377 43.0211.267 2.136 +208.87.221.228 10.0.22.49 2 u 517 512 377 92.0000.974 0.678 -206.212.242.132 128.252.19.1 2 u 323 512 377 21.781 -2.873 1.304 +38.229.71.1 204.123.2.72 2 u 211 512 377 21.977 -0.055 2.274 ind assid status conf reach auth condition last_event cnt === 1 39973 931a yes yes none outlyersys_peer 1 2 39974 941a yes yes none candidatesys_peer 1 3 39975 9324 yes yes none outlyer reachable 2 4 39976 942a yes yes none candidatesys_peer 2 5 39977 931a yes yes none outlyersys_peer 1 6 39978 961a yes yes none sys.peersys_peer 1 7 39979 9414 yes yes none candidate reachable 1 8 39980 931a yes yes none outlyersys_peer 1 9 39981 941a yes yes none candidatesys_peer 1 What you would have seen is a falseticker from the impacted clocks. This is a fairly reasonable setup. I've also been looking at an item like this: http://www.netburnerstore.com/ProductDetails.asp?ProductCode=PK70EX-NTP which is about $300 + misc parts. Should be well worth it to avoid a 'major outage' that some folks had with needing to reboot their servers, etc. - Jared
RE: Big day for IPv6 - 1% native penetration
Mike Jones wrote: On 20 November 2012 16:05, Patrick W. Gilmore patr...@ianai.net wrote: On Nov 20, 2012, at 08:45 , Owen DeLong o...@delong.com wrote: It is entirely possible that Google's numbers are artificially low for a number of reasons. AMS-IX publishes stats too: https://stats.ams-ix.net/sflow/ This is probably a better view of overall percentage on the Internet than a specific company's content. It shows order of 0.5%. Why do you think Google's numbers are lower than the real total? They are also different stats which is why they give such different numbers. In a theoretical world with evenly distributed traffic patterns if 1% of users were IPv6 enabled it would require 100% of content to be IPv6 enabled before your traffic stats would show 1% of traffic going over IPv6. If these figures are representative (google saying 1% of users and AMSIX saying 0.5% of traffic) then it would indicate that dual stacked users can push ~50% of their traffic over IPv6. If this is even close to reality then that would be quite an achievement. If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June??? Tony
Re: Big day for IPv6 - 1% native penetration
While looking into the NTP chaos from Monday, I noticed that my personal servers have an NTP peer running IPv6. I have no idea how long that's been going on - it was a complete non-event ;). -- Harald
Re: Big day for IPv6 - 1% native penetration
Hi, On 11/20/12 7:24 PM, Blair Trosper wrote: I've found myself becoming a snob about IPv6. I almost look down on IPv4-only networks in the same way that I won't go see a film that isn't projected on DLP unless my arm is twisted. I'm a convert, and I'm glad to see the adoption rate edging up. However, I still scratch my head on why most major US ISPs *have* robust IPv6 peering and infrastructure and are ready to go, but they have not turned it on for their fiber/cable/DSL customers for reasons that are not clear to me. Turning IPv6 on at the basic/core of the infrastructure is the easiest part of the job. However turning IPv6 for customers requires a lot of effort and compromises. Some of the reasons are described in: http://6lab.cz/article/deploying-ipv6-practical-problems-from-the-campus-perspective/ and related presentation: http://6lab.cz/wordpress/wp-content/uploads/2012/05/tnc2012_slides_TncPresentation.pdf Tomas
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On Tue, Nov 20, 2012 at 1:48 PM, Faisal Imtiaz fai...@snappydsl.net wrote: On 11/20/2012 1:20 PM, Christopher Morrow wrote: On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz fai...@snappydsl.net wrote: On 11/20/2012 12:10 PM, Christopher Morrow wrote: it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Be careful of what you wish for, Yes, you get fiber from the CO to the Building... however there is also a very big side-effect... Verizon is not obligated to provide equal access to Competitive providers (CLECs) on this Fiber Thus, you are also looking a significantly reduced competition. which is very likely to equate to a higher cost for end users. right, so in the end vz gets what it wants... a return to monopoly. conspiracy theories about verizon starting the floods? No Conspiracy theories... just the simple facts on where things stand, based on current regulatory environment. (I / We have no horse in this race) apologies, I forgot the emoticons after my last comment. i really did mean it in jest... I don't think VZ has harnessed weather-changing-powers. (yet).
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
On 11/20/2012 2:58 PM, Christopher Morrow wrote: On Tue, Nov 20, 2012 at 1:48 PM, Faisal Imtiaz fai...@snappydsl.net wrote: On 11/20/2012 1:20 PM, Christopher Morrow wrote: On Tue, Nov 20, 2012 at 12:49 PM, Faisal Imtiaz fai...@snappydsl.net wrote: On 11/20/2012 12:10 PM, Christopher Morrow wrote: it's acutally kinda nice that at least from CO - building now there maybe more highspeed links... and maybe lower long term costs? Be careful of what you wish for, Yes, you get fiber from the CO to the Building... however there is also a very big side-effect... Verizon is not obligated to provide equal access to Competitive providers (CLECs) on this Fiber Thus, you are also looking a significantly reduced competition. which is very likely to equate to a higher cost for end users. right, so in the end vz gets what it wants... a return to monopoly. conspiracy theories about verizon starting the floods? No Conspiracy theories... just the simple facts on where things stand, based on current regulatory environment. (I / We have no horse in this race) apologies, I forgot the emoticons after my last comment. i really did mean it in jest... I don't think VZ has harnessed weather-changing-powers. (yet). No Worries, some of us here are players in the arena, and some of us are spectators it is going to be interesting and fascinating at the same time to see how things develop. Faisal Imtiaz
Re: NTP Issues Today
In a message written on Tue, Nov 20, 2012 at 02:28:19PM -0500, Jay Ashworth wrote: I'm curious, Leo, what your internal setup looks like. Do you have an internal pair of masters, all slaved to those externals and one another, with your machines homed to them? Full mesh? Or something else? My particular internal setup is a tad weird, and so rather than answer your question, I'm going to answer with some generalities. The right answer of course depends a lot on how important it is that boxes have the right time. If you have 4 or more physical sites, I believe the right answer is to have on the order of 8 NTP servers. 2 each in 4 sites reaches the minimum nicely with redundancy. These boxes can have GPS, CDMA or other technologies if you want, but MUST peer with at least 10 stratum-1 sources outside of your network. Of course if you have more sites, one server in each of 8 sites is peachy. Those on a budget could probably get by with 4 servers total, but never less! All critical devices should then be synced to the full set of internal servers. 4 boxes minimum, 8-10 preferred. NTP will only use the 10 best servers in it's calculations, so there is a steep dropoff of diminishing returns beyond 10. For most ISP's I would include all routers in this list. For the non-critical devices? Well, there it gets more complex. For most I would only configure one server, their default gateway router. Of course, pushing out a set of 4+ to themm if that is easy is a great thing to do. The interesting thing here is that no devices except for your NTP servers should ever peer with anything outside of your network. Why? Let's say your NTP servers all go crazy together. The outside world is cut off, GPS is spoofed, the world is ending. All that you have left is that all of your devices are in time to each otherso at least your logs still coorelate and such. So having every device under your master set of NTP servers is important. One guy with an external peer may choose to use that, and leave the hive mind, so to speak. For small players, less than 4 sites, typically just use the NTP pool servers, configuring 4 per box minimum. If you want the same protection I just outlined in the paragraph before, make 4 of your servers talk to the outside world, and make everything else talk to those. Want to give back to the community? Get a GPS/CDMA/Whatever box and make it part of the NTP pool. Want to step up your game (which is what I do), reach out to various Stratum-1's on the net (or find free, open ones) and peer up 8-20 of them. In my last big gig, it was recommended to me that I have all the machines which had to speak to my DBMS NTP *to it*, and have only it connect to the rest of my NTP infrastructure. It coming unstuck was of less operational impact than *pieces of it* going out of sync with one another... Yep, a prime example of the scenario I described above. Depending on your level of network redundancy, number of NTP servers, and so on, this is a fine solution. With one NTP server (the DBMS) the downstream will always use it, and stay in sync. It's a valid and good config in many situations. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpkzZWO3GDPn.pgp Description: PGP signature
Re: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan
Christopher Morrow wrote: apologies, I forgot the emoticons after my last comment. i really did mean it in jest... I don't think VZ has harnessed weather-changing-powers. (yet). Well, they ARE The Phone Company! -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: NTP Issues Today
On Nov 20, 2012, at 11:39 AM, Jared Mauch ja...@puck.nether.net wrote: . I've also been looking at an item like this: http://www.netburnerstore.com/ProductDetails.asp?ProductCode=PK70EX-NTP which is about $300 + misc parts. Should be well worth it to avoid a 'major outage' that some folks had with needing to reboot their servers, etc. - Jared Caution - that Netburner decice is just GPS synced, so if GPS ever does go insane you're out of luck. It doesn't list a precision internal clock part. I am not sure what all is in the dev kit version, but I know the company owner and can ask if anyone cares. George William Herbert Sent from my iPhone
Re: NTP Issues Today
On Tue, Nov 20, 2012 at 3:15 PM, Leo Bicknell bickn...@ufp.org wrote: For small players, less than 4 sites, typically just use the NTP pool servers, configuring 4 per box minimum. If you want the same protection I just outlined in the paragraph before, make 4 of your servers talk to the outside world, and make everything else talk to those. Want to give back to the community? Get a GPS/CDMA/Whatever Choosing the first four servers is usually pretty straightforward: *.CC.pool.ntp.org But beyond that, I'm honestly rather curious what server selections are a good idea. A first thought would be an adjacent country, but maybe there is a benefit to picking things outside of the pool.ntp.org selection entirely? I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a specific reason for that or if my questions are even worth thinking about at all :-). Happy to hear thoughts. -- Darius Jahandarie
Re: NTP Issues Today
I usually use time.nist.gov. On Tue, Nov 20, 2012 at 1:00 PM, Darius Jahandarie djahanda...@gmail.comwrote: On Tue, Nov 20, 2012 at 3:15 PM, Leo Bicknell bickn...@ufp.org wrote: For small players, less than 4 sites, typically just use the NTP pool servers, configuring 4 per box minimum. If you want the same protection I just outlined in the paragraph before, make 4 of your servers talk to the outside world, and make everything else talk to those. Want to give back to the community? Get a GPS/CDMA/Whatever Choosing the first four servers is usually pretty straightforward: *.CC.pool.ntp.org But beyond that, I'm honestly rather curious what server selections are a good idea. A first thought would be an adjacent country, but maybe there is a benefit to picking things outside of the pool.ntp.org selection entirely? I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a specific reason for that or if my questions are even worth thinking about at all :-). Happy to hear thoughts. -- Darius Jahandarie -- Mike Lyon 408-621-4826 mike.l...@gmail.com http://www.linkedin.com/in/mlyon
RE: [outages] NTP Issues Today
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 offsetdisp *~192.5.41.41 .IRIG.1 354 512 37734.20.36 1.4 +~132.163.4.101.ACTS.1 336 512 37735.0 -2.5418.7 ~127.127.7.1 127.127.7.1 105964 377 0.00.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured CORP-NTP-02#sh ntp as address ref clock st when poll reach delay offsetdisp *~192.5.41.41 .IRIG.165 512 37736.50.91 0.6 +~132.163.4.101.ACTS.195 512 37734.3 -1.3122.8 ~127.127.7.1 127.127.7.1 104464 377 0.00.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured Here are the logs from one of the Junipers: Nov 19 14:24:48 xntpd[912]: kernel time sync enabled 2001 Nov 19 15:50:11 xntpd[912]: synchronized to 172.20.167.252, stratum=2 Nov 19 16:41:23 xntpd[912]: no servers reachable Nov 19 16:44:24 xntpd[912]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:24 xntpd[912]: time correction of -378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 16:44:24 init: ntp (PID 912) exited with status=255 Nov 19 16:44:24 init: ntp (PID 70200) started Nov 19 16:44:24 xntpd[70200]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 16:44:24 xntpd[70200]: mlockall(): Resource temporarily unavailable Nov 19 16:44:24 xntpd[70200]: precision = 0.582 usec Nov 19 16:44:24 xntpd[70200]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 16:44:24 xntpd[70200]: kernel time sync status 2040 Nov 19 16:44:24 xntpd[70200]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 16:44:24 xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:24 xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:33 xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:32 xntpd[70200]: time reset -378691200.411331 s Nov 19 16:44:32 xntpd[70200]: kernel time sync disabled 2041 Nov 19 16:45:44 xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:45:51 xntpd[70200]: kernel time sync enabled 2001 Nov 19 16:45:56 xntpd[70200]: NTP Server Unreachable Nov 19 16:53:25 xntpd[70200]: no servers reachable Nov 19 17:03:09 xntpd[70200]: NTP Server Unreachable Nov 19 17:13:00 xntpd[70200]: NTP Server Unreachable Nov 19 17:20:27 xntpd[70200]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:27 xntpd[70200]: time correction of 378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 17:20:27 init: ntp (PID 70200) exited with status=255 Nov 19 17:20:27 init: ntp (PID 70766) started Nov 19 17:20:27 xntpd[70766]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 17:20:27 xntpd[70766]: mlockall(): Resource temporarily unavailable Nov 19 17:20:27 xntpd[70766]: precision = 0.570 usec Nov 19 17:20:27 xntpd[70766]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 17:20:27 xntpd[70766]: kernel time sync status 2040 Nov 19 17:20:27 xntpd[70766]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 17:20:27 xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:27 xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:35 xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:36 xntpd[70766]: time reset +378691200.387434 s Nov 19 17:20:36 xntpd[70766]: kernel time sync disabled 6041 Nov 19 17:21:48 xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:21:48 xntpd[70766]: kernel time sync disabled 2041 Nov 19 17:21:52 xntpd[70766]: kernel time sync enabled 2001 Nov 20 00:02:29 xntpd[70766]: synchronized to 172.20.167.251, stratum=2 Nov 20 01:44:56 xntpd[70766]: kernel time sync enabled 6001 Nov 20 02:19:03 xntpd[70766]: kernel time sync enabled 2001 Nov 20 02:53:12 xntpd[70766]: kernel time sync enabled 6001 Nov 20 03:44:26 xntpd[70766]: kernel time sync enabled 2001 Nov 20 05:26:58 xntpd[70766]: kernel time sync enabled 6001 Nov 20 05:44:02 xntpd[70766]: kernel time sync enabled 2001 Nov 20 07:43:35 xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:00:39 xntpd[70766]: kernel time sync enabled 2001 Nov 20 08:34:48 xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:51:54 xntpd[70766]: kernel time sync enabled 2001 Nov 20 10:34:22 xntpd[70766]: synchronized to
Re: NTP Issues Today
On Nov 20, 2012, at 4:00 PM, Darius Jahandarie djahanda...@gmail.com wrote: Choosing the first four servers is usually pretty straightforward: *.CC.pool.ntp.org But beyond that, I'm honestly rather curious what server selections are a good idea. A first thought would be an adjacent country, but maybe there is a benefit to picking things outside of the pool.ntp.org selection entirely? I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a specific reason for that or if my questions are even worth thinking about at all :-). I'm by no means a time geek, but …. i have some ideas about what you want and can tell you why I picked the settings I did… 1) The 129.250 ones are my employer run clocks. It is a good idea to know how accurate they are. 2) The pool ones, some were default (e.g.: fedora) from my OS distro on the machine I took the example from. You will see freebsd, centOS and others based on your settings. You may even see time.apple.com if you are MacOS. 3) CC ntp pool were selected to provide additional clock diversity. 4) You want low jitter to your clocks. This will allow you to have an accurate timing source. This means don't congest that path. If you want something very reliable, don't run it on a server with the other misc functions you need (e.g.: DNS, etc). If it's important, dedicate some hardware to it. if it is of passing importance, use a fair number of peers. I was playing with the OWAMP software. Having consistent clocks is important for that, (even if they are all off by a few ms). It can be fun to play with and measure things… http://www.internet2.edu/performance/owamp/index.html 5) Monitor your NTP setup periodically. You may see clocks be rejected or outliers. Depending on how close your clocks are, you may see a fair number be unusable. Take this output: nat:~$ ntpq -n -p -c ass remote refid st t when poll reach delay offset jitter == *129.250.35.250 164.244.221.197 2 u 507 512 377 18.8830.196 18.311 +129.250.35.251 209.51.161.238 2 u 366 512 377 41.3490.429 2.184 -206.57.44.17204.123.2.5 2 u 91 512 377 35.884 -5.982 7.099 -4.53.160.75 209.81.9.7 2 u5 512 377 24.2501.522 1.353 +64.73.32.135164.67.62.1942 u 296 512 377 26.405 -0.956 11.244 +50.116.38.157 64.250.177.145 2 u 897 1024 377 42.9780.685 1.211 -208.87.221.228 10.0.22.51 2 u 390 512 377 83.858 -2.717 0.814 -206.212.242.132 128.252.19.1 2 u 262 512 377 22.278 -1.640 1.150 +38.229.71.1 204.123.2.72 2 u 95 512 377 20.6880.113 1.878 ind assid status conf reach auth condition last_event cnt === 1 39973 961a yes yes none sys.peersys_peer 1 2 39974 941a yes yes none candidatesys_peer 1 3 39975 9324 yes yes none outlyer reachable 2 4 39976 932a yes yes none outlyersys_peer 2 5 39977 941a yes yes none candidatesys_peer 1 6 39978 941a yes yes none candidatesys_peer 1 7 39979 9314 yes yes none outlyer reachable 1 8 39980 931a yes yes none outlyersys_peer 1 9 39981 941a yes yes none candidatesys_peer 1 Only 5/9 clocks are 'candidate' for usage, or the actual reference clock. The jitter on the reference clock is equal to the delay (!). This is on a business class internet link/tier, but from one of the 'usual suspects' that offers residential services as well. I haven't been able to find them operating any customer accessible clocks, but they may exist. My config, or one resembling it will give you a fair amount of diversity of clocks. Syncing to one can easily result in being lied to and resetting the clock as everyone observed that went back to 2000. - Jared
Picking outside NTP servers (Re: NTP Issues Today)
- Original Message - From: Darius Jahandarie djahanda...@gmail.com Choosing the first four servers is usually pretty straightforward: *.CC.pool.ntp.org But beyond that, I'm honestly rather curious what server selections are a good idea. A first thought would be an adjacent country, but maybe there is a benefit to picking things outside of the pool.ntp.org selection entirely? I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a specific reason for that or if my questions are even worth thinking about at all :-). Ah; the question that has plagued mankind since the beginning of.. time. :-) There are a couple of documents on this topic at ntp.org, and there's the traditional list -- of questionable accuracy at this point -- of open-acess Strat 1 and 2 servers. For myself, I usually pick the first three in us.pool.ntp.org, tick and tock, time.nist.gov, and a couple of regionally appropriate large universities. I have always aimed for 6 to 8 outside servers, and a pair inside, preferably in different locations, both talking to one another. If your site is in Internet Business, you should probably peer with your business partners. If you deal with Google Docs or AWS, you should probably peer with them, if they have servers for that. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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
Re: Picking outside NTP servers (Re: NTP Issues Today)
On Tue, Nov 20, 2012 at 1:53 PM, Jay Ashworth j...@baylink.com wrote: For myself, I usually pick the first three in us.pool.ntp.org, tick and tock, time.nist.gov, and a couple of regionally appropriate large universities. As this week indicated, perhaps tick and tock are not sufficiently far apart to be a good redundancy choice from a geographical failover point of view or common mode failure point of view. As part of a set of 8 servers as you indicate later, perhaps ok, but I fear for people who think Ok, I want redundancy, so... Tick and Tock. Which, it turns out, was significant quantities. -- -george william herbert george.herb...@gmail.com
Re: Brasil/Mexico/Argentina connectivity
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.
Re: Plages d'adresses IP Orange
In message 50abc681.5040...@rollernet.us, Seth Mattinen writes: On 11/19/12 9:16 AM, Jamie Bowden wrote: Actually, this is kind of an interesting aside. Last time I checked, Canad a counts as North America and large parts of Quebec are inhabited by folks wh o don't speak much, if any, English. Having said that, I can't recall having seen any Quebecois posting in French here, but I find it hard to believe tho se folks don't have use for a list like this. Quebecois French and French aren't exactly the same. My dad once had to order le pancakes for breakfast because the waitress didn't understand le crepes. Well pancakes are not crepes. Different receipe, different appearance, different texture, similar taste. If you ask for something that is not on the menu ~Seth -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Picking outside NTP servers (Re: NTP Issues Today)
On Tue, Nov 20, 2012 at 04:53:39PM -0500, Jay Ashworth wrote: For myself, I usually pick the first three in us.pool.ntp.org, tick and tock, time.nist.gov, and a couple of regionally appropriate large universities. I'd advise going through the RR for a while, and pick servers close to you. ntpd won't select a server that's more than 128ms away. It also degrades accuracy. Select for minimum latency, as well as a diverse set of sources. [Watch their refid over time, and make sure they aren't slaving to the same set of servers, as well as others you may be using.] It requires a bit of effort, but over time you get an idea what public time servers are close to each of your locations, and diverse from each other. --msa
Re: Plages d'adresses IP Orange
On 11/20/12 3:19 PM, Mark Andrews wrote: In message 50abc681.5040...@rollernet.us, Seth Mattinen writes: On 11/19/12 9:16 AM, Jamie Bowden wrote: Actually, this is kind of an interesting aside. Last time I checked, Canad a counts as North America and large parts of Quebec are inhabited by folks wh o don't speak much, if any, English. Having said that, I can't recall having seen any Quebecois posting in French here, but I find it hard to believe tho se folks don't have use for a list like this. Quebecois French and French aren't exactly the same. My dad once had to order le pancakes for breakfast because the waitress didn't understand le crepes. Well pancakes are not crepes. Different receipe, different appearance, different texture, similar taste. If you ask for something that is not on the menu No, this was the Quebecois waitress not understanding the French word, not semantics. It's probably illegal to print the word pancake in Quebec anyway. ~Seth
Re: NTP Issues Today
On 11/19/12, Van Wolfe vanwo...@gmail.com wrote: 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. Are you sure that you are actually using NTP to set your clock? For you to sync with 2000, you should have had multiple confused peers from multiple time sources; possibly a false radio signal NTP by default has a panic threshold of 1000 seconds. This _should_ have caused NTP to execute a panic shutdown, instead of setting the clock back 30 million seconds. Thanks, Van -- -JH
Re: NTP Issues Today
On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess mysi...@gmail.com wrote: Are you sure that you are actually using NTP to set your clock? For you to sync with 2000, you should have had multiple confused peers from multiple time sources; possibly a false radio signal NTP by default has a panic threshold of 1000 seconds. This _should_ have caused NTP to execute a panic shutdown, instead of setting the clock back 30 million seconds. For VMWare at least, their official recommendation[1] for NTP is to tinker panic 0 for suspend/resume reasons. I've seen it default in some places. [1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 -- Darius Jahandarie
Re: NTP Issues Today
On Tue, Nov 20, 2012 at 4:49 PM, Jimmy Hess mysi...@gmail.com wrote: On 11/19/12, Van Wolfe vanwo...@gmail.com wrote: 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. Are you sure that you are actually using NTP to set your clock? For you to sync with 2000, you should have had multiple confused peers from multiple time sources; possibly a false radio signal NTP by default has a panic threshold of 1000 seconds. This _should_ have caused NTP to execute a panic shutdown, instead of setting the clock back 30 million seconds. From logs various people have posted, it appears NTPd saw the excessive time shift and took the reasonable(?) step of killing itself. The OS detected ntpd's death and took the reasonable step of restarting it. On startup, ntpd can be reasonably(?) configured with the -g option to bypass the 1000s limit to set the starting time before going into the regular ntpd time adjustment code. In this case that would have set them back to 2000 It's a good lesson on how a chain of reasonable decisions can lead to a bad outcome, so you really need to understand the interactions of the whole system. Damian
Re: NTP Issues Today
Looks like something bad has happened: Behind the Random NTP Bizarreness of Incorrect Year Being Set https://isc.sans.edu/diary.html?nstoryid=14548 --- A few people have written in within the past 18 hours about their NTP server/clients getting set to the year 2000. The cause of this behavior is that an NTP server at the US Naval Observatory (pretty much the authoritative time source in the US) was rebooted and somehow reverted to the year 2000. This, then, propogated out for a limited time and downstream time sources also got this value. It's a transient problem and should already be rectified. Not much really to report except an error at the top of the food chain causing problems to the layers below. If you have a problem, just fix the year or resync your NTP server. Just goes to show how reliant NTP is that it is all but a fire and forget service once configured until bad things happen. John Bambenek --- Alvaro Pereira
Re: NTP Issues Today
That's what happens when you just follow vendor recommendations blindly. If you do follow that on vm's (which can actually be a good practice), make sure they pull from your own time infrastructure, and not just the world at large, and that those servers behave in a sane fashion with regard to time jumps. On Tue, Nov 20, 2012 at 6:56 PM, Darius Jahandarie djahanda...@gmail.comwrote: On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess mysi...@gmail.com wrote: Are you sure that you are actually using NTP to set your clock? For you to sync with 2000, you should have had multiple confused peers from multiple time sources; possibly a false radio signal NTP by default has a panic threshold of 1000 seconds. This _should_ have caused NTP to execute a panic shutdown, instead of setting the clock back 30 million seconds. For VMWare at least, their official recommendation[1] for NTP is to tinker panic 0 for suspend/resume reasons. I've seen it default in some places. [1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 -- Darius Jahandarie
Re: NTP Issues Today
As a reminder - time infrastructure is not recommended for virtualization. Make them physicals. On Tue, Nov 20, 2012 at 5:03 PM, Blake Dunlap iki...@gmail.com wrote: That's what happens when you just follow vendor recommendations blindly. If you do follow that on vm's (which can actually be a good practice), make sure they pull from your own time infrastructure, and not just the world at large, and that those servers behave in a sane fashion with regard to time jumps. On Tue, Nov 20, 2012 at 6:56 PM, Darius Jahandarie djahanda...@gmail.comwrote: On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess mysi...@gmail.com wrote: Are you sure that you are actually using NTP to set your clock? For you to sync with 2000, you should have had multiple confused peers from multiple time sources; possibly a false radio signal NTP by default has a panic threshold of 1000 seconds. This _should_ have caused NTP to execute a panic shutdown, instead of setting the clock back 30 million seconds. For VMWare at least, their official recommendation[1] for NTP is to tinker panic 0 for suspend/resume reasons. I've seen it default in some places. [1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1006427 -- Darius Jahandarie -- -george william herbert george.herb...@gmail.com
Re: Big day for IPv6 - 1% native penetration
On Nov 20, 2012, at 14:44 , Tony Hain alh-i...@tndh.net wrote: If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, why wouldn't a dual stacked end point have half of its traffic as IPv6 after June??? If you assume Kinda says it all right there. But more importantly, those three combined are not 50% of overall traffic. It _might_ be true in the US, for some times of the day, but certainly not world-wide overall traffic. If for no better reason than you cannot get NF in all countries. -- TTFN, patrick
RE: Fiber terminations -- UPC vs APC
Good stuff here: http://www.n2prise.org/fiber002.htm and http://www.n2prise.org/fiber003.htm Frank -Original Message- From: Jeff Kell [mailto:jeff-k...@utc.edu] Sent: Monday, November 19, 2012 3:37 PM To: nanog Subject: Fiber terminations -- UPC vs APC Looking for some guidance/references on the use of UPC versus APC terminations on fiber cabling. Traditionally we have done all of our fiber plant targeting data usage with UPC connectors. We are also looking at proposals for fiber distribution plant for video, and the possibility of using some of the existing fiber plant for that purpose; as well as any new fiber plant that gets installed for video potentially as data. The video folks are set, determined, and insistent that they need APC terminations. All data references I have found preach UPC. Cisco's SFP reference page even states (in bold): *Note:* Only connections with patch cords with PC or UPC connectors are supported. Patch cords with APC connectors are not supported. All cables and cable assemblies used must be compliant with the standards specified in the standards section. So are we doomed to having physically separated fiber plants with suitable connectors / jumpers dedicated to video? Anyone been down this snaky looking path? Jeff
