Re: NFPA 70 National Electrical Code 2026 first draft changes

[Martin Hannigan]

On Tue, Jan 30, 2024 at 8:05 AM Jay Hennigan  wrote:

> On 1/29/24 16:11, Jay R. Ashworth wrote:
> >> It mostly just renumbers/reorganizes the NEC. Old time electricians will
> >> grumble because almost every code number changes.
> >
> > The NEC is included *by copy* in some state statutes, is it not?  If so,
> I
> > wonder how that will affect those.
>
> I believe so. The actual text has long been behind a paywall, but could
> be accessed on some state websites. NFPA has softened the paywall to
> view it but you still need to jump through some registration hoops.
>
> Typically the individual AHJ will specify a publication date of NEC as
> authoritative and it's often a few years behind the latest publication.
> Local authorities can and do make additions and changes from NEC. No
> Romex allowed in Chicago, for example.
>


AFAIK, it's free access albeit via the 'free' pay wall. Soft is a good
description.

For example once logged in:
https://www.nfpa.org/product/nfpa-11-standard/p0011code

You'll only see the "purchase option" on the page, but once you scroll down
you'll see "free access" on the right outer side. The text is watermarked,
but it's OK for non-craft users to do specific lookups. Works.

Looks like you can subscribe online and get the clean PDF's for printing
via their NFPA Link service for ~$100 per seat. HTH.

Warm regards,

-M<

Re: "Hypothetical" Datacenter Overheating

[Martin Hannigan]

On Mon, Jan 15, 2024 at 4:10 PM Jay Hennigan  wrote:

> On 1/15/24 10:37, Pennington, Scott wrote:
> > yes but it has been -8 in Chicago plenty of times before this.
> >   Very interested in root cause...
>
> Absolutely. My point was that claiming "Global warming" isn't going to
> fly as an excuse.
>

+1

Is their design N+1?

https://www.equinix.com/data-centers/americas-colocation/united-states-colocation/chicago-data-centers/ch1

We're not smashing temp records in Chicago. At least it doesn't seem so
when you look across historical data:

https://www.weather.gov/lot/Chicago_Temperature_Records

HTH,

-M<

Re: Outside plant - prewire customer demarc preference

[Martin Hannigan]

Thanks Sean!

Looks like over priced residential inner duct to me. Sheet rock
accomplishes pretty much the same thing. I want reliable home Internet too,
but it’s not a CO. I’d install a PVC sleeve on the OSP to ISP transition.
The risk of outage isn’t going to materially move one way or the other as
far as I can tell.

YMMV,

-M<


On Tue, Dec 5, 2023 at 21:28 Sean Donelan  wrote:

>
> I should have known better, network engineers don't work on the physical
> infrastructure very much anymore - memories of sitting on concrete floors
> crimping cable ends in to many IXPs :-)
>
> If you never seen or installed ENT Electrical Nonmetallic Tubing
> Conduit, also known as "smurf tube" -- here is a new YouTube video of
> someone installing a smurf tube between an external DEMARC and internal
> distribution point for his fiber connection.
>
> https://www.youtube.com/watch?v=NUCe9lAWY4U
>
>
> In the U.S. - ENT is UL listed as electrical conduit and can be used in
> most residential (and some commercial) runs.  Commonly used for
> low-voltage and fiber runs in the US.  I'm not an expert on other
> countries wiring codes.
>
> ENT is not the same as in-rack wiring management products (i.e. the
> split-wall plastic wire holders).
>

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Martin Hannigan]

On Sat, Sep 9, 2023 at 12:30 Tom Beecher  wrote:

> What network does Nanog-news operate?
>>
>> Marketing email doesn’t  belong on an operational list.  Even if its
>> NANOG marketing itself.  (Ack Kentik non involvement).
>>
>
> This is the right comment.
>
> The NANOG Mailing List Usage Guidelines  (
> https://www.nanog.org/resources/usage-guidelines/ ) are fairly clear
> about this.
>
> Posts to NANOG’s Mailing List should be focused on operational and
>> technical content only, as described by the NANOG Bylaws.
>> Using the NANOG Mailing List as a source for private marketing
>> initiatives, or product marketing of any kind, is prohibited.
>
>
> Sending this type of message to nanog@ is not appropriate, by our own
> rules. This issue will be raised at the next members meeting.
>

Thats great. Thanks. This started to happen sometime around June looking at
the sender address and my inbox.  It would be nice to be opt-in vs opt-out
and that labels are crafted to not confuse the ops list with others. I also
agree with Randy that if we can strip out the trackers here that is key.
Consistent with culture and history. Course adjustment ++.

Hope thats constructive. Thanks!

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

[Martin Hannigan]

What network does Nanog-news operate?

Marketing email doesn’t  belong on an operational list.  Even if its NANOG
marketing itself.  (Ack Kentik non involvement).

Warm regards,

-M<


On Fri, Sep 8, 2023 at 20:52 Ryan Hamel  wrote:

> Randy,
>
> You're right, the problem is not technical. It's a choice to click the
> links or not. NANOG does not have to sanitize links for you. Those emails
> do not have to be read, and no one is stopping you from filtering them out.
> For you to say, "my privacy has been sold", is simply not true.
>
> Ryan
>
> --
> *From:* NANOG  on behalf of
> Randy Bush 
> *Sent:* Friday, September 8, 2023 5:25 PM
> *To:* John Gilmore 
> *Cc:* nanog@nanog.org 
> *Subject:* Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming
> ISOC Course + More
>
> Caution: This is an external email and may be malicious. Please take care
> when clicking links or opening attachments.
>
>
> > It is totally possible to turn off the spyware in MailChimp.  You just
> > need to buy an actual commercial account rather than using their
> > "free" service.  To save $13 or $20 per month, you are instead selling
> > the privacy of every recipient of your emails.  See:
> >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fenable-and-view-click-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Pw6uDgHDzT%2BavOz1jYAbG4VzTyP0en0oiuBq0PmTtVI%3D=0
> 
> >
> >   "Check the Track clicks box to enable click tracking, or uncheck the
> >   box to disable click tracking.  ...  Mailchimp will continue to
> >   redirect URLs for users with free account plans to protect against
> >   malicious links.  ...  When a paid user turns off click tracking,
> >   Mailchimp will continue to redirect their URLs until certain account
> >   activity thresholds are met."
> >
> > Don't forget to turn off the spyware 1x1 pixel "web bugs" that
> > MailChimp inserts by default, too:
> >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailchimp.com%2Fhelp%2Fabout-open-tracking%2F=05%7C01%7Cryan%40rkhtech.org%7C4ac3a26bb5c4481c087908dbb0cbc6d7%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638298161499653329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iqkTsuhDFD3poxVltrN4x%2FWY6eXpbIivWxf4VAWcXKA%3D=0
> 
>
>
> as usual, the problem is not technical.  there is no need for mailchump
> at all.
>
> nanog management has made a very intentional decision to sell my
> privacy.  nanog has come a long way, not all of it  good.
>
> randy
>

Re: NTP Sync Issue Across Tata (Europe)

[Martin Hannigan]

Same here. Latency and the algo work together. Time outs or un-reachable peers 
are network issues.

Paging Randy Bush.

Get Outlook for iOS

From: NANOG  on behalf of John 
Gilmore 
Sent: Tuesday, August 8, 2023 17:01
To: Mel Beckman 
Cc: nanog@nanog.org 
Subject: Re: NTP Sync Issue Across Tata (Europe)

> I was also speaking specifically about installing GPS antennas in
> viable places, not using a facility-provided GPS or NTP service.

Am I confused?  Getting the time over a multi-gigabit Internet from a
national time standard agency such as NIST (or your local country's
equivalent) should produce far better accuracy and stability than
relying on locally received GPS signals.  GPS uses very weak radio
signals which are regularly spoofed by all sorts of bad actors:

  https://www.gps.gov/spectrum/jamming/

for all sorts of reasons (like misleading drone navigation):

  https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incident

Depending on satnav systems creates a large single point of failure for
worldwide civilian infrastructure.

Jamming GPS with subtly fake time data near big data centers seems like
an easy move that would cause all sorts of distributed algorithms to
start failing in unusual ways.  And in a more serious wartime attack,
many or most GPS satellites themselves would be destroyed or disabled.
Yet digital radio modulations like FT8 or DMR rely on tight time
synchronization among different transmitters.  So do many modern
cellphone modulations -- not to mention distributed database sync
algorithms.  Depending on any of these for emergency communications when
their time comes from GPS, is a recipe for having no communications
during wars or cyber-wars in which GPS satellites are attacked or
jammed.  See a longer explanation here:

  https://www.ardc.net/apply/grants/2020-grants/grant-ntpsec/

I suspect that even today, if you rely on civilian GPS time near the US
White House, Pentagon, or other military targets like bases, you will
discover "anomalies" in the local radio GPS data, compared to what you
get from an authenticated time standard over NTP.  How reliable is
civilian GPS time in Ukraine these days?

John

Re: Cogent Abuse - Bogus Propagation of ASN 36471

[Martin Hannigan]

On Thu, Jul 20, 2023 at 2:34 PM Ian Chilton  wrote:

> On Thu, 20 Jul 2023, at 7:02 PM, Martin Hannigan wrote:
>
> Pete, if all the data I see ties together like it looks aren't you able to
> take the 15m taxi ride to 60 Hudson and recover the router or shut it off?
> It's your router. Right?
>
>
> I would assume if the company no longer exists, they won't be paying the
> DC bill, so they won't let him in.
>
> Though i'm surprised they've not cut the power... or if they are just lax,
> surely could be convinced to.
>

The ARIN ORG was updated recently and so was the domain name.
https://apps.dos.ny.gov/publicInquiry/EntityDisplay

I don't know what kind of routing problems this is causing, but someone
with standing should be able to reach out to Cogent and get something done
if needed.

On the shiny object front, I can't resist. I ordered Cogent and liked it.

Warm regards,

-M<

Re: Cogent Abuse - Bogus Propagation of ASN 36471

[Martin Hannigan]

Pete, if all the data I see ties together like it looks aren't you able to
take the 15m taxi ride to 60 Hudson and recover the router or shut it off?
It's your router. Right?


On Thu, Jul 20, 2023 at 11:10 AM Pete Rohrman 
wrote:

> Ben,
>
> Compromised as in a nefarious entity went into the router and changed
> passwords and did whatever.  Everything advertised by that comprised router
> is bogus.  The compromised router is owned by OrgID: S2NL (now defunct).
> AS 36471 belongs to KDSS-23
> .  The
> compromised router does not belong to Kratos KDSS-23
> , and is
> causing routing problems.  The compromised router needs to be shut down.
> The owner of the compromised router ceased business, and there isn't anyone
> around to address this at S2NL.  The only people that can resolve this is
> Cogent.   Cogent's defunct customer's router was compromised, and is
> spewing out bogus advertisements.
>
> Pete
>
> --
> Pete
> Stage2 "Survivor Island" Bronze Medal Winner
>
>
>
> On 7/20/23 10:40, Ben Cox wrote:
>
> Can you confirm what you mean by compromised here?
>
> The prefixes currently (as far as I can see from bgp.tools) originated are:
>
> Prefix   Description209.255.244.0/24 Windstream 
> Communications LLC209.255.245.0/24 CONSOLIDATED TECHNOLOGIES INC 325 
> HUDSON209.255.246.0/24 Windstream Communications LLC209.255.247.0/24 
> CONSOLIDATED TECHNOLOGIES INC 325 HUDSON216.197.80.0/20 --
>
> The 209.xx have valid RPKI certs, so they seem validish, but all have
> RADB IRR entries made by lightower.com in 2015.
>
> Do you mean that someone has impersonated AS36471 and set up a cogent
> port, and is now announcing your space? I'm confused
>
> On Thu, Jul 20, 2023 at 3:32 PM Pete Rohrman 
>  wrote:
>
> NANOG,
>
> A customer of Cogent has a compromised router that is announcing
> prefixes sourced from AS 36471.   Cogent is propagating that to the
> world.  Problem is, those prefixes and AS don't belong to that customer
> of Cogent - AS 36471 belongs to Kratos Defense & Security Solutions,
> Inc. (see whois).
>
> Requests to Cogent Support and Abuse go un-actioned.  Need a contact at
> Cogent Abuse that can shut down that compromised router.  Anyone have a
> good contact at Cogent Abuse Dept?
>
> Cogent ticket: HD302928500
>
> Pete
>
> --
> Pete
> Stage2 "Survivor Island" Bronze Medal Winner
>
>

Re: About emails impersonating Path Network

[Martin Hannigan]

On Tue, Feb 7, 2023 at 11:59 AM J. Hellenthal via NANOG 
wrote:

> Your only option is to monitor the generic tld's atp and register them
> yourself. Clone attacks are real, impersonation has been around since
> centuries and yes, its an attack vector but only impacting your customers.
> There is a vector you can pursue, its action by lawsuit. Would you rather
> pay the registration of the domain or would you rather pay the retainer
> costs of lawyers ...
>
> This is what the free web permits. Your only choice at this point is the
> retainer fee and intergovernmental practices.
>
>
> PeeringDB may be able to implement different practices but I have a pretty
> good feeling they are at their wits end to void practices that impact its
> "yellow pages" service.
>

[ PDB product committee hat on ]

I'll make sure this gets visibility with the PeeringDB  product/ops
committee and see if we can contribute here. If we can help make it harder
I'm sure we would.

Warm regards,

-M<

Re: About emails impersonating Path Network

[Martin Hannigan]

Is widespread impact confirmed?

Unfortunate. Our ASN’s and location contacts in PDB have not received
anything from Path. I looked in search engines (quickly) and see nothing
negative re: your ASN. I found a reference as new to the platform at AMSIX
7/21 for AS 396998. Lack of mail security bits on most platforms are
flagged or quarantined AFAIK. These are typically called “Joe Jobs”.  I’d
save the LEA path for more important things (credibility).

Warm regards,

-M<




On Mon, Feb 6, 2023 at 3:39 PM Konrad Zemek  wrote:

> Hi Nanog,
>
> It looks like someone with an axe to grind against our company has decided
> to email every AS contact they could find on PeeringDB, impersonating us
> and sometimes spoofing our domains.
>
> We're aware of the emails and are sorry for the inconvenience. We've since
> added SPF records to the domains we own but don't use (the perps have since
> name-squatted some new ones). We're also actively working with law
> enforcement on the matter.
>
> Thanks
> Konrad Zemek
> CTO Path Network
> AS396998
>

Re: txt.att.net outage?

[Martin Hannigan]

On Fri, Jan 20, 2023 at 9:15 AM William Herrin  wrote:

> On Thu, Jan 19, 2023 at 8:09 PM Dan Walters via NANOG 
> wrote:
> > Know this is a longshot, any chance anyone from the txt.att.net domain
> might be able to help us with what we believe is a blacklist block or
> possibly an outage?
> > We deal with 911 cad dispatching and is affecting first responders so
> looking to see if there is a faster way to resolution.
>
> Hi Dan,
>
> As I understand it, txt.att.net is a low-volume courtesy service not
> intended for important communications. A paid service like Twilio can
> handle production-grade SMS delivery.
>
>
>
I think ChatGPT agrees with you:

txt.att.net is a domain owned by AT, a large American telecommunications
company. It is typically used to send and receive text messages, and it is
generally considered a reliable resource for this purpose. However, as with
any online service, it is possible for issues to arise, such as delays in
delivery or errors in sending messages. It is also worth noting that
txt.att.net is a free service, so it might not have the same level of
security or reliability as a paid service. If you have any specific
concerns or experience issues with txt.att.net, it's best to contact AT
customer service for assistance.

;-)

Warm regards,

-M<

Re: ICANN

[Martin Hannigan]

[ I know, I know... ]

Looks like they have a valid registered agent for service of process in CA:

C T Corporation System
33 North Brand Blvd.
Suite 700
Glendale, CA 91203


Warm regards,

-M<




On Fri, Jul 8, 2022 at 11:24 AM Keith Medcalf  wrote:

>
> Does anyone have contact information (or address for service of legal
> documents) for ICANN?  There web site does not appear to contain contact
> information.
>
> ICANN apparently promulgates a policy which requires clickage on spam
> links in e-mail.  I intend to sue them for trillions of dollars for this
> policy.
>
>
> --
> (CAUTION) You are advised that if you attack my person or property, you
> will be put down in accordance with the provisions of section 34 & 35 of
> the Criminal Code respectively.  If you are brandishing (or in
> possession) of a weapon then lethal force will be applied to your person
> in accordance with the law.  This means that your misadventures may end
> in your death.  Consider yourself cautioned and govern your actions
> appropriately.
>
>
>
>
>

Re: MSA’s and network architecture

[Martin Hannigan]

On Wed, May 18, 2022 at 01:59 Mark Tinka  wrote:

>
>
> On 5/18/22 03:55, Martin Hannigan wrote:
>
> >
> >
> > All,
> >
> > Why do MSA’s matter as related to network architecture?
>
> As in "Master Services Agreement"?


Admittedly vague, but deliberate. Perhaps the thread answered the question.
:-)

Metropolitan Statistical Area.The easy answer is "its where the eyeballs
are". If so, that's great and it is (was) that simple. A lot of companies
are predicting where the "edge" will actually shake out and most are using
MSA. It's not that simple, there are certainly other attributes, but it may
be that simple. Sorting by MSA and descending population you would think it
is a no-brainer. Not necessarily? So perhaps a bolt on to the question,
"and what attributes influence that importance?".

Thanks --

-M<

MSA’s and network architecture

[Martin Hannigan]

All,

Why do MSA’s matter as related to network architecture?

Thanks all —

-M<

Re: Copper Termination Blocks

[Martin Hannigan]

On Thu, Apr 14, 2022 at 8:57 PM Shane Ronan  wrote:

> I think you'd be very surprised if you walked into the central offices of
> MANY of the large LECs.
>
> The majority of the wire frames are gone, replaced with fiber, even where
> the service is delivered as copper to the end user, it's usually served
> from something fiber fed much closer to the end user.
>


I'm in LEC CO's a lot. I'm not seeing this.



> I can tell you that one MAJOR LEC has a major push going on to retire ALL
> copper.
>

I'm sure they are. TDM has been on the target list for years and LEC's
still pay cross connect fees on TDM services. They're getting out of the
network, but not quickly and not if they are printing money.

Warm regards,

-M<

Re: Copper Termination Blocks

[Martin Hannigan]

Its not ancient. While cooper based products are slowly fading they still
matter. Im using 66 blocks to accommodate gauge/voltage for dial tone in
all facilities.  Lots of OOB still happens via copper dial tone or DSL.
Show me one LEC that has torn down their wire frame?

We bought new.  Im seeing this product on the intertubes new at $18 per
block. We didn’t mount distribution from LEC in rack. Instead we placed the
standard 5/8’s plywood backboard and mounted there. We transition to a 110
block in a rack over ladder tray via ABAM cable to deliver to the back of a
110  block and patch from front. Not perfect, but cost effective, easy to
manage and simple. It works.

Warm regards,

-M<


On Thu, Apr 14, 2022 at 16:14 Mike Hammett  wrote:

> I know I'm discussing what some consider ancient technology. I counter
> that it meets or exceeds the needs of many, many people.
>
> Currently, we use 100-pr Telect-style termination blocks. They don't offer
> much in terms of ease of use for testing and don't organize well on a 19"
> or 23" rack.
>
> I was recommended to look at Krone blocks. They look just great. Easy to
> break into for testing with their "look both ways" plug as well as their
> preterminated blocks looked much easier to rack-mount.
>
> Well, Krone was bought by ADC. ADC was bought by Tyco Electronics. TE was
> bought by Commscope. Commscope discontinued everything I found interesting
> with no replacements.
>
>
> Some of the stuff is on eBay (even NIB), some not.
>
> Any recommendations for places to get old telco blocks, testers, mounts,
> etc.?
>
> Any recommendations for alternatives that are easier to source?
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>

