Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread Israel G. Lugo

On 07/02/2015 04:23 AM, Israel G. Lugo wrote:
> protocol static temp_block {
>   # DDOS mitigation, etc
>   route 203.0.113.17/32 blackhole;
> }

Didn't make it clear in my example, but you can obviously have multiple
routes in a static instance:

protocol static temp_block {
  route 203.0.113.17/32 blackhole;
  route 203.0.113.28/32 blackhole;

  # redirect to honeypot for gathering info
  route 203.0.113.99/32 via 10.0.0.15;
}


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread Israel G. Lugo
+1 for BIRD.

Basically, what you want is to have several different static (blackhole)
routes, and be able to differenciate them at BGP level, for marking with
communities, etc. Correct?

This is easy with BIRD. Just use separate instances of the "static"
protocol, and filter using "proto" to distinguish between them.

E.g.:

protocol static default_sink {
  # sink all local prefixes by default, to avoid loops
  # (low localpref, let other routes override us)
  import filter { preference = 1; accept; };

  route 192.0.2.0/24 blackhole;
}

protocol static forbidden {
  # these guys looked at me the wrong way
  route 198.51.100.0/24 blackhole;
}

protocol static temp_block {
  # DDOS mitigation, etc
  route 203.0.113.17/32 blackhole;
}

protocol bgp customer1 {
  export filter {
if proto = "default_sink" then reject;
if proto = "temp_block" then set_tempblock_community();
if proto = "forbidden" then do_other_stuff();
  }
  # ...
}



On 07/01/2015 08:47 PM, David H wrote:
> Sorry I wasn't clear on that.  Traditionally on a hardware, e.g.
> cisco/brocade, router performing the RTBH role, I'd add blackhole routes by
> way of static routes with a particular tag; one tag for block this source,
> one tag for block this destination.  Redistribute static would let route
> maps operate against those tags to turn into bgp communities being applied
> to the announcements, and then the real routers can do what they need to
> do.  When I tried out Quagga/Zebra as an alternative, it doesn't work this
> way, so while it was nice that it could pick up static routes from the OS,
> or have them added manually just like a hardware router, there was no
> concept of the route tag getting to Zebra for it to do the rest of the work
> on the BGP side.
>
> I'll check out Bird too; thanks.
>
> On Wed, Jul 1, 2015 at 3:41 PM, Job Snijders  wrote:
>
>> On Wed, Jul 01, 2015 at 11:19:45AM -0400, David H wrote:
>>> I was wondering if anyone can recommend a software (preferable), or
>>> hardware-based router with an API, that supports BGP with tags on
>>> advertised routes?  I want to use it for a RTBH feed [ ... ]
>> Did you look at BIRD? It is one of the most beautiful open source BGP
>> speakers: http://bird.network.cz/
>>
>> BIRD does not have anything like an restful API, but you can just
>> generate the config file and reload it on the fly to accomplish the
>> same.
>>
>> Can you elaborate on what you mean with 'tags'? Could you use BGP
>> communities instead?
>>
>> Kind regards,
>>
>> Job
>>



Re: REMINDER: LEAP SECOND

2015-07-01 Thread Mike Hammett
No, I'm surprised we know the kernels. They're a pretty closed company. 

All we can do is enter IPs for the client side and turn it on\off server side. 
Well, and broadcast\multicast\manycast. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Harlan Stenn"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Wednesday, July 1, 2015 7:43:43 PM 
Subject: Re: REMINDER: LEAP SECOND 

Mike Hammett writes: 
> It looks to have only affected the CCR line and only those running the 
> NTP and not the SNTP package. 

Any idea what version of NTP or what their configuration looked like? 

H 



Re: REMINDER: LEAP SECOND

2015-07-01 Thread Harlan Stenn
Mike Hammett writes:
> It looks to have only affected the CCR line and only those running the
> NTP and not the SNTP package.

Any idea what version of NTP or what their configuration looked like?

H


Re: leap second outage

2015-07-01 Thread Harlan Stenn
Jimmy Hess writes:
> On Wed, Jul 1, 2015 at 12:38 AM, Mikael Abrahamsson  wrote:
> > quickly. Either we should abolish the leap second or we should make leap
> > second adjustments (back and forth) on a monthly basis to exercise the code
> .
> 
> See  maybe there should some day be building codes for
> commercially marketed software  that provide minimum independent
> formal testing to be done by licensed independent testers,  including
> leap seconds and such. ^_^

And NTF's Certification and Compliance programs are going to do this.
At least as soon as NTF has the resources to get this moving.

> The leap second issues are possibly rare and intermittent,  therefore,
>  having a few per month  is not necessarily giving adequate exposure
> to code paths that may go wrong during an insert/del event.

If they happened every 6 month's time that would be often enough, but
the earth hasn't slowed down that much yet.  There will be enough times
that we could insert or delete one every month and still have |UT-UT1|
be under .9 seconds.

If it was announced that "starting in 6 months' time we'll be inserting
or deleting a leap second every month or so that would give folks enough
time to prep for it, and I'm pretty confident that the leap-second would
soon become a non-event.

> There's never been a negative leap second, only insertions, but how
> deletions are implemented  might expose new bugs, since there hasn't
> been one before,  And you can only have one leap per 24 hours,
> positive or minus,  pick one.

Yup.

> & Shouldn't this kind of 'exercise'  be done  during the QA process
> before releasing new system software,   rather than mucking with clock
> accuracy?

leap second handling is a "mechanism" question.  Which one to choose is
a "policy" question.  IMO, a vendor should provide adequate mechanism.
The customer should get to choose policy.

> There is a recent article with some Leap Second  'stress testing' code:
>   https://access.redhat.com/articles/199563
> 
> 
> Readily available test methods are available,  there ought to be
> little legitimate excuse for anyone writing serious software that has
> long-running processes or threads   not to include  evaluation for
> possible leap second  issues  and other possible clock-related issues
> such as clock stepping, DST, and Year 2038 in their standard smoke
> tests

Yes.  And even so, testing these things takes time and equipment.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!


Re: leap second outage

2015-07-01 Thread Tim Raphael
No, it was a route leak by a colo  provider (Axcelx) downstream.

