Re: Interconnection Track

[Bevan Slattery]

Hi!  Love the interconnection track.  Great stuff.  But I can't help but think 
limiting interconnection to the peering/IXP view seems to be looking at 
interconnection from the rear view mirror.

I just think that changing the track name from peering/IXP to "Interconnection" 
has the optionality to be a bit more looking forward.  Interconnection in the 
network world is becoming more sophisticated and important than just old school 
peering (hearing the gasps of horror from the Nanog peering cabal at that 
statement) ;)

Cheers

[b]

> On 17 Apr 2017, at 9:52 pm, Mehmet Akcin  wrote:
> 
> Thank you very much for sending privately and publicly an overwhelming
> number of suggestions. I do appreciate you taking time and writing things
> up in detail. I am doing my best with help of Greg H from PC to put these
> thoughts on paper.
> 
> It looks like there is a great interest to make this track focusing on
> tooling and automation as well as introductions of new game changing ixps.
> 
> I would like to invite all new IXPs to come and talk about what they offer
> (ie denver-ix)
> 
> I also would like to invite any existing IXPs to announce price discounts
> to their services. This is the only update we will have time in this
> interconnection track. Unfortunately no graphs, other updates.
> 
> Few questions, Seattle is beautiful in summer and I hope to have many of
> you in person in beautiful washington state, but for those who can't
> travel, should we record / live stream this session? (Historically we did
> keep peering track off the grid... i believe)
> 
> Would it be interesting to focus on peering challenges globally or strictly
> focus on north america?
> 
> Last but not least, If you have a tool you want to talk about in
> interconnection track that is directly involved with peering setup, etc.
> please do contact me offlist.
> 
> Cheers! Looking forward to it.
> 
>> On Sat, Apr 1, 2017 at 1:36 PM Mehmet Akcin  wrote:
>> 
>> Hello,
>> 
>> As promised few months ago publically I have volunteered to bring together
>> content to have Peering Track back to agenda. Now called "Interconnection
>> Track"
>> 
>> I would like to ask those who will attend, have attended in person in the
>> past or those who have organized similar events to chime in and help
>> suggest topics to cover in this 90 min session.
>> 
>> I must say, Interconnection Track has been a major part if NANOG for many
>> years. We have watched those who we consider as legends to discuss very
>> important topics there.
>> 
>> Please try to make your suggestion in order of importance for you as well
>> as from community.
>> 
>> I can try to do my best with help of few folks to bring this track back
>> but you can help make it even better so please take a moment and send me
>> your suggestions.
>> 
>> Thanks in advance!
>> 
>> Mehmet
>> 

Re: IX in Iran by TIC

[Bevan Slattery]

Yes Scott. It was on topic and genuine in the approach, but understand the 
nuances around it.  I did declare the interest in the second email when a more 
detailed explainer was included with a request to take it offline.  That felt 
like I was stepping over the mark for the sake of pointing out the technical 
differences between peeringdb and XX hence the declaration and wanting 
to take it off line to not fill people's in-boxes.

That leads back to the first point to of doing it in the first place to avoid 
this.  Apologies.

Cheers

[b]

> On 13 Jul 2016, at 6:23 AM, Scott Weeks  wrote:
> 
> 
> 
> --
>> Might be worthwhile to also look at throwing your
> fabric/IX on X www.xx.com .  
> --
> 
> https://www.nanog.org/list
> 
> "5.Product marketing is prohibited"
> 
> It appears from a web search that you are affiliated 
> with the company you're speaking about.
> 
> scott

Re: IX in Iran by TIC

[Bevan Slattery]

Hi James,

I hear you.  Massive fan of peeringdb and this isn't about replacing that
(in fact love to simply integrate).

Peeringdb provides a list of registered peers in a DC that has an IX.
Great for looking at where to peer.