Re: Cogent pulled out of Russia based on risk analysis

[Martin Hannigan]

8m20s.



On Fri, Mar 25, 2022 at 8:54 AM Mike Hammett  wrote:

> Timestamp?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Lady Benjamin Cannon of Glencoe, ASCE" 
> *To: *"NANOG Group" 
> *Sent: *Friday, March 25, 2022 7:37:22 AM
> *Subject: *Cogent pulled out of Russia based on risk analysis
>
> Confirmation from their CEO that Cogent shut down service in Russia due to
> increased use of the connections for cyberattacks, and because only $10m in
> rev came from Russia.
>
> Cogent had no equipment in Russia.
>
> Details: https://youtu.be/l_x2LQZOzF8
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
>
> FCC License KJ6FJJ
>
> Sent from my iPhone via RFC1149.
>
>

Re: Bombs and Hackers are Battering Ukraine's Internet Providers

[Martin Hannigan]

There's a group of our colleagues working to help out where they can.

Keep Ukraine Connected

https://nogalliance.org/our-task-forces/keep-ukraine-connected/

FYI,

-M<



On Tue, Mar 15, 2022 at 1:22 PM Sean Donelan  wrote:

>
>
> https://www.forbes.com/sites/thomasbrewster/2022/03/15/internet-technicians-are-the-hidden-heroes-of-the-russia-ukraine-war/?ss=cybersecurity=75eb5cdd2884
>
> Images sent to Forbes by Kyivstar show what the conditions are like.
> Despite obliterated terrain and internet wires, fire-blackened data
> centers, curfews, lack of light, and the danger of death from above, the
> fixers go out and turn the internet back on so Ukrainians can stay in
> touch with one another and get word out beyond borders, to illuminate for
> the world the darkness that’s descended on their nation. Their government
> calls them the “invisible heroes” of the war, entering dangerous places to
> replace and upgrade equipment.
> [...]
>
>
> Satellite outage caused 'huge loss in communications' at war's outset
> -Ukrainian official
>
>
> https://www.reuters.com/world/satellite-outage-caused-huge-loss-communications-wars-outset-ukrainian-official-2022-03-15/
>
> A senior Ukrainian cybersecurity official said that the digital sabotage
> that hit Viasat's KA-SAT network last month caused a massive
> communications outage at the outset of Russia's invasion.
>
> Speaking to journalists on Tuesday, Victor Zhora said he could not reveal
> much about the incident, which crippled tens of thousands of satellite
> modems across Europe on the morning of Feb. 24, just as Russian armor
> pushed into Ukraine.
> [...]
>
>
> New narrative forms on Russia-Ukraine cyberwar as Viasat outage
> investigated
>
>
> https://www.scmagazine.com/analysis/cyberespionage/new-narrative-forms-on-russia-ukraine-cyberwar-as-viasat-outage-investigated
>
> Gen. Paul Nakasone, head of the National Security Agency, issued what
> retroactively seems like a carefully worded answer at a Senate hearing to
> a question about the relative lack of cyberwarfare during the war in
> Ukraine, saying that the U.S. was aware of "three or four" cyberattacks in
> Ukraine. He did not mention which attacks those were, though three or four
> candidates other than Viasat were already known to the public.
>

Re: Cogent cutting links to Russia?

[Martin Hannigan]

On Fri, Mar 4, 2022 at 5:17 PM Aaron Wendel 
wrote:

> I think you're reading it incorrectly.
>
> The US government and many other countries have imposed sanctions
> against Russia and barred businesses in those countries from doing
> business in Russia.  Cogent is a US based company and, even if it
> operates on foreign jurisdictions through subsidiaries, has issues
> providing services to sanctioned entities.  That's how I read the
> excerpt provided.
>
> Aaron
>




Yes.

I picked this up via news related to Lumen and Russia today.

"We decided to disconnect the network due to increased security risk inside
Russia."

https://news.lumen.com/RussiaUkraine

Warm regards,

-M<

Re: Cogent cutting links to Russia?

[Martin Hannigan]

I would argue they don't have much of a choice:

"The economic sanctions put in place as a result of the invasion and the
increasingly uncertain security situation make it impossible for Cogent to
continue to provide you with service."

I would expect to see others follow suit  if that is the case.



On Fri, Mar 4, 2022 at 1:55 PM Michael Thomas  wrote:

>
> I know the link is paywalled, but it's super high level so not much is
> lost. But what does everybody think of this? I imagine that just Cogent
> cutting them off isn't going to make much difference.
>
>
> https://www.washingtonpost.com/technology/2022/03/04/russia-ukraine-internet-cogent-cutoff/
>
> Mike
>
>

Re: New minimum speed for US broadband connections

[Martin Hannigan]

+1

On Sat, Feb 19, 2022 at 11:26 Mike Hammett  wrote:

> *nods* I agree.
>
> Usually, it's too many spineless people that won't stand up to someone
> that couldn't make friends in high school.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Dorn Hetzel" 
> *To: *sro...@ronan-online.com
> *Cc: *"Mike Hammett" , "NANOG" 
> *Sent: *Saturday, February 19, 2022 10:16:06 AM
> *Subject: *Re: New minimum speed for US broadband connections
>
> Yeah, the evils of HOAs go *way* beyond shitty internet
>
> On Sat, Feb 19, 2022 at 11:15 AM  wrote:
>
>> Sounds like you’ve never lived in an HOA.
>>
>> On Feb 19, 2022, at 11:09 AM, Mike Hammett  wrote:
>>
>> 
>> "A single customer who has no sway over an entire HOA"
>>
>> If you can't sway the whole HOA, then the problem must not be that bad.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Cory Sell via NANOG" 
>> *To: *"Mike Lyon" 
>> *Cc: *"NANOG" 
>> *Sent: *Wednesday, February 16, 2022 7:16:37 PM
>> *Subject: *Re: New minimum speed for US broadband connections
>>
>> See this is my point. People always dismiss these issues and say they
>> could easily get service. Then, when someone comes in with an actual
>> request for said service, the answer we get is about structured deals with
>> HOA/property management. What about for a single customer? A single
>> customer who has no sway over an entire HOA, a single customer who is told
>> to go “pound sand” by the property manager.
>>
>> If you can’t give a single figure or even rough numbers for a single
>> customer, I’d say avoid dismissing the problem. If you can provide that
>> now, I’d be very curious to still see them. :)
>>
>> On Wed, Feb 16, 2022 at 7:10 PM, Mike Lyon  wrote:
>>
>> Depends on many factors…
>>
>> If the whole HOA wanted service, then a licensed link could possibly be
>> put in delivering a high capacity circuit delivering about 100 Mbps to the
>> subscriber. Price to the customer would vary depending on how the deal is
>> structured with the HOA/property management company.
>>
>> Could also look into getting some fiber delivered and feed it from that.
>>
>> -Mike
>>
>> On Feb 16, 2022, at 17:02, Cory Sell  wrote:
>>
>>  Out of pure curiosity, let’s assume they COULD put an antenna on the
>> roof…
>>
>> What is the service? Bandwidth, latency expectation, cost?
>>
>> Note that in almost every condominium or apartment complex I have heard
>> of, they do NOT allow roof builds. This is why satellite TV in those areas
>> require people to put an antenna on their patio, even if it’s half-blocked.
>>
>> On Wed, Feb 16, 2022 at 6:51 PM, Mike Lyon  wrote:
>>
>> If they allow antennas on the roof, we can service them :)
>>
>> Your house, on the other hand, we already lucked out on that one!
>>
>> -Mike Lyon
>> Ridge Wireless
>>
>> On Feb 16, 2022, at 16:48, Matthew Petach  wrote:
>>
>> 
>>
>>
>> On Wed, Feb 16, 2022 at 1:16 PM Josh Luthman 
>> wrote:
>>
>>> I'll once again please ask for specific examples as I continue to see
>>> the generic "it isn't in some parts of San Jose".
>>>
>>
>>
>> You want a specific example?
>>
>> Friend of mine asked me to help them get better Internet connectivity a
>> few weeks ago.
>>
>> They live here:
>>
>> https://www.google.com/maps/place/Meridian+Woods+Condos/@37.3200394,-121.9792261,17.47z/data=!4m5!3m4!1s0x808fca909a8f5605:0x399cdd468d99300c!8m2!3d37.3190694!4d-121.9818295
>>
>> Just off of I-280 in the heart of San Jose.
>>
>> I dug and dug, and called different companies.
>> The only service they can get there is the 768K DSL service they already
>> have with AT
>>
>> Go ahead.  Try it for yourself.
>>
>> See what service you can order to those condos.
>>
>> Heart of Silicon Valley.
>>
>> Worse 

Re: LEC copper removal from commercial properties

[Martin Hannigan]

On Thu, Feb 17, 2022 at 11:12 AM Anne P. Mitchell, Esq. 
wrote:

>
> > On Feb 17, 2022, at 9:02 AM, Anne P. Mitchell, Esq. 
> wrote:
> >
> > I have a note in to some FCC colleagues;  I'll report back on what they
> say (assuming I hear back).
> >
>
> P.S.  In the meantime, the claimed order on which the letter rests is
> FCC-19-72A1 which you can find here, if you're in the mood for some light
> reading:
>
> https://docs.fcc.gov/public/attachments/FCC-19-72A1.docx
>
> It says nothing about this.  And certainly the FCC would not issue
> something with such a short date fuse;  that letter appears to be a scam
> using scare and pressure tactics. Perhaps they are looking to steal your
> copper.
>

Anne;

I had the same thought and dug into it. I traced the email chain backwards
as well as the office phone. The email (and named employee) are legit as
well as the switch serving the office line. Everything adds up. I don't
have a reason to believe it's a scam. They also noted they will abandon
existing infra in place. Good observation. Thanks!

-M<

Re: LEC copper removal from commercial properties

[Martin Hannigan]

On Wed, Feb 16, 2022 at 11:22 PM  wrote:

>
> >I believe that should be 19-72A1.
> >
> >https://docs.fcc.gov/public/attachments/FCC-19-72A1.pdf
> >
> >Essentially, all services must be transitioned to fiber or wireless by
> August 2nd, 2022.
>
> I'm reading that document and that's not what it appears to say at all.
>
> This seems to be about discontinuing the artificial price restrictions of
> 2 and 4 wire dry pair loops that LECs resell to service providers, e.g.
> competitive DSL providers.
>
> I don't see anything in this order which would mandate that LECs
> discontinue
> their own DSL or POTS services.  It would be especially ludicrous since in
> many parts of many markets, there is no alternative at this time.
> Shane
>


Here's the exact, troubling, language they use in the LEC letter for
commercial properties:

"If we do not here from you, or if you do not allow LEC access to your
property to complete the fiber upgrade, all services provided to your
tenants in your property over Verizon copper wires (voice and data service,
as well as, alarm, elevator, and office lines) will be discontinued as part
of the copper retirement plans that LEC expects to initiate in the near
future. *This includes services provided through other providers using
LEC's copper lines.* *After services are discontinued tenants with voice
service provided over copper will lose dial tone, including the ability to
dial 911."*

Overall, it was poorly written and initially geared towards
multi-tenant/residential, not a commercial office tower. They used the
words "plan" and "expected".

Warm regards,

-M<

Re: LEC copper removal from commercial properties

[Martin Hannigan]

Looks like its abandon in place "AIP" from the agreement.


On Wed, Feb 16, 2022 at 9:03 PM L F  wrote:

> Who becomes the Beneficial Owner of the Copper once Removed?
>
>
> Just Curious.
>
>
> LF
>
> On Wed, Feb 16, 2022 at 9:01 PM Martin Hannigan 
> wrote:
>
>>
>> NANOG'ers;
>>
>> At least in Boston, commercial property owners are receiving notices that
>> 'copper  lines are being removed per FCC rules' and replaced with fiber.
>> The property owner, not the network operators (or users of unbundled
>> elements if that's even still a thing) are being presented with an
>> agreement that acknowledges the removal, authorizes the fiber installation
>> and provides for a minor oversight of the design. It suggests that no costs
>> are involved in terms of hosting equipment. No power reimbursement. No rent
>> for spaces used.
>>
>> There is an ominous paragraph in the letter that says if the property
>> owner doesn't comply that tenants will lose all services including elevator
>> phones, alarms, voice, internet and any copper/ds0 originated services.
>> They didn't say 911, but that would go without saying.
>>
>> Has anyone heard of this?
>> What FCC rule requires this?
>>
>> Thanks for any insights.
>>
>> Warm regards,
>>
>> Martin
>>
> --
>   Liz ***
> 416.660.5456
>

LEC copper removal from commercial properties

[Martin Hannigan]

NANOG'ers;

At least in Boston, commercial property owners are receiving notices that
'copper  lines are being removed per FCC rules' and replaced with fiber.
The property owner, not the network operators (or users of unbundled
elements if that's even still a thing) are being presented with an
agreement that acknowledges the removal, authorizes the fiber installation
and provides for a minor oversight of the design. It suggests that no costs
are involved in terms of hosting equipment. No power reimbursement. No rent
for spaces used.

There is an ominous paragraph in the letter that says if the property owner
doesn't comply that tenants will lose all services including elevator
phones, alarms, voice, internet and any copper/ds0 originated services.
They didn't say 911, but that would go without saying.

Has anyone heard of this?
What FCC rule requires this?

Thanks for any insights.

Warm regards,

Martin

Re: Amazon peering revisited

[Martin Hannigan]

There are also three different ASNs and different policy decision trees;
they all report selective criteria such as minimum of 10GE, multiple
locations, specific locations, etc. Not sure it's as simple as 'getting the
right person' more than it is about meeting the right conditions. Easier
for network operators. Enterprises may be different (and better off with
their upstreams or PacketFabric).

YMMV,

-M<



On Fri, Feb 4, 2022 at 5:30 PM Mike Hammett  wrote:

> "For a company like Amazon..."
>
> True, but also, they're at a size where staffing and operating peering
> operations generously has a negligible impact on the fiscal situation of
> the company (or even department).
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Kevin Burke" 
> *To: *"Lincoln Dale" , "Kelly Littlepage" <
> ke...@onechronos.com>
> *Cc: *nanog@nanog.org
> *Sent: *Friday, February 4, 2022 3:25:53 PM
> *Subject: *RE: Amazon peering revisited
>
> Have gotten into the habit of making annual peering requests to Amazon
> asking turn up a session on a shared IXP peering.  Once was able to get a
> peering session turned up, no traffic was ever shifted onto it before we
> moved out of that carrier hotel a year or so later.  The amazon peering
> email box does have humans surfing it.
>
>
>
> Over the years a number of network operators have mentioned getting little
> response from Amazon about peering requests.
>
>
>
> For a company like Amazon they have little reason to do peering with small
> scale operators.  They already peer with the tier 1’s and assume I will do
> what I need to balance my bits.  The fancy algorithms they use to balance
> traffic around does allow them to operate a decent network with fewer staff
> and less links to the small ISPs.  Just a network operator here, trying to
> get my bytes across the wire.
>
>
>
> Enjoy your weekend!
>
>
>
> Kevin Burke
>
> 802-540-0979
>
> Burlington Telecom
>
> 200 Church St, Burlington, VT
>
>
>
> *From:* NANOG  *On
> Behalf Of *Lincoln Dale
> *Sent:* Thursday, February 3, 2022 12:20 PM
> *To:* Kelly Littlepage 
> *Cc:* nanog@nanog.org
> *Subject:* Re: Amazon peering revisited
>
>
>
> WARNING!! This message originated from an *External Source*. Please use
> proper judgment and caution when opening attachments, clicking links, or
> responding to this email.
>
> On Thu, Jan 27, 2022 at 8:22 AM Kelly Littlepage via NANOG <
> nanog@nanog.org> wrote:
>
> Hi all, a nanog thread started on November 23, 2018 discussed the
> challenges of getting Amazon peering sessions turned up. Has anyone had
> luck since/does anyone have a contact they could refer me to — off-list or
> otherwise? The process of getting PNI in place with other CSPs was
> straightforward, but I haven't heard back from AWS after a month and
> several follow-ups. Our customers would really benefit from us getting this
> sorted.
>
>
>
> There are many folks that here that are in AWS. Assuming you have followed
> what is in https://aws.amazon.com/peering/ (and
> https://aws.amazon.com/peering/policy/) then send me details privately
> about what/when/who and I'll reach out internally to the relevant folks.
>
>
>
>

Re: [External] Re: Anyone else getting the 'spam' bomb threat?

[Martin Hannigan]

Hi Becki,

For me, it's not credible enough to put resources into pursuing it. Beyond
that any benefits as a result of tracking it down would probably be less
than zero. I posted the contents and headers in pastebin so if it had value
to anyone else they'd be able to take advantage of it.

Warm regards,

-M<


On Thu, Oct 21, 2021 at 9:24 AM Kain, Becki (.)  wrote:

> So what ever happened to the threatener?  Was he caught?
>
>
>
> *From:* NANOG  *On Behalf Of *Martin
> Hannigan
> *Sent:* Wednesday, October 20, 2021 11:44 PM
> *To:* Omar Haider 
> *Cc:* nanog 
> *Subject:* Re: [External] Re: Anyone else getting the 'spam' bomb threat?
>
>
>
> WARNING: This message originated outside of Ford Motor Company. Use
> caution when opening attachments, clicking links, or responding.
>
>
>
>
>
> Hi Omar,
>
>
>
> This is likely a hoax. Probably a “joe job” - making it appear as someone
> innocent is responsible. Its good to share this info to raise  network
> operators awareness since even if it is fake its concerning how many
> received it.
>
>
>
> I’ll leave it to the pros here to tell us if we shouldn’t worry.
>
>
>
> Warm regards,
>
>
>
> -M<
>
>
>
>
>
>
>
> On Wed, Oct 20, 2021 at 21:18 Omar Haider  wrote:
>
> I feel uncomfortable in this newsletter
>
>
>
> On Wed, Oct 20, 2021, 10:56 AM Martin Hannigan  wrote:
>
>
>
>
>
> I put what we received up on pastebin entirely with headers (and redacted
> our info).
>
>
>
> https://pastebin.com/kLjPm8Nk
> <https://clicktime.symantec.com/35Wa5BUMZ7c8nUrobeoNvR67Vc?u=https%3A%2F%2Fpastebin.com%2FkLjPm8Nk>
>
>
>
> Warm regards,
>
>
>
> -M<
>
>
>
>
>
>
>
> On Wed, Oct 20, 2021 at 9:19 AM Radu-Adrian Feurdean <
> na...@radu-adrian.feurdean.net> wrote:
>
> On Tue, Oct 19, 2021, at 16:00, Hunter Fuller via NANOG wrote:
> > We have a distinct abuse address (not just abuse@) and that is where
> > the messages were sent.
> >
> > We didn't receive the bomb threat ones. We only received the (somewhat
> > more amusing) messages entitled "Your network has been PWNED" and
> > "Fuck you".
>
> Hi,
>
> We got the same here at France-IX. It was on friday 15th. Hopefully, they
> "PWNED" all our Cisco and Mikrotik routers (of which we have none).
>
> > The situation loses its humor entirely with the introduction of bomb
> > threats. Seems like a script kiddie taking things way too far.
>
> I heard that yesterday (19th) evening there was law enforcement deployment
> and evacuation in the area of a major Paris (FR, EU) telco hotel,
> apparently due to "threats to a business in the area". Details (popcorn) on
> FrNOG (in french) :
> https://www.mail-archive.com/frnog@frnog.org/msg67540.html
> <https://clicktime.symantec.com/3P7mG6Lx8b2Qo7sjs1uqaSZ7Vc?u=https%3A%2F%2Fwww.mail-archive.com%2Ffrnog%40frnog.org%2Fmsg67540.html>
>
>

Re: [External] Re: Anyone else getting the 'spam' bomb threat?

[Martin Hannigan]

Hi Omar,

This is likely a hoax. Probably a “joe job” - making it appear as someone
innocent is responsible. Its good to share this info to raise  network
operators awareness since even if it is fake its concerning how many
received it.

I’ll leave it to the pros here to tell us if we shouldn’t worry.

Warm regards,

-M<



On Wed, Oct 20, 2021 at 21:18 Omar Haider  wrote:

> I feel uncomfortable in this newsletter
>
> On Wed, Oct 20, 2021, 10:56 AM Martin Hannigan  wrote:
>
>>
>>
>> I put what we received up on pastebin entirely with headers (and redacted
>> our info).
>>
>> https://pastebin.com/kLjPm8Nk
>>
>> Warm regards,
>>
>> -M<
>>
>>
>>
>> On Wed, Oct 20, 2021 at 9:19 AM Radu-Adrian Feurdean <
>> na...@radu-adrian.feurdean.net> wrote:
>>
>>> On Tue, Oct 19, 2021, at 16:00, Hunter Fuller via NANOG wrote:
>>> > We have a distinct abuse address (not just abuse@) and that is where
>>> > the messages were sent.
>>> >
>>> > We didn't receive the bomb threat ones. We only received the (somewhat
>>> > more amusing) messages entitled "Your network has been PWNED" and
>>> > "Fuck you".
>>>
>>> Hi,
>>>
>>> We got the same here at France-IX. It was on friday 15th. Hopefully,
>>> they "PWNED" all our Cisco and Mikrotik routers (of which we have none).
>>>
>>> > The situation loses its humor entirely with the introduction of bomb
>>> > threats. Seems like a script kiddie taking things way too far.
>>>
>>> I heard that yesterday (19th) evening there was law enforcement
>>> deployment and evacuation in the area of a major Paris (FR, EU) telco
>>> hotel, apparently due to "threats to a business in the area". Details
>>> (popcorn) on FrNOG (in french) :
>>> https://www.mail-archive.com/frnog@frnog.org/msg67540.html
>>>
>>