Regards,

Tim Raphael

> On 1 Jul 2015, at 11:37 am, Justin Paine via NANOG  wrote:
> 
> Any confirmation if the AWS outage was leap second-related?
> 
> 
> Justin Paine
> Head of Trust & Safety
> CloudFlare Inc.
> PGP KeyID: 57B6 0114 DE0B 314D
> 
> 
>> On Tue, Jun 30, 2015 at 8:32 PM, Dovid Bender  wrote:
>> I read that and that at midnight local time since that's when you have the 
>> extra second. I know a large carrier in Israel is down. Waiting for conf. If 
>> it's leep second related.
>> 
>> --Original Message--
>> From: Stefan
>> Sender: NANOG
>> To: frnk...@iname.com
>> Cc: nanog@nanog.org
>> Subject: Re: leap second outage
>> Sent: Jun 30, 2015 23:30
>> 
>> This was supposed to have happened @midnight UTC, right? Meaning that we
>> are past that event. Under which scenarios should people be concerned about
>> midnight local time? Lots of confusing messages flying all over...
>>> On Jun 30, 2015 10:13 PM,  wrote:
>>> 
>>> We experienced our first leap second outage -- our SHE (super head end) is
>>> using (old) Motorola encoders and we lost those video channels.  They
>>> restarted all those encoders to restore service.
>>> 
>>> Frank
>> 
>> Regards,
>> 
>> Dovid


RE: leap second outage

2015-07-01 Thread frnkblk
And just 12.5% of them required TLC. =)

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of frnk...@iname.com
Sent: Wednesday, July 01, 2015 7:05 AM
To: 'Stefan'
Cc: nanog@nanog.org
Subject: RE: leap second outage

Yes, happened at 7 pm Central (0:oo UTC).

 

From: Stefan [mailto:netfort...@gmail.com] 
Sent: Tuesday, June 30, 2015 10:30 PM
To: frnk...@iname.com
Cc: nanog@nanog.org
Subject: Re: leap second outage

 

This was supposed to have happened @midnight UTC, right? Meaning that we are 
past that event. Under which scenarios should people be concerned about 
midnight local time? Lots of confusing messages flying all over... 

On Jun 30, 2015 10:13 PM, mailto:frnk...@iname.com> > wrote:

We experienced our first leap second outage -- our SHE (super head end) is
using (old) Motorola encoders and we lost those video channels.  They
restarted all those encoders to restore service.

Frank





Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread Dan White

On 07/01/15 15:47 -0400, David H wrote:

Sorry I wasn't clear on that.  Traditionally on a hardware, e.g.
cisco/brocade, router performing the RTBH role, I'd add blackhole routes by
way of static routes with a particular tag; one tag for block this source,
one tag for block this destination.  Redistribute static would let route
maps operate against those tags to turn into bgp communities being applied
to the announcements, and then the real routers can do what they need to
do.  When I tried out Quagga/Zebra as an alternative, it doesn't work this
way, so while it was nice that it could pick up static routes from the OS,
or have them added manually just like a hardware router, there was no
concept of the route tag getting to Zebra for it to do the rest of the work
on the BGP side.


We're using Quagga to inject blackhole routes upstream, which can match
routes on the OS's metric value:

# IPv4 blackhole
~$ ip route add 203.0.113.42/32 dev lo metric 666

!
route-map map_bad_routes permit 10
match metric 666
set community x:yyy
...
!

--
Dan White


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread David H
Sorry I wasn't clear on that.  Traditionally on a hardware, e.g.
cisco/brocade, router performing the RTBH role, I'd add blackhole routes by
way of static routes with a particular tag; one tag for block this source,
one tag for block this destination.  Redistribute static would let route
maps operate against those tags to turn into bgp communities being applied
to the announcements, and then the real routers can do what they need to
do.  When I tried out Quagga/Zebra as an alternative, it doesn't work this
way, so while it was nice that it could pick up static routes from the OS,
or have them added manually just like a hardware router, there was no
concept of the route tag getting to Zebra for it to do the rest of the work
on the BGP side.

I'll check out Bird too; thanks.

On Wed, Jul 1, 2015 at 3:41 PM, Job Snijders  wrote:

> On Wed, Jul 01, 2015 at 11:19:45AM -0400, David H wrote:
> > I was wondering if anyone can recommend a software (preferable), or
> > hardware-based router with an API, that supports BGP with tags on
> > advertised routes?  I want to use it for a RTBH feed [ ... ]
>
> Did you look at BIRD? It is one of the most beautiful open source BGP
> speakers: http://bird.network.cz/
>
> BIRD does not have anything like an restful API, but you can just
> generate the config file and reload it on the fly to accomplish the
> same.
>
> Can you elaborate on what you mean with 'tags'? Could you use BGP
> communities instead?
>
> Kind regards,
>
> Job
>


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread David H
Thanks all; I'll check out ExaBGP and the software version of Mikrotik;
didn't realize it wasn't tied to hardware.

On Wed, Jul 1, 2015 at 11:19 AM, David H  wrote:

> Hi all, I was wondering if anyone can recommend a software (preferable),
> or hardware-based router with an API, that supports BGP with tags on
> advertised routes?  I want to use it for a RTBH feed and having it in
> software would make certain things easier to automate.  I tried
> Quagga/Zebra but it doesn't support tags.  I see Mikrotik hardware routers
> have an API, but I can't tell if the API supports adding BGP networks, so I
> need to investigate that further.  I can go hardware if I have to, with
> some ssh/expect scripts, but thought there may be other options that are
> easier.
>
> Thanks,
>
> David
>


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread Job Snijders
On Wed, Jul 01, 2015 at 11:19:45AM -0400, David H wrote:
> I was wondering if anyone can recommend a software (preferable), or
> hardware-based router with an API, that supports BGP with tags on
> advertised routes?  I want to use it for a RTBH feed [ ... ]

Did you look at BIRD? It is one of the most beautiful open source BGP
speakers: http://bird.network.cz/

BIRD does not have anything like an restful API, but you can just
generate the config file and reload it on the fly to accomplish the
same.