Cloud Scene looks at all providers (4,000+) whether they are peering or not
in any DC (4,800+ DC's)  whether they are IX enabled or not.  It is aimed
to give a full view of service providers in each facility around the
world.  Good list and growing over time.  A more detailed example is
below.  Important to note that if you are a someone that acquires/sells
backhaul, L2 tails, transit, international capacity, voice etc. then
peeringdb is not really the place to go.

Agree in this instance peeringdb is definitely the first stop.  But no harm
in covering all bases for people who are looking for colo in that market
and find the fact one DC has an IX to be of value.

Cheers

[b]

PS:  Declaration that I started Cloud Scene to help me understand better
what networks were where.  Happy to take this offline after this explainer.

EXAMPLE 1.
There maybe for example an enterprise  that is looking for a service
provider in a facility (XYZ in NY for example) but that provider actually
"peers" their transit routers at the ABC facility down the street.  Because
the provider doesn't peer in XYZ there is no public record of them being
there in peering DB.  Providers are in heaps of DC's/locations that they
just don't peer.  So they effectively have no central location where people
can see that they are "available to service".  This is more of a directory
of where providers are and what services they can provide.

EXAMPLE 2.
There are also now heaps of facilities that have no IX/fabric in them at
all.  Cloud Scene gives people access to understand who is in there which
is great from a network planning perspective to see which facility/ies they
may wish to instal their kit in.  Also it's good for IX's to look at where
they may extend their infra into.  In the next few weeks/months major cloud
providers will be plugged in too to give a more complete view of the cloud
scene in any city.

Cheers

[b]

On 12 July 2016 at 23:01, James Bensley <jwbens...@gmail.com> wrote:

> On 12 July 2016 at 13:46, Bevan Slattery <be...@slattery.net.au> wrote:
> > Great work.  Might be worthwhile to also look at throwing your fabric/IX
> on
> > Cloud Scene www.cloudscene.com .  Provides visibility for people looking
> > for DC's, providers and fabrics that just aren't limited to IX locations
> or
> > peers.
> >
> > Cheers
>
> That's a nifty site but isn't it largely overlapping with peeringdb
> which is already more established?
>
> Just my two pence.
>
> James.
>

Re: IX in Iran by TIC

[Bevan Slattery]

Hi James,

I hear you.  Massive fan of peeringdb and this isn't about replacing that.

Peeringdb provides a list of registered peers in a DC that has an IX.
Great for looking at where to peer.

Cloud Scene looks at all providers (4,000+) whether they are peering or not
in any DC (4,800+ DC's)  whether they are IX enabled or not.  It is aimed
to give a full view of service providers in each facility around the
world.  Good list and growing over time.  A more detailed example of the
areas of differentiation is below.  Important to note that if you are a
someone that acquires/sells backhaul, L2 tails, transit, international
capacity, voice etc. then peeringdb is not really the place to get a
detailed list.

Agree in this instance peeringdb is definitely the first stop.  But no harm
in covering all bases for people who are looking for colo in that market
and find the fact one DC has an IX to be of value.

Cheers

[b]

EXAMPLE 1.
There maybe for example an enterprise  that is looking for a service
provider in a facility (XYZ in NY for example) but that provider actually
"peers" their transit routers at the ABC facility down the street.  Because
the provider doesn't peer in XYZ there is no public record of them being
there in peering DB.  Providers are in heaps of DC's/locations that they
just don't peer.  So they effectively have no central location where people
can see that they are "available to service".  This is more of a directory
of where providers are and what services they can provide.

EXAMPLE 2.
There are also now heaps of facilities that have no IX/fabric in them at
all.  Cloud Scene gives people access to understand who is in there which
is great from a network planning perspective to see which facility/ies they
may wish to instal their kit in.  Also it's good for IX's to look at where
they may extend their infra into.  In the next few weeks/months major cloud
providers will be plugged in too to give a more complete view of the cloud
scene in any city.

On 12 July 2016 at 23:01, James Bensley <jwbens...@gmail.com> wrote:

> On 12 July 2016 at 13:46, Bevan Slattery <be...@slattery.net.au> wrote:
> > Great work.  Might be worthwhile to also look at throwing your fabric/IX
> on
> > Cloud Scene www.cloudscene.com .  Provides visibility for people looking
> > for DC's, providers and fabrics that just aren't limited to IX locations
> or
> > peers.
> >
> > Cheers
>
> That's a nifty site but isn't it largely overlapping with peeringdb
> which is already more established?
>
> Just my two pence.
>
> James.
>

Re: IX in Iran by TIC

[Bevan Slattery]

Great work.  Might be worthwhile to also look at throwing your fabric/IX on
Cloud Scene www.cloudscene.com .  Provides visibility for people looking
for DC's, providers and fabrics that just aren't limited to IX locations or
peers.

Cheers

[b]

On 28 June 2016 at 18:49, Marty Strong via NANOG  wrote:

> Can’t agree more about putting your IXPs on PeeringDB, it’s my first port
> of call when looking at locations to expand to.
>
> Also, I would say to add the data centres too, to give a better idea of
> where the IXPs are physically located.
>
> Regards,
> Marty Strong
> --
> CloudFlare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
>
> https://www.peeringdb.com/asn/13335
>
> > On 28 Jun 2016, at 02:16, Martin Hannigan  wrote:
> >
> > On Mon, Jun 27, 2016 at 7:05 AM, Shahab Vahabzadeh
> >  wrote:
> >> Hello Everybody,
> >> I am here to announce that TIC in Iran launched Neutral Internet
> Exchange
> >> Points.
> >> Right now we have four in:
> >>
> >>   - Tehran (tehran-ix.ir)
> >>   - Shiraz (shiraz-ix.ir)
> >>   - Tabriz (tabriz-ix.ir)
> >>   - Mashhad (mashhad-ix.ir)
> >>
> >> Currently we have near 45Gbps traffic on it but it will increase to
> 100Gbps
> >> within two months. Content Providers activating their BGP peering with
> >> members one by one.
> >>
> >> Also I have something interesting for you around the world, TIC is
> >> launching a International IX in Chabahar called Chabahar IX (
> chabahar-ix.ir)
> >> which can be interesting for T1 ISPs or Content Providers like Akamai,
> >> Amazon, Google, Limelight, Cloudflare and etc.
> >>
> >
> > Thanks, I'll get this to the right people internally (AKAMAI). In the
> > meantime, there are a number of peering groups on Facebook (global
> > peering forum, peering forum, peeringDB) that you may want to join to
> > discuss this as well.
> >
> > Don't forget to register in peeringDB:
> >
> > https://www.peeringdb.com/search?q=IRAN
> >
> > And finally, great pictures!
> http://www.tehran-ix.ir/fa/news/ixp-workshop
> >
> > Good luck!
> >
> > Best,
> >
> > Martin
>
>

Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS

[Bevan Slattery]

***disclaimer - info on subject from a shareholder*** :)

Yeah.  In addition to Equinix and a few others  Megaport is expanding pretty 
quickly in US at present.  30+ locations 7 US markets.  Worth a look if you are 
trying to get your Azure and AWS fix from a single provider via 100% SDN, API 
driven platform (also and other services such as AMS-IX peering).  Interesting 
differences such as a flat rate Virtual X-Connect regardless of speed and where 
the other end of the circuit is in the metro.  Day/month/year from 1mbps to 
10gbps.  Been doing elastic interconnects since 2013.

https://www.megaport.com/services/megaport_enabled_locations

Well known in Asia but less so in US/NANOG hence the first and last public post 
about this.

Anyway, maybe worth a look.

Cheers

B

> On 2 Mar 2016, at 9:28 AM, Dave Cohen  wrote:
> 
> I can confirm that AWS (and Equinix, by extension, from a facility operator
> perspective) permit carriers to have multiple end users share a physical
> interface into the AWS gateway. The key is whether the providers that are
> permitted into the DX environment (I believe AWS has limited the list to
> only 7 or 8 in total - anyone else is reselling capacity off of those
> carriers) are willing to deal with the constraints of that configuration -
> essentially that the carrier needs to take responsibility of engaging
> directly with AWS to associate the EVC on the provider interface with the
> VPC on the AWS interface. I can confirm that at least one provider other
> than Equinix will do this. Point being, it's not an AWS restriction as much
> as whether the provider is willing to get its hands a bit dirtier. My $.02
> at least.
> 
> - Dave
> 
>> On Tue, Mar 1, 2016 at 7:59 PM, Mike Hammett  wrote:
>> 
>> I haven't heard it from the horse's mouth, but I heard that the only way
>> to have customers share an AWS DX (apparently) cross connect is through
>> Equinix's cloud exchange service. Can anyone confirm that? It doesn't seem
>> right that I could transport people to AWS all day long if they buy their
>> own cross connect, but once we share, I have to go through someone offering
>> a competitive service.
>> 
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>> 
>> - Original Message -
>> 
>> From: "Michael O'Connor" 
>> To: "Jay R. Ashworth" 
>> Cc: "North American Network Operators' Group" 
>> Sent: Tuesday, March 1, 2016 2:41:35 PM
>> Subject: Re: AWS Direct Connect - Peering VPCs to Tier 1's and MPLS
>> 
>> Jay,
>> 
>> VPC is supported over IPsec if your public path is sufficient into the AWS
>> cloud.
>> 
>> AWS shortens DirectConnect to DX not DC for some reason.
>> 
>> The AWS DirectConnect service is built on 10G infrastructure so using
>> potentially larger interconnects over public peerings with IPsec could be
>> advantageous.
>> 
>> DX requires fiber cross connects in addition to any other AWS peerings that
>> you may have at a particular location.
>> 
>> -Mike O'Connor
>> 
>> 
 On Tue, Mar 1, 2016 at 12:16 PM, Jay R. Ashworth  wrote:
>>> 
>>> Just got this dropped on my desk an hour ago, and I'm not finding as much
>>> material online as I might have hoped for...
>>> 
>>> It looks like the easiest solution is to just hang a router/firewall at
>>> Equinix Ashburn and AWS-DC to that, and then peer it to carriers both IP
>>> and
>>> MPLS; is there a "native" way to do that from an AWS VPC instead?
>>> 
>>> Any public or private replies cheerfully accepted; will summarize what I
>>> can to the list.
>>> 
>>> 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
>> 
>> 
>> 
>> --
>> Michael O'Connor
>> ESnet Network Engineering
>> m...@es.net
>> 631 344-7410
> 
> 
> -- 
> - Dave Cohen
> eM: craetd...@gmail.com
> AIM: dCo says
> 
> 
> -- 
> - Dave Cohen
> eM: craetd...@gmail.com
> AIM: dCo says

Re: Shared cabinet "security"

[Bevan Slattery]

Sorry. I'm not sure I get from which angle you are coming at this from.  Happy 
to clarify  for you and anyone interested if you can help me out here.

Cheers

[b]

> On 13 Feb 2016, at 12:58 PM, Mike Hammett <na...@ics-il.net> wrote:
> 
> There are more options when you're not just using someone else's datacenter.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> From: "Bevan Slattery" <be...@slattery.net.au>
> To: "Mike Hammett" <na...@ics-il.net>
> Cc: "North American Network Operators' Group" <nanog@nanog.org>
> Sent: Friday, February 12, 2016 4:44:34 PM
> Subject: Re: Shared cabinet "security"
> 
> In a past life we worked with our supplier to create physically separate 
> sub-enclosures.1/2 and 1/3.  Able to build in a separate and secure cable 
> path for interconnects to the meet-me-room and connection to power supplies.
> 
> Can be done and I think there are now rack suppliers that do this as 
> standard.  Been out of DC space for a few years now.
> 
> [b]
> 
> > On 13 Feb 2016, at 6:58 AM, Mike Hammett <na...@ics-il.net> wrote:
> > 
> > 
> > That moment when you hit send and remember a couple things… 
> > 
> > Of course labeling of the cables. 
> > 
> > Maybe colored wire loom for fiber and DACs in the vertical spaces to go 
> > along with the previously mentioned color scheme? 
> > 
> > 
> > 
> > 
> > - 
> > Mike Hammett 
> > Intelligent Computing Solutions 
> > http://www.ics-il.com 
> > 
> > Midwest-IX 
> > http://www.midwest-ix.com 
> > 
> > - Original Message -
> > 
> > From: "Mike Hammett" <na...@ics-il.net> 
> > To: "North American Network Operators' Group" <nanog@nanog.org> 
> > Sent: Friday, February 12, 2016 2:53:17 PM 
> > Subject: Re: Shared cabinet "security" 
> > 
> > 
> > I am finding a bunch of covers for the front. I do wish they stuck out more 
> > than an inch (like two). 
> > http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx
> >  
> > 
> > It looks like these guys stick out 1.5”. That may be workable… 
> > http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf
> >  
> > 
> > I guess those covers are really only useful for servers. That really 
> > wouldn’t work with a switch\router. Switches and routers are going to be 
> > the bulk of what we’re dealing with. 
> > 
> > I am finding locking power cables, but that seems to be specific to the PDU 
> > you’re using as it requires the other half of the lock on the PDU. 
> > 
> > I did come across colored power cords. I wonder with some enforced cable 
> > management, colored power cables, etc. we would have “good enough”? You get 
> > some 1U or 2U cable organizers, require cables to be secured to the 
> > management, vertical cables in shared spaces are bound together by 
> > customer, color of Velcro matches color of the power cord? Blue customer, 
> > green customer, red customer, etc. Could do the cat6 patch cables that way 
> > too, but that gets lost when moving to glass or DACs. 
> > 
> > I thought about a web cam that would record anyone coming into the cabinet, 
> > but Equinix doesn’t really allow pictures in their facilities, so that’s 
> > not going to fly. Door contacts should be helpful for an audit log of at 
> > least when the doors were opened or closed. 
> > 
> > Financial penalty from the violator to the victim if there’s an uh oh? 
> > 
> > I’m not trying to save someone from themselves. I’m not trying to lock the 
> > whole thing down. Just trying to prevent mistakes in a shared space. 
> > 
> > 
> > 
> > 
> > - 
> > Mike Hammett 
> > Intelligent Computing Solutions 
> > http://www.ics-il.com 
> > 
> > Midwest-IX 
> > http://www.midwest-ix.com 
> > 
> > - Original Message - 
> > 
> > From: "Mike Hammett" <na...@ics-il.net> 
> > To: "North American Network Operators' Group" <nanog@nanog.org> 
> > Sent: Wednesday, February 10, 2016 8:59:08 AM 
> > Subject: Shared cabinet "security" 
> > 
> > I say "security" because I know that in a shared space, nothing is 
> > completely secure. I also know that with enough intent, someone will 
> > a

Re: Shared cabinet "security"

[Bevan Slattery]

In a past life we worked with our supplier to create physically separate 
sub-enclosures.1/2 and 1/3.  Able to build in a separate and secure cable path 
for interconnects to the meet-me-room and connection to power supplies.

Can be done and I think there are now rack suppliers that do this as standard.  
Been out of DC space for a few years now.

[b]

> On 13 Feb 2016, at 6:58 AM, Mike Hammett  wrote:
> 
> 
> That moment when you hit send and remember a couple things… 
> 
> Of course labeling of the cables. 
> 
> Maybe colored wire loom for fiber and DACs in the vertical spaces to go along 
> with the previously mentioned color scheme? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Mike Hammett"  
> To: "North American Network Operators' Group"  
> Sent: Friday, February 12, 2016 2:53:17 PM 
> Subject: Re: Shared cabinet "security" 
> 
> 
> I am finding a bunch of covers for the front. I do wish they stuck out more 
> than an inch (like two). 
> http://www.middleatlantic.com/~/media/middleatlantic/documents/techdocs/s_sf%20series%20security%20covers_96-035/96_035s_sf.ashx
>  
> 
> It looks like these guys stick out 1.5”. That may be workable… 
> http://www.lowellmfg.com/tinymce/jscripts/tiny_mce/plugins/filemanager/files/1717-SSCV.pdf
>  
> 
> I guess those covers are really only useful for servers. That really wouldn’t 
> work with a switch\router. Switches and routers are going to be the bulk of 
> what we’re dealing with. 
> 
> I am finding locking power cables, but that seems to be specific to the PDU 
> you’re using as it requires the other half of the lock on the PDU. 
> 
> I did come across colored power cords. I wonder with some enforced cable 
> management, colored power cables, etc. we would have “good enough”? You get 
> some 1U or 2U cable organizers, require cables to be secured to the 
> management, vertical cables in shared spaces are bound together by customer, 
> color of Velcro matches color of the power cord? Blue customer, green 
> customer, red customer, etc. Could do the cat6 patch cables that way too, but 
> that gets lost when moving to glass or DACs. 
> 
> I thought about a web cam that would record anyone coming into the cabinet, 
> but Equinix doesn’t really allow pictures in their facilities, so that’s not 
> going to fly. Door contacts should be helpful for an audit log of at least 
> when the doors were opened or closed. 
> 
> Financial penalty from the violator to the victim if there’s an uh oh? 
> 
> I’m not trying to save someone from themselves. I’m not trying to lock the 
> whole thing down. Just trying to prevent mistakes in a shared space. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message - 
> 
> From: "Mike Hammett"  
> To: "North American Network Operators' Group"  
> Sent: Wednesday, February 10, 2016 8:59:08 AM 
> Subject: Shared cabinet "security" 
> 
> I say "security" because I know that in a shared space, nothing is completely 
> secure. I also know that with enough intent, someone will accomplish whatever 
> they set out to do regarding breaking something of someone else's. My concern 
> is mainly towards mitigation of accidents. This could even apply to a certain 
> degree to things within your own space and your own careless techs 
> 
> If you have multiple entities in a shared space, how can you mitigate the 
> chances of someone doing something (assuming accidentally) to disrupt your 
> operations? I'm thinking accidentally unplug the wrong power cord, patch 
> cord, etc. Accidentally power off or reboot the wrong device. 
> 
> Obviously labels are an easy way to point out to someone that's looking at 
> the right place at the right time. Some devices have a cage around the power 
> cord, but some do not. 
> 
> Any sort of mesh panels you could put on the front\rear of your gear that you 
> would mount with the same rack screw that holds your gear in? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> 

Re: Rack Locks

[Bevan Slattery]

Hi Kevin,

Well I¹m happy to provide my experience.  When I decided to build a new
data centre business back in 2010, I started with a simple premise.  That
the core data centre experience must be controlled by browser and phone.
That system was (and still is called) ONEDC.

A key component of this is for the ability for our customers to:

*  Remotely lock and unlock racks from their phone (great for remote hands)
*  Use Facility Prox swipe cards to lock/unlock racks in facility at swipe
points at end of aisle (did that back in 2008)
*  Needed to provide users/customers the ability to add/remove their staff
(and their customers) access to racks including time of day, time of week
access as well as a per rack access granular level (handy if you have 10
racks in a row with 5 different customers so you can limit their access,
or a contractor with time of day access such as a tape swap out service)
*  Full data output allowing me to provide real time audit logs (yes audit
logs for security).

We did some pretty cool stuff with power management/measurement etc. and
made a little video 3 years ago (my kids are playing soccer in the
background ;))
https://www.youtube.com/watch?v=58vvIJOfBcE  The product has come on a lot
since it launched (I left the company 2 years ago now).