Re: [External] Re: Anyone else getting the 'spam' bomb threat?

[Martin Hannigan]

I put what we received up on pastebin entirely with headers (and redacted
our info).

https://pastebin.com/kLjPm8Nk

Warm regards,

-M<



On Wed, Oct 20, 2021 at 9:19 AM Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net> wrote:

> On Tue, Oct 19, 2021, at 16:00, Hunter Fuller via NANOG wrote:
> > We have a distinct abuse address (not just abuse@) and that is where
> > the messages were sent.
> >
> > We didn't receive the bomb threat ones. We only received the (somewhat
> > more amusing) messages entitled "Your network has been PWNED" and
> > "Fuck you".
>
> Hi,
>
> We got the same here at France-IX. It was on friday 15th. Hopefully, they
> "PWNED" all our Cisco and Mikrotik routers (of which we have none).
>
> > The situation loses its humor entirely with the introduction of bomb
> > threats. Seems like a script kiddie taking things way too far.
>
> I heard that yesterday (19th) evening there was law enforcement deployment
> and evacuation in the area of a major Paris (FR, EU) telco hotel,
> apparently due to "threats to a business in the area". Details (popcorn) on
> FrNOG (in french) :
> https://www.mail-archive.com/frnog@frnog.org/msg67540.html
>

Re: FYI: NANOG and ICANN

[Martin Hannigan]

On Fri, Oct 8, 2021 at 4:47 PM Owen DeLong via NANOG 
wrote:

>
>
> On Oct 8, 2021, at 12:39 PM, Warren Kumari  wrote:
>
>
>
> On Fri, Oct 8, 2021 at 2:39 PM Owen DeLong via NANOG 
> wrote:
>
>> I see this as a way to allow NANOG to help channel some of ICANN’s
>> incredible excess of funding
>> towards more useful pursuits than those ICANN has endowed so far.
>>
>
>
> https://www.icann.org/en/announcements/details/icann-and-first-sign-memorandum-of-understanding-on-dns-threats-mitigation-22-5-2020-en
>
>
> https://www.icann.org/en/announcements/details/icann-signs-memorandum-of-understanding-with-the-georgian-national-communications-commission-7-12-2020-en
>
>
> https://www.icann.org/en/announcements/details/gsma-and-icann-sign-memorandum-of-understanding-at-gsma-mobile-world-congress-28-2-2018-en
>
>
> https://www.icann.org/en/announcements/details/icann-signs-memorandum-of-understanding-with-the-global-cyber-alliance-16-6-2020-en
>
> I suspect that if you think that this will make it rain, you will be sadly
> disappointed...
>
>
> I don’t expect it will do any good at all. I hope that it will be slightly
> less damaging than the things ICANN
> usually spends money on.
>

I had some time on my hands early this morning and did a close reading.

There'a typo in Article 3 Section 1.

Seems like it was more about the education program than anything.

I trust NANOG to be less destructive than ICANN and as near as I can tell,
> this partnership is mostly ICANN funding
> and NANOG doing.
>

See Article 4.

*The Parties agree to use their own funds or financial resources to fulfill
their respective responsibilities under this MoU*. This MoU shall not cause
any financial obligations on any one of the Parties hereto as a result of
enforcing any of its rights or executing any of its obligations hereunder.


It's a nice letter from ICANN supporting the education program for the most
part.



Warm regards,

-M<

Re: Rack rails on network equipment

[Martin Hannigan]

On Fri, Sep 24, 2021 at 1:34 PM Jay Hennigan  wrote:

> On 9/24/21 09:37, Andrey Khomyakov wrote:
>
> > *So ultimately my question to you all is how much do you care about the
> > speed of racking and unracking equipment and do you tell your suppliers
> > that you care? How much does the time it takes to install or replace a
> > switch impact you?*
>
> Very little. I don't even consider it when comparing hardware. It's a
> nice-to-have but not a factor in purchasing.
>
> You mention a 25-minute difference between racking a no-tools rail kit
> and one that requires a screwdriver. At any reasonable hourly rate for
> someone to rack and stack that is a very small percentage of the cost of
> the hardware. If a device that takes half an hour to rack is $50 cheaper
> than one that has the same specs and takes five minutes, you're past
> break-even to go with the cheaper one.
>

This. Once they're racked, they're not going anywhere. I would summarize as
they're certainly nice, but more of a nice to have. The only racking
systems I try to avoid are the WECO (Western Electric COmpany) standard.
The square "holes".

Warm regards,

-M<

Re: The great Netflix vpn debacle!

[Martin Hannigan]

On Tue, Aug 31, 2021 at 2:19 PM Bryan Holloway  wrote:

> So I've made some progress, but not on the HBO front. (Hulu and Netflix
> have been responsive so far.)
>
> Tried the e-mail address on Mike Hammett and Co.'s handy web-page, but
> got no response after several days. Ironically we were able to get
> through to the "closed-captioning" department, but this isn't
> particularly useful.
>
> Does anyone have another possible contact for HBO folks to get some
> prefixes unflagged as "VPN"?
>

I see a CDN at least in the path of their web server:


> To be clear, this is not a geolocate issue. At least according to the
> error our users are getting.
>
> Thanks, all!
>
>
> On 8/28/21 1:51 AM, Justin Krejci wrote:
> > +1 on Bryan's message.
> >
> >
> > TL;DR
> >
> > It seems lots of ISPs are struggling to figure out the why and the where
> > of many IP addresses or blocks that are suddenly being blacklisted or
> > flagged as VPNs or as out of service area.
> >
> >
> >
> >
> > I would really love to find, as Bryan said, if there is one particular
> > IP reputation data provider who either got real aggressive recently or
> > some (contaminated?) data was shared around. If there is I have no
> > problem wading through their support processes to get it sorted but as
> > it stands I just don't know who to call. It just has been very difficult
> > to glean anyactionable info and of course the normal support teams at
> > the respective streaming providers mostly just are telling customers to
> > call their ISP as if every random ISP has some special backdoor
> > contact to every streaming provider where we can just get problems
> > resolved quickly and easily while we all have a good laugh at people
> > being able to watch their preferred movies and shows.
> >
> >
> > At least with email DNSBL filtering you usually get informed which DNSBL
> > you are listed on and you can sort that out directly. In this case, the
> > overall system of IP reputation based filtering seems still
> > comparatively immature. The most I have gotten is after a very long
> > phone call with someone at Hulu, they confirmed there is some issue
> > affecting multiple networks and they are working on the issue and
> > suggested I go through a whitelisting request process which may solve
> > the problems but just for Hulu obviously.
> >
> >
> > I have published and tried to register our own geofeed data as defined
> > in RFC8805 with as many IP geolocation providers as possible. I have
> > checked around to as many IP geolocation and IP reputations sites as I
> > can find and everything is either clean/accurate or there is no query
> > method open to the public for troubleshooting that I can find. This is
> > just yet another example to me of immaturity on dealing with geolocation
> > problems: just spinning my wheels in the dark with mud spraying
> > everywhere. There does not appear to be any consistency on handling
> > issues by the content providers using IP geolocation and reputation to
> > filter. If the content providers want to reject client connections they
> > ought to provide more actionable information in their errors messages
> > for ISPs since they are all just telling the users to call their ISPs.
> > It just feels like a vicious circle.
> >
> >
> > So currently we are left with multiple video streaming providers that
> > all started to flag many customers across many of our IP blocks all
> > beginning earlier this month affecting customers, many of whom have been
> > using the same IP address for years without issue until now. Do we try
> > and decommission multiple IP subnets shuffle users over to new subnets
> > and risk contaminating more subnets if this is an ongoing and
> > regularly updated blacklist data set. This would further exacerbate the
> > problem across yet more subnets that are getting scarcer. As a tangent,
> > I am curious to see how IP geolocation and reputation systems are
> > handling IPv6, I suppose they are just grouping larger and larger
> > networks together into the same listings.
> >
> >
> > Someone who knows something concrete about this current issue, please
> > throw us ISPs a bone.
> >
> >
> > With this email I feel like Leia recording a video plea for help
> > addressed to Obi-Wan Kenobi help me Nanog Community... you're my
> > only hope.
> >
> >
> >
> >
> >
> > 
> > *From:* NANOG  on
> behalf
> > of Bryan Holloway 
> > *Sent:* Friday, August 27, 2021 4:56 PM
> > *To:* Mike Hammett; John Alcock
> > *Cc:* nanog@nanog.org
> > *Subject:* Re: The great Netflix vpn debacle!
> > Is there some new DB that major CDNs are using?
> >
> > We've been getting several reports of prefixes of ours being blocked,
> > claiming to be VPNs, even though we've been using those subnets without
> > incident for years.
> >
> > HBO, Netflix, and Hulu appear to be common denominators. I have to
> > wonder if they're all siphoning 

Re: An update on the AfriNIC situation

[Martin Hannigan]

On Sun, Aug 29, 2021 at 21:13 Rubens Kuhl  wrote:

> > %s/isolate/move/g functions. That equates to a leadership change. It may
> be too soon to suggest that ICANN has any role other than risk analysis and
> coordination of mitigation. I'm not even certain if that's their role
> seeing how complicated the relationships between the RIR's and ICANN is.
> I've seen good summaries including John Currans and Milton Muellers. I've
> been leaning towards Milton's view. He didn't pardon Afrinic, but he also
> didn't suggest it's time to fold up shop there.
> >
> > A fight over crumbs: The Afrinic Crisis
> >
> >
> https://www.internetgovernance.org/2021/08/19/a-fight-over-crumbs-the-afrinic-crisis/
>
> The problem with Milton's POV is that he is willing to pick and choose
> which AfriNIC policies he likes and which he doesn't; this is not how
> it works.
> That community decided the policies, and it's our job in the other
> regions to make sure that scum bags like the one currently trying to
> suffocate AfriNIC fail miserably.
>


Fair enough, but his TL;DR appears fair and he underscored the risk of  the
matter to the entire RIR system: government intervention.


Warm regards,

-M<

Re: An update on the AfriNIC situation

[Martin Hannigan]

On Sun, Aug 29, 2021 at 8:44 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

[ clip]

As
>
> ICP-2: Criteria for Establishment of New Regional
> Internet Registries
>
> https://www.icann.org/resources/pages/new-rirs-criteria-2012-02-25-en
> 2) The new RIR must demonstrate that it has the broad
> support of the LIRs (ISP community) in the proposed region
>
> if overwhelming majority, which means there is no competition,
> of LIRs in AfriNIC region request to abandon AfriNIC and to
> have an alternate RIR, ICANN should honor the request.
>
> > For another, they are extremely allergic to
> > anything that might even possibly involve them in a lawsuit.
> ICANN was established to protect governance structure (including
> RIRs, of course) of the Internet free from government (especially
> USG) interventions. As such, ICANN is expected to work to isolate
> African RIR operations from existing lawsuit.
>
>
%s/isolate/move/g functions. That equates to a leadership change. It may be
too soon to suggest that ICANN has any role other than risk analysis and
coordination of mitigation. I'm not even certain if that's their role
seeing how complicated the relationships between the RIR's and ICANN is.
I've seen good summaries including John Currans and Milton Muellers. I've
been leaning towards Milton's view. He didn't pardon Afrinic, but he also
didn't suggest it's time to fold up shop there.

A fight over crumbs: The Afrinic Crisis

https://www.internetgovernance.org/2021/08/19/a-fight-over-crumbs-the-afrinic-crisis/



Warm regards,

-M<

Re: Email and Web Hosting

[Martin Hannigan]

Sounds like you already know what the decision is. If you can justify it,
no need to second guess.

If my ISP stopped providing email services I wouldn’t even know. [ may even
check if i get bored ]

Hope that helps.

YMMV,

-M<


On Tue, Jul 6, 2021 at 5:22 PM Steve Saner  wrote:

> The issue is not an understanding of how to run the system. The issue is
> that it isn't our core business and we want to minimize/eliminate the money
> and time needed to maintain the infrastructure and support the services.
>
>
>
> On Tue, Jul 6, 2021 at 3:54 PM Bryan Fields  wrote:
>
>> On 7/6/21 3:26 PM, Steve Saner wrote:
>> > The current platform is a custom collection of open source software,
>> smtp,
>> > imap, pop, webmail. Web hosting is a basic LAMP stack all php 5.2 or
>> > greater. There is no interest in growing these services.
>>
>> Ok, so this really doesn't say much in terms of software in use.  Almost
>> all
>> SMTP/IMAP/POP servers are open source, and could be anything from
>> sendmail 8
>> to postfix.  If you're capping it, just run what's in place and learn it,
>> I'd
>> think most people in networking have configured apache once or twice
>> before.
>>
>> --
>> Bryan Fields
>>
>> 727-409-1194 - Voice
>> http://bryanfields.net
>>
>
>
> --
>
> Steve Saner | Senior Network Engineer
>
> ideatek INTERNET FREEDOM FOR ALL
>
> Cell: 620-860-9433 | 111 Old Mill Lane, Buhler, KS 67522 | ideatek.com
> 
>
> This email transmission and any documents, files or previous email
> messages attached to it may contain confidential information. If the reader
> of this message is not the intended recipient or the employee or agent
> responsible for delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you are not or believe you may not
> be the intended recipient, please advise the sender immediately by return
> email or by calling 620.543.5026. Then, please take all steps necessary to
> permanently delete the email and all attachments from your computer system.
> No trees were affected by this transmission – though a few billion photons
> were mildly inconvenienced.
>

Re: DoD IP Space

[Martin Hannigan]

On Sat, Apr 24, 2021 at 11:27 AM Mel Beckman  wrote:

> This doesn’t sound good, no matter how you slice it. The lack of
> transparency with a civilian resource is troubling at a minimum. I’m going
> to bogon this space as a defensive measure, until its real — and detailed —
> purpose can be known. The secret places of our government have proven
> themselves untrustworthy in the protection of citizens’ data and networks.
> They tend to think they know “what’s good for” us.
>
>  -mel
>
>

If you apply that ideology to 0/0 you're not going to have much of an
Internet beyond cat pics.

Wish i was in the room when they turned it on. I hope they make a tiktok of
the expressions of everyone looking at the first data. [ joke ]

Warm regards,

-M<


> On Apr 24, 2021, at 8:05 AM, John Curran  wrote:
>
> 
> As noted -
> https://www.washingtonpost.com/technology/2021/04/24/pentagon-internet-address-mystery/#click=https://t.co/mVh26yBq9G
>
> FYI,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> On Jan 20, 2021, at 8:35 AM, John Curran  wrote:
>
> 
> Tom –
>
> Most definitely: lack of routing history is not at all a reliable
> indicator of the potential for valid routing of a given IPv4 block in the
> future, so best practice suggest that allocated address space should not be
> blocked by others without specific cause.
>
> Doing otherwise opens one up to unexpected surprises when issued space
> suddenly becomes more active in routing and is yet is inexplicably
> unreachable for some destinations.
>
> /John
>
> On Nov 5, 2019, at 10:38 AM, Tom Beecher  wrote:
>
>
> Using the generally accepted definition of a bogon ( RFC 1918 / 5735 /
> 6598 + netblock not allocated by an RiR ), 22/8 is not a bogon and
> shouldn't be treated as one.
>
> The DoD does not announce it to the DFZ, as is their choice, but nothing
> says they may not change that position tomorrow. There are plenty of
> subnets out there that are properly allocated by an RiR, but the assignees
> do not send them to the DFZ because of $reasons.
>
> In my opinion, creating bogon lists that include allocated but not
> advertised prefixes is poor practice that is likely to end up biting an
> operator at one point or another.
>
> On Tue, Nov 5, 2019 at 9:45 AM Töma Gavrichenkov 
> wrote:
>
>> Peace,
>>
>> On Tue, Nov 5, 2019, 4:55 PM David Conrad  wrote:
>> > On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG 
>> wrote:
>> >> This thread got me to wondering, is there any
>> >> legitimate reason to see 22/8 on the public
>> >> Internet?  Or would it be okay to treat 22/8
>> >> like a Bogon and drop it at the network edge?
>> >
>> > Given the transfer market for IPv4 addresses,
>> > the spot price for IPv4 addresses, and the need
>> > of even governments to find “free” (as in
>> > unconstrained) money, I’d think treating any
>> > legacy /8 as a bogon would not be prudent.
>>
>> It has been said before in this thread that the DoD actively uses this
>> network internally.  I believe if the DoD were to cut costs, they
>> would be able to do it much more effectively in many other areas, and
>> their IPv4 networks would be about the last thing they would think of
>> (along with switching off ACs Bernard Ebbers-style).  With that in
>> mind, treating the DoD networks as bogons now makes total sense to me.
>>
>> --
>> Töma
>>
>

Re: Perhaps it's time to think about enhancements to the NANOG list...?

[Martin Hannigan]

Agree. I’ve had it filtered to a casual folder for 5 years now. I
appreciate the banter. Abilities to sort and shred would be great.

While I miss mail, I’m OK using browser code if it can make nanog-l more
relevant.

$0.02 only




On Thu, Mar 18, 2021 at 18:31 Matthew Petach  wrote:

>
> On Thu, Mar 18, 2021 at 10:37 AM Tom Beecher  wrote:
>
>> CC back to the mailing list for visibility, since I ate the CC list.
>>
>> On Thu, Mar 18, 2021 at 1:31 PM Tom Beecher  wrote:
>>
>>> Rod-
>>>
>>> Please refer to the usage guidelines found here.
>>> https://nanog.org/resources/usage-guidelines/
>>>
>>> 14. Posts that encourage or facilitate an agreement about the following
 subjects are inappropriate: prices, discounts, or terms or conditions of
 sale; salaries; benefits, profits, profit margins, or cost data; market
 shares, sales territories, or markets; allocation of customers or
 territories; or selection, rejection, or termination of customers or
 suppliers.
>>>
>>>
>>>  I would tend to agree that while most of your posts to the list are
>>> within the guidelines, there have been occasions where a reasonable person
>>> could think you might be skirting the line a bit. In this case :
>>>
>>> - Your company works as a broker to procure capacity for others.
>>> - You sent an email to the list that wording wise would be exactly the
>>> same as many of us might send to someone they were looking for capacity
>>> from.
>>>
>>> I think most would agree this is pretty clearly against both the usage
>>> guidelines and the spirit of what this mailing list is about.
>>>
>>> I would also like to remind you that this list is administered by the
>>> NANOG organization. You have no authority to tell others to 'cease and
>>> desist', and insult someone as 'underemployed' is also not well tolerated
>>> here.
>>>
>>> I have looped in the list admins here. It would probably be a good idea
>>> to refrain from future messages that are clearly commercial in nature, or
>>> that contain unnecessary insults.
>>>
>>
>
>
> If only we had some way to segregate out different topics
> of interest or disinterest, so that people who weren't interested
> in questions about bandwidth availability could unsubscribe
> from those topics, and only subscribe to the topics that *did*
> interest them...
>
> #AFewDaysTooEarly
>
> ^_^;;
>
> Matt
>
>
>

Re: Disney+ Geolocation (again)

[Martin Hannigan]

Hey Seth.

I still like SOA for troubleshooting. The older our beloved net gets the
less useful old reliable things get, but there can sometimes be good clues.

shell01-clt01> dig SOA disneystreaming.com

;; ANSWER SECTION:
disneystreaming.com. 3600 IN SOA ns1.p72.dynect.net.
dnsadmin.bamtechmedia.com. 2018072197 3600 600 604800 1800

I forgot MLBAM spunoff BAMTECH and then Disney acquired them. They have a
peeringDB entry. I don't think its unreasonable at all to try dnsadmin@ or
peering@ in this case. If all else fails, OOB and I will hunt down my
connection there for you.


Cheers,

-M<







On Sat, Nov 21, 2020 at 1:48 PM Seth Mattinen  wrote:

> On 11/21/20 08:48, Mike Hammett wrote:
> >
> > I think this is another example of the disconnect between technical
> > teams and support teams at consumer-facing organizations.
> > Consumer-facing support often can't find their way out of a wet paper
> > bag on consumer-related issues, much less on network issues.
> >
> > I think the community's impression so far is that the advised avenues
> > are insufficient to actually solve anything. Since this message, there
> > seems to have been more than one attempt to resolve these types of
> > problems via that link without success. The support site linked to also
> > has rather sparse information regarding how to solve these types of
> issues.
>
>
> There's nothing to indicate the support site is anything other than for
> subscription holding end users only. Phrases that I would think to type
> in the search box like "ISP" and "geolocation" return nothing. The error
> 73 page just says you are on a VPN or your ISP has a location problem,
> neither of which is useful information to me as an ISP.
>
> Calling in got me nowhere. The service rep couldn't open a ticket or
> even request escalation without a subscriber account. Even if I
> personally had one, I'm not going to mention it when I'm calling as an
> ISP on behalf of all of my customers and potential future customers
> because of the real danger of having an exception applied to that
> account rather than addressing the issue as a whole. They told me I
> should email back to the person who gave me the phone contact info and
> ask to speak to a supervisor, which I did, and never received a reply.
>
> I was able to eventually get through on live chat successfully after
> answering its automated questions in a way that would lead it to believe
> i was a customer but could not help me through its auto response means
> and get what I presume is a live person. However, even though I got
> lucky with this method someone else reported they just got dead ended
> with "what's an ISP" when they tried chat.
>
> So the lesson here is to just keep trying the end user chat and phone
> number until you get lucky.
>
> ~Seth
>

Re: Boston Telecom Hotels

[Martin Hannigan]

For interconnection? Coresite and Markley. Equals if not soon to be
differentiated through Mass-IX being regional and Boston-IX not. As well as
costs, yield curves, power costs, etc. Boston is very much a ‘what do you
need’ location and not everything will work for everyone.

For true carrier hotels? 451 D Street, 230 Congress and 50 Post Office
Square. If you need help with that solution, reach out to me directly. I
will get you pointed in the right direction and the right people. These are
not enterprise plays unless you have deep fiber clue and want long term NNN
leases.

For Boston commodity data center? See {datacenterhawk, peeringDB}.

There is a solid core of Boston on this list. Catch us aksi on Twitter
@peeringforumNE or search engine = Boston Network Operators Group BOSNOG.

300 Bent is fiber rich. Never stood up as an interconnection site. Level 3
wasn’t neutral. 50 IB? Don’t think Internap was neutral per se, but someone
will correct me if I am wrong.


Cheers,

-M<


On Wed, Aug 19, 2020 at 16:16 Rod Beck 
wrote:

> Does everyone agree that the 4 most important data centers are 1 Summer,
> Coresite, INAP, and 300 Bent Street. Both 1 Summer and Coresite clearly
> below in that group. Not sure about INAP and 300 Bent Street.
>
> Regards,
>
> Roderick.
>
> Roderick Beck
> VP of Business Development
>
> United Cable Company
>
> www.unitedcablecompany.com
>
> New York City & Budapest
>
> rod.b...@unitedcablecompany.com
>
> Budapest: 36-70-605-5144
>
> NJ: 908-452-8183
>
>
> [image: 1467221477350_image005.png]
>

Re: 60 ms cross-continent

[Martin Hannigan]

On Sat, Jun 20, 2020 at 16:14 Bryan Fields  wrote:

> On 6/20/20 1:56 PM, Saku Ytti wrote:
> > On Sat, 20 Jun 2020 at 20:52, Wayne Bouchard  wrote:
> >
> >> And thus far, no one has mentioned switching speed and other
> >> electronic overhead such as the transceivers (that's the big one,
> >> IIRC.)
> > This will be something from tens of meters (low lat swich), to few
> > hundred meters (typical pipeline),  to 2km delay (NPU+FAB+NPU) per
> > active IP device. If that is a big one, I guess it depends, cross
> > atlantic, no, inside rack, maybe.
>
> I think he might be referring to the newer modulation types (QAM) on long
> haul
> transport.  There's quite a bit of time in uS that the encoding takes into
> QAM
> and adding FEC.  You typically won't see this at the plug-able level
> between
> switches and stuff.
>
> 60ms is nothing really, and I'm happy I don't need to play in the HFT space
> anymore.  I do wish my home connection wasn't 60 ms across town as spectrum
> wants takes TPA-ATL-DCA-DEN-NY to get to my rack. :-)



working on that .. :-)






> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: IPv4 Broker / Service -

[Martin Hannigan]

For small needs? Honestly, don’t waste too much time. Overhead is expense.

The market is competitive. You care about if it is clean, chain of custody
and can it legitimately transfer to you. BTW, IPV6? ARIN v6 NAT block? Make
sure you exhaust all options before paying.

I have never used it. However, I find the people at Hilco reputable.

   https://ipv4auction.com


Good luck!

-M<


On Thu, Jun 11, 2020 at 14:29  wrote:

> Hi Nanog,
>
>
>
> I have need of a reputable IPv4 broker or service  – personal experience
> with said broker would be preferred.  These would be for small blocks -
> /23, 24s – in the US, so ARIN.  I know, I know, IPv6 for life and all that
> and I agree, but … you know, the business.  I’m happy to take responses
> off-list, but I would really appreciate any recommendations.
>
>
>
> Thanks!
>
>
>
> Ed
>

Re: [EXT] Shining a light on ambulance chasers - Noction

[Martin Hannigan]

This is overt and more than DB scraping IMHO. It's repulsive.

Public pressure is the only way to police _this_.

YMMV,

-M<

On Wed, Mar 25, 2020 at 4:30 PM Chuck Anderson  wrote:

> Someone should tell them what happened to Cogent for scraping ARIN WHOIS.
>
> On Wed, Mar 25, 2020 at 04:13:51PM -0400, Rodney Joffe wrote:
> > Under the heading of sales spam from our community that is in even
> poorer taste, and sucks:
> >
> >
> > Begin forwarded message:
> >
> > > From: Josh Ankin 
> > > Subject: BGP Management
> > > Date: March 25, 2020 at 3:39:02 PM EDT
> > > To: rjo...@centergate.com
> > > Reply-To: jan...@noction.com
> > >
> > > Hello Rodney,
> > >
> > > I know things are pretty hectic right now with COVID-19 precautions
> being taken everywhere. I hope it's not affecting your team too much, and
> most importantly, I hope everyone is safe.
> > >
> > > In recent months, I've been trying to bring your attention to BGP
> optimization. However, our solution's other notable features can be of
> utmost value at these uncertain times as the Internet traffic volumes and
> patterns change
> >
> > Etc Etc
>

Re: Hawaii exchange and connection to mainland pops

[Martin Hannigan]

Antoni,

Search engine or PeeringDB == Dr Fortress // Fred Rodi. Solid.

They have the primary IX. Charter and Level3/CL are best option for haulage
or IP. #IMHO. Probably cable IRU options, but nit my space.

Let me know if no luck.

Cheers, and good luck!

-M<



On Wed, Jan 29, 2020 at 12:38 Antoni Matamalas 
wrote:

> Hi NANOG,
>
> I'm trying to figure out how is the connectivity in the Hawaiian Islands
> for a project I have. I'm based in Europe and my knowledge of the details
> of the communications in the islands is still limited. The project is based
> in the O'ahu island but I'm trying to understand how things are working in
> the whole Hawaiian islands (pure professional curiosity). I'm focusing on
> two aspects:
>
> * Content delivery and connection to content providers (Google, Apple,
> Netflix,...)
> * Availability of providers that can supply wavelength between Hawaiian
> Islands and the continent (LA, Seattle or other locations)
>
> Doing a quick investigation I found the Aloha-IX in the PeeringDB but it
> looks like it doesn't have many participants and non of them appear to be a
> content provider. I was expecting that Hawaii being one of the major
> landing points of fiber in the Pacific would have some more presence of
> content providers and CDNs. However, I know that the total population of
> the island is not that much (and disperse) and maybe not enough for such
> kind of deployments.
>
> Also, in terms of connectivity to the continent I have not been too lucky
> finding providers with wavelength services. For the moment I have had some
> contact with GTT and NTT but not sure if there are any other
> regional/national providers that can also provide such services.
>
> Thanks you very much in advanced for your help!
>
> Kind regards,
> --
> Antoni
>

Re: FYI - Suspension of Cogent access to ARIN Whois

[Martin Hannigan]

On Tue, Jan 7, 2020 at 08:51 John Curran  wrote:

> On 7 Jan 2020, at 5:01 AM, Martijn Schmidt via NANOG 
> wrote:
> >
> > Out of curiosity, since we aren't affected by this ourselves, I know of
> cases where Cogent has sub-allocated IP space to its customers but which
> those customers originate from their own ASN and then announce to multiple
> upstream providers.
> >
> > So while the IP space is registered to Cogent and allocated to its
> customer, the AS-path might be something like ^174_456$ but it's entirely
> possible that ARIN would observe it as ^123_456$ instead. Are such IP
> address blocks affected by the suspension?
>
> As noted earlier, ARIN has suspended service for all Cogent-registered IP
> address blocks - this is being done as a discrete IP block access list
> applied to relevant ARIN Whois services, so the routing of the blocks are
> immaterial - a customer using a suballocation of Cogent space could be
> affected but customers with their own IP blocks blocks that are simply
> being routed by Cogent are not affected.



This is a disproportionate response IMHO. $0.02

YMMV,

-M<

Re: FYI - Suspension of Cogent access to ARIN Whois

[Martin Hannigan]

— shifting a side thread


John,

I have no stake in this, so far, but I have a few questions.

Can you define exactly what services have been blocked? IRR/ROA/TLA
registry updates, etc? Were they blocked ^174 or 174$? This is a precedent
AFAIK. I’d like to understand consequences. In case I decide to attend
Dave’s sales training? :-)

Cheers,

-M<



On Mon, Jan 6, 2020 at 10:45 John Curran  wrote:

> On 22 Sep 2019, at 8:52 AM, Tim Burke  wrote:
>
>
> That is just The Cogent Way™, unfortunately. I just had (yet another)
> Cogent rep spam me using an email address that is _only_ used as an ARIN
> contact, trying to sell me bandwidth. When I called him out on it, with
> complia...@arin.net CCed, he backpedaled and claimed to obtain my
> information from Google.
>
>
> ARIN has repeatedly informed Cogent that their use of the ARIN Whois for
> solicitation is contrary to the terms of use and that they must stop.
> Despite ARIN’s multiple written demands to Cogent to cease these prohibited
> activities, ARIN has continued to receive complaints from registrants that
> Cogent continues to engage in these prohibited solicitation activities.
>
> For this reason, ARIN has suspended Cogent Communications’ use of
> ARIN’s Whois database effective today and continuing for a period of six
> months.  For additional details please refer to
> https://www.arin.net/vault/about_us/corp_docs/20200106_whois_tos_violation.pdf
>ARIN will restore Cogent’s access to the Whois database at an earlier
> time if Cogent meets certain conditions, including instructing its sales
> personnel not to engage in the prohibited solicitation activities.
>
> Given the otherwise general availability of ARIN Whois, it is quite
> possible that Cogent personnel may evade the suspension via various means
> and continue their solicitation.  If that does occur, please inform us (via
> complia...@arin.net), as ARIN is prepared to extend the suspension
> and/or bring appropriate legal action.
>
> FYI,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>
>
>
>
>

Re: Boston Fiber Optic Networks

[Martin Hannigan]

Definitely good. However, you cant tell shared fiber or sole/joint conduit
builds via Infrapedia. You also do not need a referral. That matters in
Boston. Boston also has an outstanding shadow conduit system. You do need
local help.

Talk to Janes and Gavin at Towardex. Let me know if you need an intro.


Best,


-M<



On Thu, Nov 14, 2019 at 20:57 Mehmet Akcin  wrote:

>
> live.infrapedia.com has an extensive list of networks.
>
> On Thu, Nov 14, 2019 at 13:12 Rod Beck 
> wrote:
>
>> I am looking to discuss off list the fiber optic landscape for greater
>> Boston. Trying to understand who are the key players.
>>
>> Thanks.
>>
>> Regards,
>>
>> Roderick.
>>
>> Roderick Beck
>> VP of Business Development
>>
>> United Cable Company
>>
>> www.unitedcablecompany.com
>>
>> New York City & Budapest
>>
>> rod.b...@unitedcablecompany.com
>>
>> 36-70-605-5144
>>
>>
>> [image: 1467221477350_image005.png]
>>
> --
> Mehmet
> +1-424-298-1903
>

Re: T-Mobile help!!

[Martin Hannigan]

Check out STIR/SHAKEN:

https://transnexus.com/whitepapers/understanding-stir-shaken/
https://transition.fcc.gov/cgb/Robocall-Strike-Force-Final-Report.pdf

For what it's worth, American Express Fraud Department comes up at "Spam
Risk" through my provider.

There are "recommendations" for labels. I do believe the carrier is setting
the labels and I would reasonably surmise they are the source. It could be
prior use of an assigned number. Or not. I am not aware of how to get the
labeling of a number fixed. Anyone?

YMMV.

Best,

-M<





On Thu, Oct 31, 2019 at 8:24 AM Ca By  wrote:

>
>
> On Thu, Oct 31, 2019 at 6:05 AM David Funderburk 
> wrote:
>
>> One of our customers office number is coming across as 'Survey Call' on
>> T-Mobile cell phones.  I know with certainty it's with 'T-Mobile' phones.
>> I don't have another contact on another network that I know I can try.  How
>> do we get that fixed?
>>
>> Thanks for any suggestions!
>>
>
> Probably number spoofing and has nothing to do with T-Mobile
>
>
> https://www.npr.org/2019/06/06/727711432/do-i-know-you-and-other-spam-phone-calls-we-can-t-get-rid-of
>
>
>
> --
>> Regards,
>>
>> David Funderburk
>> GlobalVision
>> 864-569-0703
>>
>> For Technical Support, please email gv-supp...@globalvision.net
>>
>> GlobalVision is a communications company that provides services which
>> includes Internet, internal and external networks with over 25 years
>> experience. With our Zero Downtime strategies we help companies increase
>> up-time and decrease lost productivity and costs.
>>
>> --
>> This message has been scanned for viruses and dangerous content by
>> *E.F.A. Project* , and is believed to be
>> clean.
>>
>

Re: IPv6 Thought Experiment

[Martin Hannigan]

On Wed, Oct 2, 2019 at 18:59 Owen DeLong  wrote:

>
>
> > On Oct 2, 2019, at 09:33 , Antonios Chariton 
> wrote:
> >
> > Dear list,
> > First of all, let me apologize if this post is not allowed by the list.
> To my best interpretation of the guidelines [1] it is allowed, but may be
> in a gray area due to rule #7.
> >
> > I would like to propose the following thought experiment about IPv6, and
> I would like your opinion on what you believe would happen in such a case.
> Feel free to reply on or off list.
> >
> > What if, globally, and starting at January 1st, 2020, someone (imagine a
> government or similar, but with global reach) imposed an IPv4 tax. For
> every IPv4 address on the Global Internet Routing Table, you had to pay a
> tax. Let’s assume that this can be imposed, must be paid, and cannot be
> avoided using some loophole. Let’s say that this tax would be $2, and it
> would double, every 3 or 6 months.
>
> You’re talking about starting at $1536 per quarter for a /24 and doubling
> that every three to 6 months?
>
> Who, exactly gets all this money in your make money fast scheme here?
>
> I’d say it would provide an impressive motivation to get rid of IPv4, but
> I also would say that nobody would ever stand for such a tax.
>
> > What do you think would happen? Would it be the only way to reach 100%
> IPv6 deployment, or even that wouldn’t be sufficient?
>
> The internet’s version of the Boston Tea Party.
>

I can represent that. +1

Best,

Martin
Boston, USA

Re: BGP prefix filter list

[Martin Hannigan]

Those numbers were subject to fraudulent acquisition. Some end users of
these subject prefixes are victims. This blanket approach victimizes them
further IMHO. My guess is this direction is why ARIN didn't post the
prefixes in their blog post. They are however in the court docs. I don't
recommend acting now.  I could be wrong?

Follow the registry, IMHO. John?


Best,

-M<



On Wed, May 15, 2019 at 08:25 Anderson, Charles R  wrote:

> What about these ones?
>
> https://teamarin.net/2019/05/13/taking-a-hard-line-on-fraud/
>
> On Wed, May 15, 2019 at 01:43:30PM +0200, Baldur Norddahl wrote:
> > Hello
> >
> > This morning we apparently had a problem with our routers not handling
> > the full table. So I am looking into culling the least useful prefixes
> > from our tables. I can hardly be the first one to take on that kind of
> > project, and I am wondering if there is a ready made prefix list or
> similar?
> >
> > Or maybe we have a list of worst offenders? I am looking for ASN that
> > announces a lot of unnecessary /24 prefixes and which happens to be far
> > away from us? I would filter those to something like /20 and then just
> > have a default route to catch all.
> >
> > Thanks,
> >
> > Baldur
>

