Re: DataCenter color-coding cabling schema

[Valdis . Kletnieks]

On Sun, 13 Mar 2016 22:21:48 -0400, "Oliver O'Boyle" said:
> Just place a piece of tape under the padding and it won't slide anymore. 5
> seconds of extra work per end, though.

I dunno. Your dexterity must be better than mine.  I'd have trouble digging up
the roll of tape, removing a section, putting the tape roll down, and applying
the tape to the cable, all in 5 seconds.

Especially if you drop it and it manages to bounce through a cutout in the
raised floor.  That's got to be the single best reason for overhead cabling. :)


pgpoIbis1nH3z.pgp
Description: PGP signature

Re: DataCenter color-coding cabling schema

[Oliver O'Boyle]

Just place a piece of tape under the padding and it won't slide anymore. 5
seconds of extra work per end, though.

On Sun, Mar 13, 2016 at 9:57 PM, Owen DeLong  wrote:

> The only problem I’ve had with those is that they tend to slide down the
> fiber and you can
> end up having to trace the fiber to find the label which sort of defeats
> the purpose.
>
> Owen
>
> > On Mar 13, 2016, at 18:33 , Nick Pratley <
> nick.prat...@serversaustralia.com.au> wrote:
> >
> > Hi Baldur,
> >
> > Equinix in Sydney use the below, for Cross Connects.
> >
> > Goes around the fiber to pad it out, and the label keeps it on the fiber.
> >
> > http://www.cableorganizer.com/panduit/labelcore-cable-id-sleeve/
> >
> > Been meaning to order some for internal use, too.
> >
> > Nick
>
>


-- 
:o@>

Re: Juniper MX Sizing

[Colton Conor]

Brad,

Did you ever get the numbers for the MX480?

On Fri, Dec 5, 2014 at 3:10 PM, Brad Fleming  wrote:

> We haven’t received the MX480 gear yet (POs just went in about a week
> ago). But we tested MX960s with the same RE-S-1800x4 w/ 16GB RAM RIB+FIB
> convergence time was roughly 45sec. We never worried about getting a super
> accurate time for the MX960 because even an “eye test” showed it was fast
> enough for our application and we were much more concerned with other parts
> of the box. Also, we had inline-flow reporting configured on the MX960.
> Actually, the MX960’s had a full, production-ready config while the MX104
> was tested with a stripped down after we discovered the slow convergence.
>
> Once we get some MX480s on the bench I’ll report back.
>
>
> > On Dec 5, 2014, at 2:35 PM, Shawn Hsiao  wrote:
> >
> >
> > MX480 is also not instantaneous, so the same problem applies.   Brad, do
> you have the number for MX480 for comparison?
> >
> > What we decided was, given both models suffer the same problems, just
> different duration, we decided to mitigate the problem and not spending the
> money.
> >
> > Thanks.
> >
> >
> >
> > On Dec 5, 2014, at 3:01 PM, Brad Fleming  wrote:
> >
> >> Then you should look for something other then the MX104.
> >>
> >> In our testing an MX104 running Junos 13.3R4 with a single, full feed
> took about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms
> RTT away and (2) update the FIB with all entries. This performance was
> observed with single RE and dual RE and without any excess services
> running. If we added inline-flow sampling to the device full convergence
> took closer to 5min 45sec in our lab. Efforts to bring the convergence time
> down (without filtering ingress advertisements) with the assistance of JTAC
> proved unsuccessful.
> >>
> >> We decided to “bite the bullet” and procure MX480s instead but
> obviously that’s not possible for everyone. If the MX480 is out of the
> question a Brocade CER Premium is an option. We have 3 in production and
> see very attractive convergence times; however, they have a more limited
> feature set and you’ll want to understand how their FIB memory scales.
> Apologies, I don’t know the Cisco equivalent from the ASR line these days
> but I’m sure others on the list could help out.
> >>
> >>
> >>> On Dec 5, 2014, at 11:45 AM, Graham Johnston 
> wrote:
> >>>
> >>> Shawn,
> >>>
> >>> It's more about FIB than RIB as I am concerned about the time it takes
> until MPCs have updated route information after large scale changes in
> routes learned via BGP.
> >>>
> >>> Graham Johnston
> >>> Network Planner
> >>> Westman Communications Group
> >>> 204.717.2829
> >>> johnst...@westmancom.com
> >>> think green; don't print this email.
> >>>
> >>> -Original Message-
> >>> From: Shawn Hsiao [mailto:phs...@tripadvisor.com]
> >>> Sent: Friday, December 05, 2014 11:30 AM
> >>> To: Graham Johnston
> >>> Cc: nanog@nanog.org
> >>> Subject: Re: Juniper MX Sizing
> >>>
> >>>
> >>> Is your sizing concern just for the RIB, or also for FIB to sync up?
>  The latter was a problem for us, but not the former.   We also have
> inline-jflow turned on and that is still a work-in-progress in terms of
> impacting performance.
> >>>
> >>> We are using MX104 for similar purposes for many months now, and with
> some tweaks in our procedures and configurations we found it to be
> acceptable.MX104 may not be able to process routes as fast as MX480,
> but MX480 is also not instantaneous either so similar risks exist.
> >>>
> >>>
> >>>
> >>> On Dec 5, 2014, at 11:59 AM, Graham Johnston 
> wrote:
> >>>
>  I am wondering if anyone can provide their real world experience
> about sizing Juniper MX routers as it relates to BGP.  I am needing a
> device that has a mix of layer 2 and 3 features, including MPLS, that will
> have a very low port count requirement that will primarily be used at a
> remote POP site to connect to the local IX as well as one or two full route
> transit providers.  The MX104 has what I need from a physical standpoint
> and a data plane standpoint, as well as power consumption figures.  My only
> concern is whether the REs have enough horsepower to churn through the
> convergence calculations at a rate that operators in this situation would
> find acceptable.  I realize that 'acceptable' is a moving target so I would
> happily accept feedback from people using them as to how long it takes and
> their happiness with the product.
> 
>  For those of you that deem the MX104 unacceptable in this kind of
> role and moved up to the MX240, what RE did you elect to use?
> 
>  Thanks,
>  Graham Johnston
>  Network Planner
>  Westman Communications Group
>  204.717.2829
>  johnst...@westmancom.com
>  P think green; don't print this email.

Re: DataCenter color-coding cabling schema

[Owen DeLong]

The only problem I’ve had with those is that they tend to slide down the fiber 
and you can
end up having to trace the fiber to find the label which sort of defeats the 
purpose.

Owen

> On Mar 13, 2016, at 18:33 , Nick Pratley 
>  wrote:
> 
> Hi Baldur,
> 
> Equinix in Sydney use the below, for Cross Connects.
> 
> Goes around the fiber to pad it out, and the label keeps it on the fiber.
> 
> http://www.cableorganizer.com/panduit/labelcore-cable-id-sleeve/
> 
> Been meaning to order some for internal use, too.
> 
> Nick

Re: DataCenter color-coding cabling schema

[Owen DeLong]

> On Mar 13, 2016, at 18:14 , Baldur Norddahl  wrote:
> 
> Hi,
> 
> What is the best solution for thin 2 mm or 0.9 mm fiber labelling? I like
> the idea of wrap around labels but does that work on thin wires? Maybe use
> something to pad the wire to more thickness where the label is to be?

I doubt it would work on 0.9mm single strands, but I’ve had reasonably good
luck with it on standard SM and MM fiber pairs with normal zip-cord style
sheathing.

Owen

Re: DataCenter color-coding cabling schema

[Nick Pratley]

Hi Baldur,

Equinix in Sydney use the below, for Cross Connects.

Goes around the fiber to pad it out, and the label keeps it on the fiber.

http://www.cableorganizer.com/panduit/labelcore-cable-id-sleeve/

Been meaning to order some for internal use, too.

Nick

Re: Why the US Government has so many data centers

[Sean Donelan]

On Sun, 13 Mar 2016, Lee wrote:

Where does it say test/dev has to be done solely in a cloud data
center?  This bit
  For the purposes of this memorandum, rooms with at least one
server, providing
  services (whether in a production, test, stage, development, or any other
  environment), are considered data centers.
seems to be more about trying to close the self-reporting loophole -
ie 'these aren't the droids you're looking for.'   for example -
https://github.com/WhiteHouse/datacenters/issues/9


Sigh, read any Inspector General report for how memorandums are 
implemented by auditors.  If the memorandum says "or any other 
environment" the IG's will treat that as no exceptions.


So IG's will "close the reporting loophole" by reporting that their are 
100,000 "data centers" if a room contains  even a single server.


Auditors like counting things, they don't like interpretations.  Inspector 
Generals are uber-auditors.

Re: DataCenter color-coding cabling schema

[Baldur Norddahl]

Hi,

What is the best solution for thin 2 mm or 0.9 mm fiber labelling? I like
the idea of wrap around labels but does that work on thin wires? Maybe use
something to pad the wire to more thickness where the label is to be?

Regards,

Baldur

Re: Cogent - Google - HE Fun

[William Herrin]

On Sun, Mar 13, 2016 at 5:25 PM, Doug Barton  wrote:
> No one who is serious about IPv6 is single-homed to Cogent. Arguably, no one
> who is serious about "The Internet" is single-homed on either protocol.

At the very least, no one who is clueful about "The Internet" is
single-homed to Cogent with any protocol.

Regards,
Bill Herrin


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

Re: DataCenter color-coding cabling schema

[William Herrin]

On Sat, Mar 12, 2016 at 2:11 PM, Yardiel Fuentes  wrote:
> Have any of you had the option or; conversely, do you know of “best
> practices" or “common standards”,  to color code physical cabling for your
> connections in DataCenters for Base-T and FX connections? If so, Could you
> share  any ttype of color-coding schema you are aware of ?…. Yes, this is
> actually considering paying for customized color-coded cabling in a Data
> Center...
>
> Mr. Google did not really provide me with relevant answers on the above…
> beyond the typical (Orange is for MMF, yellow for SMF, etc)…
>
> Any reasons for or against it welcome too...

Hi Yardiel,

Patch cables or fixed cabling to patch panels?

For fixed cabling, it's common to pick colors which match the cable
type. Orange for multimode fiber, yellow for single mode fiber, blue
for four-pair cat5e, something else for cat6, etc. At each end, label
the location of the opposite endpoint twice, once on the panel and
once on the cable itself (cables can pull loose from panels).

With fixed cabling terminating in patch panels they'll tend to get
reused over time for different types of signalling so don't overthink
it.


For patch cables, it's common to pick a color for each type of
physical signaling so you don't jam the wrong kind of signal in to a
port that doesn't match. Your gig-e switch may not like the voltage
from that ringing pots line. Blue for ethernet, white for POTs, green
for T1s, some other color for the rs232 serial cables, IP/KVM cables,
etc.

I find the easiest way to label patch cables is with color electrical
tape. Put the same bands of unique colors at both ends of the cable.
This will let you visually identify the cables without pulling on them
to try and line up tiny text on the tags with your eyeballs.

Regards,
Bill Herrin


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

Re: Cogent - Google - HE Fun

[Baldur Norddahl]

On 13 March 2016 at 19:20, Matthew Kaufman  wrote:

> I come to the opposite conclusion - that this situation can persist with
> apparently no business impact to either party shows that IPv6 is still
> unnecessary.
>

It does in fact have business impact on Cogent (but not Google). It means
that some Cogent customers, like us, that are multihomed no longer will
take in any Google IPv6 traffic via Cogent. This means we will be upgrading
other transits before we upgrade Cogent. Cogent will simply have less bytes
to sell to us.

This effect will be most profound in markets with eyeball networks that
implement IPv6.

On the other hand, Cogent might not know what they are missing out on. Our
traffic growth will mask the fact that they lost some revenue here.

It might also be that we did already get the Google traffic on a different
circuit and therefore nothing changed. But Cogent has many customers, so
there has to be some that just moved their IPv6 google traffic to other
transits as result of this.

Regards,

Baldur

Re: Cogent - Google - HE Fun

[Owen DeLong]

> On Mar 11, 2016, at 11:50 , Damien Burke  wrote:
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with 
> Google as it is up to their discretion as to how they announce routes to us 
> v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to 
> IPs that are not announced to us by the IP owner, directly or through a 
> network peer."
> 

Which is a cute way of leaving out “However, since we refuse to accept them 
directly peering with us…”

Owen

Re: DataCenter color-coding cabling schema

[Owen DeLong]

I don’t know of any universal standards, but I’ve used the following in several
installatins I was responsible for to good avail:

Twisted Pair:

RED:Untrusted Network (Internet or possibly DMZ)
YELLOW: Optional for DMZ networks though I preferred to avoid documented in [1] 
below
BLUE:   Trusted Network (back-end, internal, etc.)
GREEN:  RS-232 straight-thru
PURPLE: RS-232 X-Over (effectively Null Modem) 12345678 <-> 87654321 pin map.
ORANGE: Ethernet X-Over (Best avoided documented in [2] below)
GREY:   Special purpose cabling not in one of the above categories

Fiber:
Orange — Multimode Fiber
Yellow — Singlemode Fiber

The absolute most useful thing you can do if you can impose the discipline to 
update
the cable map rigorously and/or allocate manpower for periodic audits is to 
apply a
unique serial number to each cable. I preferred to document not only the cable 
ID,
but also the length. For the installations where I have worked, 5 digits was 
sufficient
unique ID, so I used formats like I-L[.L] where I was a unique ID and 
L.L was
the length of the cable in feet. (e.g. 00123-6.5 is cable number 123 which is 
6.5 feet
in length).

The labels are (ideally) the self-laminating wrap-around types. I prefer the 
Brady
labeling system which will automatically print 2-4 (depending on font size) 
instances
of the label text on the self-laminating label such that it can be read from 
virtually
any side of the cable without requiring you to rotate the label into view in 
most cases.

The Brady labeling system is a bit overpriced compared to the Brother P-Touch, 
but the
expanded capabilities and the quality of the label adhesives and such is, IMHO, 
sufficiently
superior to justify the cost.

Whatever you do, please do not use Flag labels on cables… I HATE THEM. They are 
a constant
source of entanglement and snags. They often get knocked off as a result or 
mangled beyond
recognition, rendering them useless.

Similarly, I’ve found that circuit-ID and end-point labels on cables are often 
ill-maintained,
so if you do use them, please make sure you remove them when the cable is 
moved/removed.

The length is very useful because it gives you a radius within which the other 
end of
the cable must be located and you can usually expect it to be reasonably close 
to the
outer edge of that radius.

More than a few times I’ve prevented a serious outage by giving the port number 
to the remote
hands guy and then insisting that he read me the cable ID. “No, try the other 
port
FE-0/2/4… You’re off by one. It’s above/left/right/below you.”

[1] I prefer to avoid Yellow cables because some people have trouble 
understanding
that Yellow Fiber and Yellow UTP might have different meanings. I also feel 
that the
distinction between UNTRUSTED and DMZ networks is usually not all that 
important in
most cabling situations. YMMV.

[2] In this era of Auto-MDI/MDI-X ports and the like, it’s very rare to 
encounter a
situation that truly requires a crossover cable with no viable alternative. If 
such
is needed, I prefer to document it on the cable tags rather than using a 
special color
code. Again, you have the risk of people not understanding that orange Fiber 
might not
mean what Orange copper means. YMMV

Yes, I know you can now get virtually any type of fiber in virtually any color, 
but
the simple fact of the matter remains that when you send skippy out to buy 
emergency
jumpers or such, you’re most likely going to either get orange multimode or 
yellow
singlemode and that’s just the way it is.

Owen

> On Mar 12, 2016, at 11:11 , Yardiel Fuentes  wrote:
> 
> Hello Nanog-ers,
> 
> Have any of you had the option or; conversely, do you know of “best
> practices" or “common standards”,  to color code physical cabling for your
> connections in DataCenters for Base-T and FX connections? If so, Could you
> share  any ttype of color-coding schema you are aware of ?…. Yes, this is
> actually considering paying for customized color-coded cabling in a Data
> Center...
> 
> Mr. Google did not really provide me with relevant answers on the above…
> beyond the typical (Orange is for MMF, yellow for SMF, etc)…
> 
> Any reasons for or against it welcome too...
> 
> -- 
> Yardiel Fuentes

Re: Why the US Government has so many data centers

[Lee]

On 3/13/16, Sean Donelan  wrote:
> On Sun, 13 Mar 2016, Roland Dobbins wrote:
>> On 13 Mar 2016, at 3:03, George Herbert wrote:
>>
>>> It's a symptom of trying to save a few cents at the risk of dollars.
>>
>> Concur 100%.
>>
>> Not to mention the related security issues.
>
> Just remember, no exceptions, no waivers.
>
> I understand why cloud vendors want 100% of government IT dollars.  But
> requiring all test and development to be done solely in cloud data
> centers...  there is your 100%

Where does it say test/dev has to be done solely in a cloud data
center?  This bit
   For the purposes of this memorandum, rooms with at least one
server, providing
   services (whether in a production, test, stage, development, or any other
   environment), are considered data centers.
seems to be more about trying to close the self-reporting loophole -
ie 'these aren't the droids you're looking for.'   for example -
https://github.com/WhiteHouse/datacenters/issues/9

Lee

Re: Why the US Government has so many data centers

[George Herbert]

I really don't care about AWS sales (customer, but not investor or employee).  
But...

If it's not highly loaded, cloud is cheaper.

If it's not in a well run datacenter / machine room, cloud is FAR more reliable.

The cost of blowing up hardware in less than well run machine rooms / 
datacenters can be immense.  At a now defunct cell provider, we lost a badly 
maintained machine room to fire, only about 24 racks, $2.1 million damage.  And 
nearly burned down the Frys Palo Alto building.  And that's just the worst 
catastrophe; had more losses than that in smaller clusters / onsies.

George William Herbert
Sent from my iPhone

> On Mar 13, 2016, at 2:15 PM, Sean Donelan  wrote:
> 
>> On Sun, 13 Mar 2016, Roland Dobbins wrote:
>>> On 13 Mar 2016, at 3:03, George Herbert wrote:
>>> 
>>> It's a symptom of trying to save a few cents at the risk of dollars.
>> 
>> Concur 100%.
>> 
>> Not to mention the related security issues.
> 
> Just remember, no exceptions, no waivers.
> 
> I understand why cloud vendors want 100% of government IT dollars.  But
> requiring all test and development to be done solely in cloud data centers... 
>  there is your 100%
> 

Re: Cogent - Google - HE Fun

[Doug Barton]

s/IPv6/Cogent/  :)