Can you elaborate on what you mean with 'tags'? Could you use BGP
communities instead?

Kind regards,

Job


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Mike Hammett
http://forum.mikrotik.com/viewtopic.php?f=2&t=98138#p488731 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Rubens Kuhl"  
To: "Nanog"  
Sent: Wednesday, July 1, 2015 1:20:30 PM 
Subject: Re: REMINDER: LEAP SECOND 

On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams  wrote: 

> Once upon a time, Mike Hammett  said: 
> > v5 is 2.4, v6 3.3.5 
> 
> Don't know why a 3.3.5 kernel would have deadlocked; don't think there 
> are any known issues that would cause that, unless there are Mikrotik 
> specific patches that caused the problem. 
> 
> I believe the bug from the 2008 leap second was present in kernels in 
> 2.4 up through 2.6.26 (although Red Hat at least patched it in their 
> older version long-term support kernels). 
> 

3.3 was listed as buggy in this regard as well. 


Rubens 



Re: GRE performance over the Internet - DDoS cloud mitigation

2015-07-01 Thread Dennis B
Kenneth,

That would also be my recommendation to this scenario. The only caveat
would be to consider the risk in the service-policy dropping legit traffic
because the policy. Often times, the PPS rates of a DDoS attack fill's the
policy queue up with malicious packets, sending the legit packets into a
'blackhole' or whatever mechanism you use to discard.

Rate-limiters / QoS / Service-policies are good for some use cases but not
for others, I am confident we all agree.

In this case, "buying" time by implementing some initiate tactics to
maintain stability is well worth the risk of being hard down. While the
mean-time to detect, alert, start blocking, and stop the attack is being
completed by the Cloud Provider.

>From our perspective, we're talking 1 min averages with 5 min stop time for
L3/L4 attacks. Even if these situations were apparent, they'd be short
lived.

Ramy,

Does this answer your question or give you some ideas?

It was pointed out to me that this thread started June 8th, didn't see any
other replies.

DB




On Wed, Jul 1, 2015 at 12:15 PM, Kenneth McRae  wrote:

> How stable can GRE transports and BGP sessions be when under load?
>
>
> I typically protect the BGP session by policing all traffic being
> delivered to the remote end except for BGP.  Using this posture, my BGP
> session over GRE are stable; even under attack.
>
> Kenneth
>
> On Jun 30, 2015, at 01:37 PM, Dennis B  wrote:
>
> Roland,
>
> Agreed, Ramy's scenario was not truly spot on, but his question still
> remains. Perf implications when cloud security providers time to
> detect/mitigate is X minutes. How stable can GRE transports and BGP
> sessions be when under load?
>
> In my technical opinion, this is a valid argument, which deems wide
> opinion. Specifically, use-cases about how to apply defense in depth
> logically in the DC vs Hybrid vs Pure Cloud.
>
> Good topic, already some back-chatter personal opinions from Nanog lurkers!
>
> Regards,
>
> Dennis B.
>
>
> On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins 
> wrote:
>
>
> On 1 Jul 2015, at 1:37, Dennis B wrote:
>
>
> Would you like to learn more? lol
>
>
>
> I'm quite conversant with all these considerations, thanks.
>
>
> OP asserted that BGP sessions for diversion into any cloud DDoS mitigation
>
> service ran from the endpoint network through GRE tunnels to the
>
> cloud-based mitigation provider. I was explaining that in most cloud
>
> mitigation scenarios, GRE tunnels are used for re-injection of 'clean'
>
> traffic to the endpoint networks.
>
>
> ---
>
> Roland Dobbins 
>
>
>


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread Pavel Odintsov
My voice for awesome ExaBGP too!

On Wednesday, July 1, 2015, harbor235  wrote:

> Quagga supports BGP communities,
>
>
>
> Mike
>
> On Wed, Jul 1, 2015 at 11:19 AM, David H  > wrote:
>
> > Hi all, I was wondering if anyone can recommend a software (preferable),
> or
> > hardware-based router with an API, that supports BGP with tags on
> > advertised routes?  I want to use it for a RTBH feed and having it in
> > software would make certain things easier to automate.  I tried
> > Quagga/Zebra but it doesn't support tags.  I see Mikrotik hardware
> routers
> > have an API, but I can't tell if the API supports adding BGP networks,
> so I
> > need to investigate that further.  I can go hardware if I have to, with
> > some ssh/expect scripts, but thought there may be other options that are
> > easier.
> >
> > Thanks,
> >
> > David
> >
>


-- 
Sincerely yours, Pavel Odintsov


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread harbor235
Quagga supports BGP communities,



Mike

On Wed, Jul 1, 2015 at 11:19 AM, David H  wrote:

> Hi all, I was wondering if anyone can recommend a software (preferable), or
> hardware-based router with an API, that supports BGP with tags on
> advertised routes?  I want to use it for a RTBH feed and having it in
> software would make certain things easier to automate.  I tried
> Quagga/Zebra but it doesn't support tags.  I see Mikrotik hardware routers
> have an API, but I can't tell if the API supports adding BGP networks, so I
> need to investigate that further.  I can go hardware if I have to, with
> some ssh/expect scripts, but thought there may be other options that are
> easier.
>
> Thanks,
>
> David
>


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread james machado
David,

check out exabgp https://github.com/Exa-Networks/exabgp

james

On Wed, Jul 1, 2015 at 8:19 AM, David H  wrote:
> Hi all, I was wondering if anyone can recommend a software (preferable), or
> hardware-based router with an API, that supports BGP with tags on
> advertised routes?  I want to use it for a RTBH feed and having it in
> software would make certain things easier to automate.  I tried
> Quagga/Zebra but it doesn't support tags.  I see Mikrotik hardware routers
> have an API, but I can't tell if the API supports adding BGP networks, so I
> need to investigate that further.  I can go hardware if I have to, with
> some ssh/expect scripts, but thought there may be other options that are
> easier.
>
> Thanks,
>
> David


Re: Inexpensive software bgp router that supports route tags?

