Re: DataCenter color-coding cabling schema

[Owen DeLong]

> On Mar 18, 2016, at 18:42 , Jay Hennigan  wrote:
> 
> On 3/12/16 12:15 PM, Joe Hamelin wrote:
>> I know at Clearwire data centers we used gray for network, blue for
>> management and orange for RS-232 console.  At least for the initial build.
>> Later re-work or additions were whatever the tech had on hand ;)  They also
>> had labels on each end of each wire showing the path through the system,
>> sometimes up to six lines.  It did make it easy to bring up a data center
>> and find cabling errors.  To see the system last more than a year or two up
>> upgrades would take some strong rules and oversight.  I think it would be
>> worth it if your management system can keep the religion.
> 
> That's the issue, keeping it that way. "Gray for network" is likely to result 
> in mostly gray cables which won't really help to differentiate things in the 
> long run. Breaking it down further can get tricky in terms of definition. 
> Each network has a color, but then there's this trunk link
> 
> We had a customer who had a scheme involving five different colors. When they 
> did the initial build their wiring vendor came in with barrels of new cables 
> of various lengths and colors and it looked really nice with cable management 
> and all.
> 
> After a couple of years it was pretty much random in terms of color coding. 
> Keeping multiple lengths on hand for dressing in raceway without incurring 
> either tons of slack or bow-string taut wires is tough but possible, doing 
> that in half a dozen colors can be daunting.

Yes and no.

If you have a requirement that all cabling between racks goes via fixed cabling 
from patch panels and patch cables are only used for intra-rack runs between 
equipment in the same rack and/or equipment<->patch panel in the same rack, it 
gets a lot less so. This can also help keep a lot of other things more sane in 
the long run as well.

I found that you could deal pretty well with any intra-rack run (assuming 7’ 
racks) if you stocked the following lengths:

0.5’
1’
1.5’
2’
2.5’
3’
4’
5’
6’
7’
8’
10’

That’s a total of 12 lengths. We kept those in stock in Yellow (SMF), Orange 
(MMF), Other colors all Cat 6: Blue, Red, Purple, Green.

Total of 72 part numbers to keep track of. We got one of those roll-around bin 
carts that had 4 rows of 9 drawers on each side. Worked out perfectly to have 
72 kinds of cables. (IIRC, we did 3 columns per color working up in size from 
left to right).

We had a guy who was responsible for making sure none of the bins were ever 
empty. I think he checked the cart twice a week and ordered once a month most 
months. I think we tended to keep at least 5 on the cart and topped the bins up 
to 20 for most sizes and 40 for the popular size/color combinations.

We didn’t have any trouble maintaining the system and as long as the right 
color was available, we got pretty good compliance from the people installing 
cables. (Our “retraining” method for people who ran a wrong-colored cable 
didn’t hurt, either.)

YMMV.

Owen

www.cisco.com no resolve?

[Dmitry Sherman]

dig www.cisco.com @8.8.8.8


; <<>> DiG 9.8.3-P1 <<>> www.cisco.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60416
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:
;www.cisco.com. IN  A


;; AUTHORITY SECTION:
cisco.com.  1247IN  SOA edns-rtp5-1-l. 
postmaster.cisco.com. 16034550 7200 1800 864000 86400


;; Query time: 94 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Mar 19 07:36:22 2016
;; MSG SIZE  rcvd: 91





— 
Dmitry Sherman
Interhost Networks Ltd
dmi...@interhost.net
office: 972-74-7029881
mobile: 972-54-3181182
http://www.interhost.co.il





>

Re: Internet Exchanges supporting jumbo frames?

[Jakob Heitz (jheitz)]

What's driving the desire for larger packets?

A single bit error will drop a whole packet.
Larger packets will cause more loss. Cables will need to be
shorter or bitrates lower to compensate.

Byte overhead of packet headers?

Are we seeing degradation of packets per second in forwarding
due to the increase in IPv6? Are we seeing IPv6 packets with
hop-by hop extension headers (which forward on the slow path)?

Increasing the packet size will reduce the number of TCP
packets as well as the number of TCP ack packets.
TCP ACK packets are significantly larger in IPv6 than IPv4.

TCP slow start is faster with large MTU. Is this an issue?

Are IPv6 packets with extension headers causing performance
degradation in firewalls?

Thanks,
Jakob.

Re: Cogent - Google - HE Fun

[Mark Tinka]

On 16/Mar/16 17:41, Christopher Morrow wrote:

> my guess is the same as Owen's ... 'your rfq don't mean squat'.
> honestly it's not like people don't ask their cogent sales folk for
> this sort of thing, it's just not cogent's (clearly, given how long
> the HE/Cogent thing along has persisted) way of doing things.
>
> Sometimes your belief system just isn't theirs.

The first time I considered buying from Cogent was out of One Wilshire,
back in 2010. I did a 1-month PoC with them.

The global IPv6 BGP table was around 2,500 routes then. Cogent had only
100 or so, IIRC. I told them I would not sign with them due to this.