So what did we do.  I used to use a relay type system in 2007-10 in my
previous data centre life.  It¹s pretty good but a bit ³industrial².  It¹s
also so 2007 (even 1990) and doesn¹t scale well when you are trying to do
3,000 racks and 6,000 doors per facility.  I looked at the APC electronic
locking system, but the big issue is that some fool in product decided to
remove radius authentication, allowing a decent independent
command/control capability.

The product I went with was TZ rack locking because:
*  Solid product with background in remote post office/delivery locking
systems
*  Use ³Shape Memory Alloy² system in which the lock mechanism is a fluid
type alloy that changes shape with voltage, rather than old school
mechanical locking
*  They look really cool, fit most racks and have some great features
(like delayed lock for 5 seconds in case you realise you left your screw
driver in the rack :))
*  Provided API Access so I can integrate it into our rack management
system (ONEDC)
*  Full log interface

They will try to ship you the entire product suite, but if you can commit
to decent scale they are flexible (API access, support etc.) and let you
integrate into the locks.  I think NEXTDC has probably deployed about
10,000 doors and one of the old team at NEXTDC is now working for TZ and
he eats this stuff for breakfast.  I can pass on his details if you wish.

Anyway I can definitely recommend TZ http://ixp.tz.net .  In looking at
their website their product set and locking systems have expanded in the
last 2 years or so.  Hope this helps.