2015-07-01 Thread Faisal Imtiaz
FYI, Mikrotik is software (ROS) you can run it on an x86 platform (physical or 
virtual machine).
Not sure about the API and BGP, but they have extensive support for scripting.
Additionally check the Mikrotik Forums for other user developed 
API/Interfaces...

Regards.

Faisal Imtiaz
Snappy Internet & Telecom


- Original Message -
> From: "David H" 
> To: nanog@nanog.org
> Sent: Wednesday, July 1, 2015 11:19:45 AM
> Subject: Inexpensive software bgp router that supports route tags?
> 
> Hi all, I was wondering if anyone can recommend a software (preferable), or
> hardware-based router with an API, that supports BGP with tags on
> advertised routes?  I want to use it for a RTBH feed and having it in
> software would make certain things easier to automate.  I tried
> Quagga/Zebra but it doesn't support tags.  I see Mikrotik hardware routers
> have an API, but I can't tell if the API supports adding BGP networks, so I
> need to investigate that further.  I can go hardware if I have to, with
> some ssh/expect scripts, but thought there may be other options that are
> easier.
> 
> Thanks,
> 
> David
> 


Re: in-cabinet PDU safety regs?

2015-07-01 Thread Ian Smith
If you are in the US, NFPA 70 article 645 may, or may not, apply.

http://www.powercabling.com/documents/NEC645.pdf

On Wed, Jul 1, 2015, 12:44 William Herrin  wrote:

> Hi Folks,
>
> Do you know of any regulations, standards or publications covering the
> safe installation and use of the little 1U and 2U PDUs in rack
> cabinets? My google fu is failing me. All I've found is OSHA
> 1926.403(i)(1)(i)
> (
> https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=10704
> )
> and I'm not 100% sure it applies.
>
> Thanks in advance,
> Bill Herrin
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
>


Inexpensive software bgp router that supports route tags?

2015-07-01 Thread David H
Hi all, I was wondering if anyone can recommend a software (preferable), or
hardware-based router with an API, that supports BGP with tags on
advertised routes?  I want to use it for a RTBH feed and having it in
software would make certain things easier to automate.  I tried
Quagga/Zebra but it doesn't support tags.  I see Mikrotik hardware routers
have an API, but I can't tell if the API supports adding BGP networks, so I
need to investigate that further.  I can go hardware if I have to, with
some ssh/expect scripts, but thought there may be other options that are
easier.

Thanks,

David


Re: Route leak in Bangladesh

2015-07-01 Thread Mark Tinka


On 1/Jul/15 17:11, Nick Hilliard wrote:
>
> The source code is available on github.com/inex.  Lots of IXPs use it in
> production.

Thanks, Nick. I'll have a bit of a sniff...

Mark.


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Rubens Kuhl
On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams  wrote:

> Once upon a time, Mike Hammett  said:
> > v5 is 2.4, v6 3.3.5
>
> Don't know why a 3.3.5 kernel would have deadlocked; don't think there
> are any known issues that would cause that, unless there are Mikrotik
> specific patches that caused the problem.
>
> I believe the bug from the 2008 leap second was present in kernels in
> 2.4 up through 2.6.26 (although Red Hat at least patched it in their
> older version long-term support kernels).
>

3.3 was listed as buggy in this regard as well.


Rubens


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Mike Hammett
The only v6 ones that are sure to have had the problem are based on tilera 
chips and one of two NTP packages available. *shrugs* 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Chris Adams"  
To: nanog@nanog.org 
Sent: Wednesday, July 1, 2015 1:17:06 PM 
Subject: Re: REMINDER: LEAP SECOND 

Once upon a time, Mike Hammett  said: 
> v5 is 2.4, v6 3.3.5 

Don't know why a 3.3.5 kernel would have deadlocked; don't think there 
are any known issues that would cause that, unless there are Mikrotik 
specific patches that caused the problem. 

I believe the bug from the 2008 leap second was present in kernels in 
2.4 up through 2.6.26 (although Red Hat at least patched it in their 
older version long-term support kernels). 

-- 
Chris Adams  



Re: REMINDER: LEAP SECOND

2015-07-01 Thread Chris Adams
Once upon a time, Mike Hammett  said:
> v5 is 2.4, v6 3.3.5 

Don't know why a 3.3.5 kernel would have deadlocked; don't think there
are any known issues that would cause that, unless there are Mikrotik
specific patches that caused the problem.

I believe the bug from the 2008 leap second was present in kernels in
2.4 up through 2.6.26 (although Red Hat at least patched it in their
older version long-term support kernels).

-- 
Chris Adams 


Re: Leap Second Folo/After Action

2015-07-01 Thread goemon

supposedly vulnerable devices sailed through without a peep.

-Dan

On Wed, 1 Jul 2015, Jay Ashworth wrote:


Here's LWN's piece on the then-upcoming event from last week, presumably
with comments trailing into today.

 http://lwn.net/Articles/648313/

How'd it go for everyone?  Did the world end?

Cheers,
-- jra

--
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274



Re: Leap Second Folo/After Action

2015-07-01 Thread Scott Weeks

--- j...@baylink.com wrote:
From: Jay Ashworth 

Here's LWN's piece on the then-upcoming event from last week, presumably
with comments trailing into today.

  http://lwn.net/Articles/648313/

How'd it go for everyone?  Did the world end?
---



Not one single problem.  Yay! :-)



scott


RE: [outages] CenturyLink fiber cut between Modesto, CA and San Jose, CA this AM.. Start time 4:26AM PST

2015-07-01 Thread Keith Medcalf

Have they asked No-Such-Agency?

No-Such-Agency typically taps communication lines by "back-hoe accident" of 
some sort on the path they are interested in tapping.  That way they can 
install a tap "over yonder" while the victim telecom is attempting to repair 
the original damage.  I guess this time is taking longer than expected so they 
FBI has been recruited to prevent the victim from completing repairs to quickly.

Then again, maybe my tinfoil hat is too tight.