ARIN v4 revocations with followup felony indictments

[Martin Hannigan]

ARIN revokes fraudulently obtained IPv4 numbers:

http://www.circleid.com/posts/20190514_735k_fraudulently_obtained_ip_addresses_have_been_revoked/

USAO indicts Micfo founder in South Carolina.

https://www.justice.gov/usao-sc/pr/charleston-man-and-business-indicted-federal-court-over-9m-fraud

Relevant threads over at ARIN on PPML.

Cheers,

-M<

Re: Special Counsel Office report web site

[Martin Hannigan]

Hey Mike.

Agreed. But the scale of a 400 page document with global interest? Should
be highly cached with a good ratio of served to pull bits. I'm willing to
bet you a beer its just another day on the Internet. However, I could be
wrong. Hope to see you in DC to collect! I already know Brett is in. :)

Best,

-M<



On Thu, Apr 18, 2019 at 12:21 AM  wrote:

> Oh spiffy!
>
> Will be interesting to see if there are any problems then.
>
> -Mike
>
> On Apr 17, 2019, at 21:14, Brett Watson  wrote:
>
> Or maybe do this (faster than nanog archives) :)
>
>
> bash-3.2# dig cia.gov ns
>
> ; <<>> DiG 9.10.6 <<>> cia.gov ns
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33203
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;cia.gov. IN NS
>
> ;; ANSWER SECTION:
> cia.gov. 86400 IN NS a22-66.akam.net.
> cia.gov. 86400 IN NS a16-67.akam.net.
> cia.gov. 86400 IN NS a1-22.akam.net.
> cia.gov. 86400 IN NS a12-65.akam.net.
> cia.gov. 86400 IN NS a3-64.akam.net.
> cia.gov. 86400 IN NS a13-65.akam.net.
>
>
>
> On Apr 17, 2019, at 9:11 PM, Martin Hannigan  wrote:
>
>
> Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It
> certainly is.
>
>
>
> On Wed, Apr 17, 2019 at 23:34  wrote:
>
>> Isn’t this why god invented CDNs? Though, i doubt the govment is
>> Akamized...
>>
>> -Mike
>>
>> On Apr 17, 2019, at 20:26, Mark Seiden  wrote:
>>
>> of course p2p is the way to distribute this but i doubt the justice
>> department can admit there is any positive legitimate use for p2p.
>>
>> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent
>> yet.  “russiar, are you listening?”)
>>
>> (i sure hope there’s a signed version or at least a hash.)
>>
>> i predict there will be versions with fake content, missing content, and
>> malware inserted that are distributed as well.
>>
>>
>>
>>
>> and i’ll bet there will be some infected pdf version as well distributed
>> that way.
>> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG ,
>> wrote:
>>
>> And we may still see the web stack being the ultimate cause of the delay.
>>
>>
>> Parkinson's law always comes to the rescue:-)
>> More faster and efficient processing architecture, Hyper transport buses,
>> amd-64 Branch prediction.
>> Massively faster storage subsystems and disk arrays, SSD slab caching for
>> hypervisors
>>
>> And some dude with a AJAX framework to serve a PDF bringging the whole
>> thing to a a screeching halt
>>
>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
>>
>> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
>>
>> Things will probably be easier this time. The Internet has evolved
>>
>> ways
>>
>> of dealing with exactly this problem. (Avi used to call it “slash-dot
>>
>>
>> insurance”, but the idea is the same.) Specifically:
>>
>>
>> Yep, it will be interesting to see where the chokepoints are tommorrow.
>>
>> In 1998, the bandwidth pipes never filled up. The chokepoint was in the
>>
>> TCP and Web stacks. Eventually the Associated Press got a copy of the
>> Starr Report on a CD from a congressional staffer. The press intern
>> running down the street holding a CD was faster than 1998 internet :-)
>>
>> We were also lucky in 1998, no one had thought of DDOS yet.
>>
>>
>> Frederick Wessling (CIO)
>> Succinct Systems LLC
>> Cell: +1(561) 571-2799
>> Office: +1(904) 758-9915 ext. 9925
>> Fax: +1(904) 758-9987
>> www.SuccinctSystems.com <http://www.succinctsystems.com/>
>>
>>
>

Re: Special Counsel Office report web site

[Martin Hannigan]

Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It
certainly is.



On Wed, Apr 17, 2019 at 23:34  wrote:

> Isn’t this why god invented CDNs? Though, i doubt the govment is
> Akamized...
>
> -Mike
>
> On Apr 17, 2019, at 20:26, Mark Seiden  wrote:
>
> of course p2p is the way to distribute this but i doubt the justice
> department can admit there is any positive legitimate use for p2p.
>
> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent
> yet.  “russiar, are you listening?”)
>
> (i sure hope there’s a signed version or at least a hash.)
>
> i predict there will be versions with fake content, missing content, and
> malware inserted that are distributed as well.
>
>
>
>
> and i’ll bet there will be some infected pdf version as well distributed
> that way.
> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG ,
> wrote:
>
> And we may still see the web stack being the ultimate cause of the delay.
>
>
> Parkinson's law always comes to the rescue:-)
> More faster and efficient processing architecture, Hyper transport buses,
> amd-64 Branch prediction.
> Massively faster storage subsystems and disk arrays, SSD slab caching for
> hypervisors
>
> And some dude with a AJAX framework to serve a PDF bringging the whole
> thing to a a screeching halt
>
> On April 17, 2019 10:35:29 PM EDT, Sean Donelan  wrote:
>
> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote:
>
> Things will probably be easier this time. The Internet has evolved
>
> ways
>
> of dealing with exactly this problem. (Avi used to call it “slash-dot
>
>
> insurance”, but the idea is the same.) Specifically:
>
>
> Yep, it will be interesting to see where the chokepoints are tommorrow.
>
> In 1998, the bandwidth pipes never filled up. The chokepoint was in the
>
> TCP and Web stacks. Eventually the Associated Press got a copy of the
> Starr Report on a CD from a congressional staffer. The press intern
> running down the street holding a CD was faster than 1998 internet :-)
>
> We were also lucky in 1998, no one had thought of DDOS yet.
>
>
> Frederick Wessling (CIO)
> Succinct Systems LLC
> Cell: +1(561) 571-2799
> Office: +1(904) 758-9915 ext. 9925
> Fax: +1(904) 758-9987
> www.SuccinctSystems.com
>
>

Re: Purchasing IPv4 space - due diligence homework

[Martin Hannigan]

Jeffrey,

Thanks. A good start, but under-scoped. When you are purchasing IP number
blocks whatever source you use; a marketplace, a broker, a single source
should provide you with a compelling history on a number block REPUTATION
that includes all the attributes listed below and then some. Some of the
blocks I’ve seen being discussed lately appear notorious. In one case I
counted 17 difffernt RBL’s being attributed to it. Checking Spamhaus is
good, but then there are many others and some not so well known. There are
many embedded in devices (remember auto config) that will never be updated.

For most, do not buy v4 numbers blocks without a pro and you’ll sorta know
when they talk about everything but price. Price matters, but if its
unusable or you need to spend a month cleaning it up, no income = more
cost.

Best,

-M<

On Wed, Apr 3, 2019 at 15:38 Jeffrey Hathaway via NANOG 
wrote:

> Hi,
>
>
>
> While I think #3 is important, it depends on your use of the end-block,
> and those entries can sometimes be cleaned up with some work. If the block
> is listed, that would certainly lower my buying price I am willing to pay
> for the block.  I did buy a block once in the ARIN region which showed up
> in IP geolocation databases as Russian (no idea why), but it took me quite
> a while to get it fixed.
>
>
>
>
>
> *Sincerely,*
>
> *Jeffrey Hathaway*
>
> Information Technology • Howard Center Inc.
>
>
>
>
>
> *From:* NANOG  *On Behalf Of *Torres, Matt via
> NANOG
> *Sent:* Wednesday, April 3, 2019 11:20 AM
> *To:* nanog@nanog.org
> *Subject:* Purchasing IPv4 space - due diligence homework
>
>
>
> All,
>
> Side stepping a migration to IPv6 debate…. I’d like to hear advise from
> the group about performing due diligence research on an IPv4 block before
> purchasing it on the secondary market (on behalf of an end-user company).
> My research has branched into two questions: a) What ‘checks’ should I
> perform?, and b) what results from those checks should cause us to walk
> away?
>
>
>
> My current list is:
>
>1. Check BGP looking glass for route. It should not show up in the
>Internet routing table. If it does, walk away.
>2. Check the ARIN registry. The longer history without recent
>transfers or changes is better. I don’t know what explicit results should
>cause me to walk away here.
>3. Check SORBS blacklisting. It should not show up except maybe the
>DUHL list(?). If it does, walk away.
>
>
>
> Anything else? Advise?
>
> Thanks,
>
> Matt
>
>
> --
>
> *HowardCenter.org* 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail is intended only for the use of the
> individual or entity to which it is addressed and may contain information
> that is patient protected health information, privileged, confidential and
> exempt from disclosure under applicable law. If you have received this
> communication in error, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> Please notify the sender by reply e-mail and delete the original message
> immediately, or notify Howard Center, Inc. immediately by forwarded e-mail
> to our Privacy Officer, da...@howardcenter.org. Thank you.
>

Re: WIndows Updates Fail Via IPv6 - Update!

[Martin Hannigan]

On Tue, Mar 5, 2019 at 07:15 Rich Kulawiec  wrote:

> On Mon, Mar 04, 2019 at 08:04:12AM +1100, Mark Andrews wrote:
> > ICMP is NOT optional.
>
> I've pointed folks at this for years:
>
> ICMP Packet Filtering v1.2
> http://www.cymru.com/Documents/icmp-messages.html
>
> ---rsk
>


Some of the networks that completely block ICMP are shocking.

Best,

-M<

Re: What are people using for IPAM these days?

[Martin Hannigan]

Literally for years, I managed a /9 and a v6 /26 in a text file checked
into a vanilla source code control system. Sophistication need depends on
your frequency of updates, dynamic allocations and regulatory needs ( read
RIR). For low turn over assignments, you may not need much.

The options Job and Jordi point to are good. The open source options are
always a go to IMHO. YMMV.

Best Regards,

-M<

On Sun, Jun 10, 2018 at 17:38 JORDI PALET MARTINEZ via NANOG <
nanog@nanog.org> wrote:

> One more open source option:
>
> https://www.gestioip.net/
>
>
> Regards,
> Jordi
>
>
>
> -Mensaje original-
> De: NANOG  en nombre de Job Snijders <
> j...@instituut.net>
> Fecha: domingo, 10 de junio de 2018, 23:01
> Para: Mike Lyon 
> CC: NANOG 
> Asunto: Re: What are people using for IPAM these days?
>
> Hey Mike,
>
> On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon 
> wrote:
> > Title says it all... Currently using IPPlan, but it is kinda
> antiquated..
>
> This is always a good thing to review every 2-3 years or so.
>
> My current favorites in the open source world are:
>
> Netbox - https://github.com/digitalocean/netbox
> NIPAP - http://spritelink.github.io/NIPAP/
> ed - http://man.openbsd.org/ed ;-)
>
> Give a few of the IPAMs out there a chance and just see which one
> suits your operational procedures best! (Though, using a spreadsheet
> file on a shared network drive is still not recommended.)
>
> Kind regards,
>
> Job
>
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
>

Re: Temp at Level 3 data centers

[Martin Hannigan]

Hi David,

80F seems ~reasonable to me. What is the inlet temp, the temperature air is
going in at? What kind of gear are operating? Routers and switches?
Servers? Disk? Is the cabinet top fan working? Most modern equipment should
be able to handle those temps. As another poster noted, are these triggers
modifiable (or have they been)? I would refer to the manufactures
guidelines. You haven't given us enough information to help. You can refer
(them) to ASHRAE standards in your conversation. I'd be surprised if they
weren't already well aware of it and practicing most of what it preaches.
They may operate safely outside of some norms.

15F-20F cooler? You might be paying too much for colo if that's true.

Best,

-M<



On Wed, Oct 11, 2017 at 8:31 AM, David Hubbard <
dhubb...@dino.hostasaurus.com> wrote:

> Curious if anyone on here colo’s equipment at a Level 3 facility and has
> found the temperature unacceptably warm?  I’m having that experience
> currently, where ambient temp is in the 80’s, but they tell me that’s
> perfectly fine because vented tiles have been placed in front of all
> equipment racks.  My equipment is alarming for high temps, so obviously not
> fine.  Trying to find my way up to whomever I can complain to that’s in a
> position to do something about it but it seems the support staff have been
> told to brush questions about temp off as much as possible.  Was wondering
> if this is a country-wide thing for them or unique to the data center I
> have equipment in.  I have equipment in several others from different
> companies and most are probably 15-20 degrees cooler.
>
> Thanks,
>
> David
>

Re: Find carriers that peer in two IX's

[Martin Hannigan]

Which will also have dramatically different results. An IX is not a good
key for a carrier search.

On Fri, Sep 15, 2017 at 12:32 Marty Strong via NANOG 
wrote:

> > TELX 60 Hudson and then SIX (Seattle IX)
>
> IX or building? Telx 60 Hudson is a building and SIX is an IX.
>
> Regards,
> Marty Strong
> --
> Cloudflare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
>
> https://www.peeringdb.com/asn/13335
>
> > On 15 Sep 2017, at 17:08, Mehmet Akcin  wrote:
> >
> > +carrier
> >
> > "Hurricane Electric"
> >
> > On Fri, Sep 15, 2017 at 8:40 AM, Job Snijders  wrote:
> >
> >> On Fri, Sep 15, 2017 at 11:25:10AM -0400, Dovid Bender wrote:
> >>> Does anyone know of a tool like PeeringDB where I can select two
> >> exchanges
> >>> say TELX 60 Hudson and then SIX (Seattle IX) and find all carriers that
> >>> have a presence in both locations?
> >>
> >> a bit hacky ;-)
> >>
> >> Vurt:~ job$ comm -1 -2 <(curl -s https://peeringdb.com/api/ixlan/13 |
> jq
> >> ".data | .[] | .net_set | .[] | .name" | sort) <(curl -s
> >> https://peeringdb.com/api/ixlan/325 | jq ".data | .[] | .net_set | .[]
> |
> >> .name" | sort)
> >> "Amazon.com"
> >> "Cloudflare"
> >> "Default Route, LLC"
> >> "Digital Realty | Telx"
> >> "Facebook"
> >> "Facebook"
> >> "Faction Inc."
> >> "Google Inc."
> >> "Highwinds Network Group, Inc"
> >> "Hurricane Electric"
> >> "IPTP Networks"
> >> "ISPrime, LLC."
> >> "Internap"
> >> "Internet2 TransitRail"
> >> "Limelight Networks Global"
> >> "Microsoft"
> >> "NTT DATA Services - HCLS Cloud"
> >> "Netflix"
> >> "Nitel"
> >> "OpenDNS, Inc."
> >> "Packet Clearing House AS42"
> >> "Packet Clearing House"
> >> "Sipartech"
> >> "SoftLayer Technologies, Inc. (an IBM Company)"
> >> "Verizon Digital Media Services (EdgeCast Networks)"
> >> "Wolfe"
> >> "Yahoo!"
> >> Vurt:~ job$
> >>
>
>

Re: Last Week's Canadian Fiber Cut

[Martin Hannigan]

On Tue, Aug 15, 2017 at 3:52 PM, Jared Mauch  wrote:

>
> > On Aug 15, 2017, at 1:22 PM, Rod Beck 
> wrote:
> >
> > Did we ever get any resolution on why this was such a big outage?
> Appears there were two fiber cuts. Were the fibers damaged in the same
> conduit? Is this a collapsed ring scenario?
> >
> >
> > http://www.cbc.ca/news/canada/newfoundland-labrador/concerns
> -about-backup-bell-outage-1.4239064
>
> Perhaps some transatlantic fallback?  It looks like the only cable out
> there is the Greenland one.. guessing that’s not very competitive?  It only
> gets you to Iceland it seems.
>
>
For background on the Greenland Connect cable, the UKNOF presentation I
presented (built by Heller, Harland, and I) in 2009 is here at
http://bit.ly/GrConnect - You can get past Iceland for sure. Just not for
free.

(Honorable mentions in all of this for AMS-IX, LINX, Nick Hilliard, Andy
Davidson and Will Hargrave. Remco van Mook got the Golden Jökulhlaup for
his part).

The route was cost prohibitive as you guessed. There was reach-ability from
the EU to CA via RVK and GOH, The built paths were CPH-RVK-GOH-YHZ and
LON-RVK-GOH-YHZ. While the GOH route were most prohibitive, the RVK paths
less so. It was much cheaper to route LON to LGA via Hibernia. I like it as
a back up path. So did a few banks. But cost. Do I think this is a viable
path? Yes. Will it ever come down in cost? I'd go back to try this again.
Maybe things have changed?

Best,

-M<

Re: Puerto Rico Internet Exchange

[Martin Hannigan]

Hi Arturo,

Good call. I believe the funds are coming from the USF? (Mike Hammet knows
more about this than me). I had conversations with multiple congressional
staffers about using USF funds for IXP development. They're in for good
projects. The USG and US congress is more than willing to fund IXPs using
USF funds. Commercial or otherwise, depending on the bnenefits and commits.

I agree, it would be a good vector to work an improved IXP with larger
scale support in Puerto Rico, building on the work Mehmet did with
PR^H^HIX-PR. :-) I remember that conversation here vividly. Still requires
a key location e.g. Power + fiber. Where to?

Econmically, PR is long overdue for a neutral IX, locally organized, that
can make an impact.

Cheers,

-M<



On Sun, Aug 13, 2017 at 13:56 Arturo Servin  wrote:

> What about the PRBI project for an IXP?
>
> I think that is working, possibly it just need a hand. If possible, I would
> like to put my effort in something that is working and improve it rather
> than start something else from scratch.
>
> Regards
> as
>
> On Sat, 12 Aug 2017 at 14:15 Mike Hammett  wrote:
>
> > Reach out to Gino Villarini at Aeronet.
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> >
> > Midwest Internet Exchange
> >
> > The Brothers WISP
> >
> > - Original Message -
> >
> > From: "Mehmet Akcin" 
> > To: "nanog" 
> > Sent: Saturday, August 12, 2017 6:27:57 AM
> > Subject: Puerto Rico Internet Exchange
> >
> > Hey there!
> >
> > ... ok this time I am not going to call it PRIX ;) well name doesn't
> matter
> > really. Nearly 13 years ago I have attempted to start Puerto rico
> Internet
> > exchange in San Juan. I have lived there over 5 years and i just wanted
> to
> > really watch videos faster. The project somewhat died when i moved to LA
> > but now there are few interested party to start an internet exchange in
> > Puerto rico. The jsland historically had one of the slowest
> > broadband/internet services which seemed to have improved in recent years
> > however as of 2017 there still is not an IX in Puerto rico.
> >
> > We , 3-4 internet engineers (on island and remote) , want to look into
> > relaunch of this IX and hopefully find a way to keep local traffic
> > exchanged at high speeds and low cost. We need expertise, and people who
> > want to help any way they can.
> >
> > We are trying to make this IX a not-for-profit one and we are looking at
> > opeeating models to adapt which has worked incredibly well like Seattle
> IX.
> >
> > We are hoping the relaunch to happen sometime in 2018. Thanks in advance
> > hope to share more info and traffic data sometime , soon. Watch this
> space!
> >
> > Mehmet
> >
> >
>