No one who is serious about IPv6 is single-homed to Cogent. Arguably, no 
one who is serious about "The Internet" is single-homed on either protocol.


Thus your conclusion seems to be more like wishful thinking. :)

Doug


On 03/13/2016 11:20 AM, Matthew Kaufman wrote:

I come to the opposite conclusion - that this situation can persist with 
apparently no business impact to either party shows that IPv6 is still 
unnecessary.

Matthew Kaufman

(Sent from my iPhone)


On Mar 13, 2016, at 7:31 AM, Dennis Burgess  wrote:

In the end, google has made a choice. I think these kinds of choices will delay 
IPv6 adoption.

-Original Message-
From: Damien Burke [mailto:dam...@supremebytes.com]
Sent: Friday, March 11, 2016 2:51 PM
To: Mark Tinka ; Owen DeLong ; Dennis Burgess 

Cc: North American Network Operators' Group 
Subject: RE: Cogent - Google - HE Fun

Just received an updated statement from cogent support:

"We appreciate your concerns. This is a known issue that originates with Google 
as it is up to their discretion as to how they announce routes to us v4 or v6.

Once again, apologies for any inconvenience."

And:

"The SLA does not cover route transit beyond our network. We cannot route to IPs 
that are not announced to us by the IP owner, directly or through a network peer."