> -Original Message-
> From: Outages [mailto:outages-boun...@outages.org] On Behalf Of Hugo
> Slabbert via Outages
> Sent: Tuesday, 30 June, 2015 16:57
> To: Peter Kranz via Outages; Peter Kranz
> Subject: Re: [outages] CenturyLink fiber cut between Modesto, CA and San
> Jose, CA this AM.. Start time 4:26AM PST
>
> Related?
>
> http://arstechnica.com/tech-policy/2015/06/fbi-baffled-over-wave-of-
> nighttime-fiber-optic-cable-vandalism/
>
> --
> Hugo
>
>
>
>  Peter Kranz via Outages wrote 
>
>
> This appears to be part of a larger act of intentional sabotage:
>
> "We have just been advised that crews have been removed from the area
> while
> law enforcement investigates the damage, which was caused by vandalism.
> Three enclosures were damaged impacting three different carriers. There is
> no time given for when they will be allowed to begin work again,
> subsequently, there is still no ETR.
> "
>
>
> ___
> Outages mailing list
> outa...@outages.org
> https://puck.nether.net/mailman/listinfo/outages






Leap Second Folo/After Action

2015-07-01 Thread Jay Ashworth
Here's LWN's piece on the then-upcoming event from last week, presumably
with comments trailing into today.

  http://lwn.net/Articles/648313/

How'd it go for everyone?  Did the world end?

Cheers,
-- jra

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Mike Hammett
v5 is 2.4, v6 3.3.5 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Chris Adams"  
To: nanog@nanog.org 
Sent: Wednesday, July 1, 2015 9:39:09 AM 
Subject: Re: REMINDER: LEAP SECOND 

Once upon a time, Rubens Kuhl  said: 
> Not quite. Reported crashes included 6.27, so it's possible that some other 
> mitigating factor helped not to crash (like using SNTP instead of NTP, 
> although there seems to be people with crashes using SNTP or no SNTP/NTP at 
> all). 

These are running Linux kernels, right? Anybody know which version? I 
know the last couple of leap seconds hit (different) bugs in the Linux 
kernel. The 2012 bug was timer related and confused some user-space 
applications, but the 2008 bug could cause a kernel deadlock (which this 
sounds like). 

-- 
Chris Adams  



in-cabinet PDU safety regs?

2015-07-01 Thread William Herrin
Hi Folks,

Do you know of any regulations, standards or publications covering the
safe installation and use of the little 1U and 2U PDUs in rack
cabinets? My google fu is failing me. All I've found is OSHA
1926.403(i)(1)(i)
(https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=10704)
and I'm not 100% sure it applies.

Thanks in advance,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 


Re: GRE performance over the Internet - DDoS cloud mitigation

2015-07-01 Thread Kenneth McRae

How stable can GRE transports and BGP sessions be when under load?
 
I typically protect the BGP session by policing all traffic being delivered to 
the remote end except for BGP.  Using this posture, my BGP session over GRE are 
stable; even under attack.

Kenneth 

On Jun 30, 2015, at 01:37 PM, Dennis B  wrote:

Roland,

Agreed, Ramy's scenario was not truly spot on, but his question still
remains. Perf implications when cloud security providers time to
detect/mitigate is X minutes. How stable can GRE transports and BGP
sessions be when under load?

In my technical opinion, this is a valid argument, which deems wide
opinion. Specifically, use-cases about how to apply defense in depth
logically in the DC vs Hybrid vs Pure Cloud.

Good topic, already some back-chatter personal opinions from Nanog lurkers!

Regards,

Dennis B.


On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins  wrote:


On 1 Jul 2015, at 1:37, Dennis B wrote:

Would you like to learn more? lol


I'm quite conversant with all these considerations, thanks.

OP asserted that BGP sessions for diversion into any cloud DDoS mitigation
service ran from the endpoint network through GRE tunnels to the
cloud-based mitigation provider. I was explaining that in most cloud
mitigation scenarios, GRE tunnels are used for re-injection of 'clean'
traffic to the endpoint networks.

---
Roland Dobbins 



Re: Route leak in Bangladesh

2015-07-01 Thread Nick Hilliard
On 01/07/2015 17:03, Joe Abley wrote:
> The idea of configuring this stuff from the IRR is great in terms of
> distributing the ops cycles in the right places, but it doesn't help with
> verifying that the end result isn't insane, as I think you and Mike have
> described on this list over the past couple of days.

that doesn't invalidate it as being part of a critical mechanism for
filtering ebgp.  Implemented well, it will catch 99% of problems.
maxprefixes with no autorecover catches 75% of the rest.  Between these two
mechanisms, that's pretty good.

Nick



Re: Route leak in Bangladesh

2015-07-01 Thread Joe Abley



On 1 Jul 2015, at 11:03, Jared Mauch wrote:


On Wed, Jul 01, 2015 at 03:54:16PM +0100, Nick Hilliard wrote:

On 01/07/2015 15:51, Mark Tinka wrote:
I found RPSL complicated a few years ago, and sort of put that on 
the

back-burner.


you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6 objects.  RPSL is not going to 
live up

to your expectations.


Yes, like any technology there are lots of knobs that one could
use but are not recommended.

You just need these few objects and life will be simple.


... as long as the people responsible for maintaining those as-sets 
don't get confused and include lots of other inappropriate as-sets by 
reference, right?


The idea of configuring this stuff from the IRR is great in terms of 
distributing the ops cycles in the right places, but it doesn't help 
with verifying that the end result isn't insane, as I think you and Mike 
have described on this list over the past couple of days.



Joe


Re: Route leak in Bangladesh

2015-07-01 Thread Mike Hammett
That they do. Thanks for a great system, BTW! 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Nick Hilliard"  
To: "Mark Tinka" , "Jared Mauch"  
Cc: "North American Network Operators' Group"  
Sent: Wednesday, July 1, 2015 10:11:13 AM 
Subject: Re: Route leak in Bangladesh 

On 01/07/2015 16:02, Mark Tinka wrote: 
> Honestly, I'm ambivalent about using the IRR data for prefix-list 
> generation (even without RPSL), also because of how much junk there is 
> in there, and also how redundant some of it really is, e.g., someone 
> creating a /32 (IPv4) route object and yet we only accept up to a /24 
> (IPv4) on the actual eBGP session, e.t.c. 