Re: BGP peering question

[Martin Hannigan]

On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
craigwashingto...@hotmail.com> wrote:

> Hello,
>
>
> Newbie question, what criteria do you look for when you decide that you
> want to peer with someone or if you will accept peering with someone from
> an ISP point of view.
>


You didn't say what kind of 'peering'. That could mean over an IXP or to be
directly connected. You do not need to be a member of an IX to peer.

There are at least three types of criteria to evaluate. Technical, business
and legal.  Take a look here for a few ideas on technical and business
criteria:

http://bit.ly/2ue2t0P

"Me too" with the rest of the thread. If peering serves your mutual
interests (or just yours even), its an easy decision.

The Dr Peering http://drpeering.net/ website is also a resource for folks
new to peering.

http://drpeering.net/


Best Regards,

-M<

Re: Retarus (AS 48328)

[Martin Hannigan]

I heard from the team at Retarus. They were responsive. Much appreciated.

Thanks all.


On Fri, May 5, 2017 at 08:41 Patrick Schultz <lists-na...@schultz.top>
wrote:

> Hi Martin,
> the only address I can point you at is "support at retarus dot com".
> We once had to contact them about a SMTP problem and this was the only
> working contact.
>
> Best,
> Patrick
>
> Am 04.05.17 um 06:31 schrieb Martin Hannigan:
> > I hate to do this, but I have exhausted _all of my sources of data
> > including the SOA (points at VRSN) and domain name contact addresses for:
> >
> > Registrant Name: Retarus GmbH
> > Registrant Organization: Retarus GmbH
> > Registrant Street: Aschauerstrasse 30
> > Registrant City: Muenchen
> > Registrant State/Province: Bav
> > Registrant Postal Code: 81549
> > Registrant Country: DE
> >
> > I worked backwards from a domain name of RMX.DE. I don't know what the
> > distinction is other than this name perhaps being an operational domain
> for
> > their mail security services.
> >
> > If someone has a pointer or can do an offline introduction to someone in
> > tech-ops or networking there, I'd appreciate it.
> >
> > Best,
> >
> > -M<
> >
>
>

Retarus (AS 48328)

[Martin Hannigan]

I hate to do this, but I have exhausted _all of my sources of data
including the SOA (points at VRSN) and domain name contact addresses for:

Registrant Name: Retarus GmbH
Registrant Organization: Retarus GmbH
Registrant Street: Aschauerstrasse 30
Registrant City: Muenchen
Registrant State/Province: Bav
Registrant Postal Code: 81549
Registrant Country: DE

I worked backwards from a domain name of RMX.DE. I don't know what the
distinction is other than this name perhaps being an operational domain for
their mail security services.

If someone has a pointer or can do an offline introduction to someone in
tech-ops or networking there, I'd appreciate it.

Best,

-M<

Re: Interconnection Track

[Martin Hannigan]

Hi Mehmet,

*Great effort here. +1.*

I'd suggest that you bring new faces to the game. New ideas are needed.

Topic wise:

- 'inside' settlement free peering
- Content vs. Network Operators, and right sizing where the traffic comes
from
- Once and for all: Are IXP's as dead as some say?


Hope that helps.

Best,

-M<





On Sat, Apr 1, 2017 at 4: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: Purchased IPv4 Woes

[Martin Hannigan]

Which broker did you use fot the transaction?

 Did you get a discount for knowingly accepting a dirty block or is this a
surprise?

Are folks asking for warranties on acquired addresses these days?

Cheers,

-M<






Best,

-M<




On Fri, Mar 10, 2017 at 12:11 Pete Baldwin  wrote:

> Hi All,
>
>  Hopefully this is not taken in bad taste.   Our organization
> purchased some IP space last year (163.182.192.0/18 to be specific), and
> it appears that this block must have been used for less-than-admirable
> purposes in the past.
>
> We have been trying to clean up the reputation where possible, and we do
> not appear to be on any blacklists, but we do appear to be blocked from
> a lot of networks across the US/Canada.I am noticing a lot of name
> servers blocking our requests, many web servers, gaming servers, mail etc.
>
> This is a transition block for us to move towards v6 everywhere, but we
> have many systems that will need to rely on this block of space for some
> time to come.
>
> We are a small rural co-op ISP in Ontario, and I am just writing this
> email as an extra plea so that if you happen to run a network that has
> this entire range on your naughty list, we would appreciate you giving
> it another chance.  I can be contacted on or off list, thanks.
>
>
> --
>
>
> -
>
> Pete Baldwin
> Tuckersmith Communications
> (P) 519-565-2400
> (C) 519-441-7383
>
>

Re: Akamai and Instagram Ranges

[Martin Hannigan]

On Saturday, January 28, 2017, Royce Williams 
wrote:

> On Sat, Jan 28, 2017 at 2:22 AM, Shahab Vahabzadeh
> > wrote:
> >
> > Hello Hello,
> > Can anybody help me to find out IP Address Ranges of Akamai and
> Instagram?
> > I wanna do some optimizations on my cache side?
> > Thanks
>
> I do not know the difference between Akamai's corporate blocks and
> those used for caching. I also do not know the value of what you're
> trying to accomplish.



Insignificant. Dont waste any time on it. If you do have a corp question
ask peering@ to redirect.

Also read Patrick Gilmores response for color.

Best,

-M<

Re: Safe IPv4 Was: Re: premiumcolo.net IP address rental

[Martin Hannigan]

On Mon, Jan 9, 2017 at 2:34 PM, Robert Story  wrote:

> On Mon, 9 Jan 2017 13:40:23 -0500 Martin wrote:
> MH> 2. Apply for and receive a last /22 from RIPE. EVERYONE can do this.
>
> Not quite everyone. You have to be a RIPE NCC member, which not everyone
> can do.
>
> "Who can become a Local Internet Registry (LIR)/RIPE NCC member?
>
> Any organisation with a legally established office in the RIPE NCC
> service region can become a member of the RIPE NCC."
>
> https://www.ripe.net/manage-ips-and-asns/resource-management/faq/faq-ipv4-
> address-space
>
>
>

I'm not sure this applies to the situation we're discussing. For example, a
US based corporation can apply and will receive an allocation of a /22 from
the RIPE last /8. I believe they do become an LIR. That does not require an
EU subsidiary or physical office. This is "good" for a variety of reasons
including providing for need and rushing towards exhaustion. This isn't
surreptitious. It is within policy.


Best,

-M<

Re: Safe IPv4 Was: Re: premiumcolo.net IP address rental

[Martin Hannigan]

On Mon, Jan 9, 2017 at 2:35 PM, Aaron  wrote:

> The emails I've seen are looking to rent FROM us, not TO us. I've received
> an email to every one of our ARIN POCs so I assumed they were scraping
> whois data and marked it all as spam.
>
> Aaron
>
>


If you did have excess v4 space, IMHO you'd be better off selling
purchase/transfer first right of refusal over the risk of rental and
scorched earth. YMMV here, zero experience in rentals, but I can imagine.

Cheers,

-M<

Safe IPv4 Was: Re: premiumcolo.net IP address rental

[Martin Hannigan]

On Mon, Jan 9, 2017 at 11:20 AM, Matt Freitag  wrote:

> Joel,
>
> I can't speak to "premiumcolo.net"
>

Neither can I, but that may not mean much. Perhaps someone else can
validate that they're reputable and can execute a transaction end to end?

If you need IPv4 addresses for your network:

1. Make sure you have an IPV6 allocation from your favorite RIR and are
using it
2. Apply for and receive a last /22 from RIPE. EVERYONE can do this.
3. Contact a reputable broker.

The ones I have experience with (Alphabetical):

A. Peter Thimmesch at Addrex http://www.addrex.net
B. Amy Cooper at Hilco Streambank http://www.ipv4auctions.com/
C. Mike Burns at http://www.IPTrading.com

ARIN also publishes a list (which is not a requirement to be able to
transact or support transfers):


https://www.arin.net/resources/transfer_listing/facilitator_list.html

Network operators have many choices for answering their IP numbering needs
these days. Including IPv6.

Sorry to be a broken record on this topic, but it seems to come up a lot.
And if you search the archives I'll suspect you'll find something similar
to this a few time now.

An educated network operator is the best kind. That's why we are here.

YMMV and Best,

-M<

Re: Google Global Cache Contact

[Martin Hannigan]

Jason,

In case you haven't already heard from the good people at Google:

   http://bit.ly/2hTJOhX

Best,

-M<


On Mon, Dec 19, 2016 at 4:15 PM, Jason Rokeach  wrote:
> Hi folks, could a contact for GGC contact me off-list?
>
> Thank you!
> - Jason R. Rokeach

Re: Softlayer abuse contact

[Martin Hannigan]

[ Has been coming up a lot lately. A public response may be useful, YMMV  ]

After abuse@, which many still do answer, I try the SOA (which is
really old fashioned I guess) if I don't get an answer from abuse@

;; ANSWER SECTION:
softlayer.com.900INSOAns1.softlayer.net.
root.softlayer.com. 2016101401 7200 600 1728000 43200

More and more blocking cases these days are also related to IP
reputation and malware infections. I'm not aware of any self service
capabilities for at least confirmation. Once you're spotted, many
application layer firewalls refuse to service your requests e.g.
webserver claiming "not allowed".

Softlayer was also acquired by IBM. Could try their SOA:

;; ANSWER SECTION:
ibm.com.86400INSOAasia3.akam.net.
hostmaster.akamai.com. 1480273175 43200 7200 604800 3600

[ I'd go with whoever owns the IP address space you are trying to
reach regardless of a packet filter or application filter ]

WHOIS queries on the domain occasionally point to someone with clue.