Re: Why the US Government has so many data centers

[Sean Donelan]

On Sun, 13 Mar 2016, Roland Dobbins wrote:

On 13 Mar 2016, at 3:03, George Herbert wrote:


It's a symptom of trying to save a few cents at the risk of dollars.


Concur 100%.

Not to mention the related security issues.


Just remember, no exceptions, no waivers.

I understand why cloud vendors want 100% of government IT dollars.  But
requiring all test and development to be done solely in cloud data 
centers...  there is your 100%

Re: Cogent - Google - HE Fun

[Matthew Kaufman]

I come to the opposite conclusion - that this situation can persist with 
apparently no business impact to either party shows that IPv6 is still 
unnecessary.

Matthew Kaufman

(Sent from my iPhone)

> On Mar 13, 2016, at 7:31 AM, Dennis Burgess  wrote:
> 
> In the end, google has made a choice. I think these kinds of choices will 
> delay IPv6 adoption.  
> 
> -Original Message-
> From: Damien Burke [mailto:dam...@supremebytes.com] 
> Sent: Friday, March 11, 2016 2:51 PM
> To: Mark Tinka ; Owen DeLong ; Dennis 
> Burgess 
> Cc: North American Network Operators' Group 
> Subject: RE: Cogent - Google - HE Fun
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with 
> Google as it is up to their discretion as to how they announce routes to us 
> v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to 
> IPs that are not announced to us by the IP owner, directly or through a 
> network peer."
> 