We went through this a couple of years ago at INEX and ended up with a 
provisioning system which allows the operator to only allow specific IRRDB 
source: entries, customisable per customer. You're right that it would be 
foolish to accept any IRRDB source because a lot of them are complete trash. 

Otherwise, it works incredibly well for us and has stopped innumerable 
prefix leaks and other silly misconfigs. 

The source code is available on github.com/inex. Lots of IXPs use it in 
production. 

Nick 




Re: Route leak in Bangladesh

2015-07-01 Thread Nick Hilliard
On 01/07/2015 16:02, Mark Tinka wrote:
> Honestly, I'm ambivalent about using the IRR data for prefix-list
> generation (even without RPSL), also because of how much junk there is
> in there, and also how redundant some of it really is, e.g., someone
> creating a /32 (IPv4) route object and yet we only accept up to a /24
> (IPv4) on the actual eBGP session, e.t.c.

We went through this a couple of years ago at INEX and ended up with a
provisioning system which allows the operator to only allow specific IRRDB
source: entries, customisable per customer.  You're right that it would be
foolish to accept any IRRDB source because a lot of them are complete trash.

Otherwise, it works incredibly well for us and has stopped innumerable
prefix leaks and other silly misconfigs.

The source code is available on github.com/inex.  Lots of IXPs use it in
production.

Nick



Re: Route leak in Bangladesh

2015-07-01 Thread Mark Tinka


On 1/Jul/15 17:04, Nick Hilliard wrote:
> Naah, trie compilation is simple, particularly with a line oriented
> configuration like IOS (one of the worse offenders).  Once the config is
> syntax-checked, a regexp will split it out trivially and the binary form of
> the data can be compiled.  Even on Junos, that sort of config will be
> handled by lex/yacc, which is highly optimised.
>
> Insertion / deletion of data in a patricia trie is ridiculously fast and
> there are a couple of bsd licensed implementations out there.

My experience around this was mostly when Cisco began introducing Turbo
ACL's. There seemed to be a few problems around that time, but it was
such a long time ago that I barely remember the details.

That said, I'm not quite sure if there are specific issues Jared and
others are facing around this in their networks. From my side, none that
we have witnessed. But then again, our configurations are significantly
smaller because we do not take data from the IRR.

Mark.


Re: Route leak in Bangladesh

2015-07-01 Thread Nick Hilliard
On 01/07/2015 15:57, Mark Tinka wrote:
> Remember some high-end Cisco routers only have 2MB of NVRAM. This could
> get tested with a large prefix-list configuration. Junos may not have
> much of a space issue since the configuration is stored on the compact
> flash or HDD.

Not at all.  Even C6500 could store startup-config on external CF which
could be 2G.

> Trie compilation or process will be very OS-dependent, and how the
> vendor has chosen to optimize that operation.

Naah, trie compilation is simple, particularly with a line oriented
configuration like IOS (one of the worse offenders).  Once the config is
syntax-checked, a regexp will split it out trivially and the binary form of
the data can be compiled.  Even on Junos, that sort of config will be
handled by lex/yacc, which is highly optimised.

Insertion / deletion of data in a patricia trie is ridiculously fast and
there are a couple of bsd licensed implementations out there.

Nick




Re: Route leak in Bangladesh

2015-07-01 Thread Jared Mauch
On Wed, Jul 01, 2015 at 03:54:16PM +0100, Nick Hilliard wrote:
> On 01/07/2015 15:51, Mark Tinka wrote:
> > I found RPSL complicated a few years ago, and sort of put that on the
> > back-burner.
> 
> you probably want to ignore more rpsl constructs and depend solely on
> as-sets, aut-nums and route/route6 objects.  RPSL is not going to live up
> to your expectations.

Yes, like any technology there are lots of knobs that one could
use but are not recommended.

You just need these few objects and life will be simple.

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.


Re: Route leak in Bangladesh

2015-07-01 Thread Mark Tinka


On 1/Jul/15 16:54, Nick Hilliard wrote:
> you probably want to ignore more rpsl constructs and depend solely on
> as-sets, aut-nums and route/route6 objects.  RPSL is not going to live up
> to your expectations.

Honestly, I'm ambivalent about using the IRR data for prefix-list
generation (even without RPSL), also because of how much junk there is
in there, and also how redundant some of it really is, e.g., someone
creating a /32 (IPv4) route object and yet we only accept up to a /24
(IPv4) on the actual eBGP session, e.t.c.

What I'm more focused is how we can continue to scale our current
system, which is much more strict, focuses on deploying customer
aggregates + le 24 & le 128, instead of enumerating all possible
de-aggregates that have been registered in the IRR (helps keep the
configuration file small and manageable, without sacrificing
reachability). And then see how we can add RPKI into the mix to make
things even simpler, if at all.

Mark.


Re: Route leak in Bangladesh

2015-07-01 Thread Mark Tinka


On 1/Jul/15 16:52, Nick Hilliard wrote:
> This is a strange sort of thing really.  There's no reason that a compiled
> prefix list of 250k entries should take up much RAM in a trie structure;
> there's no reason that a competently written parser shouldn't be able to
> handle 20 megs of prefix lists / sets in a trivial amount of time and
> there's no reason that writing a 20 meg configuration file should take long
> to write to disk / flash / etc.
>
> BIRD handles this in ultraquick time.  Even recent versions of Quagga can
> now suck + parse 10 megs of prefix filters in a second or two and write
> them out in less.
>
> But Junos / IOS / XR puke horribly.  What gives?

Nick, I think the concerns are two-fold:

1. The time it takes to process the trie.
2. How much physical space there is to support the configuration.

Remember some high-end Cisco routers only have 2MB of NVRAM. This could
get tested with a large prefix-list configuration. Junos may not have
much of a space issue since the configuration is stored on the compact
flash or HDD.

Trie compilation or process will be very OS-dependent, and how the
vendor has chosen to optimize that operation.

Mark.


Re: Route leak in Bangladesh

2015-07-01 Thread Nick Hilliard
On 01/07/2015 15:51, Mark Tinka wrote:
> I found RPSL complicated a few years ago, and sort of put that on the
> back-burner.

you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6 objects.  RPSL is not going to live up
to your expectations.

Nick




