Re: Leap Second planned for 2016

Once upon a time, Javier J said: > Unless you are running something that can't handle leap seconds what do you > really need to prepare for? The last several leap seconds have exposed weird and hard to predict bugs in various bits of software. Those previous bugs

Re: Leap Second planned for 2016

Once upon a time, Patrick W. Gilmore said: > But time _DOES_ flow. The seconds count > 58, 59, 60, 00, 01, … > If you can’t keep up, that’s not UTC’s fault. Here in the real world of modern computers, virtually everybody has copied the UNIX/C behavior that doesn't

Re: Leap Second planned for 2016

On Jul 8, 2016, at 7:47 PM, Saku Ytti wrote: > On 9 July 2016 at 02:27, Jared Mauch wrote: >> Time is actually harder than it seems. Many bits of software break in >> unexpected ways. Expect the unexpected. > > Aye. How many have written code like this: >

Re: Leap Second planned for 2016

On 7/8/16 4:47 PM, Saku Ytti wrote: > On 9 July 2016 at 02:27, Jared Mauch wrote: >> Time is actually harder than it seems. Many bits of software break in >> unexpected ways. Expect the unexpected. > > Aye. How many have written code like this: > > start = time(); >

Re: Leap Second planned for 2016

That was great, I would actually like NIST to link to it… > On Jul 8, 2016, at 7:14 PM, Hal Ponton wrote: > > I'll just leave this here :) > > http://spendyourleapsecondhere.com/ > -- > -- > Regards, > > Hal Ponton > Senior Network

Re: DNS resolving issues with AT Customer Resolvers

Hi, For my tested it did work with google but not several internal AT resolvers. A ticket has been created in one of the AT NOC departments. (after a 4 hour phone call) and I hope they can get to this soon. Sincerely, Mark Keymer On 7/8/2016 4:46 PM, Brian Henson wrote: Resolves here in

Re: Leap Second planned for 2016

On 9 July 2016 at 02:27, Jared Mauch wrote: > Time is actually harder than it seems. Many bits of software break in > unexpected ways. Expect the unexpected. Aye. How many have written code like this: start = time(); do_something(); elapsed = time() - start; Virtually

Re: DNS resolving issues with AT Customer Resolvers

Resolves here in Ohio and using 8.8.8.8 anycast address. on Timewarner On Fri, Jul 8, 2016 at 3:55 PM, Hiawatha Demby wrote: > C:\Users>nslookup bridgecatalog.com > Server: UnKnown > Address: 192.168.0.1 > > DNS request timed out. > timeout was 2 seconds. > DNS

An open letter to security researchers and practitioners

An open letter to security researchers and practitioners: We need you to take a stand to protect security researchers who report defects in browsers, before it's too late. Earlier this month, the World Wide Web Consortium's Encrypted Media Extensions (EME) spec progressed to Draft Recommendation

Re: Leap Second planned for 2016

Time is actually harder than it seems. Many bits of software break in unexpected ways. Expect the unexpected. Jared Mauch On Jul 8, 2016, at 6:53 PM, Javier J wrote: >> Time to start preparing > > > Unless you are running something that can't handle leap seconds

Re: Leap Second planned for 2016

I'll just leave this here :) http://spendyourleapsecondhere.com/ -- -- Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi Andrew Kirch 9 July 2016 at 00:09 Its a whole extra second you can spend doing something awesome. You have to plan now!

Re: Leap Second planned for 2016

Its a whole extra second you can spend doing something awesome. You have to plan now! On Friday, July 8, 2016, Javier J wrote: > > Time to start preparing > > > Unless you are running something that can't handle leap seconds what do you > really need to prepare for?

Re: L3 over OTN vs pure IP/MPLS

This sounds like somebody is trying to sell you equipment. Can you elaborate on the degradation you're experiencing? Are you sure you're utilizing all your link bandwidth effectively and packets are not being stuck in large buffers or crammed into a starving forwarding class? On Thu, Jul 7,

Re: Leap Second planned for 2016

> Time to start preparing Unless you are running something that can't handle leap seconds what do you really need to prepare for? On Thu, Jul 7, 2016 at 12:59 PM, Andrew Gallo wrote: > Looks like we'll have another second in 2016: >

Re: Interesting Article on Modulation Schemes

I don't see wide spread deployment. The most recently built TransAtlantic cable is Aquacomms It is QPSK and 130 100 gig waves per pair. Does one really need more? C-Lion, the new Finland/Germany cable is 18 terabits per fiber pair. I think that is 8 QAM. Is that a representative sample? I

Re: Interesting Article on Modulation Schemes