Registry Registrant ID:
Registrant Name: Domain Administrator
Registrant Organization: Softlayer Technologies, Inc.
Registrant Street: 4849 Alpha Road
Registrant City: Dallas
Registrant State/Province: TX
Registrant Postal Code: 75244
Registrant Country: US
Registrant Phone:  (look it up, it's there )
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: XX

In the last few years, and when near the end of the road, the
twittersphere has proven an awesome mechanism to reach out and touch
someone. I've had 100% success there.

If you have a peering relationship, IMHO opinion it is fair game to
try them if all else fails. Most peering teams are super happy to help
get you to the right people and especially if you've tried. Helping
someone solve a problem via peering relationships has always brought a
smile to my face and made that five o'clock beer taste even better.
Good luck!

Cheers,

-M<

On Mon, Nov 28, 2016 at 8:13 AM, Brian Ellwood via NANOG
 wrote:
> Could someone with Softlayer abuse contact me off list?
>
>  I have a netblock that cannot communicate with your network - emailed
> abuse@ about 2 weeks ago and didn't hear back.
>
>  Thank you.
>
>

Re: Death of the Internet, Film at 11

[Martin Hannigan]

> On Oct 23, 2016, at 16:26, b...@theworld.com wrote:
> 
> 
> I'm not sure who you mean when you say "people". My reference was to
> manufacturers of IoT devices only.

The users are not going to be able to help. You're right, it's all about the 
manufacturers. If you can remove or reduce profits enough where it matters, it 
will help tremendously. 

I spent an hour looking through the IEEE standards RA pattern searching mac 
addrs thinking about mitigation techniques and doing random lookups of the 
registrants.

These attacks are the canary in the coal mine in terms of what is probably 
coming.

Best,

-M<

Re: ARIN legacy block transfer process

[Martin Hannigan]

On Sun, Oct 2, 2016 at 10:56 PM, John Curran  wrote:
> On 30 Sep 2016, at 12:49 PM, Bryan Fields  wrote:
>>

[ clip ]

>
>> I'm thinking of referring both parties to an experienced broker as well.
>
> That certainly works - there is a list of several brokers available here
> 
> and many of them are very experienced in facilitating transfers under
> a wide variety of circumstances.

Morning NANOG'ers;

Disclaimer: Get IPv6. Deploy it. Avoid cost. With that said...

The theme of the thread is that brokers can be useful. I'd argue they
are almost imperative for those wishing to be completely informed. I'm
not criticizing, but I'd be careful to understand that along with
using the STLS (as well as making transfers) comes additional
sacrifice of rights and assumption of liabilities.

  https://www.arin.net/resources/transfer_listing/tos.pdf

That list also missing at least one significant company:

 ADDREX http://www.addrex.net/ -

My personal list of go-to brokers is for questions like asset
disposition, acquisition, transfers and the conversation above
(alphabetically):

Addrex
Hilco
IP Trading

Hope this is helpful.

YMMV, and best,

-M<

Re: CDN Overload?

[Martin Hannigan]

Mike,

I have the right contact there and I'll flag this thread that way in
case they havent already  seen it.

Best,

Martin Hannigan
AS 20940 // AS 32787



On Thursday, September 22, 2016, Mike Hammett <na...@ics-il.net> wrote:

> Do we have any contacts at Microsoft that we can talk to about this? This
> time around, they are the common denominator. I know people have been
> complaining about this for longer than Windows 10 has been out, so there
> must be some other reasons why other parties we are to blame.
>
> -Mike HammettIntelligent Computing SolutionsMidwest Internet
> ExchangeThe Brothers WISP
>
> - Original Message -
> From: Bruce Curtis <bruce.cur...@ndsu.edu <javascript:;>>
> To: Mike Hammett <na...@ics-il.net <javascript:;>>
> Cc: Martin Hannigan <hanni...@gmail.com <javascript:;>>, NANOG <
> nanog@nanog.org <javascript:;>>
> Sent: Thu, 22 Sep 2016 16:28:17 -0500 (CDT)
> Subject: Re: CDN Overload?
>
>
>   I have seen traffic from Microsoft in Europe to single hosts on our
> campus that seemed to be unusually (high bps) and long.
>
>   I don’t recall if the few multiple hosts I noticed this on over time
> were only on our campus wifi.
>
>   If not perhaps the common factor is longer latency?  Both connects over
> wireless and connections from Europe to the US would have longer latency.
>
>   Perhaps this longer latency combined with some other factor is
> triggering a but in modern TCP Congestion Control algorithms?
>
>
>
> This mentions that there have been bugs in TCP Congestion Control
> algorithm implementations.   Perhaps there could be other bugs that result
> in the descried issue?
>
> https://www.microsoft.com/en-us/research/wp-content/
> uploads/2016/08/ms_feb07_eval.ppt.pdf
>
>
> I have seen cases on our campus where too small buffers on an ethernet
> switch caused a Linux TCP Congestion Control algorithm to act badly
> resulting in slower downloads than a simple algorithm that depended on
> dropped packets rather than trying to determine window sizes etc.  The fix
> in that case was to increase the buffer size.  Of course buffer bloat is
> also known to play havoc with TCP Congestion Control algorithms.  Just
> wondering if some combination of higher latency and another unknown
> variable or just a bug might cause a TCP Congestion Control algorithm to
> think it can safely try to increase the transmit rate?
>
>
> > On Sep 21, 2016, at 8:29 PM, Mike Hammett <na...@ics-il.net
> <javascript:;>> wrote:
> >
> > Thanks Marty. I have only experienced this on my network once and it was
> directly with Microsoft, so I haven't done much until a couple days ago
> when I started this campaign. I don't know if anyone else has brought this
> to anyone's attention. I just sent an e-mail to Owen when I saw yours.
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> >
> > Midwest Internet Exchange
> >
> > The Brothers WISP
> >
> > - Original Message -
> >
> > From: "Martin Hannigan" <hanni...@gmail.com <javascript:;>>
> > To: "Mike Hammett" <na...@ics-il.net <javascript:;>>
> > Cc: "NANOG" <nanog@nanog.org <javascript:;>>
> > Sent: Wednesday, September 21, 2016 8:19:35 PM
> > Subject: Re: CDN Overload?
> >
> >
> >
> >
> >
> > Mike,
> >
> >
> > I will forward to the requisite group for a look. Have you brought this
> to our attention previously? I don't see anything. If you did, please
> forward me the ticket numbers or message(s) (peering@ is best) so wee can
> track down and see if someone already has it in queue.
> >
> >
> > Jared alluded to fasttcp a few emails ago. Astute man.
> >
> >
> > Best,
> >
> >
> > Martin Hannigan
> > AS 20940 // AS 32787
> >
> >
> >
> >
> >
> > On Sep 21, 2016, at 14:30, Mike Hammett < na...@ics-il.net
> <javascript:;> > wrote:
> >
> >
> >
> >
> > https://docs.google.com/spreadsheets/d/1Jdm0dOBf81kSnXEvVfI6ZJbWFNt5A
> bYUV8CDxGwLSm8/edit?usp=sharing
> >
> > I have made the anonymized answers public. This will obviously have some
> bias to it given that I mostly know fixed wireless operators, but I'm
> hoping this gets some good distribution to catch more platforms.
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> >
> > Midwest Internet Exchange
> >
> > The Brothers WISP
> >
> &

Re: CDN Overload?

[Martin Hannigan]

No problem.

If you can drop a pcap file somewhere we can reach (and drop me an email where) 
that was created during the event that'd be great.

Thanks again, and great use of the list. 

Best,

Martin Hannigan
AS 20940 // AS 32787


> On Sep 21, 2016, at 15:29, Mike Hammett <na...@ics-il.net> wrote:
> 
> Thanks Marty. I have only experienced this on my network once and it was 
> directly with Microsoft, so I haven't done much until a couple days ago when 
> I started this campaign. I don't know if anyone else has brought this to 
> anyone's attention. I just sent an e-mail to Owen when I saw yours.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP
> 
> From: "Martin Hannigan" <hanni...@gmail.com>
> To: "Mike Hammett" <na...@ics-il.net>
> Cc: "NANOG" <nanog@nanog.org>
> Sent: Wednesday, September 21, 2016 8:19:35 PM
> Subject: Re: CDN Overload?
> 
> 
> Mike,
> 
> I will forward to the requisite group for a look. Have you brought this to 
> our attention previously? I don't see anything. If you did, please forward me 
> the ticket numbers or message(s) (peering@ is best) so wee can track down and 
> see if someone already has it in queue.
> 
> Jared alluded to fasttcp a few emails ago. Astute man.
> 
> Best,
> 
> Martin Hannigan 
> AS 20940 // AS 32787
> 
> 
> 
> On Sep 21, 2016, at 14:30, Mike Hammett <na...@ics-il.net> wrote:
> 
> https://docs.google.com/spreadsheets/d/1Jdm0dOBf81kSnXEvVfI6ZJbWFNt5AbYUV8CDxGwLSm8/edit?usp=sharing
>  
> 
> I have made the anonymized answers public. This will obviously have some bias 
> to it given that I mostly know fixed wireless operators, but I'm hoping this 
> gets some good distribution to catch more platforms. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Mike Hammett" <na...@ics-il.net> 
> To: "NANOG" <nanog@nanog.org> 
> Sent: Wednesday, September 21, 2016 9:08:55 AM 
> Subject: Re: CDN Overload? 
> 
> https://goo.gl/forms/LvgFRsMdNdI8E9HF3 
> 
> I have made this into a Google Form to make it easier to track compared to 
> randomly formatted responses on multiple mailing lists, Facebook Groups, etc. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message - 
> 
> From: "Mike Hammett" <na...@ics-il.net> 
> To: "NANOG" <nanog@nanog.org> 
> Sent: Monday, September 19, 2016 12:34:48 PM 
> Subject: CDN Overload? 
> 
> 
> I participate on a few other mailing lists focused on eyeball networks. For a 
> couple years I've been hearing complaints from this CDN or that CDN was 
> behaving badly. It's been severely ramping up the past few months. There have 
> been some wild allegations, but I would like to develop a bit more 
> standardized evidence collection. Initially LimeLight was the only culprit, 
> but recently it has been Microsoft as well. I'm not sure if there have been 
> any others. 
> 
> The principal complaint is that upstream of whatever is doing the rate 
> limiting for a given customer there is significantly more capacity being 
> utilized than the customer has purchased. This could happen briefly as TCP 
> adjusts to the capacity limitation, but in some situations this has persisted 
> for days at a time. I'll list out a few situations as best as I can recall 
> them. Some of these may even be merges of a couple situations. The point is 
> to show the general issue and develop a better process for collecting what 
> exactly is happening at the time and how to address it. 
> 
> One situation had approximately 45 megabit/s of capacity being used up by a 
> customer that had a 1.5 megabit/s plan. All other traffic normally held 
> itself within the 1.5 megabit/s, but this particular CDN sent excessively 
> more for extended periods of time. 
> 
> An often occurrence has someone with a single digit megabit/s limitation 
> consuming 2x - 3x more than their plan on the other side of the rate limiter. 
> 
> Last month on my own network I saw someone with 2x - 3x being consumed 
> upstream and they had *190* connections downloading said data from Microsoft. 
> 
> The past week or two I've been hearing of people only having a single 
> connection downloading at more than their plan rate. 
> 
> 
> These situations effectively shut out all other Internet traffic to that 
> 

Re: CDN Overload?

[Martin Hannigan]

Mike,

I will forward to the requisite group for a look. Have you brought this to our 
attention previously? I don't see anything. If you did, please forward me the 
ticket numbers or message(s) (peering@ is best) so wee can track down and see 
if someone already has it in queue.

Jared alluded to fasttcp a few emails ago. Astute man.

Best,

Martin Hannigan 
AS 20940 // AS 32787



> On Sep 21, 2016, at 14:30, Mike Hammett <na...@ics-il.net> wrote:
> 
> https://docs.google.com/spreadsheets/d/1Jdm0dOBf81kSnXEvVfI6ZJbWFNt5AbYUV8CDxGwLSm8/edit?usp=sharing
>  
> 
> I have made the anonymized answers public. This will obviously have some bias 
> to it given that I mostly know fixed wireless operators, but I'm hoping this 
> gets some good distribution to catch more platforms. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Mike Hammett" <na...@ics-il.net> 
> To: "NANOG" <nanog@nanog.org> 
> Sent: Wednesday, September 21, 2016 9:08:55 AM 
> Subject: Re: CDN Overload? 
> 
> https://goo.gl/forms/LvgFRsMdNdI8E9HF3 
> 
> I have made this into a Google Form to make it easier to track compared to 
> randomly formatted responses on multiple mailing lists, Facebook Groups, etc. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message - 
> 
> From: "Mike Hammett" <na...@ics-il.net> 
> To: "NANOG" <nanog@nanog.org> 
> Sent: Monday, September 19, 2016 12:34:48 PM 
> Subject: CDN Overload? 
> 
> 
> I participate on a few other mailing lists focused on eyeball networks. For a 
> couple years I've been hearing complaints from this CDN or that CDN was 
> behaving badly. It's been severely ramping up the past few months. There have 
> been some wild allegations, but I would like to develop a bit more 
> standardized evidence collection. Initially LimeLight was the only culprit, 
> but recently it has been Microsoft as well. I'm not sure if there have been 
> any others. 
> 
> The principal complaint is that upstream of whatever is doing the rate 
> limiting for a given customer there is significantly more capacity being 
> utilized than the customer has purchased. This could happen briefly as TCP 
> adjusts to the capacity limitation, but in some situations this has persisted 
> for days at a time. I'll list out a few situations as best as I can recall 
> them. Some of these may even be merges of a couple situations. The point is 
> to show the general issue and develop a better process for collecting what 
> exactly is happening at the time and how to address it. 
> 
> One situation had approximately 45 megabit/s of capacity being used up by a 
> customer that had a 1.5 megabit/s plan. All other traffic normally held 
> itself within the 1.5 megabit/s, but this particular CDN sent excessively 
> more for extended periods of time. 
> 
> An often occurrence has someone with a single digit megabit/s limitation 
> consuming 2x - 3x more than their plan on the other side of the rate limiter. 
> 
> Last month on my own network I saw someone with 2x - 3x being consumed 
> upstream and they had *190* connections downloading said data from Microsoft. 
> 
> The past week or two I've been hearing of people only having a single 
> connection downloading at more than their plan rate. 
> 
> 
> These situations effectively shut out all other Internet traffic to that 
> customer or even portion of the network for low capacity NLOS areas. It's a 
> DoS caused by downloads. What happened to the days of MS BITS and you didn't 
> even notice the download happening? A lot of these guys think that the CDNs 
> are just a pile of dicks looking to ruin everyone's day and I'm certain that 
> there are at least a couple people at each CDN that aren't that way. ;-) 
> 
> 
> 
> 
> Lots of rambling, sure. What do I need to have these guys collect as evidence 
> of a problem and who should they send it to? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> 
> 

Re: Akamai Edgescape query

[Martin Hannigan]

I do?

Drop us a note with your request to peer...@akamai.com and we're happy
to see if we can  accommodate.


Best,

-M<

AS 20940 / AS 32787



On Tue, Sep 13, 2016 at 3:42 AM, Janusz Jezowicz
 wrote:
> Hello,
>
> We are doing some network research to various cloud/CDNs and we need to run
> few tests on Akamai Edgescape. Does anyone has access to run few queries to
> geo-locate IPs using Edgescape for us?
>
> We don't have Akamai contract and it would take us lot of time (and money)
> to get one just to run few tests.
>
> Many thanks for any help!
>
> Janusz Jezowicz
> *Speedchecker Ltd*
> *email*: jan...@speedchecker.xyz
> *skype*: jezowicz
> *phone*: +442032863573
> *web*: www.speedchecker.xyz
> The Black Church, St. Mary’s Place, Dublin 7, D07 P4AX, Ireland

Re: IPv4 Broker

[Martin Hannigan]

Hi Lorenzo,

You can obtain a last /22 from the RIPE region as long as you comply
with their policy, yes, even if you are "in" the United States.

   http://bit.ly/RIPE22-20160831

That reduces your need and spend, unless you already received it.

Then use the link Marco posted. It's a good list.

And reference the archives as Cameron noted.


Best Regards,

-M<



On Tue, Aug 30, 2016 at 11:43 AM, Lorenzo Mainardi
 wrote:
> Do you know any good IPv4 broker?
> I need a /20.
> Regards
>
>
>

Question re: Routing Table Report Was: Re: [pacnog] Weekly Routing Table Report

[Martin Hannigan]

Phillip, Geoff, et. al.

[ trimmed dist, please feel free to expand if you think it's proper ]


On Fri, Aug 19, 2016 at 2:01 PM, Routing Analysis Role Account
 wrote:

>
> Advertised Unallocated Addresses
> 
>
> NetworkOrigin AS  Description
> 23.249.144.0/20  40430 COLO4JAX-AS - colo4jax, LLC, US
> 27.100.7.0/2456096 UNKNOWN
> 41.73.1.0/24 37004 -Reserved AS-, ZZ
> 41.73.2.0/24 37004 -Reserved AS-, ZZ
> 41.73.3.0/24 37004 -Reserved AS-, ZZ
> 41.73.4.0/24 37004 -Reserved AS-, ZZ
> 41.73.5.0/24 37004 -Reserved AS-, ZZ
> 41.73.6.0/24 37004 -Reserved AS-, ZZ
> 41.73.7.0/24 37004 -Reserved AS-, ZZ
> 41.73.8.0/24 37004 -Reserved AS-, ZZ
>
> Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA
>

i regularly check the report for references to 20940 and I was digging
in to these a bit and I noticed something odd:

Comment:AfriNIC - http://www.afrinic.net
Comment:The African & Indian Ocean Internet Registry
Ref:https://whois.arin.net/rest/org/AFRINIC
ReferralServer:  whois://whois.afrinic.net
ResourceLink:  http://afrinic.net/en/services/whois-query

OrgAbuseHandle: GENER11-ARIN <
OrgAbuseName:   Generic POC
OrgAbusePhone:  +230 416
OrgAbuseEmail:  abuse...@afrinic.net
OrgAbuseRef:https://whois.arin.net/rest/poc/GENER11-ARIN <---

I followed OrgAbuseRef to ARIN and got this:

"Do not use this information to contact AfriNIC for registration or
business purposes."


This registry record is confusing. Can you explain? Sorry, I must've
have missed this class in Registry 101.


Appreciated, and thanks!

-M<

Re: Best practices for tracking intra-facility crossconnects

[Martin Hannigan]

On Mon, Aug 8, 2016 at 1:14 PM, Eric Kuhnke  wrote:
> Hey all,
>
> I am looking to see what the community's experience has been with different
> types of labeling systems and XC tracking systems for intra-facility
> crossconnects.
>

I haven't used these in a long time, but here are a few example cable
run lists that can be modified to your hearts content:

  http://bit.ly/CRL2016

I found the format useful to create implementation detail and generate
labels. It was easy to pay the data forward and reverse afterwards.
Exported data should be loaded into a management system. It could also
work in reverse, but being able to have dynamic documentation to end
with as-builts is generally a win.

> In addition to the standard practice of labeling every fiber at both ends,
> if you're using a system that wraps a cable marker around the cable every 3
> ft/1 meter, what type of system are you using to track XCs?
>

Greybar or Anixter-like supply houses can sell you/your vendor striped
fiber optic bundles. It's an additional expense, but it's not entirely
ugly. The last deployment I worked on with respect to a fiber
interconnect system IIRC we asked the electricians to wrap a loop
every N' using different colored electrical tape for the A and B runs.
That worked too.

> If you have implemented a standards-based system with some type of GUID for
> every cable, and a unique per-cable tracking system that is utilized with a
> ticketing system for each distinct cable (whether -48VDC, fiber, cat5e,
> alarm wire, whatever), what did you have to customize for your needs?
>

I don't have any advice other than don't over think it. If a text file
or excel spreadsheet works; embrace it.

Best,

-M<

Re: Advertising rented IPv4 prefix from a different ASN.

[Martin Hannigan]

On Thu, Aug 4, 2016 at 3:39 PM, Andrew  wrote:
> Hello List,
>

[ clip, plenty of advice on these points ]


> I feel if we just adverse the prefix it get put on a bogon list for prefix
> hijacking.  This space is rented long term but they are not interested in
> reassigning the space to us.  They also want to keep advertising their
> prefix as one contiguous block.


You will also likely need a letter of authorization from the network
lending you their space for your upstreams or others.

Here's a usable template that you can customize for your own purposes.
Hope this helps:

   http://bit.ly/LOA-0805201601

Caveats, IPv6? Be sure to consult with lawyers, comply with your
favorite RIR policy and compare the cost of "renting" to "leasing" or
acquiring on the open market. There are a number of sources to acquire
IPv4 address space easily found using your favorite search engine.

You may be also be eligible for a last /22 allocation from RIPE if you
qualify under their current policy. See http://bit.ly/LASTCALL-22 for
further information.

Best Regards,

-M<

Re: Akamai IPv6 contact needed

[Martin Hannigan]

Thanks! We'll reach out to you offline shortly. You can also always
reach us for peering, v6, or AS specific issues at n...@akamai.com

Best Regards,

Martin Hannigan AS 209040 / AS 32787


On Mon, Jul 25, 2016 at 4:35 AM, Yang Yu <yang.yu.l...@gmail.com> wrote:
> Some servers are not serving content over IPv6 HTTPS. It fails in such
> a way that most applications can't fall back to IPv4. tcp/443 is open
> but RST as soon as client sends TLS 1.2 client hello. It has been this
> way for 24+ hours.
>
>>>>
> $ telnet 2600:1404:18::17d7:fbc 443
> Trying 2600:1404:18::17d7:fbc...
> Connected to 2600:1404:18::17d7:fbc.
> Escape character is '^]'.
>
> Connection closed by foreign host
>
>>
> ncat -6 --ssl -v 2600:1404:18::17d7:fac 443
> Ncat: Version 7.00SVN ( https://nmap.org/ncat )
> Ncat: Input/output error.
>
>
>>>>
> www.apple.com.  681 IN  CNAME   www.apple.com.edgekey.net.
> www.apple.com.edgekey.net. 11306 IN CNAME
> www.apple.com.edgekey.net.globalredir.akadns.net.
> www.apple.com.edgekey.net.globalredir.akadns.net. 1664 IN CNAME
> e6858.dscc.akamaiedge.net.
> e6858.dscc.akamaiedge.net. 5IN  2600:1404:18::17d7:fac
> e6858.dscc.akamaiedge.net. 5IN  2600:1404:18::17d7:fbc
>
>>
> 2600:1404:18::17d7:0/112 serves www.apple.com, download.microsoft.com etc.
>
>
>>>> HTTP does work
> $ wget http://www.apple.com
> --2016-07-25 03:09:17--  http://www.apple.com/
> Resolving www.apple.com (www.apple.com)... 2600:1404:18::17d7:fbc,
> 2600:1404:18::17d7:fac, 23.11.55.206
> Connecting to www.apple.com
> (www.apple.com)|2600:1404:18::17d7:fbc|:80... connected.
> HTTP request sent, awaiting response... 200 OK
>
>>>>
> $ dig whoami.akamai.com +short
> whoami.akamai.net.
> 72.183.81.39
>
>
> Thanks.
>
>
> Yang

Re: [apops] BGP Update Report

[Martin Hannigan]

On Fri, Jul 15, 2016 at 6:00 PM,   wrote:

> 15 - 104.111.200.0/21   6948  0.2%   AS16625 -- AKAMAI-AS - Akamai 
> Technologies, Inc., US
>  AS20940 -- AKAMAI-ASN1 , US


This has been addressed. Appreciated Potaroo Team.


Best,

-M<

Re: akamai abnormal spike

[Martin Hannigan]

On Wed, Jul 13, 2016 at 5:37 PM, eric c <xcell...@gmail.com> wrote:
> Good afternoon,
>
> Has anyone notice any abnormal spike in Akamai trafic in the last 24-48
> hours compared to other days. I know it was black tuesday yesterday but
> traffic from last month didn't even come close to what we saw from Akamai.
>
> We have some caching servers and even notice a spike to them as well.


Hi Eric,

There were two major software updates that spanned Tuesday and
Wednesday which are responsible for the increase you saw.

Best,

Martin Hannigan / AS 20940 / AS 32787

Re: IX in Iran by TIC

[Martin Hannigan]

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

IXP economics Was: Re: NANOG67 - Tipping point of community and sponsor bashing?

[Martin Hannigan]

Well. Its complicated. I think this is far more political than about COGS.
But hey. Why not?

I agree with Dave. Shocking. I know. At least the context. He's right.
Thanks for reminding us. We know these things. We'll have to see how IXP
communities react now. Perhaps espresso service will be defined as good
outreach? If it is, thats certainly up to them.

Btw, have you thanked your local US branded euro IXP? They created market
pressures that saved many of us a Brinks truck full of cash by increasing
competitiveness. A lot of us owe them thanks and support for doing
good.  If you do, grab Job, John, Henk, Pauline, Arnold or Andreas and give
them a big COGS crushing hug. Go easy on Pauline, less crush please.

Best,

Marty

On Thursday, June 16, 2016, Zbyněk Pospíchal  wrote:

> Dne 16.06.16 v 17:17 Niels Bakker napsal(a):
> > * zby...@dialtelecom.cz  (Zbyněk Pospíchal) [Thu 16 Jun
> 2016, 14:23 CEST]:
>
> >> Are you sure they still want them if they have to pay for these
> >> features separately?
> >>
> >> Currently, such luxury functions are increasing costs also for
> >> networks who don't need/want it.
> >
> > sFlow statistics isn't a luxury function.
>
> Anything more than plain L2 in an IXP is a kind of luxury. An IXP member
> with it's own flow collection (or at least mac accounting) can feel they
> don't need sFlow statistics in an exchange. It's also proven it's
> possible to run an IXP, including a big one, without sFlow stats.
>
> We can say the same about route servers, SLA, customer portals etc. (ok,
> remote peering is a different case).
>
> If IXP members think they have to pay such functionality in their port
> fees, ok, it's their own decision, but member's opinion "we don't need
> it and we don't want to pay for it" is rational and plausible.
>
> Best Regards,
> Zbynek
>

Re: NANOG67 - Tipping point of community and sponsor bashing?

[Martin Hannigan]

> On Jun 16, 2016, at 01:12, Leslie <geekg...@gmail.com> wrote:
> 
>> On Wed, Jun 15, 2016 at 8:41 PM, Martin  Hannigan <hanni...@gmail.com> wrote:
> 
>> SFMIX is great. But poorly distributed. We should support their efforts, but 
>> how many IXPs do we need in the Bay area? AMS-IX Bay Area is creating a 
>> market along with SFMIX.
> 
> SFMIX is in 5 physical locations(
> https://www.sfmix.org/connect/locations ) and is always open to
> talking to other providers about extending into their datacenter. So
> I'd say we're in a variety of locations! We've also just celebrated
> our 10 year anniversary :)
> 
> Leslie

Agreed. Extended XC?

Best,

-M<

Re: NANOG67 - Tipping point of community and sponsor bashing?

[Martin Hannigan]

> On Jun 15, 2016, at 22:24, Ca By  wrote:
> 
>> On Wednesday, June 15, 2016, Seth Mattinen  wrote:
>> 
>>> On 6/15/16 4:03 PM, Bill Woodcock wrote:
>>> 

[ clip ]


> 
> I also like sfmix and fl-ix.

FL-IX is great. It created real competition in the American South and for the 
Americas peering. I kept my interconnections to VZ while we see what happens 
when Zayo needs to recover their costs for the panel they're using to drain 
NOTA. There will be a day of reckoning, free is never free.  Its a good hedge. 

SFMIX is great. But poorly distributed. We should support their efforts, but 
how many IXPs do we need in the Bay area? AMS-IX Bay Area is creating a market 
along with SFMIX. 

There is still copious amounts of traffic at VZ NOTA MIA. Two in a market works 
well IMHO. 

Best,

-M<

Re: Akamai GeoIP

[Martin Hannigan]

On Fri, Jun 10, 2016 at 2:54 PM, Josh Reynolds  wrote:
> Can somebody from Akamai contact me offlist about a GeoIP location
> change for a block please?
>
> Thank you.


You can always mail n...@akamai.com or peer...@akamai.com for this
type of request and we'll help get it to the right place.

I'll go ahead and reach out to you from my work address to get it started.

Best Regards,

-M< / AS 20940 / AS 32787

Re: CALEA

[Martin Hannigan]

Misfire. Sorry, early in the AM. The URL I intended to send is here:

http://www.uscourts.gov/statistics-reports/wiretap-report-2014


Best,

-M<

On Tue, May 31, 2016 at 9:10 AM, Martin Hannigan <hanni...@gmail.com> wrote:
> CALEA isn't a type of request, it's a law that enabled par function
> access for LEO's e.g. "the ladder" pin register, trap+trace, DTMF
> translation, three-way/off hook ops and the call content (not
> necessarily in that order).
>
> You can see the non national security activity here:
>
>
> On Sat, May 28, 2016 at 5:37 AM, Mike Joseph <m...@doze.net> wrote:
>> I can say via firsthand knowledge that CALEA requests are definitely
>> happening and are not even that rare, proportional to a reasonably sized
>> subscriber-base.  It would be unlawful for me to comment specifically on
>> any actual CALEA requests, however.  But if you have general questions
>> about my observations, feel free to reach out directly.
>>
>> -MJ
>>
>> On Thu, May 12, 2016 at 11:28 AM, Brian Mengel <bmen...@gmail.com> wrote:
>>
>>> My comments were strictly limited to my understanding of CALEA as it
>>> applied to ISPs, not telcos.  A request for a lawful intercept can entail
>>> mirroring a real time stream of all data sent to/from a customer's Internet
>>> connection (cable modem/DSL/dedicated Ethernet) to a LEA.  AFAIK this
>>> requires mediation before being sent to the LEA and it is the mediation
>>> server itself that initiates the intercept when so configured by the ISP.
>>> Perhaps some LEAs have undertaken the mediation function so as to
>>> facilitate these intercepts where the neither the ISP nor a third party can
>>> do so.  If that were the case then very little would be needed on the part
>>> of the ISP in order to comply with a request for lawful intercept.  I can
>>> say with certainty that these types of requests are being made of broadband
>>> ISPs though I agree that they are very rare.
>>>
>>> On Wed, May 11, 2016 at 2:58 PM, Ricky Beam <jfb...@gmail.com> wrote:
>>>
>>> > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel <bmen...@gmail.com>
>>> > wrote:
>>> >
>>> > AFAIK being able to do a lawful intercept on a specific, named,
>>> >> individual's service has been a requirement for providers since 2007.
>>> >>
>>> >
>>> > It's been required for longer than that. The telco I worked for over a
>>> > decade ago didn't build the infrastructure until the FCC said they were
>>> > going to stop funding upgrades. That really got 'em movin'. (suddenly
>>> "data
>>> > services" people -- i.e. ME -- weren't redheaded stepchildren.)
>>> >
>>> > have never heard of a provider, big or small, being called out for being
>>> >> unable to provide this service when requested.
>>> >>
>>> >
>>> > Where existing infrastructure is not already in place (read:
>>> T1/BRI/etc.),
>>> > the telco can take up to 60 days to get that setup. I know more than one
>>> > telco that used that grace period to actually setup CALEA in the first
>>> > place.
>>> >
>>> > did not perform intercepts routinely.
>>> >>
>>> >
>>> > The historic published figures (i've not looked in years) suggest CALEA
>>> > requests are statistically rare. The NC based telco I worked for had
>>> never
>>> > received an order in the then ~40yr life of the company.
>>> >
>>> > The mediation server needed to "mediate" between your customer
>>> aggregation
>>> >> box and the LEA is not inexpensive.
>>> >>
>>> >
>>> > And also is not the telco's problem. Mediation is done by the LEA or 3rd
>>> > party under contract to any number of agencies. For example, a telco tap
>>> > order would mirror the control and voice traffic of a POTS line (T1/PRI
>>> > channel, etc.) into a BRI or specific T1 channel. (dialup was later
>>> added,
>>> > but wasn't required in my era, so we didn't support it.) We used to test
>>> > that by tapping a tech's phone. Not having any mediation software, all I
>>> > could do is "yeap, it's sending data" and listen to the voice channels
>>> on a
>>> > t-berd.
>>> >
>>> > --Ricky
>>> >
>>>
>>>

Re: CALEA

[Martin Hannigan]

CALEA isn't a type of request, it's a law that enabled par function
access for LEO's e.g. "the ladder" pin register, trap+trace, DTMF
translation, three-way/off hook ops and the call content (not
necessarily in that order).

You can see the non national security activity here:


On Sat, May 28, 2016 at 5:37 AM, Mike Joseph  wrote:
> I can say via firsthand knowledge that CALEA requests are definitely
> happening and are not even that rare, proportional to a reasonably sized
> subscriber-base.  It would be unlawful for me to comment specifically on
> any actual CALEA requests, however.  But if you have general questions
> about my observations, feel free to reach out directly.
>
> -MJ
>
> On Thu, May 12, 2016 at 11:28 AM, Brian Mengel  wrote:
>
>> My comments were strictly limited to my understanding of CALEA as it
>> applied to ISPs, not telcos.  A request for a lawful intercept can entail
>> mirroring a real time stream of all data sent to/from a customer's Internet
>> connection (cable modem/DSL/dedicated Ethernet) to a LEA.  AFAIK this
>> requires mediation before being sent to the LEA and it is the mediation
>> server itself that initiates the intercept when so configured by the ISP.
>> Perhaps some LEAs have undertaken the mediation function so as to
>> facilitate these intercepts where the neither the ISP nor a third party can
>> do so.  If that were the case then very little would be needed on the part
>> of the ISP in order to comply with a request for lawful intercept.  I can
>> say with certainty that these types of requests are being made of broadband
>> ISPs though I agree that they are very rare.
>>
>> On Wed, May 11, 2016 at 2:58 PM, Ricky Beam  wrote:
>>
>> > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel 
>> > wrote:
>> >
>> > AFAIK being able to do a lawful intercept on a specific, named,
>> >> individual's service has been a requirement for providers since 2007.
>> >>
>> >
>> > It's been required for longer than that. The telco I worked for over a
>> > decade ago didn't build the infrastructure until the FCC said they were
>> > going to stop funding upgrades. That really got 'em movin'. (suddenly
>> "data
>> > services" people -- i.e. ME -- weren't redheaded stepchildren.)
>> >
>> > have never heard of a provider, big or small, being called out for being
>> >> unable to provide this service when requested.
>> >>
>> >
>> > Where existing infrastructure is not already in place (read:
>> T1/BRI/etc.),
>> > the telco can take up to 60 days to get that setup. I know more than one
>> > telco that used that grace period to actually setup CALEA in the first
>> > place.
>> >
>> > did not perform intercepts routinely.
>> >>
>> >
>> > The historic published figures (i've not looked in years) suggest CALEA
>> > requests are statistically rare. The NC based telco I worked for had
>> never
>> > received an order in the then ~40yr life of the company.
>> >
>> > The mediation server needed to "mediate" between your customer
>> aggregation
>> >> box and the LEA is not inexpensive.
>> >>
>> >
>> > And also is not the telco's problem. Mediation is done by the LEA or 3rd
>> > party under contract to any number of agencies. For example, a telco tap
>> > order would mirror the control and voice traffic of a POTS line (T1/PRI
>> > channel, etc.) into a BRI or specific T1 channel. (dialup was later
>> added,
>> > but wasn't required in my era, so we didn't support it.) We used to test
>> > that by tapping a tech's phone. Not having any mediation software, all I
>> > could do is "yeap, it's sending data" and listen to the voice channels
>> on a
>> > t-berd.
>> >
>> > --Ricky
>> >
>>
>>

Re: Best Source for ARIN Region /24

[Martin Hannigan]

There's an option that I forgot to mention:

You can still use an RIR and get a last /22 in the RIPE region provided you
follow their rules, and no, you do not have to be in Europe.

Read carefully:

 https://www.ripe.net/participate/policies/proposals/2013-03


Best,

-M<


On Mon, Jan 11, 2016 at 9:43 PM, Rafael Possamai 
wrote:

> Makes sense. In that case, I think only way out is to go through a broker
> to find a suitable party for a transfer. I would read the rules and
> regulations regarding transfer of ARIN blocks, they have some details and
> the process requires some paperwork.
>
>
> On Mon, Jan 11, 2016 at 8:35 PM, Matthew D. Hardeman <
> mharde...@ipifony.com>
> wrote:
>
> > I’m aware of the /24 block for facilitation concept, but my client’s use
> > case can qualify as an end-user rather than as an ISP, thus their annual
> > operating cost is smaller than even the X-SMALL ISP category, which
> they’d
> > land in — if they opted for the smaller /36 initial IPv6 direct
> allocation,
> > rather than the default /32 direct allocation.
> >
> > That seems to balance toward buying an existing /24.
> >
> >
> > On Jan 11, 2016, at 8:00 PM, Rafael Possamai 
> > wrote:
> >
> > If you apply for an IPv6 block, as an ISP, and you have the intention of
> > truly utilizing it, then you can apply for a /24 to facilitate that
> > transition.
> >
> > It will cost you about $1500 or so, which is about half of what a /24 is
> > going for in the transfer market.
> >
> > Thing is, if you take the IPv6 block just to use the /24 they give you,
> > then one could argue you are cheating the system.
> >
> >
> >
> > On Mon, Jan 11, 2016 at 1:19 PM, Matthew D. Hardeman <
> > mharde...@ipifony.com> wrote:
> >
> >> I’m looking to buy a /24 of space for a new multi-homed network in the
> >> ARIN region.  Can anyone out there speak to going rates for a /24 and
> best
> >> places to shop?
> >>
> >>
> >
> >
>

Re: Best Source for ARIN Region /24

[Martin Hannigan]

If you aren't advised to at least analyze the potential to avoid buying and
using v6, you'd be getting bad advice. With that said:

For large blocks, >/16, you're going to want to work with a *reputable*
broker that understands how the market works. The two I am consistent in
pointing to are Addrex and Hilco Streambank. They seem to be both reputable
and knowledgeable. There are many others. You can speak with each  if
necessary and ask about experiences. Being registered with an RIR is not a
requirement to participate in the market as a broker.

For the smallish blocks, < /16, I'd point to the Hilco auction platform.
Appears to be able to process small transactions reliably and you can price
track with the public data. And it's automated.

There are pitfalls when acquiring IPv4 addresses, including whether you
want them to be assets or to be leases. The regions are treating legacy
addresses and transfers differently. V4 addresses are usable globally and
there are enough people here as well as broker knowledge to help you
navigate that as well. Brokers can guide you through these decisions and
which markets to acquire them in based on your needs and objectives, which
RIRs to work with and how to transfer addresses.

I've been recommending folks avoid transferring space from friends. Failed
transactions can be costly in many ways.

YMMV.

Best,

-M<



On Mon, Jan 11, 2016 at 3:16 PM, Shon Elliott 
wrote:

> I also am interested in where people are finding blocks of /22 or smaller
> just in case. We have some blocks from Level 3, but eventually, we're going
> to be out.
>
> That being said, we did get our IPv6 /32 allocation from ARIN. If anyone
> has any ideas on how to properly deploy this in an ISP environment, I'd
> love to learn. I've read some whitepapers on the subject, but most of those
> deal with enterprise based networks, and not so much as a service provider.
>
> Kind Regards,
> Shon Elliott, KK6TOO
> unWired Broadband, Inc.
> www.getunwired.com
>
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
> Sent: Monday, January 11, 2016 12:11 PM
> To: North American Network Operators' Group 
> Subject: Re: Best Source for ARIN Region /24
>
> Some expansions under my ISP hat may lead to needing some address space,
> so I'd be interested in where people are getting space from as well.
> Smaller blocks, though, /22 and smaller.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
> - Original Message -
>
> From: "Matthew D. Hardeman" 
> To: nanog@nanog.org
> Sent: Monday, January 11, 2016 1:19:00 PM
> Subject: Best Source for ARIN Region /24
>
> I’m looking to buy a /24 of space for a new multi-homed network in the
> ARIN region. Can anyone out there speak to going rates for a /24 and best
> places to shop?
>
>
>

Re: IPv4 subnets for lease?

[Martin Hannigan]

On Thu, Dec 17, 2015 at 9:31 PM, Nick Ellermann 
wrote:

> We have customers asking to lease IP space for BGP transit with us and
> other peers. But they are struggling to get at a minimum even a Class C,
> even though they have their own ASN. We don't have large amounts of free
> IPv4 space to lease out to a single customer in most cases anymore. Hope to
> at least introduce these customers to some contacts that may be able to
> help.
> Do we know of any reputable sources that are leasing or selling IPv4
> subnets as small as a /24 to satisfy their diversity needs? Thanks!
>
>

I'm going to stay focused on your question.

There are many methods to obtain additional IPv4 address space.

o You can still use an RIR and get a last /22 in the RIPE region provided
you follow their rules, and no, you do not have to be in Europe.

Read carefully:

 https://www.ripe.net/participate/policies/proposals/2013-03

o You can use a marketplace where buyers and sellers live in harmony to
conduct buy and sell (bid, offer) transactions. I find the folks at Addrex
very knowledgeable www.addrex.net

o You can use a auction site. The folks at Hilco Streambank seem to be able
to keep theirs running at www.ipv4auctions.com

The above are not endorsements. There are many others. Some are credible.
Some are interesting. YMMV.

This thread will now self-destruct.

Best,

-M<

Re: Prefix hijacking by AS20115

[Martin Hannigan]

Is this related to 104.73.161.0/24? That's ours. :-) 

We'll take a look and get back to you.  Thanks for caring! 

Best, 

Marty

> On Sep 28, 2015, at 23:08, Seth Mattinen  wrote:
> 
>> On 9/28/15 18:30, William Herrin wrote:
>>> On Mon, Sep 28, 2015 at 9:01 PM, Seth Mattinen  wrote:
>>> I've got a problem where AS20115 continues to announce prefixes after BGP
>>> neighbors were shutdown. They claim it's a wedged BGP process but aren't in
>>> any hurry to fix it outside of a maintenance window.
>> 
>> If they weren't lying to you, they'd fix it now. That's not the kind
>> of problem that waits.
>> 
>> Thing is: they lied to you. Long ago they "helpfully" programmed their
>> router to announce your route regardless of whether you sent a route
>> to them. They want to wait for a maintenance window to remove that
>> configuration.
>> 
>> 
>>> I'm at a loss of what else I can do. They admit the problem but won't take
>>> action saying it needs to wait for a maintenance window. Am I out of line
>>> insisting that's an unacceptable response to a problem that results in
>>> prefix/traffic hijacking?
>> 
>> Try dropping the link entirely. If they still announce your addresses,
>> bring it back up but report it as emergency down, escalate, and call
>> back every 10 minutes until the junior tech understands that it's time
>> to call and wake up the guy who makes the decision to fix it now.
> 
> 
> I'm at the tail end here almost 8 hours later since the hijacking started. 
> Their NOC is just blowing me off now and they're happy to continue the 
> hijacking until it's convenient for them to have a maintenance window. And 
> that's apparently the final decision.
> 
> ~Seth

Re: Data Center operations mail list?

[Martin Hannigan]

On Sun, Aug 16, 2015 at 3:22 PM, Chris Boyd cb...@gizmopartners.com wrote:


  On Aug 15, 2015, at 12:13 PM, Martin Hannigan hanni...@gmail.com
 wrote:
 
  There is reasonable demand for a forum.  It might need a little marketing
  to get a list with traction going.

 There seems to be some traction, with 268 members on the NADCOG list so
 far.



Great! It's a little more complicated than list member count. Consider a
social media presence as well? While the Facebook isn't designed as mailing
list or collaboration media, it sort of works communication wise. If there
were some service like /. for mailing lists (that I knew about) I would
really like the community thumbs up/thumbs down approach so you can sift
through quality vs. quantity. The quality issue has been discussed for
literally years.

Good luck and I just joined. Looking forward to it!

Best,

-M

Re: Data Center operations mail list?

[Martin Hannigan]

On Tue, Aug 11, 2015 at 3:27 PM, Simon Lockhart si...@slimey.org wrote:

 On Tue Aug 11, 2015 at 01:35:28pm -0400, Jay Ashworth wrote:
  Absolutely feel free to use it; I haven't seen a single message on it
 in...
  well, it was 3 years ago I was in datacenters regularly, so I'm goin with
  3 years.  :-)

 There's a message there now... :)

 Rather than fragmenting further, I'd suggest building up demand first on
 existing infrastructure. If it gets to the size of NANOG and needing a
 support organisation around it, then it can split off then...




A few of us have been operating and supporting a data center track at the
last 4 or 5 NANOG meetings. The sessions are well attended and the topics
are getting more interesting e.g. real estate, energy management and
interconnection focused.

There is reasonable demand for a forum.  It might need a little marketing
to get a list with traction going.

Best,

-M

OCP Data Center Spec: Ladder Tray

[Martin Hannigan]

Hi NANOG,

The Open Compute Project OCP had, at least that I can recall but now can
not find, a ladder tray deployment spec in the data center working group.
It called for tray to span the middle of the aisle as I remember it. Anyone
recall or have a pointer to it? My favorite search engine and the OCP wiki
yields nothing.

I was also hoping to find someone involved in the spec to discuss a related
NFPA issue with.

Best,

-M

Re: 'gray' market IPv4

[Martin Hannigan]

On Tue, Jul 14, 2015 at 10:22 AM, Matt Kelly mjke...@gmail.com wrote:

 This list is actual sale prices,
 http://www.ipv4auctions.com/previous_auctions/


 --
 Matt


 On July 14, 2015 at 10:14:05 AM, Justin Wilson - MTIN (li...@mtin.net)
 wrote:

 Thes folks (and I am not advertising or affiliated with them) publish a
 list of most recent transfer completed:

 http://ipv4marketgroup.com/broker-services/buy/


http://ipv4marketgroup.com/broker-services/buy/  vs.
http://www.ipv4auctions.com/previous_auctions/


If you compare the pricing that both have made available you will find one
is posting average prices exponentially higher than the other. When you
trend the granular auction site data the auction numbers demonstrate a
trend  would expect, that smaller prefixes are more expensive since it
takes a similar amount of effort to process a /24 as it does a /20. Dollar
differences between a  /24 unit and a /17 unit move the needle
significantly.

Based on both of both sets of public data its easy to conclude that
auctions will work for at least small buyers of space if they're
sophisticated enough to address the RIR issues. If you do decide to take
the simple broker approach (not all are simple and not all approaches are
suitable to simple brokers), use an RFP.  And Yelp. :-)

Best,

-M

Re: 'gray' market IPv4

[Martin Hannigan]

On Tue, Jul 14, 2015 at 9:48 AM, Hank Nussbacher h...@efes.iucc.ac.il
wrote:

 At 15:39 14/07/2015 +0200, Seth Mos wrote:

 We had the same thing finding a broker for a /24 pi in the RIPE region.
 Not all of the brokers have the size you want, eg a /20 when you need a /24.



 https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/brokers

 https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/listing

 https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers

 Enuff?



/personal opinion, self, etc.

Should we enter them all into Yelp and start rating? That's too many to
comparison shop. I'm being a little wry, I know who is naughty and nice.
I've been tracking them all since the beginning. Not everyone else has. The
potential for harm to network operators is moderate IMHO.

Best,

-M

Re: Akamai minimum prefix length issue

[Martin Hannigan]

Hi Patrick,

Correct answer. No surprise. And yes, netsupport-...@akamai.com is still
the way to go for these types of issues.

Thanks for the help!

Best,

-M  // AS 20940



On Wed, May 13, 2015 at 3:37 PM, Patrick W. Gilmore patr...@ianai.net
wrote:

 Akamai does not follow BGP perfectly, for many reasons, including BGP
 preferring crappy paths much of the time.

 ISPs should email netsupport-...@akamai.com to get help with traffic
 engineering, performance, and other questions. (Or at least that used to be
 the case a year ago.)

 --
 TTFN,
 patrick

  On May 13, 2015, at 15:33 , Chuck Church chuckchu...@gmail.com wrote:
 
  Anyone from Akamai (or who might know),
 
Having an issue with AS 20940 either not seeing or ignoring a /23
  we're announcing, and following a /22 to another path.  Other ISPs our
  upstream peers with see the /23.  I didn't see a looking glass for
 Akamai to
  verify.  Anyone from Akamai able to help?  Prefix in question is
  162.220.232.0/23.
 
  Thanks,
 
  Chuck