Re: Route leak in Bangladesh

2015-07-01 Thread Nick Hilliard
On 01/07/2015 15:12, Jared Mauch wrote:
>   I would like to see others participate in the dialog with vendors
> so we don't seem to be quite an outlier with "wow, you have really
> large configs".  The vendors haven't quite kept pace with the increase
> in density proportional to the number of configuration lines and
> it sure feels like we are the only people pushing them to improve.

This is a strange sort of thing really.  There's no reason that a compiled
prefix list of 250k entries should take up much RAM in a trie structure;
there's no reason that a competently written parser shouldn't be able to
handle 20 megs of prefix lists / sets in a trivial amount of time and
there's no reason that writing a 20 meg configuration file should take long
to write to disk / flash / etc.

BIRD handles this in ultraquick time.  Even recent versions of Quagga can
now suck + parse 10 megs of prefix filters in a second or two and write
them out in less.

But Junos / IOS / XR puke horribly.  What gives?

Nick




Re: Route leak in Bangladesh

2015-07-01 Thread Mark Tinka


On 1/Jul/15 16:12, Jared Mauch wrote:
>
>   I would like to see others participate in the dialog with vendors
> so we don't seem to be quite an outlier with "wow, you have really
> large configs".  The vendors haven't quite kept pace with the increase
> in density proportional to the number of configuration lines and
> it sure feels like we are the only people pushing them to improve.

I'm happy to help beat up the vendors (it's a favorite pass time of
mine), but I'll be honest, we don't particularly have this problem in
our network because - well, besides being a reasonably young operation -
we do the opposite where we request customers to provide their prefix
data, and we upload that into the network, together with strict AS_PATH
lists (and max-prefix to boot).

I found RPSL complicated a few years ago, and sort of put that on the
back-burner. I have looked at it less in recent times because I'm
putting quite a bit of work into RPKI (vendor implementation issues have
been slowing me down, though, but we're looking better compared to just
twelve months ago).

So perhaps if there are other operators on this list using RPSL to build
reasonably large configuration files that are testing the limits of
router code, I echo Jared's plea to beat up your vendors and make this a
priority, before we all get taken offline for the 3rd time in one year
by the next boo-boo.

And for anyone running Brocade, extra points if we can get them to
implement RPKI as well :-)...

Mark.


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Chris Adams
Once upon a time, Rubens Kuhl  said:
> Not quite. Reported crashes included 6.27, so it's possible that some other
> mitigating factor helped not to crash (like using SNTP instead of NTP,
> although there seems to be people with crashes using SNTP or no SNTP/NTP at
> all).

These are running Linux kernels, right?  Anybody know which version?  I
know the last couple of leap seconds hit (different) bugs in the Linux
kernel.  The 2012 bug was timer related and confused some user-space
applications, but the 2008 bug could cause a kernel deadlock (which this
sounds like).

-- 
Chris Adams 


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Rubens Kuhl
On Wed, Jul 1, 2015 at 11:15 AM, Michel Luczak  wrote:

> > I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28,
> 6.5 and other versions.
> >
> > Configured NTP Client in all of them.
> >
> > Anyone else had this problem?
>
> Apparently 6.27 was the safe version to have (no issues on our CRS and CCR
> routers).
>
>
>
Not quite. Reported crashes included 6.27, so it's possible that some other
mitigating factor helped not to crash (like using SNTP instead of NTP,
although there seems to be people with crashes using SNTP or no SNTP/NTP at
all).

Variations also include whether hardware watchdog was able to reboot the
box or it just froze (including frontal display not responding).

Rubens


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Michel Luczak
> I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 
> and other versions.
> 
> Configured NTP Client in all of them.
> 
> Anyone else had this problem?

Apparently 6.27 was the safe version to have (no issues on our CRS and CCR 
routers).

Regards, Michel



Re: Route leak in Bangladesh

2015-07-01 Thread Jared Mauch
On Wed, Jul 01, 2015 at 08:25:06AM +0200, Mark Tinka wrote:
> 
> 
> On 30/Jun/15 17:09, Job Snijders wrote:
> >
> > If you are a network providing transit to the leak originator mentioned
> > in the above paragraph, I believe a prefix based filter could have made
> > a big difference.
> 
> And therein lies the secret sauce.
> 
> Given that we've had an incident like this twice in the past month, I'm
> seriously concerned about the network operations of "top-tier" providers.

I'll say we certainly try hard to mitigate these issues.  It's
hard because while platitudes on this list don't cause IOS devices
to not send a full routing table by default (for example).

I would like to see others participate in the dialog with vendors
so we don't seem to be quite an outlier with "wow, you have really
large configs".  The vendors haven't quite kept pace with the increase
in density proportional to the number of configuration lines and
it sure feels like we are the only people pushing them to improve.

This combined with the number of devices that are doing
kinky routing to 'optmize' a network make it more likely that
something will cause damage.  rfc1925 2.(9)a applies.

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Rubens Kuhl
On Wed, Jul 1, 2015 at 10:17 AM, Mike Hammett  wrote:

> It looks to have only affected the CCR line and only those running the NTP
> and not the SNTP package.
>
>
That's Mikrotik's position, but reports of some users contradict their
version (both in the need for NTP and for only affecting CCR line),
although the NTP package is clearly a contributing factor.



Rubens


Re: REMINDER: LEAP SECOND

2015-07-01 Thread Mike Hammett
It looks to have only affected the CCR line and only those running the NTP and 
not the SNTP package. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Guilherme Ganascim"  
To: nanog@nanog.org 
Sent: Tuesday, June 30, 2015 8:08:28 PM 
Subject: Re: REMINDER: LEAP SECOND 

I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and 
other versions. 

Configured NTP Client in all of them. 

Anyone else had this problem? 


> On Jun 19, 2015, at 19:30, Baldur Norddahl  wrote: 
> 
> On 19 June 2015 at 23:58, Harlan Stenn  wrote: 
> 
>> Bad idea. 
>> 
>> When restarting ntpd your clocks will likely be off by a second, which 
>> will cause a backward step, which will force the problem you claim to be 
>> avoiding. 
>> 
> 
> If you are afraid that your routers will crash due to the leapsecond, then 
> it would help to disable the thing that you think will crash them. Even if 
> the router crashes when you enable it later on. Because then you can have 
> one router crash at a time and have it happen in a service window where you 
> are ready for it. Instead of having all routers in your whole network crash 
> at exactly the same time. 
> 
> Regards, 
> 
> Baldur 