Fast-forward to 2012, nothing much had changed when they tried to get me
to buy from them again (out of London, this time), and I told them why.
Then in 2014, they tracked me down again and confirmed they then had a
full IPv6 BGP table. So I added them to my network (out of Amsterdam).

Cogent form part of the 7x upstreams I have (not to mention all the
peering we do). So if they de-peer some network, we aren't stuck. I have
them on my network because they add value to some paths on the Internet,
and not because of price.

I'm one guy, so I can't say whether my actions over the years prompted a
warm body within the Cogent machine to rethink their IPv6 strategy. But
I think if you refuse to buy from them on principles that matter to you,
and you tell them why, it could help. If it doesn't, move on - it won't
be your loss.

I would, though, say that the amount of support this list is giving
Cogent to keep their heart beating is astounding. If there was ever a
time for them to listen to their environment, this would be it. But alas...

Mark.

Re: CALEA Requirements

[Scott Helms]

Kevin,

That's largely true, but keep in mind that it's normal for people who have
had to fulfill a request to be disallowed from talking about it which makes
them seem even more rare than they actually are.  I'm also not familiar
with any laws that prevent state or local agencies from leveraging CALEA
and I've certainly seen it used on the voice side by state level law
enforcement.


Scott Helms
Chief Technology Officer
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms


On Fri, Mar 18, 2016 at 4:19 PM, Kevin Burke 
wrote:

> Ignore it until you get the paperwork.  The local law enforcement can not
> get a warrant for the real time, full data capture.  Only FBI or other
> national agencies can get those subpeona's.  We went through this with our
> local police department.  They wanted to make sure we were prepared and
> wanted a test for the real time number capture on phone calls.  They didn't
> mention they don't have any equipment on their side to connect the T1.
>
> Ask your local neighbors.  Some area's have a number of local federal
> investigations.  If you get the deer in the headlights look from your
> competition then you may never get one of these.
>
> The full data captures are rare.
>
> Kevin Burke
> 802-540-0979
> Burlington Telecom - City of Burlington
> 200 Church St, Burlington, VT 05401
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Lorell Hathcock
> Sent: Monday, March 14, 2016 4:47 PM
> To: 'NANOG list' 
> Subject: CALEA Requirements
>
> NANOG:
>
>
>
> Can someone point me to the current CALEA requirements?
>
>
>
> As an ISP, should I be recording all internet traffic that passes my
> routers?  Or do I only have to record when and if I receive a court order?
>
>
>
> I'm not under any court order now, I just want to be sure that I am
> compliant going forward in my capabilities.
>
>
>
> Thanks!
>
>
>
> Lorell Hathcock
>
>

Re: Internet Exchanges supporting jumbo frames?

[Chris Woodfield]

I think that’s the problem in a nutshell…until every vendor agrees on the size 
of a “jumbo” packet/frame (and as such, allows that size to be set with a 
non-numerical configuration flag). As is, every vendor has a default that 
results in 1500-byte IP MTU, but changing that requires entering a value…which 
varies from vendor to vendor.

The IEEE *really* should be the ones driving this particular standardization, 
but it seems that they’ve explicitly decided not to. This is…annoying to say 
the least. Have their been any efforts on the IETF side of things to 
standardize this, at least for IPv4/v6 packets?

-C

> On Mar 9, 2016, at 10:38 PM, Frank Habicht  wrote:
> 
> Hi,
> 
> On 3/10/2016 9:23 AM, Tassos Chatzithomaoglou wrote:
>> Niels Bakker wrote on 10/3/16 02:44:
>>> * nanog@nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]:
 I'm pretty confident there is no need for a specific MTU consensus and not 
 all IXP participants are obligated to raise their interface MTU if the IXP 
 starts allowing jumbo frames.
>>> 
>>> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too Big 
>>> messages.  That's why everybody must agree on one MTU.
>>> 
>>> 
>> Isn't that the case for IXP's current/default MTU?
>> If an IXP currently uses 1500, what effect will it have to its customers if 
>> it's increased to 9200 but not announced to them?
> 
> none.
> everyone has agreed on 1500. it is near impossible to get close to
> everyone to agree on 9200 (or similar number) and implement it (at the
> same time or in a separate VLAN) (Nick argues, and i see the problem).
> The agreement and actions of the (various) operators of L3 devices
> connected at the IXP is what matters and seems not trivial.
> They are not under one control.
> 
> Frank

[NANOG-announce] NANOG On The Road Comes to Raleigh!

[Valerie Wittkop]

We are very excited to be holding the next NOTR event in Raleigh/Durham 
Research Triangle on April 12, 2016, and we invite you to join us!

Are you interested in Internet networking/peering? Do you work at a colocation, 
hosting or data center facility? Are you a provider of hardware/software 
solutions for the Internet industry?  If so, the NANOG On The Road 
 Raleigh event is perfect for you!

Date:  April 12, 2016
Time:  Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM
Location:  Embassy Suites Hilton Raleigh Durham Research Triangle 
 - 201 Harrison Oaks Blvd, Cary, 
NC 27513