Apparently 40 gigs is the limit of simple laser flash equals 1, no flash equals 0. Above that threshold the signal becomes larger than an ITU 50 gigahertz channel. Most new undersea cables are using QPSK or 8 QAM and talking about 16 QAM. This companion piece explains it:

Re: NAT firewall for IPv6?

Wonderfully crafted, too. Great work. S. On 5 July 2016 at 15:39, Seth Mattinen wrote: > On 7/1/16 19:28, Edgar Carver wrote: > >> Hello NANOG community. I was directed here by our network administrator >> since she is on vacation. Luckily, I minored in Computer Science so

Re: DNS resolving issues with AT Customer Resolvers

C:\Users>nslookup bridgecatalog.com Server: UnKnown Address: 192.168.0.1 DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. *** Request to

Re: Interesting Article on Modulation Schemes

Not just "talking about" 16QAM is in active use for subsea high capacity channels... Both Xtera and Infinera are shipping DWDM terminals for installation at cable landing stations that use 16QAM for 100/200/400 Gbps superchannels. http://www.xtera.com/home/technology/100g-and-400g/

Re: DNS resolving issues with AT Customer Resolvers

The specific DNS server that are not resolve for my client are. Primary DNS 68.94.156.9 Secondary DNS 68.94.157.9 If any AT people out there that can look into this. Thank you. Sincerely, Mark Keymer On 7/8/2016 12:36 PM, Mark Keymer wrote: Hi all, I have a client bridgecatalog.com

Re: Interesting Article on Modulation Schemes

Essentially the transceiver optics are applying the same modulation and coding that have been used in point-to-point microwave for a long time... Starting from OOK, up to BPSK and then on to QPSK, 16QAM and possibly 64QAM with varying levels of FEC. A singlemode fiber is just an extremely narrow

DNS resolving issues with AT Customer Resolvers

Hi all, I have a client bridgecatalog.com and it seems like customers with AT are unable to resolve his Domain. Maybe I am just overlooking something here but it seems like all should be working. Looking at outside tool things look ok too. http://dnscheck.pingdom.com/?domain=bridgecatalog.com

Weekly Routing Table Report

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to

RE: www.RT.com bad dns record

Matt Palmer wrote: > On Thu, Jul 07, 2016 at 06:36:23PM -0700, Ca By wrote: > > On Thursday, July 7, 2016, Spencer Ryan wrote: > > > > > Dotted-quad notation is completely valid, and works fine. > > > > > > https://en.wikipedia.org/wiki/IPv6_address#Presentation > > > > > >

Re: packet loss question

On 2016-07-07 11:53 PM, William Herrin wrote: On Thu, Jul 7, 2016 at 3:52 PM, Ken Chase wrote: ICMP is allowed to be dropped by intervening routers. Someone will quote an RFC at us shortly. Hi Ken, That's not correct. Routers might not generate an ICMP time-exceeded packet

Interesting Article on Modulation Schemes

The new undersea cable systems are now capable of 18 terabits per fiber pair. It is interesting how combinations of bits are being represented by combinations of optical features.

Re: packet loss question

On Fri, Jul 8, 2016 at 9:09 AM, Ken Chase wrote: > And we know the whole internet observes handling > mtu discovery properly > and doesnt just firewall all ICMP because 'hackers'. > > (OP's issue may well be MTU discovery, esp if he's on > broadband. Don't have > enough details.

Re: packet loss question

Philip, Quite often slow Web page loading and email transport -- termed an application-layer problem because basic transport seems unaffected -- is due to DNS problems, particularly reverse DNS for the IP addresses originating your Web queries. If you have non-existent or intermittent IN-ADDR

Re: packet loss question

And we know the whole internet observes handling mtu discovery properly and doesnt just firewall all ICMP because 'hackers'. (OP's issue may well be MTU discovery, esp if he's on broadband. Don't have enough details. I just solved this exact problem a couple weeks ago for a client with an UBNT

Re: packet loss question

On 07/07/2016 03:52 PM, Ken Chase wrote: No offence, but i swear that mtr should come with a license to use it. I get more questions from people accusing us of network issues with mtr in hand... You shoudlnt care that there's 80% packet loss in the middle of your route, unless you have actual

Re: www.RT.com bad dns record

On 2016-07-08 04:33, Matt Palmer wrote: On Thu, Jul 07, 2016 at 06:36:23PM -0700, Ca By wrote: On Thursday, July 7, 2016, Spencer Ryan wrote: Dotted-quad notation is completely valid, and works fine. https://en.wikipedia.org/wiki/IPv6_address#Presentation