Re: Cogent - Google - HE Fun

[joel jaeggli]

On 3/13/16 7:31 AM, Dennis Burgess wrote:
> In the end, google has made a choice. I think these kinds of choices will 
> delay IPv6 adoption.  

Given that they publish  records for a great deal of their services
I'm not sure how you would conclude that.

> -Original Message-
> From: Damien Burke [mailto:dam...@supremebytes.com] 
> Sent: Friday, March 11, 2016 2:51 PM
> To: Mark Tinka ; Owen DeLong ; Dennis 
> Burgess 
> Cc: North American Network Operators' Group 
> Subject: RE: Cogent - Google - HE Fun
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with 
> Google as it is up to their discretion as to how they announce routes to us 
> v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to 
> IPs that are not announced to us by the IP owner, directly or through a 
> network peer."
> 
> 




signature.asc
Description: OpenPGP digital signature

RE: Cogent - Google - HE Fun

[Dennis Burgess]

In the end, google has made a choice. I think these kinds of choices will delay 
IPv6 adoption.  

-Original Message-
From: Damien Burke [mailto:dam...@supremebytes.com] 
Sent: Friday, March 11, 2016 2:51 PM
To: Mark Tinka ; Owen DeLong ; Dennis 
Burgess 
Cc: North American Network Operators' Group 
Subject: RE: Cogent - Google - HE Fun

Just received an updated statement from cogent support:

"We appreciate your concerns. This is a known issue that originates with Google 
as it is up to their discretion as to how they announce routes to us v4 or v6. 

Once again, apologies for any inconvenience."

And:

"The SLA does not cover route transit beyond our network. We cannot route to 
IPs that are not announced to us by the IP owner, directly or through a network 
peer."