The FREE to attend event is open for registration.  Register Now! 


Agenda Topics  are posted, which 
include:
- Life After IPv4
- DNSSEC & RPKI
- Traceroute Tutorial
- IPv6 Tutorial
- BGP Tutorial

If you are, or will be, in the Raleigh area, we invite you to attend.  And 
don’t forget to share the invitation with your colleagues or others you feel 
may benefit from attending.  Make NANOG On The Road your first step toward 
learning how you can take the wheel and steer the future of the Internet.  

Learn more about On The Road events here 
.  Feel free to contact us at 
nanog-supp...@nanog.org  if you have any 
questions.
Regards,


Valerie

Valerie Wittkop
NANOG Program Director
Tel: +1 866 902 1336, ext 103

___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Why the US Government has so many data centers

[George Herbert]

So...

Before I go on, I have not been in Todd's shoes, either serving nor directly 
supporting an org like that.

However, I have indirectly supported orgs like that and consulted at or 
supported literally hundreds of commercial and a few educational and nonprofit 
orgs over the last 30 years. 

There are corner cases where distributed resilience is paramount, including a 
lot of field operations (of all sorts) on ships (and aircraft and spacecraft), 
or places where the net really is unstable.  Any generalizations that wrap 
those legitimate exceptions in are overreaching their valid descriptive range.

That said, the vast bulk of normal world environments, individuals make 
justifications like Todd's and argue for distributed services, private servers, 
etc.  And then do not run them reliably, with patches, backups, central 
security management, asset tracking, redundancy, DR plans, etc.

And then they break, and in some cases are and will forever be lost.  In other 
cases they will "merely" take 2, 5, 10, in one case more than 100 times longer 
to repair and more money to recover than they should have.

Statistically these are very very poor operational practice.  Not so much 
because of location (some) but because of lack of care and quality management 
when they get distributed and lost out of IT's view.

Statistically, several hundred clients in and a hundred or so organizational 
assessments in, if I find servers that matter under desks you have about a 2% 
chance that your IT org can handle supporting and managing them appropriately.

If you think that 98% of servers in a particular category being at high risk of 
unrecoverable or very difficult recovery when problems crop up is acceptable, 
your successor may be hiring me or someone else who consults a lot for a very 
bad day's cleanup.

I have literally been at a billion dollar IT disaster and at tens of smaller 
multimillion dollar ones trying to clean it up.  This is a very sad type of 
work.

I am not nearly as cheap for recoveries as for preventive management and 
proactive fixes. 


George William Herbert
Sent from my iPhone

> On Mar 18, 2016, at 9:28 PM, Todd Crane  wrote:
> 
> I was trying to resist the urge to chime in on this one, but this discussion 
> has continued for much longer than I had anticipated... So here it goes
> 
> I spent 5 years in the Marines (out now) in which one of my MANY duties was 
> to manage these "data centers" (a part of me just died as I used that word to 
> describe these server rooms). I can't get into what exactly I did or with 
> what systems on such a public forum, but I'm pretty sure that most of the 
> servers I managed would be exempted from this paper/policy.
> 
> Anyways, I came across a lot of servers in my time, but I never came across 
> one that I felt should've been located elsewhere. People have brought up the 
> case of personal share drive, but what about the combat camera (think public 
> relations) that has to store large quantities (100s of 1000s) of high 
> resolution photos and retain them for years. Should I remove that COTS 
> (commercial off the shelf) NAS underneath the Boss' desk and put in a data 
> center 4 miles down the road, and force all that traffic down a network that 
> was designed for light to moderate web browsing and email traffic just so I 
> can check a box for some politician's reelection campaign ads on how they 
> made the government "more efficient"
> 
> Better yet, what about the backhoe operator who didn't call before he dug, 
> and cut my line to the datacenter? Now we cannot respond effectively to a 
> natural disaster in the Asian Pacific or a bombing in the Middle East or a 
> platoon that has come under fire and will die if they can't get air support, 
> all because my watch officer can't even login to his machine since I can no 
> longer have a backup domain controller on-site
> 
> These seem very far fetched to most civilian network operators, but to 
> anybody who has maintained military systems, this is a very real scenario. As 
> mentioned, I'm pretty sure my systems would be exempted, but most would not. 
> When these systems are vital to national security and life & death 
> situations, it can become a very real problem. I realize that this policy was 
> intended for more run of the mill scenarios, but the military is almost 
> always grouped in with everyone else anyways. 
> 
> Furthermore, I don't think most people realize the scale of these networks. 
> NMCI, the network that the Navy and Marine Corps used (when I was in), had 
> over 500,000 active users in the AD forest. When you have a network that 
> size, you have to be intentional about every decision, and you should not 
> leave it up to a political appointee who has trouble even checking their 
> email. 
> 
> When you read how about much money the US military hemorrhages, just 
> remember 
> - The multi million dollar storage array combined with a complete 

Re: Cogent - Google - HE Fun

[Baldur Norddahl]

On 16 March 2016 at 14:56, Dennis Bohn  wrote:

> So if someone (say an eyeball network) was putting out a RFQ for a gig say
> of upstream cxn and wanted to spec full reachability to the full V6 net,
> what would the wording for that spec look like?
> Would that get $provider's attention?
>

But is that even possible to deliver? I might have some address space that
I only advertised with no export to a single peer - does that count? If
some third party decides to stop advertising a prefix to $provider are they
then in breach of contract with no way to resolve it? If so, I want to sign
up and then I will pull some insignificant prefix, just so I can demand $5
million USD in ransom money.

Google decided they have some prefixes they don't want to advertise to
Cogent. They did offer a reasonable way for Cogent to resolve that issue,
but what if Google werent reasonable? Do you still demand that Cogent cave
in to anything?

I see no easy way here other than let the market decide. If Cogent sucks
they will get less traffic and less customers. Or maybe someone finds them
useful at the pricepoint they offer.

Regards,

Baldur

RE: So Cal Verizon Business FIOS to Frontier cutover

[Azinger, Marla]

Hi Paul

I will email you privately to address your concerns.

Regards
Marla Azinger
Supervisor Network ENG
IP Address Management



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Paul B. Henson
Sent: Wednesday, March 16, 2016 5:27 PM
To: nanog@nanog.org
Subject: So Cal Verizon Business FIOS to Frontier cutover

So the transition from Verizon to Frontier is coming up, and I recently got a 
notice from Verizon pointing me to the following website:

http://meetfrontier.com/

Evidently one of the things Verizon did not sell to Frontier is their IP 
address space, as it seems customers with static IP addresses are going to have 
to change their allocations :(. I have five statics, and while it is not the 
end of the world, it will certainly be annoying to have to reconfigure not only 
my equipment but also update the configurations of my clients that access it 
and the other service providers I access who restrict based on it . I was 
hoping to get some simple additional information regarding this migration, such 
as:

* How far in advance of the cutover will we be notified?
* How far in advance of the cutover will we be supplied with the new static IP 
addresses?
* How big will the cutover window be, and will it be attended or unattended?
* How will reverse DNS resolution be handled?

So I called the phone number on the website that was provided for questions or 
additional information. I'm not quite sure why they provided it, as the person 
who answered it had absolutely no information to provide other than that that 
was already on the website, and said they were unable to direct me to anyone 
who could provide any further information; I guess it was for people who needed 
the website read to them?

Any chance there is a Frontier engineer on the list who might be able to 
provide this information, anonymously if necessary :)? Or someone who has gone 
through a Verizon to Frontier FIOS static IP address transition in another 
location who might describe their experience with the assumption it will be 
similar in California?

As far as reverse DNS, the only thing I can seem to find is this:

http://hostmaster.frontier.com/reverse.html

Which talks about "Business Class DSL and Dedicated Internet" customers, not 
sure if it applies to FIOS? What I'd really like is to get my PTR entries 
delegated to me via CNAMEs so I could control the TTLs and update them whenever 
I wanted to without having to hassle the provider (one of my colleagues has 
this arrangement with charter business cable), Verizon was never willing to do 
that.

