Re: Cloud backups versus lightning strikes

2015-08-19 Thread Karl Auer
On Thu, 2015-08-20 at 11:38 +1000, Matt Palmer wrote: > Backups are never optional. Love the phrasing too - "permanently lost access to their data". Their data is not lost, not gone, not destroyed, oh no! It's still there, somewhere, but they will just never, ever be able to access it again. Mayb

Re: Cloud backups versus lightning strikes

2015-08-19 Thread Matt Palmer
On Wed, Aug 19, 2015 at 08:44:03PM -0400, Sean Donelan wrote: > As the saying goes, cloud computing is just someone else's computer. Always > backup your cloud backups... in your backup. This was data loss on GCE "persistent disks" (equivalent to AWS EBS), not archival storage. Hopefully very few

Cloud backups versus lightning strikes

2015-08-19 Thread Sean Donelan
As the saying goes, cloud computing is just someone else's computer. Always backup your cloud backups... in your backup. Google's spokesperson used the percentage statistic to avoid how much data was lost. Other cloud providers have also lost customer data due to various problems. While a we

Suddenlink: Texas panhandle

2015-08-19 Thread Blair Trosper
They apparently experienced massive fiber cuts last night and are still 100% down. Anyone know anything about this?

Re: Peering + Transit Circuits

2015-08-19 Thread Andy Davidson
Hi, Max -- On 19/08/2015 17:36, Max Tulyev wrote: >My solution is: > >1. Don't care. >2. If some peer steal your transit, and it is noticeable amount of >traffic causing some problems for you - investigate and terminate that peer. Unless this bandwidth fraud is taking place over a public p

Re: Peering + Transit Circuits

2015-08-19 Thread Jon Lewis
On Wed, 19 Aug 2015, Max Tulyev wrote: My solution is: 1. Don't care. 2. If some peer steal your transit, and it is noticeable amount of traffic causing some problems for you - investigate and terminate that peer. You forgot 3. Publicly shame on NANOG so that others will think twice before p

Re: Peering + Transit Circuits

2015-08-19 Thread Max Tulyev
My solution is: 1. Don't care. 2. If some peer steal your transit, and it is noticeable amount of traffic causing some problems for you - investigate and terminate that peer. On 18.08.15 15:29, Tim Durack wrote: > Question: What is the preferred practice for separating peering and transit > circu

Re: [c-nsp] Peering + Transit Circuits

2015-08-19 Thread Nick Hilliard
On 18/08/2015 22:10, William Herrin wrote: > This technique described isn't URPF, it's simple destination routing. > The routes I offer you via BGP are the only routes in my table, hence > the only routes I'm capable of routing. If you send me a packet for a > _destination_ I didn't offer to you, I