Re: REMINDER: LEAP SECOND

2015-07-01 Thread Guilherme Ganascim
I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and 
other versions.

Configured NTP Client in all of them.

Anyone else had this problem?


> On Jun 19, 2015, at 19:30, Baldur Norddahl  wrote:
> 
> On 19 June 2015 at 23:58, Harlan Stenn  wrote:
> 
>> Bad idea.
>> 
>> When restarting ntpd your clocks will likely be off by a second, which
>> will cause a backward step, which will force the problem you claim to be
>> avoiding.
>> 
> 
> If you are afraid that your routers will crash due to the leapsecond, then
> it would help to disable the thing that you think will crash them. Even if
> the router crashes when you enable it later on. Because then you can have
> one router crash at a time and have it happen in a service window where you
> are ready for it. Instead of having all routers in your whole network crash
> at exactly the same time.
> 
> Regards,
> 
> Baldur



Re: Sacramento Outage.

2015-07-01 Thread Brooks Bridges

I suspect most people here also sub the outages lists

https://puck.nether.net/pipermail/outages/2015-June/007904.html

Brooks Bridges

On 6/30/2015 5:37 PM, Larry Sheldon wrote:


Is it odd that there is no mention of this even here?

http://www.wavebroadband.com/resources/outage/service.txt




Re: leap second outage

2015-07-01 Thread Justin Paine via NANOG
Any confirmation if the AWS outage was leap second-related?


Justin Paine
Head of Trust & Safety
CloudFlare Inc.
PGP KeyID: 57B6 0114 DE0B 314D


On Tue, Jun 30, 2015 at 8:32 PM, Dovid Bender  wrote:
> I read that and that at midnight local time since that's when you have the 
> extra second. I know a large carrier in Israel is down. Waiting for conf. If 
> it's leep second related.
>
> --Original Message--
> From: Stefan
> Sender: NANOG
> To: frnk...@iname.com
> Cc: nanog@nanog.org
> Subject: Re: leap second outage
> Sent: Jun 30, 2015 23:30
>
> This was supposed to have happened @midnight UTC, right? Meaning that we
> are past that event. Under which scenarios should people be concerned about
> midnight local time? Lots of confusing messages flying all over...
> On Jun 30, 2015 10:13 PM,  wrote:
>
>> We experienced our first leap second outage -- our SHE (super head end) is
>> using (old) Motorola encoders and we lost those video channels.  They
>> restarted all those encoders to restore service.
>>
>> Frank
>>
>>
>
> Regards,
>
> Dovid


Re: Sacramento Outage.

2015-07-01 Thread Duga
Was surprised too.

http://www.usatoday.com/story/tech/2015/06/30/california-internet-outage/29521335/
 





> On 30 Jun 2015, at 19:37, Larry Sheldon  wrote:
> 
> 
> Is it odd that there is no mention of this even here?
> 
> http://www.wavebroadband.com/resources/outage/service.txt
> -- 
> sed quis custodiet ipsos custodes? (Juvenal)



Re: leap second outage

2015-07-01 Thread Jimmy Hess
On Wed, Jul 1, 2015 at 12:38 AM, Mikael Abrahamsson  wrote:
> quickly. Either we should abolish the leap second or we should make leap
> second adjustments (back and forth) on a monthly basis to exercise the code.

See  maybe there should some day be building codes for
commercially marketed software  that provide minimum independent
formal testing to be done by licensed independent testers,  including
leap seconds and such. ^_^

The leap second issues are possibly rare and intermittent,  therefore,
 having a few per month  is not necessarily giving adequate exposure
to code paths that may go wrong during an insert/del event.

There's never been a negative leap second, only insertions, but how
deletions are implemented  might expose new bugs, since there hasn't
been one before,  And you can only have one leap per 24 hours,
positive or minus,  pick one.

& Shouldn't this kind of 'exercise'  be done  during the QA process
before releasing new system software,   rather than mucking with clock
accuracy?

There is a recent article with some Leap Second  'stress testing' code:
  https://access.redhat.com/articles/199563


Readily available test methods are available,  there ought to be
little legitimate excuse for anyone writing serious software that has
long-running processes or threads   not to include  evaluation for
possible leap second  issues  and other possible clock-related issues
such as clock stepping, DST, and Year 2038 in their standard smoke
tests

> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
--
-JH


RE: leap second outage

2015-07-01 Thread frnkblk
Yes, happened at 7 pm Central (0:oo UTC).

 

From: Stefan [mailto:netfort...@gmail.com] 
Sent: Tuesday, June 30, 2015 10:30 PM
To: frnk...@iname.com
Cc: nanog@nanog.org
Subject: Re: leap second outage

 

This was supposed to have happened @midnight UTC, right? Meaning that we are 
past that event. Under which scenarios should people be concerned about 
midnight local time? Lots of confusing messages flying all over... 

On Jun 30, 2015 10:13 PM, mailto:frnk...@iname.com> > wrote:

We experienced our first leap second outage -- our SHE (super head end) is
using (old) Motorola encoders and we lost those video channels.  They
restarted all those encoders to restore service.

Frank



Re: leap second outage

2015-07-01 Thread Johnny Eriksson
Mikael Abrahamsson  wrote:
> This is similar to the jiffycounter wrapping, since this doesn't happen 
> that often, it's not commonly tested for. Good way is to start the jiffy 
> counter so it wraps after 10 minutes of uptime. That way you'll run into 
> any bugs quickly. Either we should abolish the leap second or we should 
> make leap second adjustments (back and forth) on a monthly basis to 
> exercise the code.

You could do this, move back on even-numbered months and forward on odd.

Any real adjustment could be done via inhibiting the monthly change...

> This is a hard sell though...

'fraid so.

> Mikael Abrahamssonemail: swm...@swm.pp.se

--Johnny