Cheers

[b]


On 21/11/2015 11:55 am, "NANOG on behalf of Jimmy Hess"
 wrote:

>On Fri, Nov 20, 2015 at 2:37 PM, Kevin Burke
> wrote:
>> What kind of experience do people have with rack access control systems
>> (electronic locks)?  Anything I should pay attention to with the
>
>Overpriced, overkill for most real-world uses?
>High-Tech technology for technology's sake?
>
>Avoid them if you can. Within six months or so,  at least once,there
>will
>probably be some glitch delaying or denying required prompt access.
>[snip]
>
>> Background
>> We have half a dozen racks, mostly ours.  Mostly I want something to log
>> who opened what door when.  Cooling overhaul is next on the list but one
>
>It probably makes sense if there are more than a handful of people with
>unobserved physical access, and high frequency of access,  or there's a
>trust issue, high-risk consideration.Or  you have to satisfy a
>"Checkbox Auditor".
>
>You're not going to be able to look at a log and see Joe opened it at
>2:45AM
>12 months ago,  and ever since then,  the servers are not quite right.
>
>Consider manual procedures
>
>Example:   Electronic access control to the actual rooms.
>A Robo-Key system (RKS),  Keyvault, or Realtor lockboxes on
>each server rack ^_^
>
>Physical locks on cabinets.Key vault that supports multiple
>combinations.
>Then you don't need exotic hardware,  just a good lock, and sound key
>control
>procedures.
>
>I am imaging if you need to automate control of individual keys;
>that there will be more competing solutions for this than specialty rack
>locks.
>
>Logging procedures for key access...
>Send an e-mail when someone opens the vault.
>
>Simple magnetic reed switches on all cabinet doors.
>Send an e-mail when a cabinet door is opened.
>Quite a few standard alarm panels can do those types of things.
>
>Assign someone to periodically check  handwritten logs and check for
>discrepancies. ^_^
>
>> at a time.  Even with cameras those janky make nobody happy.
>-- 
>-JH