On another note, does anybody have any idea regarding Frontier's position on 
rolling out IPv6 for business FIOS :)? Hopefully they won't be quite as archaic 
and stuck in the mud as Verizon has been on that topic :(.

Thanks much for any info.





This communication is confidential. Frontier only sends and receives email on 
the basis of the terms set out at http://www.frontier.com/email_disclaimer.

Re: Craiglist blocked

[George Herbert]

I know someone (not ops but ha can forward internally);  forwarding to him.

George William Herbert
Sent from my iPhone

> On Mar 16, 2016, at 2:18 PM, Christopher Tyler  
> wrote:
> 
> Does anyone have a contact at Craigslist? 
> Some of our IP addresses got blocked and we are getting no response from the 
> email address listed when attempting to visit their site. Our customers are 
> threatening mutiny.
> 
> -- 
> Christopher Tyler 
> MTCRE/MTCNA/MTCTCE/MTCWE 
> Total Highspeed Internet Services 
> 417.851.1107
> 

Re: Craiglist blocked

[Michael J Wise]

>
>> I know someone (not ops but ha can forward internally);  forwarding to
>> him.
>
> If George's contact doesn't pan out, I have a name that I can forward your
> concern to.
> Ping me at work (address in the Cc:) with details if there's no response?

/facepalm

Let's try that again, once more with feeling.


>> George William Herbert
>> Sent from my iPhone
>>
>>> On Mar 16, 2016, at 2:18 PM, Christopher Tyler
>>>  wrote:
>>>
>>> Does anyone have a contact at Craigslist?
>>> Some of our IP addresses got blocked and we are getting no response
>>> from
>>> the email address listed when attempting to visit their site. Our
>>> customers are threatening mutiny.
>>>
>>> --
>>> Christopher Tyler
>>> MTCRE/MTCNA/MTCTCE/MTCWE
>>> Total Highspeed Internet Services
>>> 417.851.1107
>>>
>>
>
>
> Aloha mai Nai`a.
> --
> " So this is how Liberty dies ...  http://kapu.net/~mjwise/
> " To Thunderous Applause.
>
>
>


Aloha mai Nai`a.
-- 
" So this is how Liberty dies ...  http://kapu.net/~mjwise/
" To Thunderous Applause.

Re: CALEA Requirements

[Kraig Beahn]

I believe Scott, just hit the nail on the head...
"but keep in mind that it's normal for people who have
had to fulfill a request *to be disallowed from talking about it* which
makes
them seem even more rare than they actually are."

On Fri, Mar 18, 2016 at 4:28 PM, Scott Helms  wrote:

> Kevin,
>
> That's largely true, but keep in mind that it's normal for people who have
> had to fulfill a request to be disallowed from talking about it which makes
> them seem even more rare than they actually are.  I'm also not familiar
> with any laws that prevent state or local agencies from leveraging CALEA
> and I've certainly seen it used on the voice side by state level law
> enforcement.
>
>
> Scott Helms
> Chief Technology Officer
> ZCorum
> (678) 507-5000
> 
> http://twitter.com/kscotthelms
> 
>
> On Fri, Mar 18, 2016 at 4:19 PM, Kevin Burke  >
> wrote:
>
> > Ignore it until you get the paperwork.  The local law enforcement can not
> > get a warrant for the real time, full data capture.  Only FBI or other
> > national agencies can get those subpeona's.  We went through this with
> our
> > local police department.  They wanted to make sure we were prepared and
> > wanted a test for the real time number capture on phone calls.  They
> didn't
> > mention they don't have any equipment on their side to connect the T1.
> >
> > Ask your local neighbors.  Some area's have a number of local federal
> > investigations.  If you get the deer in the headlights look from your
> > competition then you may never get one of these.
> >
> > The full data captures are rare.
> >
> > Kevin Burke
> > 802-540-0979
> > Burlington Telecom - City of Burlington
> > 200 Church St, Burlington, VT 05401
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Lorell
> Hathcock
> > Sent: Monday, March 14, 2016 4:47 PM
> > To: 'NANOG list' 
> > Subject: CALEA Requirements
> >
> > NANOG:
> >
> >
> >
> > Can someone point me to the current CALEA requirements?
> >
> >
> >
> > As an ISP, should I be recording all internet traffic that passes my
> > routers?  Or do I only have to record when and if I receive a court
> order?
> >
> >
> >
> > I'm not under any court order now, I just want to be sure that I am
> > compliant going forward in my capabilities.
> >
> >
> >
> > Thanks!
> >
> >
> >
> > Lorell Hathcock
> >
> >
>

Re: collectd as alternative to RTG for high-resolution polling and long term storage?

[Ulf Zimmermann]

Be aware that collectd itself is a collection agent. It doesn't include
(last I checked) a grapher. There are however a number of graphers out
there to work with those RRD files, if you use that to store the data.

I personally have been using collectd across hundreds of Linux systems,
using rrdcached to a central collector and wrote my own grapher for that
stuff I am interested int.

Ulf.


On Wed, Mar 16, 2016 at 11:45 AM, Eric Kuhnke  wrote:

> Would anyone care to share their experience using collectd as an
> alternative to rtg for high-resolution polling of interface traffic and
> long term storage?
>
> I am investigating the various options for large data set size, lossless
> long term traffic charting (not RRAs which lose precision over time). One
> possible use is precision 95th billing.
>
> https://collectd.org/
>



-- 

Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764
You can find my resume at: http://www.Alameda.net/~ulf/resume.html

collectd as alternative to RTG for high-resolution polling and long term storage?

[Eric Kuhnke]

Would anyone care to share their experience using collectd as an
alternative to rtg for high-resolution polling of interface traffic and
long term storage?

I am investigating the various options for large data set size, lossless
long term traffic charting (not RRAs which lose precision over time). One
possible use is precision 95th billing.

https://collectd.org/

Re: Cogent - Google - HE Fun

[Mark Tinka]

On 16/Mar/16 21:23, Owen DeLong wrote:

> Please confirm that you in fact are receiving 174 * 6939 IPv6 paths from them?
>
> Seems unlikely to me.

Nope (neither IPv4 nor IPv6) - they are about 1,500 IPv6 routes short
from what we see from the others.

You're welcome to poke if you want to test my perspective:

http://as37100.net/

They've obviously regressed a little bit, although it appears they never
did have any engagement with HE in particular, for either IP protocol.
In fairness, we knew getting into bed with Cogent would bring Daily Joy,
which is why we considered them last of all the major networks to on-board.

But as I said before, we have sufficient transit and peering that
Cogent's insufficiencies do not impact us. For now, what they have on
their network offers us some value (and they aren't necessarily any
cheaper than any of our other transit providers). If that value should
drop below a level where having them on the network is neither here nor
there, they'll get the boot.

Mark.

Re: Internet Exchanges supporting jumbo frames?

[Jakob Heitz (jheitz)]

You would hardly notice it.
Helium is 4 times as heavy as hydrogen, but only marginally less buoyant.

Header overhead:
Ethernet=38
IPv4=20
TCP=20
Total=78
Protocol efficiency:
1500: 1500/1578 = 95%
9000: 9000/9078 = 99%

That's 4% better for a TCP packet, not 600%.

Thanks,
Jakob.


> On Mar 18, 2016, at 6:45 PM, Tim McKee  wrote:
> 
> I would hazard a guess that reducing the packet header overhead *and* the 
> Ethernet interframe gap time by a factor of 6 could make enough of an 
> improvement to be quite noticeable when dealing with huge dataset transfers.
> 
> Tim McKee
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jakob Heitz (jheitz)
> Sent: Friday, March 18, 2016 18:21
> To: Dale W. Carder
> Cc: nanog@nanog.org
> Subject: RE: Internet Exchanges supporting jumbo frames?
> 
> Then it's mainly TCP slowstart that you're trying to improve?
> 
> Thanks,
> Jakob.
> 
>> -Original Message-
>> From: Dale W. Carder [mailto:dwcar...@wisc.edu]
>> Sent: Friday, March 18, 2016 3:03 PM
>> To: Jakob Heitz (jheitz) 
>> Cc: nanog@nanog.org
>> Subject: Re: Internet Exchanges supporting jumbo frames?
>> 
>> Thus spake Jakob Heitz (jheitz) (jhe...@cisco.com) on Fri, Mar 18, 2016 at 
>> 09:29:44PM +:
>>> What's driving the desire for larger packets?
>> 
>> In our little corner of the internet, it is to increase the 
>> performance of a low number of high-bdp flows which are typically dataset 
>> transfers.
>> All of our non-commercial peers support 9k.
>> 
>> Dale
> 
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6189 / Virus Database: 4542/11829 - Release Date: 03/17/16

Re: Internet Exchanges supporting jumbo frames?

[Dale W. Carder]

Thus spake Jakob Heitz (jheitz) (jhe...@cisco.com) on Fri, Mar 18, 2016 at 
09:29:44PM +:
> What's driving the desire for larger packets?

In our little corner of the internet, it is to increase the performance
of a low number of high-bdp flows which are typically dataset transfers.
All of our non-commercial peers support 9k.  

Dale

Re: Why the US Government has so many data centers

[Todd Crane]

I was trying to resist the urge to chime in on this one, but this discussion 
has continued for much longer than I had anticipated... So here it goes

I spent 5 years in the Marines (out now) in which one of my MANY duties was to 
manage these "data centers" (a part of me just died as I used that word to 
describe these server rooms). I can't get into what exactly I did or with what 
systems on such a public forum, but I'm pretty sure that most of the servers I 
managed would be exempted from this paper/policy.

Anyways, I came across a lot of servers in my time, but I never came across one 
that I felt should've been located elsewhere. People have brought up the case 
of personal share drive, but what about the combat camera (think public 
relations) that has to store large quantities (100s of 1000s) of high 
resolution photos and retain them for years. Should I remove that COTS 
(commercial off the shelf) NAS underneath the Boss' desk and put in a data 
center 4 miles down the road, and force all that traffic down a network that 
was designed for light to moderate web browsing and email traffic just so I can 
check a box for some politician's reelection campaign ads on how they made the 
government "more efficient"

Better yet, what about the backhoe operator who didn't call before he dug, and 
cut my line to the datacenter? Now we cannot respond effectively to a natural 
disaster in the Asian Pacific or a bombing in the Middle East or a platoon that 
has come under fire and will die if they can't get air support, all because my 
watch officer can't even login to his machine since I can no longer have a 
backup domain controller on-site

These seem very far fetched to most civilian network operators, but to anybody 
who has maintained military systems, this is a very real scenario. As 
mentioned, I'm pretty sure my systems would be exempted, but most would not. 
When these systems are vital to national security and life & death situations, 
it can become a very real problem. I realize that this policy was intended for 
more run of the mill scenarios, but the military is almost always grouped in 
with everyone else anyways. 

Furthermore, I don't think most people realize the scale of these networks. 
NMCI, the network that the Navy and Marine Corps used (when I was in), had over 
500,000 active users in the AD forest. When you have a network that size, you 
have to be intentional about every decision, and you should not leave it up to 
a political appointee who has trouble even checking their email. 

When you read how about much money the US military hemorrhages, just 
remember 
- The multi million dollar storage array combined with a complete network 
overhaul, and multiple redundant 100G+ DWDM links was "more efficient" than a 
couple of NAS that we picked up off of Amazon for maybe $300 sitting under a 
desk connected to the local switch. 
- Using an old machine that would otherwise be collecting dust to ensure that 
users can login to their computers despite conditions outside of our control is 
apparently akin to treason and should be dealt with accordingly.



--Todd

Sent from my iPad

> On Mar 14, 2016, at 11:01 AM, George Metz  wrote:
> 
>> On Mon, Mar 14, 2016 at 12:44 PM, Lee  wrote:
>> 
>> 
>> Yes, *sigh*, another what kind of people _do_ we have running the govt
>> story.  Altho, looking on the bright side, it could have been much
>> worse than a final summing up of "With the current closing having been
>> reported to have saved over $2.5 billion it is clear that inroads are
>> being made, but ... one has to wonder exactly how effective the
>> initiative will be at achieving a more effective and efficient use of
>> government monies in providing technology services."
>> 
>> Best Regards,
>> Lee
> 
> That's an inaccurate cost savings though most likely; it probably doesn't
> take into account the impacts of the consolidation on other items. As a
> personal example, we're in the middle of upgrading my site from an OC-3 to
> an OC-12, because we're running routinely at 95+% utilization on the OC-3
> with 4,000+ seats at the site. The reason we're running that high is
> because several years ago, they "consolidated" our file storage, so instead
> of file storage (and, actually, dot1x authentication though that's
> relatively minor) being local, everyone has to hit a datacenter some 500+
> miles away over that OC-3 every time they have to access a file share. And
> since they're supposed to save everything to their personal share drive
> instead of the actual machine they're sitting at, the results are
> predictable.
> 
> So how much is it going to cost for the OC-12 over the OC-3 annually? Is
> that difference higher or lower than the cost to run a couple of storage
> servers on-site? I don't know the math personally, but I do know that if we
> had storage (and RADIUS auth and hell, even a shell server) on site, we
> wouldn't be needing to upgrade 

Re: Cogent - Google - HE Fun

[Christopher Morrow]

On Wed, Mar 16, 2016 at 11:22 AM, Dennis Bohn  wrote:
>
> On Mar 16, 2016 10:06 AM, "Christopher Morrow" 
> wrote:
>>
>> On Wed, Mar 16, 2016 at 9:56 AM, Dennis Bohn  wrote:
>> > So if someone (say an eyeball network) was putting out a RFQ for a gig
>> > say
>> > of upstream cxn and wanted to spec full reachability to the full V6 net,
>> > what would the wording for that spec look like?
>> > Would that get $provider's attention?
>>
>> "We would like transit services to the full ipv4 and ipv6 addressable
>> space, we would like our prefixes to be advertised to the whole of the
>> above space as well."
>>
>> then you'd by one (some) connection(s) from 'best option #1' and
>> one(some) connection(s) to 'next best option'.
>>
>> I'm not sure 'rfq' is required here is it? 
>
> I was thinking RFQ with specific requirements might get cogent attention
> more than a call. Sure they wouldn't change policy for me, but if they were
> unable to meet quote requirements repeatedly it might have some effect... or
> am I dreaming?
>

my guess is the same as Owen's ... 'your rfq don't mean squat'.
honestly it's not like people don't ask their cogent sales folk for
this sort of thing, it's just not cogent's (clearly, given how long
the HE/Cogent thing along has persisted) way of doing things.

Sometimes your belief system just isn't theirs.

>   and potentially what knobs
>> the providers expose to you for bgp TE functionality?
>
> Good thought to include that. Tnx.
> D.

Re: Cogent - Google - HE Fun

[Dennis Bohn]

So if someone (say an eyeball network) was putting out a RFQ for a gig say
of upstream cxn and wanted to spec full reachability to the full V6 net,
what would the wording for that spec look like?
Would that get $provider's attention?
On Mar 15, 2016 12:50 AM, "Todd Crane"  wrote:

>
> > This is only tangentially related but it looks like HE has surpassed
> Cogent on IPv4 adjacencies. That said the source probably suffers from a
> selection bias at the very least.
> >
> > http://bgp.he.net/report/peers
> >
> >
> Hit reply by mistake instead of reply all.
>
> > Todd Crane
> >
> >> On Mar 14, 2016, at 8:40 PM, Matthew D. Hardeman 
> wrote:
> >>
> >> It looks like Google is experimenting with a change in course on this
> issue.
> >>
> >> Here’s a look at the IPv6 routing table tonight on my router bordering
> Cogent.
> >>
> >> *>i 2607:f8b0:4013::/48
> >>2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
> >>  0150  0
>  15169 i
> >> *2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
> >>  090   0
>  174 6461 15169 i
> >> *>i 2607:f8b0:4014::/48
> >>2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
> >>  0110  0
>  6939 6461 15169 i
> >> *2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
> >>  090   0
>  174 6461 15169 i
> >> *>i 2607:f8b0:4016::/48
> >>2620:121:a000:f0::2(fe80::618:d6ff:fef1:c540)
> >>  0150  0
>  15169 i
> >> *2001:550:2:22::1d:1(fe80::12f3:11ff:fe29:2c24)
> >>  090   0
>  174 6461 15169 i
> >>
> >>
> >> This is only 3 IPv6 prefixes (out of 47 prefixes seen in my IPv6
> routing table).  Two of these prefixes I see via direct peering with Google
> and, alternatively, via Cogent through Zayo transit.  One of these prefixes
> doesn’t advertise in Google’s direct peering session (at least not in mine,
> but HE picks it up via Zayo and Cogent picks it up via Zayo).
> >>
> >> All of these are /48 subnets of their greater 2620:f8b0::/32 prefix,
> which does show up in both their direct session and in HE via Zayo.
> >>
> >>
> >>> On Mar 13, 2016, at 9: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: CALEA Requirements

[Kevin Burke]

Ignore it until you get the paperwork.  The local law enforcement can not get a 
warrant for the real time, full data capture.  Only FBI or other national 
agencies can get those subpeona's.  We went through this with our local police 
department.  They wanted to make sure we were prepared and wanted a test for 
the real time number capture on phone calls.  They didn't mention they don't 
have any equipment on their side to connect the T1.  

Ask your local neighbors.  Some area's have a number of local federal 
investigations.  If you get the deer in the headlights look from your 
competition then you may never get one of these.

The full data captures are rare.

Kevin Burke
802-540-0979
Burlington Telecom - City of Burlington
200 Church St, Burlington, VT 05401

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Lorell Hathcock
Sent: Monday, March 14, 2016 4:47 PM
To: 'NANOG list' 
Subject: CALEA Requirements

NANOG:

 

Can someone point me to the current CALEA requirements?

 

As an ISP, should I be recording all internet traffic that passes my routers?  
Or do I only have to record when and if I receive a court order?

 

I'm not under any court order now, I just want to be sure that I am compliant 
going forward in my capabilities.

 

Thanks!

 

Lorell Hathcock

Re: DataCenter color-coding cabling schema

[Jay Hennigan]

On 3/12/16 12:15 PM, Joe Hamelin wrote:

I know at Clearwire data centers we used gray for network, blue for
management and orange for RS-232 console.  At least for the initial build.
Later re-work or additions were whatever the tech had on hand ;)  They also
had labels on each end of each wire showing the path through the system,
sometimes up to six lines.  It did make it easy to bring up a data center
and find cabling errors.  To see the system last more than a year or two up
upgrades would take some strong rules and oversight.  I think it would be
worth it if your management system can keep the religion.


That's the issue, keeping it that way. "Gray for network" is likely to 
result in mostly gray cables which won't really help to differentiate 
things in the long run. Breaking it down further can get tricky in terms 
of definition. Each network has a color, but then there's this trunk 
link


We had a customer who had a scheme involving five different colors. When 
they did the initial build their wiring vendor came in with barrels of 
new cables of various lengths and colors and it looked really nice with 
cable management and all.


After a couple of years it was pretty much random in terms of color 
coding. Keeping multiple lengths on hand for dressing in raceway without 
incurring either tons of slack or bow-string taut wires is tough but 
possible, doing that in half a dozen colors can be daunting.


The electrons on the inside can't see the jacket on the outside and most 
of them are rumored to be color-blind anyway.


Maybe a compromise of a single color for most things and a different one 
for specials.


--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: Cogent - Google - HE Fun

[Jay Hennigan]

On 3/11/16 7:18 AM, Robert Jacobs wrote:

 Till we have exclusive content on IPV6 or it is a shorter, faster, bigger, 
better path then we are still fighting this uphill battle to get more adoption 
of IPV6 and it will not matter to the majority of Cogent customers that they 
can't get full IPV6 routes and connections from Cogent.


Time to resurrect "The Great IPv6 Experiment"?

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: Why the US Government has so many data centers

[Jay Hennigan]

On 3/11/16 9:03 AM, Sean Donelan wrote:


https://datacenters.cio.gov/optimization/

"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. However, rooms
containing only routing equipment, switches, security devices (such as
firewalls), or other telecommunications components shall not be
considered data centers."


In other words, Hillary Clinton's bathroom closet is a data center.

--
--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: transferring [legacy] address space from arin to ripe

[Jima]

On 2016-03-17 00:41, Randy Bush wrote:

i have just finished $subject.  arin and ripe host and admin folk were
cooperative and helpful to the point of being embarrassing; dealing with
me when the moon is in klutz has to be a major pita.  but inter-rir
transfer works, works well, and works for legacy space.


Apparently my data analytics skills are sharp enough to have found those 
networks in under 5 minutes. A /16, a /22 (effectively), and two /24s, 
right?


I see another /18 got transferred to RIPE the day after yours, so 
apparently you're not the only one doing this.


 Jima

RE: Internet Exchanges supporting jumbo frames?

[Jakob Heitz (jheitz)]

Then it's mainly TCP slowstart that you're trying to improve?

Thanks,
Jakob.

> -Original Message-
> From: Dale W. Carder [mailto:dwcar...@wisc.edu]
> Sent: Friday, March 18, 2016 3:03 PM
> To: Jakob Heitz (jheitz) 
> Cc: nanog@nanog.org
> Subject: Re: Internet Exchanges supporting jumbo frames?
> 
> Thus spake Jakob Heitz (jheitz) (jhe...@cisco.com) on Fri, Mar 18, 2016 at 
> 09:29:44PM +:
> > What's driving the desire for larger packets?
> 
> In our little corner of the internet, it is to increase the performance
> of a low number of high-bdp flows which are typically dataset transfers.
> All of our non-commercial peers support 9k.
> 
> Dale